[OSM-talk] Errors on the API - results of some testing

[Andy Robinson]

I have been checking out the API calls with wget and JOSM.

400 errors: 

Testing of calls just either side of the 0.014 sq deg apparent code limit
show that those below do not get 400's and those that are above do. So
although Steve was pretty sure that the code was still commented out on the
server the results suggest otherwise.

Connection reset errors:

If the call passes the bbox area limit discussed above we then run into the
wrath of the misbehaving database server and its memory/disk swapping
issues.

For me, there is a 3min time limit before the connection is reset. Not sure
where this reset instruction comes from as it may not be OSM (ie it may be
my ISP Blueyonder). Both wget and JOSM run for the same time (2min 50 sec to
3min) however JOSM currently sends out the request twice (sequentially)
before the "connection reset" box is displayed, in my case therefore after
almost 6 mins. Imi is looking into why this happens.

So the result appears to be for me that any call that results in the query
process taking more than the 3 mins will fail.

I looked also at comparing calls that do work to see if there was any
correlation. There does not appear to be although I am sure that those areas
with lots of ways are worse that those areas with none.

On top of these issues the server does sometimes respond with a 500 server
error. These seem to be random in nature.

These issues do not affect calls for trackpoint data as far as I am aware.

Suggestions therefore:

1. Keep your box size below the 0.014 sq degrees threshold to avoid the 400
bad request responses.
2. Work on locations with less coverage - time to get out there and map
something new :-)
3. If you do have to work in an area with a lot of current data then make
the calls very small. In JOSM if you load lots of small areas in you may
find some of the junctions between imported sections don't colour the ways
properly or give errors when adjusting node positions (one adjoining segment
does not adjust). The way around this is to download all the bits you want
piecemeal, save the lot as an .osm file with JOSM and then reload this file
again back into a clean start of JOSM. All should then be properly displayed
and you can carry on editing and uploading. Just remember that you cannot
use the harddisk osm file for long if anyone else is editing around your
same area of interest.

Hopefully these comments and suggestions will help keep the offline editing
ticking over till the server issues are resolved.

Cheers,

Andy

Andy Robinson
Andy_J_Robinson at blueyonder.co.uk