Yep. On Tue, Apr 12, 2011 at 3:51 PM, Steve Coast <[email protected]> wrote:
> and using the builtin spatial index? > > > > On 4/12/2011 1:50 PM, Ian Dees wrote: > > Yes, one document per node/way/relation. > > On Tue, Apr 12, 2011 at 3:47 PM, Steve Coast <[email protected]> wrote: > >> how was the data put in the db though? 1 document per node? >> >> >> On 4/12/2011 1:39 PM, Nolan Darilek wrote: >> >> Oopse, meant for this to go to the whole list. >> >> >> >> -------- Original Message -------- Subject: Re: [OSM-dev] OSM and >> MongoDB Date: Tue, 12 Apr 2011 15:26:41 -0500 From: Nolan Darilek >> <[email protected]> <[email protected]> To: Ian Dees >> <[email protected]> <[email protected]> >> >> I had/am having a somewhat bad experience storing OSM data in MongoDB. >> >> Initially I stored all map data in MongoDB, but queries took ages. The >> same queries that happen in 100-200 MS now often took nearly a second. >> Additionally, some took upwards of 5, and I even found spots on my map >> sparsely populated with points, but which reliably performed the queries I >> need in 30+ seconds. >> >> I filed a thorough bug in their tracker, including a dataset and queries >> that reliably duplicated the issue. It was marked wontfix, I abandoned >> MongoDB, and it was apparently re-opened and fixed several months later. So >> perhaps it's a non-issue now. >> >> I'm still using MongoDB for part of my current project, user POI storage. >> It does indeed use geohashes, and I'm experiencing strange accuracy issues. >> My platform is pedestrian navigation with many small distance queries. >> Points in the non-MongoDB dataset are reliably detected in a radius roughly >> 100 meters around the traveler. Points in MongoDB queried with the same >> bounding boxes don't appear until they're within 30-40 meters. I recently >> updated from an older version to a new build of 1.8. The older version >> widely varied the detection range. Some points were detected 100 or so >> meters out, while others weren't picked up until 30 or so. It was always the >> same points, too. The point for my apartment remains reliably visible for >> ~100 meters or so, while the corner store and restaurant didn't appear until >> I was very close. 1.8 at least appears to be consistent, always detecting at >> 30 meters or so. I can only assume that this is a geohash oddity that only >> appears for very small differences, something that works out to rounding >> error for larger values. >> >> I like MongoDB for many things, but not for geospatial data more >> complicated than a series of points. I'm working on migrating user/POI >> storage to a geospatial store. >> >> >> On 04/12/2011 01:20 PM, Ian Dees wrote: >> >> Yep, and I think Mongo uses geohashes as their index behind the scenes. >> One of the problems with that, though, is they have some arbitrary length >> that they compute the geohash to and when you have lots of points (as OSM >> data does) the buckets they're searching are very full. >> >> On Tue, Apr 12, 2011 at 1:00 PM, Steve Coast <[email protected]> wrote: >> >>> bbox queries using the built in spatial indexing presumably? OSM has >>> it's own magical bitmask for that, that may also be as fast in mongo, who >>> knows. >>> >>> >>> On 4/11/2011 5:58 PM, Ian Dees wrote: >>> >>> On Mon, Apr 11, 2011 at 6:36 PM, Sergey Galuzo <[email protected]>wrote: >>> >>>> Hi, >>>> >>>> >>>> >>>> I am working on evaluation of MongoDB for several storage solutions at >>>> hand. Some of them resemble current OSM editing database. I have heard that >>>> OSM dev is/was evaluating MongoDB also. I was wondering whether it possible >>>> to share the findings? >>>> >>>> >>>> >>> >>> In my experimentation with MongoDB (seen here: >>> https://github.com/iandees/mongosm/) I found it to be very slow. Inserts >>> were speedy, but bounding-box queries took a long time. >>> >>> The most recent dev version of MongoDB includes "multi-location >>> documents" support: >>> >>> http://www.mongodb.org/display/DOCS/Geospatial+Indexing#GeospatialIndexing-MultilocationDocuments >>> >>> This would allow a single way document to be indexed at multiple >>> locations and vastly speed up the map query. >>> >>> >>> _______________________________________________ >>> dev mailing list >>> [email protected]http://lists.openstreetmap.org/listinfo/dev >>> >>> >>> _______________________________________________ >>> dev mailing list >>> [email protected] >>> http://lists.openstreetmap.org/listinfo/dev >>> >>> >> >> _______________________________________________ >> dev mailing >> [email protected]http://lists.openstreetmap.org/listinfo/dev >> >> >> >> _______________________________________________ >> dev mailing >> [email protected]http://lists.openstreetmap.org/listinfo/dev >> >> >> _______________________________________________ >> dev mailing list >> [email protected] >> http://lists.openstreetmap.org/listinfo/dev >> >> >
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
