| 5 | | [[Image(source:/trunk/images/upload.png)]] ''Keyboard shortcut:'' '''{{{Ctrl-Shift-U}}}''' |
| 6 | | |
| 7 | | '''Upload new, modified, and deleted objects in the current data layer to the server.''' |
| 8 | | |
| 9 | | Geo 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 [http://www.openstreetmap.org public maps] and can be used by other members of the OSM community. |
| | 5 | [[Image(source:trunk/images/upload.png)]] ''Keyboard shortcut:'' **{{{Ctrl+Shift+U}}}** |
| | 6 | |
| | 7 | **Upload new, modified, and deleted objects in the current data layer to the server.** |
| | 8 | |
| | 9 | Geo 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 [http://www.openstreetmap.org public maps] and can be used by other members of the OSM community. |
| 23 | | The OSM project calls such a package a '''[wiki:/Help/Concepts/Changeset changeset]'''. A '''changeset''' is a collection of related changes (new objects, object modifications, or object deletions) applied to OSM data. |
| 24 | | |
| 25 | | Changesets are different from '''upload requests'''. A changeset is a '''logical''' grouping of [wiki:/Help/Concepts/Object objects], whereas an upload request is a '''technical grouping''' for transferring geo data to the central OSM server only. In JOSM we say, that objects are uploaded '''using''' upload requests '''to''' a changeset. The JOSM Upload Dialog allows aspects of the upload requests and changeset objects to be configured. Some of the settings are compulsory (i.e. the user has to configure them before geo data can be uploaded) but most of them are optional and JOSM works with reasonable default values. |
| | 23 | The OSM project calls such a package a **[wiki:/Help/Concepts/Changeset changeset]**. A **changeset** is a collection of related changes (new objects, object modifications, or object deletions) applied to OSM data. |
| | 24 | |
| | 25 | Changesets are different from **upload requests**. A changeset is a **logical** grouping of [wiki:/Help/Concepts/Object objects], whereas an upload request is a **technical grouping** for transferring geo data to the central OSM server only. In JOSM we say, that objects are uploaded **using** upload requests **to** a changeset. The JOSM Upload Dialog allows aspects of the upload requests and changeset objects to be configured. Some of the settings are compulsory (i.e. the user has to configure them before geo data can be uploaded) but most of them are optional and JOSM works with reasonable default values. |
| 65 | | * '''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. |
| 66 | | |
| 67 | | * '''Collisions with other mappers''': if you upload 30,000 objects in one request and if the server encounters a problem on the 29,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 30,000 objects will then have to be uploaded again. On the other hand, if you upload 30,000 objects with 10 requests containing 1,000 objects each and the server encounters a problem on the 29,999th object then you only have to repeat the last upload request for the 29,000th to 30,000th objects. Objects 1-28,999 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. |
| | 65 | * **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. |
| | 66 | |
| | 67 | * **Collisions with other mappers**: if you upload 30,000 objects in one request and if the server encounters a problem on the 29,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 30,000 objects will then have to be uploaded again. On the other hand, if you upload 30,000 objects with 10 requests containing 1,000 objects each and the server encounters a problem on the 29,999th object then you only have to repeat the last upload request for the 29,000th to 30,000th objects. Objects 1-28,999 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. |
| 139 | | 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. |
| 140 | | |
| 141 | | 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. |
| 142 | | |
| 143 | | 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. |
| 144 | | |
| 145 | | '''Recommendations''' |
| 146 | | * For small (<1,000 objects) to medium upload sizes (<5,000 objects), choose '''Upload data in one request''' |
| 147 | | * 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. |
| 148 | | * 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. |
| | 139 | 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. |
| | 140 | |
| | 141 | 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. |
| | 142 | |
| | 143 | 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. |
| | 144 | |
| | 145 | **Recommendations** |
| | 146 | * For small (<1,000 objects) to medium upload sizes (<5,000 objects), choose **Upload data in one request** |
| | 147 | * 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. |
| | 148 | * 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. |
