Thanks for pointing me there, it is interesting to see what experiments have been made to address this issue.<br><br>It largely confirms my view that limiting requests to the API to a sensible tile size (to be determined) together with a meaningful error message would improve the current situation, because
<br><br>1. people would know why their requests fail, rather than receiving the 500 error.<br>2. no time would be wasted in trying to compute results that cannot be computed with the resources available.<br>3. less repeated (and repeatedly failing requests) to the OSM server
<br><br>=> a net gain of successfully served requests, with the same resources, little programming effort and no risk to existing data.<br><br>Ludwig<br><br><br><div><span class="gmail_quote">On 1/8/07, <b class="gmail_sendername">
Nick Black</b> <<a href="mailto:nickblack1@gmail.com">nickblack1@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The reasons are well documented by Nick Hill in his posts to the osm lists, eg:<br><br><a href="http://lists.openstreetmap.org/pipermail/talk/2006-April/003557.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://lists.openstreetmap.org/pipermail/talk/2006-April/003557.html
</a><br><br><br><br><div><div><span class="e" id="q_11002afb9e57b9f5_1"><span class="gmail_quote">On 1/8/07, <b class="gmail_sendername">Ludwig Max Brinckmann</b> <<a href="mailto:ludwigbrinckmann@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

ludwigbrinckmann@gmail.com
</a>> wrote:</span></span></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span class="e" id="q_11002afb9e57b9f5_3"><div><span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>On the other hand there is a limit in size, but you probably will only see it<br>if you are in a not so well filled area like Africa, ...
</blockquote></span><div><br>True. Maybe we should first find the bottleneck before looking for solutions. Maybe someone who has access to the server logs could fill us in what the actual error message on this error 500 is.
<br><br>
In the meantime have just been a bit browsing through the DB code and one thing I noticed is -- correct me if I am wrong -- that OSM does not use the MySql spatial extensions to represent the geometries, and thus cannot use spatial indices on the data.
<br><br>My personal experience is with PostGIS and there adding spatial indices to large geometry tables speeds up retrieval by several magnitudes (*1000). <br><br>Is there any reason, apart from historic, that spatial extensions and spatial indices are not used for OSM? Are there Ruby limitations in using spatial extensions (good for prototyping, not so good for speed AFAIK)?
<br><br>Ludwig<br> </div></div><br>

<br></span></div><span class="q">_______________________________________________<br>dev mailing list<br><a href="mailto:dev@openstreetmap.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">dev@openstreetmap.org
</a><br><a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev</a><br><br><br></span></blockquote></div><span class="sg"><br><br clear="all"><br>-- <br>Nick Black<br>--------------------------------<br><a href="http://www.blairclock.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://www.blairclock.com
</a><br>---------------------------------<br><a href="http://www.blacksworld.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.blacksworld.net</a>


</span></blockquote></div><br>