Filtering within a Circle not working as expected

4 posts, 1 answers
  1. Viktor
    Viktor avatar
    14 posts
    Member since:
    Dec 2011

    Posted 30 Aug Link to this post

    Hi guys,

    I have a content type (called Problems) that has a GeoPoint field called Location (what a surprise). I would like to filter Problems in radius from my current position.

    For this purpose I try using Filter within a circle based on documentation. This is my filter:

     

    { "Location": { "$within": { "$centerSphere": { "center": { "latitude": 42.68873679844848, "longitude": 23.321410417556763 }, "radiusInKilometers": 10 } } } }

     

    So, I set the center to { "latitude": 42.68873679844848, "longitude": 23.321410417556763 } and radius in kilometers to 10. The response contains single element (P1) with Location: { "longitude": 23.30376148223877, "latitude": 42.66969657424687}, but in the database I have another one (P2) with Location: { "longitude": 23.32123875617981, "latitude":42.686445812676766 }. If you check the coordinates on the map you can easily see that P2 is closer to the center than P1.

     

    Any ideas?

  2. Viktor
    Viktor avatar
    14 posts
    Member since:
    Dec 2011

    Posted 31 Aug in reply to Viktor Link to this post

    The same behavior is examined with other filters as well - Near sphere and Within rectangle.
  3. Viktor
    Viktor avatar
    14 posts
    Member since:
    Dec 2011

    Posted 31 Aug Link to this post

    OMG
    This was not working because of the order of the properties... In the table everything has {"latitude":..., "longitude":...},
    but in the filter it was {"longitude":..., "latitude":...} as it was in the docs. As soon as I switched the values it worked.
    This is bizarre... 

    Why are there named properties when the only thing that matters is the order?
    Why in you docs you use longitude as a first property at all, when everywhere latitude is used?

    By pure luck we don't have INCONSISTENT DATA - all of our client apps use latitude as first property.

    Guys, really? It's 2017, not 1967.. and this approach is error prone.
  4. Answer
    Lyubomir Dokov
    Admin
    Lyubomir Dokov avatar
    44 posts

    Posted 31 Aug Link to this post

    Hi Victor,

    I am sorry to hear you had such an issue, but it is great that you found a solution. You are correct, this behavior is unexpected, we will verify what you wrote and fix our documentation as needed.

    Unfortunately, as far as I remember, this is something related to how MongoDB works with GeoPoint queries, it is not something we designed on purpose.

    And, of course, you are right, it is not 1967. This behavior probably dates a few years back to when we first implemented the GeoPoint functionality. As a matter of fact, you might remember it, as back then you were still part of our team :)

    Regards,
    Lyubomir Dokov
    Progress Telerik
     
    Everlive is now Telerik Backend Services, and is part of the Telerik Platform.
     
Back to Top