[OSM-dev] Various OSM troubles
Ludwig Max Brinckmann
ludwigbrinckmann at gmail.com
Mon Jan 8 15:36:25 GMT 2007
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.
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.)
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.
On 1/8/07, Nick Hill <nick at nickhill.co.uk> wrote:
> Andy Robinson wrote:
> > This is most likely an SQL query timeout and has always been present to
> > degree or other throughout the project to date. If we had tons more
> > my guess is the project could deliver more data for each query. Until
> > we must consider the workaround.
> > The temporary solution is to download the area in chunks into JOSM and
> > save the whole lot as an .osm file to your hard disk. Close down JOSM
> > then reload the same file again from the hard disk and you should find
> > have a fully functioning enlarged area. (JOSM does not always handle
> > between partly downloaded data properly and hence the recommendation to
> > close JOSM and reload the file before working on it)
> I feel we should have a capability to server large bounding boxes.
> However, this
> capability probably should be kept separate from the regular workload of
> database servers delivering real-time API data.
> Any ideas whether this would most efficiently be done through using planet
> osm-subset.pl or through a db + API approach?
> dev mailing list
> dev at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev