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

[Steve Chilton]

Ta for useful analysis. Working in close-nit areas as a matter of
principle, but will change to surveying some blank areas with less
detail for a while. Just one thing for the less mathematically
sophisticated amongst us - what does 0.014 sq deg represent? I zoom in
on OSM and then clip the resulting URL into JOSM for downloads. Does it
mean scales of 12 and above or something like that?

Cheers
STEVE

Steve Chilton, Learning Support Fellow
Learning and Technical Support Unit Manager
School of Health and Social Sciences
Middlesex University
phone/fax: 020 8411 5355
email: steve8 at mdx.ac.uk

Chair of the Society of Cartographers:
http://www.soc.org.uk/
2006 SoC Summer School at Keele Uni:
http://www.esci.keele.ac.uk/soc/


-----Original Message-----
From: talk-bounces at openstreetmap.org
[mailto:talk-bounces at openstreetmap.org] On Behalf Of Andy Robinson
Sent: Thursday, June 08, 2006 4:33 PM
To: 'Talk Openstreetmap'
Subject: [SPAM: 4.146] RE: [OSM-talk] Errors on the API - results of
some testing


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 



_______________________________________________
talk mailing list
talk at openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk