Does anyone know what the exact error is? As humble API users we only get the 500 error, there should be more in the OSM log.<br><br>I have the slight suspicion that if this is due to some sort of (changeable) configuration value that upping that value will not actually impact the OSM server performance badly, as the overall load will probably _decrease_, because people will not try and try again to load a larger region to then cut down their requests to tiles smaller in individual extent, but the same overall. (I do not know how many times I tried to download an area that interested me as it seemed a transient error, before I decided to cut my losses and tile my request instead. Every time the server spent endless time before deciding that it was too big -- all that processing wasted in vain.) 
<br><br>However there should be a check on the size, so that people do not regularly download the planet just to see it is too big to digest for them. Limiting requests to a tile size smaller than 1 arc degree square should not be too onerous and combined with a meaningfull error message should solve most of the problem. It is at least worth a try before bringing mirrored dbs and new servers into play.
<br><br>HTH<br>Ludwig<br><br><div><span class="gmail_quote">On 1/8/07, <b class="gmail_sendername">Nick Hill</b> <<a href="mailto:nick@nickhill.co.uk">nick@nickhill.co.uk</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;">
Andy Robinson wrote:<br><br>> This is most likely an SQL query timeout and has always been present to some<br>> degree or other throughout the project to date. If we had tons more hardware<br>> my guess is the project could deliver more data for each query. Until then
<br>> we must consider the workaround.<br>><br>> The temporary solution is to download the area in chunks into JOSM and then<br>> save the whole lot as an .osm file to your hard disk. Close down JOSM and<br>> then reload the same file again from the hard disk and you should find you
<br>> have a fully functioning enlarged area. (JOSM does not always handle joins<br>> between partly downloaded data properly and hence the recommendation to<br>> close JOSM and reload the file before working on it)
<br><br><br>I feel we should have a capability to server large bounding boxes. However, this<br>capability probably should be kept separate from the regular workload of<br>database servers delivering real-time API data.<br>
<br>Any ideas whether this would most efficiently be done through using planet +<br>osm-subset.pl or through a db + API approach?<br><br>_______________________________________________<br>dev mailing list<br><a href="mailto:dev@openstreetmap.org">
dev@openstreetmap.org</a><br><a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev</a><br></blockquote></div><br>