On Sun, May 2, 2010 at 4:58 AM, Frederik Ramm <span dir="ltr"><<a href="mailto:frederik@remote.org">frederik@remote.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<div class="im"><br>
<br>
Scott Crosby wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>

</blockquote>
<br></div>
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).<br>
<br></blockquote><div><br>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 message.<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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:<br>

<br></blockquote><div><br>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.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
"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"<br>

<br></blockquote><div><br>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.<br>
<br>'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.<br><br>Scott<br><br>
</div></div>