The geoNear command no longer returns distance in radians for legacy points

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Done
    • Priority: Major - P3
    • 2.6.1, 2.7.0
    • Affects Version/s: 2.6.0
    • Component/s: Geo
    • None
    • ALL
    • Hide 
      use test
db.location.save({"_id":1, "position" : [-74.044628, 40.689182]})
db.location.save({"_id":2, "position" : [-74.041243, 40.700309]})
db.location.ensureIndex( {position: "2dsphere"} )

      The following commands executed against mongodb 2.4.9 result in:

      > db.runCommand( { geoNear : "location" , near : [-74.045255, 40.702554], spherical : true } ).results[0].dis
0.00006597925143247339 <- radians
Note that the last command used a "legacy point"

> db.runCommand( { geoNear : "location" , near : { type : "Point" , coordinates: [-74.045255, 40.702554] } , spherical : true } ).results[0].dis
420.82226356145856 <- meters

Note that the last command used a GeoJSON Point

      The following commands executed against mongodb 2.6.0 result in:

      >  db.runCommand( { geoNear : "location" , near : [-74.045255, 40.702554], spherical : true } ).results[0].dis
420.82602810248557 <- meters
Note that the last command used a "legacy" Point but returned meters.

>  db.runCommand( { geoNear : "location" , near : { type : "Point" , coordinates: [-74.045255, 40.702554] } , spherical : true } ).results[0].dis
420.82602810248557 <- meters
      Show
      use test db.location.save({ "_id" :1, "position" : [-74.044628, 40.689182]}) db.location.save({ "_id" :2, "position" : [-74.041243, 40.700309]}) db.location.ensureIndex( {position: "2dsphere" } ) The following commands executed against mongodb 2.4.9 result in: > db.runCommand( { geoNear : "location" , near : [-74.045255, 40.702554], spherical : true } ).results[0].dis 0.00006597925143247339 <- radians Note that the last command used a "legacy point" > db.runCommand( { geoNear : "location" , near : { type : "Point" , coordinates: [-74.045255, 40.702554] } , spherical : true } ).results[0].dis 420.82226356145856 <- meters Note that the last command used a GeoJSON Point The following commands executed against mongodb 2.6.0 result in: > db.runCommand( { geoNear : "location" , near : [-74.045255, 40.702554], spherical : true } ).results[0].dis 420.82602810248557 <- meters Note that the last command used a "legacy" Point but returned meters. > db.runCommand( { geoNear : "location" , near : { type : "Point" , coordinates: [-74.045255, 40.702554] } , spherical : true } ).results[0].dis 420.82602810248557 <- meters
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      Issue Status as of April 17, 2014

      ISSUE SUMMARY

      In 2.4 the geoNear command returned the distance in radians for legacy coordinate pairs. In 2.6, this behavior changed and the geoNear command returned the result in meters. This behavior change was unintentional and needs to be reverted.

      USER IMPACT
      Users that have their data stored in legacy coordinate pairs (rather than in GeoJSON format) and who use the geoNear command get the results back in an unexpected unit, which may break their applications.

      WORKAROUNDS
      A client-side rescaling of the result back from meters to radians can be used as a workaround.

      RESOLUTION
      Revert the behavior change and return the result in radians again if the coordinates are stored in legacy format.

      AFFECTED VERSIONS
      Version 2.6.0 was affected by this bug.

      PATCHES
      The patch is included in the 2.6.1 production release.

      Original description

      It seems that the distance metric for handling legacy points has changed from mongodb 2.4.x to 2.6.0.

      Previously the distance in geoNear queries for legacy points was returned as radians - since 2.6.0 it is now returned in meters. Since this behaviour is not listed in the incompatibility / changes list and could be seen as a breaking change I suppose that this is a bug.

      See also here:
      https://jira.spring.io/browse/DATAMONGO-906

            Assignee:
            Greg Studer (Inactive)
            Reporter:
            Thomas Darimont
            Votes:
            1 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: