[OSM-dev] New OSM binary fileformat implementation.

Scott Crosby scrosby06 at gmail.com
Sun May 2 17:58:44 BST 2010

On Sun, May 2, 2010 at 4:58 AM, Frederik Ramm <frederik at remote.org> wrote:

> Hi,
> Scott Crosby wrote:
>> But there may be problems in geographic queries. Things like
>> cross-continental airways if they are in the OSM planet file would cause
>> huge problems; their bounding box would cover the whole continent,
>> intersecting virtually any geographic lookup. Those geographic lookups would
>> then need to find the nodes in those long ways which would require loading
>> virtually every block containing nodes.  I have considered solutions for
>> this issue, but I do not know if problematic ways like this exist. Does OSM
>> have ways like this.
> We do not recommend having ways that long (anyway, ways are limited to 2000
> nodes so you'd have to place your nodes very far apart to achieve this).
But if they exist, they would cause huge inefficiencies. For this particular
use-case, the solution may be for generate a special planet dump with a
geographic-localizing serializer that rejects such ways with a warning

> It is however very well possible to have relations that span the globe so
> you will have to think about that. Even today you will find a relation
> describing, say, a whole country boundary, and most people asking for
> geographic queries actually mean something like:
I have a few ideas, eg, extra cross-references 'all the nodes needed to
understand ways and relations in block X can be found in blocks A,B,C', or
putting such relations in the same block as the nodes they reference. Such a
file could be done in an upward-compatible way, in that my osmosis reader
would ignore the extra cross-indexes and metadata. However generating a file
with the appropriate physical order and generating that metadata requires
spending significantly more effort on the writer. At some point, the
tradeoff is to use more computer resources instead of more programmer
resources. Flash capacity is ever increasing.

> "give me all nodes in my bbox, plus all ways and relations using any of
> these nodes; and after that I am very likely to ask you for (a) all other
> objects which are also part of one of the ways or relations returned and (b)
> any relations that use any of the objects collected"
I did not intend my format to replace a database. With the indexing ideas I
proposed above and by having two files, one sorted geographically and the
other by ID, it might be doable, but I'm not sure that imitating a database
with an extended version of my format is the right design.

'Give me a superset of every node and way and relation that touches or is in
this bounding box' is a query I did intend my format to be able to answer
efficiently through geographic sorting.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20100502/21d027ba/attachment.html>

More information about the dev mailing list