[OSM-dev] Grumble, grumble

Karl Guggisberg karl.guggisberg at guggis.ch
Mon May 11 08:54:57 BST 2009


> Why not? How is this different from a user having to go through all his
changes manually and download every node/way he changed manually?
Exactly. I was thinking of a kind of "Sync with server" action and dialog
(or plugin?) which would also support the user in resolving
other kinds of conflicts, i.e.
- conflicts due to different nodes in a way on the server and on the client
- conflicts due to different members in a relation on the server and on the
client

This would be helpful. Users today analyse conflicts using OSM "../browse"
pages. Then they fix them locally by editing their local dataset with a text
or XML editor. 

> By doing it that way, does it give an errormessage with the offending
node/way id? That would be really helpful.
For both cases, 410 Gone and 409 Conflict you now get an error message with
the offending primitive id.
JOSM could take action based on this. In case of 409 Conflicht it could
query the primitive individually because a 
409 Conflict also occurs when JOSM *updates* an already deleted node. 
In case of 410 Gone (which only happens if the user tries to *delete* an
alreay deleted primitive) it could silently 
remove the primitive from the local dataset and upload again 

Karl


-----Ursprüngliche Nachricht-----
Von: dev-bounces at openstreetmap.org [mailto:dev-bounces at openstreetmap.org] Im
Auftrag von Maarten Deen
Gesendet: Montag, 11. Mai 2009 09:31
An: dev at openstreetmap.org
Betreff: Re: [OSM-dev] Grumble, grumble

Frederik Ramm wrote:
> Hi,
>
> Maarten Deen wrote:
>>> 1. you hit upload
>>> 2. upload fails, JOSM complains
>>> 3. if you try to exit JOSM, it should warn about unsaved changes 4. 
>>> you must now do a download and resolve any conflicts 5. you hit 
>>> upload again 6. it works
>>>
>>> Unfortunately, step "4" will not send you deleted objects, so JOSM 
>>> has no way of knowing that the object has already been deleted. It 
>>> could,
>>
>> Yes it does. When you delete a node or way, you get a return with 
>> "visible=false".
>
> No it doesn't; if you do a "map" query against the API, you will *not* 
> receive deleted objects, and that's what JOSM does in step 4. It would 
> not be feasible to query each object individually.

Why not? How is this different from a user having to go through all his
changes manually and download every node/way he changed manually?

>> JOSM can then take action and inform the user that it is deleted and 
>> take action (either upload it as a new node or delete it in the local 
>> dataset).
>
> However one thing that JOSM could do is compare the list of objects in 
> memory with those returned by the "map" query and thus find out which 
> ones are "missing" from the map query, then request those individually 
> to confirm they are really "410 Gone".

Well, depending on how you downloaded the data in the first place. It is not
said that the data came from a download in JOSM.
But if it is, and JOSM can "recreate" the download and then only query the
missing items, that's even more efficient.

>> Does it upload everyting except the deleted way, or does it upload 
>> its list of changes and stops with an error when it gets to the 
>> deleted way and does not get past that?
>
> The latter (it is exactly the way as used in 0.5). But it does not 
> upload the changes in the order you made them, instead it first 
> uploads all creations, then all modifications, then all deletions.

By doing it that way, does it give an errormessage with the offending
node/way id? That would be really helpful.

Regards,
Maarten


_______________________________________________
dev mailing list
dev at openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev





More information about the dev mailing list