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

Brett Henderson brett at bretth.com
Mon Apr 27 02:22:02 BST 2009


Chris Browet wrote:
> 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 ;-)
This has always been an issue and may not be seen as a high priority by 
many.  It is typically worked around in two ways:
1. Always place nodes at regular intervals on long ways.
2. Always download an area larger than you require.

Because of the available workarounds and the performance impact of 
making it smarter it has never been fixed.  The Osmosis pgsql schema I 
referred to earlier was originally created to solve this problem because 
I was unable to make the streamable --bounding-box task work perfectly.  
The schema allows true bounding box queries to be made, but because of 
the performance impacts the ROMA servers don't use it.

So yes, I'd like to see it fixed but it may not be feasible to add this 
type of expensive query to the api database.  It requires significant 
extra disk storage to hold the new columns and indexes, and this has a 
corresponding detrimental impact on the amount of data that can be 
cached in RAM.  It can always be done offline or by replicated databases 
if required.

But don't let this stop anybody from trying.  If you can get true 
bounding box queries working efficiently on OSM-sized datasets then it 
will be a great enhancement to the API.  The Osmosis pgsql schema 
provides a potential testbed for experimentation.

Brett





More information about the dev mailing list