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).<br>IMHO, the assumption that a BBOX query will return all nodes, ways and relations (even incomplete) is one of the fundamentals of the api...<br>
<br>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.<br>Does Potlach somehow (with its "special" api) circumvent the problem?<br>
<br>Another solution is to forbid long straight highways ;-)<br><br>- Chris - <br><br><div class="gmail_quote">2009/4/27 Brett Henderson <span dir="ltr"><<a href="mailto:brett@bretth.com">brett@bretth.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">Frederik Ramm wrote:<br>
> Hi,<br>
><br>
> Matt Amos wrote:<br>
><br>
>> On Sun, Apr 26, 2009 at 9:16 PM, Frederik Ramm <<a href="mailto:frederik@remote.org">frederik@remote.org</a>> wrote:<br>
>><br>
>>> I think it would be promising to set up a daily/hourly/minutely diff<br>
>>> based API mirror outside of the OSM empire that uses proper PostGIS<br>
>>> geometries so we could do performance comparisons.<br>
>>><br>
>> i did a simple performance comparison of our tile-based btree node<br>
>> lookup versus a proper postgis r-tree. the r-tree was twice as slow.<br>
>><br>
><br>
> It is possible that these effects would be offset by PostGIS being able<br>
> to include way geometries in the index, thus allowing us to drop the<br>
> node->way indirection we currently employ.<br>
><br>
> It is of course equally possible that this is even slower.<br>
><br>
</div>If anybody wishes to test some PostGIS magic out without too much effort<br>
you may wish to look into the existing 0.6-based Osmosis pgsql schema.<br>
It allows optional bbox and linestring columns to be created on the way<br>
table.  The --write-pgsql and --write-pgsql-dump tasks (one writes<br>
direct, the other creates bulk import files) both support optional<br>
in-memory geometry calculation functionality which if you have 6GB RAM<br>
or greater will let you create the columns very quickly.  If not you'll<br>
have to rely on either a temp file approach (medium speed) or raw SQL<br>
update queries (very slow).  The key difference between this schema and<br>
the main API schema (PostGIS aside) is that it doesn't support history,<br>
otherwise it is layed in in a similar fashion (ie.<br>
users/nodes/ways/relations/node_tags/etc).<br>
<br>
If you want any further info let me know.<br>
<font color="#888888"><br>
Brett<br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/dev" target="_blank">http://lists.openstreetmap.org/listinfo/dev</a><br>
</div></div></blockquote></div><br>