[OSM-dev] API: no BBOX download of a way if no nodes inside the BBOX?

[Chris Browet]

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 <brett at bretth.com>

> Frederik Ramm wrote:
> > Hi,
> >
> > Matt Amos wrote:
> >
> >> On Sun, Apr 26, 2009 at 9:16 PM, Frederik Ramm <frederik at remote.org>
> 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
> dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20090427/4e5bbb5c/attachment.html>