[OSM-dev] Structured error messages from API

Ian Dees ian.dees at gmail.com
Thu Dec 10 17:12:50 GMT 2009

On Thu, Dec 10, 2009 at 10:55 AM, Ævar Arnfjörð Bjarmason
<avarab at gmail.com>wrote:

> On Thu, Dec 10, 2009 at 16:20, Ian Dees <ian.dees at gmail.com> wrote:
> > On Thu, Dec 10, 2009 at 10:16 AM, Matthias Julius <lists at julius-net.net>
> > wrote:
> >>
> >> There are requests in JOSM's trac to improve the handling of API
> >> errors.  To do that JOSM needs to get a better understanding on what
> >> is wrong with the data.
> >>
> >> Currently, JOSM is parsing the error strings the API is returning.
> >> This is far from ideal because they are not structured, not documented
> >> and might change without warning.
> >>
> >> To improve things I would like to see the API extended to return meta
> >> data about errors (error type, id of offending element, ...) in a
> >> structured way.  There are a couple of ways to that (that came to my
> >> mind):
> >>
> >> - change the Error header
> >> - add home-made HTTP headers (X-Error-Type ...)
> >> - add pseudo headers to the body
> >> - return a XML document containing all the info
> >>
> >> (see also http://trac.openstreetmap.org/ticket/2544)
> >>
> >> What do you think?
> >>
> >> How important is that to people on the receiving end (application
> >> developers)?
> >>
> >
> > On a related note, I would be very interested in seeing a progress of
> some
> > kind being returned when doing a osmChange upload. I realize that it is
> > difficult (because it could fail after spitting out lots of seemingly
> valid
> > IDs), but if it was documented it would be doable.
> You mean showing upload progress in JOSM as opposed to the current
> cylon impression? That could be implemented by counting the number of
> bytes of the osmChange request that have been successfully sent over
> the wire. That's how upload progress bars are usually implemented.
> Obviously the upload could fail but that's another issue.

The number of bytes uploaded != the progress of the changeset upload process
(although it's better than what's there now). I'm assuming the server reads
the entire file to memory of some sort before parsing the XML and applying
changes to the database? If so, the upload of the osmc file could happen in
a few seconds but it could then take lots more time for the server to apply
the changeset. At that point, the tool will only be able to block until it
times out or receives a response from the server.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20091210/dd169e0d/attachment.html>

More information about the dev mailing list