Whatever the technical solution, I think this must be addressed sooner or late and have a rather high priority (from a "dev user" point-of-view). IMHO, the assumption that a BBOX query will return all nodes, ways and relations (even incomplete) is one of the fundamentals of the api...
Obviously, this is mainly true for an editor -> live databse point-of-view, which is probably a special case because non-live usage can probably avoid the problem by using other tools. Does Potlach somehow (with its "special" api) circumvent the problem? Another solution is to forbid long straight highways ;-) - Chris - 2009/4/27 Brett Henderson <[email protected]> > Frederik Ramm wrote: > > Hi, > > > > Matt Amos wrote: > > > >> On Sun, Apr 26, 2009 at 9:16 PM, Frederik Ramm <[email protected]> > wrote: > >> > >>> I think it would be promising to set up a daily/hourly/minutely diff > >>> based API mirror outside of the OSM empire that uses proper PostGIS > >>> geometries so we could do performance comparisons. > >>> > >> i did a simple performance comparison of our tile-based btree node > >> lookup versus a proper postgis r-tree. the r-tree was twice as slow. > >> > > > > It is possible that these effects would be offset by PostGIS being able > > to include way geometries in the index, thus allowing us to drop the > > node->way indirection we currently employ. > > > > It is of course equally possible that this is even slower. > > > If anybody wishes to test some PostGIS magic out without too much effort > you may wish to look into the existing 0.6-based Osmosis pgsql schema. > It allows optional bbox and linestring columns to be created on the way > table. The --write-pgsql and --write-pgsql-dump tasks (one writes > direct, the other creates bulk import files) both support optional > in-memory geometry calculation functionality which if you have 6GB RAM > or greater will let you create the columns very quickly. If not you'll > have to rely on either a temp file approach (medium speed) or raw SQL > update queries (very slow). The key difference between this schema and > the main API schema (PostGIS aside) is that it doesn't support history, > otherwise it is layed in in a similar fashion (ie. > users/nodes/ways/relations/node_tags/etc). > > If you want any further info let me know. > > Brett > > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/dev >
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
