Changes between Version 71 and Version 78 of Help/Action/Upload


Ignore:
Timestamp:
(multiple changes)
Author:
(multiple changes)
Comment:
(multiple changes)

Legend:

Unmodified
Added
Removed
Modified

  • Help/Action/Upload

    v71 v78  
    44= File > Upload data =
    55
    6 [[JOSMImage(upload,48,link=,middle,margin-right=20)]] ''Keyboard shortcut:'' **{{{Ctrl+Shift+↑}}}**
     6[[JOSMImage(upload,48,link=,middle,margin-right=20)]] ''Keyboard shortcut:'' **`Ctrl+Shift+↑`**
    77
    88**Upload new, modified, and deleted objects in the current data layer to the server.**
    … …  
    1010Geo data edited in JOSM is only available locally and only usable by the user who entered the data unless the user decides to make it available to the community too. In order to publish data the user has to **upload** it. Uploading means that the geo data is transferred to a central server run by the OSM community where it is integrated with geo data from other mappers in a central database. It's by uploading data that locally edited geo data both becomes part of the main database and [osmwww: map at osm.org] and can be used by other members of the OSM community.
    1111
     12
    1213== In simple words ==
    13 
    14 * (like online editors like iD or Potlatch) you need to upload your changes to OSM server. Make sure you connected to server :-)
     14* (like online editors like iD or Potlatch) you need to upload your changes to OSM server. Make sure you're connected to the server! :-)
    1515* you may encounter [wikitr:/Help/Concepts/Conflict conflicts] after you upload changes (in most cases this means you will have to [wikitr:/Help/Dialog/Conflict#Resolvingdifferencesbetweentags choose what tags to leave on your objects])
    16 * to reduce chance of conflict:
     16* to reduce the chance of conflict:
    1717 * don't edit data other mappers edit in same time window
    1818 * make your downloads-uploads quicker, so there no overlap between your time-window and theirs
    19 * (rough idea) to entirely avoid conflict, don't edit objects with same id and don't alter their parent relations (node-way and way-relation and relation-relation). If you (and other editor) are editing disjoint datasets (https://en.wikipedia.org/wiki/Disjoint_sets), then there won't be conflict at all. Please note that it also means that all parent ways and all parent relations should be respected (which is likely to change).
     19* (rough idea) to avoid conflicts entirely, don't edit objects with the same ID and don't alter their parent relations (node-way and way-relation and relation-relation). If you (and other editors) are editing disjoint datasets (https://en.wikipedia.org/wiki/Disjoint_sets), then there won't be a conflict at all. Please note that it also means that all parent ways and all parent relations should be respected (which is likely to change).
    2020* (unlike online editors like iD or Potlatch) you don't have to upload immediately (you may [wikitr:/Help/Action/Save save] file manually but [wikitr:/Help/Action/AutoSave auto save] will further assist you)
    2121* (unlike every other editor?) JOSM will let you upload changes to already opened (but not a closed) changeset (see [#Multipleuploadsintoonechangeset Multiple uploads into one changeset]). Every open changeset will "close" automatically by [osmwww: OSM server] after 1 hour.
    … …  
    4848* for users who are working in longer mapping session. For them it could be safer to upload intermediate results to the server than to upload the result of the complete session only. In the former case they can use multiple uploads into one changeset which helps them to safe their data without fragmenting them up in unrelated changesets.
    4949
    50 JOSM still supports to upload each object individually.
     50JOSM still supports the option to upload each object individually.
    5151
    5252[[Image(one-changeset-individual-object-upload-request.png,link=)]]
    … …  
    5454Please note that this is a legacy feature. Until recently, this was the only upload option in OSM.  Technically, it uses a slightly different approach to communicate with the OSM server. It is still available in JOSM although the OSM server now supports upload requests with up to 10,000 objects. For the casual and normal user it is almost obsolete. In rare cases, it could be useful for power users.
    5555
    56 === Uploading large datasets into multiple changeset ===
     56=== Uploading large datasets into multiple changesets ===
    5757JOSM also supports uploading large datasets that don't fit into a single changeset.
    5858
    … …  
    6060
    6161This is an advanced option which is only useful for power users. They can select this configuration if they have to upload a dataset with more than 10,000 new, modified, or deleted objects.
     62
    6263
    6364== Choosing your upload strategy - when and how often to upload ==
    … …  
    6667Here are some rules of thumb:
    6768
    68 * **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.
    69 
    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.
     69* **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.
     70
     71* **Collisions with other mappers**: if you upload 10,000 objects in one request and 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-object upload 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.
     72
    7173
    7274== Uploading data  ==#UploadData
    7375
    7476=== Launching the Upload Dialog ===#LaunchUploadDialog
    75 
    76 * ''Keyboard shortcut:'' **{{{Ctrl+Shift+↑}}}**
     77* ''Keyboard shortcut:'' **`Ctrl+Shift+↑`**
    7778* Menu item ''File->[[JOSMImage(upload)]] Upload''
    7879* Toolbar button [[JOSMImage(upload)]]
    … …  
    9394[[Image(upload-dialog-screenshot.png,link=)]]
    9495
     96since JOSM version 17708, the Upload Dialog is modified:
     97
    9598The Upload Dialog consists of two sections:
    96 * the upper part displays a summary of the objects to be added, to be modified, and to be deleted on the server
    97 * the lower part provides tabs for configuring various aspects of the upload process
    98 
    99 When the Upload Dialog is launched it always displays the Settings tab which allows you to enter the most important information about your [wikitr:/Help/Concepts/Changeset changeset]:
    100  the changeset comment::
     99* the left side displays a summary of the objects to be added, to be modified, and to be deleted on the server
     100* the right side provides tabs for configuring various aspects of the upload process
     101
     102When the Upload Dialog is launched it always displays the ''Description'' tab which allows you to enter the most important information about your [wikitr:/Help/Concepts/Changeset changeset]:
     103 The changeset comment::
    101104  It's important to provide a brief comment describing the changes you are uploading. This makes it easier for other contributors and for yourself to know what your changes are about and why you made the changes.
    102  the changeset source::
     105  * if the comment is empty or too short: the text below the comment box warns you
     106[[Image(comment_empty.png,link=)]]
     107  * if the comment is provided: the text below the comment thanks you
     108[[Image(comment_present.png,link=)]]
     109 The changeset source::
    103110  Specify the date source for the changes, to allow other contributors to check them if needed.
     111  * if the data source is not specified: the text below the comment box warns you
     112[[Image(source_not_specified.png,link=)]]
     113  * if the data source is provided: the text below the comment thanks you
     114[[Image(source_provided.png,link=)]]
     115
    104116Below there is a summary of the other upload parameters for this upload. And a checkbox which sets the `review_requested=yes` changeset tag.
    105117
    … …  
    108120See [wikitr:/Introduction#UploadingtoOSM "Uploading to OSM"].
    109121
    110 === Running an upload with advanced options ===#AdvancedOptions
     122=== Running an upload with advanced options (Settings tab) ===#AdvancedOptions
     123
     124==== Choosing the changeset to upload to ====
     125In the Changeset Configuration Panel you can select what [wikitr:/Help/Concepts/Changeset changeset] the data is uploaded to, see the screenshot below:
     126
     127[[Image(changeset-config-panel-1_JOSMr18303.png,link=)]]
     128
     129To upload your data, you can choose from the drop down list ''(since r18283)'':
     130* JOSM uploads to a new changeset if [[JOSMImage(dialogs/changesetdialog,24,link=,bottom)]] **New changeset** is selected in the drop down list. This is the standard setting.
     131* If you want to upload to an existing changeset you have to select one of the available changesets from the drop down list (they are only available, in the list, if there are open changesets which you can upload data because you own them). Click on [[JOSMImage(dialogs/refresh)]] ''Refresh'' to load the list of available open changesets from the server.
     132
     133Click on [[JOSMImage(closechangeset,24,link=,bottom)]] **Close Changeset** to close the currently selected open changeset. This is for convenience only. You don't have to close a changeset here in order to run a successful upload.
     134
     135After a successful upload JOSM can either close the changeset used or leave it open for another upload. The default setting is to close it. You can configure whether JOSM should leave it open by unselecting the checkbox **Close changeset after upload**.
     136
     137==== Configuring the number and size of upload requests ====
     138JOSM uploads geo data with one or more **upload requests** to a [wikitr:/Help/Concepts/Changeset changeset] on the OSM server. In the Advanced Configuration Panel you can decide about the number and the size of upload requests, see screenshot:
     139
     140[[Image(advanced-config-panel.png,link=)]]
     141
     142Select **Upload data in one request** to upload all object in one request. If you're uploading a medium to large number of objects this might take some time and JOSM will not be able to inform you about the progress. There are only two outcomes of such an upload: the upload either succeeded or it didn't. In the former case everything is fine, in the later no objects at all have been uploaded. This kind of upload will never lead to a partial upload which is both its strength and its weakness. It can be its weakness if the entire upload fails because there is a problem in the very last object in the upload request.
     143
     144Select **Upload data in chunks of objects** to upload the objects in a sequence of requests with a predefined size. You can enter a preferred size for an upload request (called the "chunk size"). Depending on its value JOSM will submit a number of upload requests (the number is displayed on the right of the input field for the "chunk size"). In contrast to the former option, every upload of a chunk can either succeed or fail. You will get some coarse grained progress feedback because JOSM will inform you when an individual chunk has been uploaded successfully or when its upload has failed. Uploading in chunks is in most cases slower than uploading in one requests, though.
     145
     146Select **Upload each object individually** to upload each object with an individual upload request. You will get very fine grained progress feedback because JOSM will inform you when an individual object was uploaded successfully or when its upload has failed. Note that this option is in most cases the slowest option.
     147
     148**Recommendations**
     149* For small (<1,000 objects) to medium upload sizes (<5,000 objects), choose **Upload data in one request**
     150* For medium to large upload sizes (> 5,000 objects) choose **Upload data in chunks of objects**. A chunk size of 1,000 is a good value to start with.
     151* Don't use **Upload each object individually** unless you have a specific reason to do so. This is basically a legacy strategy from former versions of the OSM server.
    111152
    112153==== Adding tags to the changeset ====
    … …  
    126167Note that the required upload comment is also a tag. You can either enter it in the Tag Configuration Panel with the key {{{comment}}} or in the Basic Settings Panel in the text input field provided there.
    127168
    128 ==== Choosing the changeset to upload to ====
    129 In the Changeset Configuration Panel you can select what [wikitr:/Help/Concepts/Changeset changeset] the data is uploaded to, see the screenshot below:
    130 
    131 [[Image(changeset-config-panel.png,link=)]]
    132 
    133 JOSM uploads to a new changeset if **Upload to a new changeset** is selected. This is the standard setting.
    134 
    135 If you want to upload to an existing changeset you have to select one of the available changesets from the drop down list. This list is only enabled if there are open changesets which you can upload data to because you own them. Click on [[JOSMImage(dialogs/refresh)]] ''Refresh'' to load the list of available open changesets from the server. If there is at least one open changeset available you can select the radio button **Upload to an existing changeset** and select a changeset.
    136 
    137 Click on [[JOSMImage(closechangeset,24,link=,bottom)]] **Close Changeset** to close the currently selected open changeset. This is for convenience only. You don't have to close a changeset here in order to run a successful upload.
    138 
    139 After a successful upload JOSM can either close the changeset used or leave it open for another upload. The default setting is to close it. You can configure whether JOSM should leave it open by unselecting the checkbox **Close changeset after upload**.
    140 
    141 
    142 ==== Configuring the number and size of upload requests ====
    143 JOSM uploads geo data with one or more **upload requests** to a [wikitr:/Help/Concepts/Changeset changeset] on the OSM server. In the Advanced Configuration Panel you can decide about the number and the size of upload requests, see screenshot:
    144 
    145 [[Image(advanced-config-panel.png,link=)]]
    146 
    147 Select **Upload data in one request** to upload all object in one request. If you're uploading a medium to large number of objects this might take some time and JOSM will not be able to inform you about the progress. There are only two outcomes of such an upload: the upload either succeeded or it didn't. In the former case everything is fine, in the later no objects at all have been uploaded. This kind of upload will never lead to a partial upload which is both its strength and its weakness. It can be its weakness if the entire upload fails because there is a problem in the very last object in the upload request.
    148 
    149 Select **Upload data in chunks of objects** to upload the objects in a sequence of requests with a predefined size. You can enter a preferred size for an upload request (called the "chunk size"). Depending on its value JOSM will submit a number of upload requests (the number is displayed on the right of the input field for the "chunk size"). In contrast to the former option, every upload of a chunk can either succeed or fail. You will get some coarse grained progress feedback because JOSM will inform you when an individual chunk has been uploaded successfully or when its upload has failed. Uploading in chunks is in most cases slower than uploading in one requests, though.
    150 
    151 Select **Upload each object individually** to upload each object with an individual upload request. You will get very fine grained progress feedback because JOSM will inform you when an individual object was uploaded successfully or when its upload has failed. Note that this option is in most cases the slowest option.
    152 
    153 **Recommendations**
    154 * For small (<1,000 objects) to medium upload sizes (<5,000 objects), choose **Upload data in one request**
    155 * For medium to large upload sizes (> 5,000 objects) choose **Upload data in chunks of objects**. A chunk size of 1,000 is a good value to start with.
    156 * Don't use **Upload each object individually** unless you have a specific reason to do so. This is basically a legacy strategy from former versions of the OSM server.
    157 
    158169=== Running a very large upload ===
    159170An upload is considered to be very large if its size exceeds the maximum size of a changeset on the OSM server. Currently, the upper limit for the size of a changeset is 10,000 objects and if JOSM detects that your upload is bigger it displays the following information in the Upload Dialog:
    … …  
    172183
    173184* whether JOSM should fill up one changeset and return to the Upload Dialog. Select this option if you want to have full control over the changesets created for the upload.
     185
    174186
    175187== Error and Warning messages ==
    … …  
    197209* Click on **Continue Uploading** to continue the upload with as many new changesets as necessary.
    198210* Click on **Go back to Upload Dialog** to go back to the Upload Dialog. There you can select another changeset to upload the remaining objects to.
    199 * Click on **Abort** to abort uploading and return to the main map editing interface.
    200 
     211* Click on **Abort** to abort uploading and return to the main map editing interface.
    201212
    202213=== Deleting nodes that are still in use ===
    … …  
    215226After 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.
    216227
     228=== bounding box very large ===
     229If the bounding box of the changeset is very large: JOSM displays an a warning: you can continue by clicking on "Upload Changes" or stop by clicking on "Cancel" and split your changes.
     230
     231[[Image(error-dialog-large-bounding-box.png,link=)]]
     232
     233**Note**: The size of the bounding box which is considered as very large can be set in advanced preferences (`upload.max-area` (default is `3.0`)).
     234
    217235== See also ==
    218236* [[JOSMImage(uploadselection)]] [wikitr:/Help/Action/UploadSelection Upload Selection to OSM]