Changes between Version 63 and Version 64 of Help/Action/Upload


Ignore:
Timestamp:
2019-12-26T20:19:58+01:00 (6 years ago)
Author:
skyper
Comment:

wikitr:

Legend:

Unmodified
Added
Removed
Modified
  • Help/Action/Upload

    v63 v64  
    6868* **Time required to upload**: the smaller the upload requests you choose the longer it takes to upload. It takes more time to upload 100 objects using 100 individual upload requests than to upload them in one request containing 100 objects.
    6969
    70 * **Collisions with other mappers**: if you upload 10,000 objects in one request and if the server encounters a problem on the 9,999th object the whole upload is rolled back. The problem has to be fixed first (i.e. by resolving a [wiki:/Help/Concepts/Conflict conflict]). The whole 10,000 objects will then have to be uploaded again. On the other hand, if you upload 10,000 objects with 10 requests containing 1,000 objects each and the server encounters a problem on the 9,999th object then you only have to repeat the last upload request for the 9,001th to 10,000th objects. Objects 1-9,000 are already successfully uploaded. If you're mapping in areas where other mappers are active too you should therefore prefer smaller sizes for upload requests.
     70* **Collisions with other mappers**: if you upload 10,000 objects in one request and if the server encounters a problem on the 9,999th object the whole upload is rolled back. The problem has to be fixed first (i.e. by resolving a [wikitr:/Help/Concepts/Conflict conflict]). The whole 10,000 objects will then have to be uploaded again. On the other hand, if you upload 10,000 objects with 10 requests containing 1,000 objects each and the server encounters a problem on the 9,999th object then you only have to repeat the last upload request for the 9,001th to 10,000th objects. Objects 1-9,000 are already successfully uploaded. If you're mapping in areas where other mappers are active too you should therefore prefer smaller sizes for upload requests.
    7171
    7272== Uploading data  ==
     
    205205<a name="NodeStillInUseInWay">
    206206}}}
    207 If your upload includes a deleted [Concepts/Object node] the OSM server checks if the node is still used in one of the ways known to the server. You have to make sure that the node is ''isolated'' (not part of any way and not referred to by any relation) before it can be deleted.
     207If your upload includes a deleted [wikitr:/Help/Concepts/Object node] the OSM server checks if the node is still used in one of the ways known to the server. You have to make sure that the node is ''isolated'' (not part of any way and not referred to by any relation) before it can be deleted.
    208208
    209209If the OSM server detects that the node is still in use it replies an error message which JOSM displays as follows:
     
    211211[[Image(upload-412-node-still-in-use.png)]]
    212212
    213 If you click on **Prepare conflict resolution** JOSM supports you in resolving the issue. First it downloads all ways in which the node is still used and merges them with your current dataset. In most cases, JOSM removes the deleted node from all parent ways automatically. If for some reason this isn't possible, JOSM creates a [Concepts/Conflict conflict] which you have to [Concepts/Conflict resolve] manually.
     213If you click on **Prepare conflict resolution** JOSM supports you in resolving the issue. First it downloads all ways in which the node is still used and merges them with your current dataset. In most cases, JOSM removes the deleted node from all parent ways automatically. If for some reason this isn't possible, JOSM creates a [wikitr:/Help/Concepts/Conflict conflict] which you have to [wikitr:/Help/Concepts/Conflict resolve] manually.
    214214
    215215After that, just upload again. Your upload now includes all parent ways of the deleted node and the deleted node is removed from all of them. The upload should therefore succeed.