[mongodb-dev] Geospatial distances

[hcarvalhoalves]

As of 1.3.3 (http://groups.google.com/group/mongodb-user/browse_thread/
thread/48f6c7defd08e880 ) you guys implemented geospatial indexing,
with some features for distance calculation and area querying.

While it got me interested because it's the first non-relational to
implement geospatial support, the actual implementation is not
desired, as the simple cartesian math will yield too big of an error,
making MongoDB unsuitable even for civil-grade GIS (errors smaller
than ~20 m).

The fix is simple, and I'm hacking on geodesic algorithms for the
distance calculation and area queries (I'm leaning towards a haversine
formula as it's faster and good enough - up to 3 m accuracy on
average). This would make MongoDB suitable for a broader range of GIS
applications (beyond toy level).

The problem is, this would trigger a major backward incompatibility.
According to the documentation (http://www.mongodb.org/display/DOCS/
Geospatial+Indexing), the coordinate format was never enforced,
neither recommended, expecting just a pair of angles. This won't work
once you introduce latitude and longitude calculations, as those are
not interchangeable. Also, there's no way that I'm aware of to tell
which value the user is using for lat or lon.

So, while I'm all into hacking those features, the simple assumptions
made when introducing the feature will be a major drawback. What you
guys think? Are you welcoming improvements on geospatial support for
Mongo, and how to deal with this backward incompatibility?

--
You received this message because you are subscribed to the Google Groups "mongodb-dev" group.
To post to this group, send email to mongo...@googlegroups.com.
To unsubscribe from this group, send email to mongodb-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mongodb-dev?hl=en.

[Eliot Horowitz]

Very cool.

The way to do it so its totally backwards compatible is add a new
index name a bit.

{ geo : "2d" } will work as it does not
{ geo : "2d-gis" } will work for spherical (name should be better)

[hcarvalhoalves]

So what you're saying is that it should work like ...

{ loc : { lat : 40.739037, long: 73.992964 } }

db.places.ensureIndex( { loc : "2d" } ) // Old behaviour
db.places.ensureIndex( { loc : "sphere" } ) // Spherical model

That's it? If so, cool, because then it can have room for future
expansion for other models:

db.places.ensureIndex( { loc : "wgs-84" } ) // GPS' ellipsoid


What is the best approach to implement this then? Should I just derive
new Geo2dSphereType, Geo2dSpherePlugin, etc (I would have to derive
new Box and Circle too, as it's different math depending on the geode
model)? If you can provide an example how to support a new index type,
I can figure the rest.

> > For more options, visit this group athttp://groups.google.com/group/mongodb-dev?hl=en.

>
> --
> You received this message because you are subscribed to the Google Groups "mongodb-dev" group.
> To post to this group, send email to mongo...@googlegroups.com.
> To unsubscribe from this group, send email to mongodb-dev...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/mongodb-dev?hl=en.

[Eliot Horowitz]

Yes - that's the basic idea.
You can just copy index_geo and make index_sphere to play with.
I would start with making a sphereNear or other command - then you
don't have to touch any other code.

[cbmeeks]

Is there somewhere I can follow the progress on this? I too need this
ability. :-)

Thanks!

> >> > The fix is simple, and I'm hacking ongeodesicalgorithms for the

[Andrei]

How are you planning to store and specify the coordinates: [ lat,
lon ], [ lon, lat ], or as an object like in your example below? The
geospatial community apparently recommends the [ lon, lat ] order.

-Andrei