[OSM-dev] C++ implementation of the API

Dave Stubbs osm.list at randomjunk.co.uk
Tue May 27 10:05:23 BST 2008


2008/5/27 Karl Newman <siliconfiend at gmail.com>:
> On Mon, May 26, 2008 at 8:33 AM, Tom Hughes <tom at compton.nu> wrote:
>>
>> In message <3f7a6e1c0805260805r549bd02ere680ae7c24256c34 at mail.gmail.com>
>>          Ludwig <ludwigbrinckmann at gmail.com> wrote:
>> <snip>
>> Map data for editing purposes will always have to come from the
>> master database anyway, or you might get an old version which you
>> are then unable to upload.
>>
> That may hold true for "live" editors such as potlatch, but for offline
> editors like JOSM, if you download from the master database server, do some
> editing and then upload, the editing time is going to far exceed any
> replication delay, so you could instead download from a replication server,
> do your edits and then upload to the master server. The chance of a
> collision/version mismatch is increased only a miniscule amount.
>

Yes... and no.

The problem here is the remedial action taken by the user/editor:
they're going to try to work out the conflicts by downloading the
latest version of the region. If this comes off a replication server
that's a couple of minutes behind, then they're going to be sitting
there retrying for a couple of minutes before they can actually get a
version they can upload. It may be possible to fix many of these cases
by redesigning the fail returns of the API uploads... but if not
thought through then this could end up pretty tedious for the editor.

There's also then the problem of inconsistent downloads: if I download
a map area twice I expect the second time to be identical or a later
version. If I'm pulling it from a couple of different replication
servers, one 1 minute behind, one 2 minutes behind because of an
earlier high load, then the second map call could actually return an
older version. This may not be much of an issue, but it's another
thing editors would have to watch out for.


Dave




More information about the dev mailing list