Work in progress! - the following help text describes features not available yet in either tested or latest.

Upload to OSM

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 integraded 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 ​public maps and can be used by other members of the OSM community.

Please be careful with editing and uploading data. When in doubt that everything is ok, rather refrain from uploading and save the area locally on disk to check back to it later.

TOC(inline)

Changesets, upload requests, and upload strategies

Geo data contributed to the OSM server consists of nodes, ways, and relations. Because there are hundreds of mappers publishing their geo data on the OSM server it is important to track who published what data in which context. It would be tedious for mappers to describe for every singe node and every single way why it is published. A more convenient approach is to package a group of related objects and assign the package a comment, not the individual objects.

The OSM project calls such a package a changeset. A changeset is a collection of related changes (new objects, object modifications, or object deletings) applied to OSM data.

Changesets are not equal to upload requests, though. A changeset is a logical grouping of objects whereas an upload request is a technical grouping for the purpose of 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 one to configure both aspects of the upload requests to be used and of the changeset objects are uploaded to. Some of the settings are compulsory (i.e. the user has to configure them before he or she can upload geo data) but most of them are optional and JOSM works with reasonable default values.

Geo data can be retrieved later by the changeset it was uploaded to, it can't be retrieved by the upload request used. Changesets have a unique id, upload requests have not. For instance, ​this changeset includes geo data gained by tracing over orthofotos of the city of Bern, Switzerland. It isn't possible, though, to see which and how many upload requests have be used to fill it in.

One upload request into one changeset

In the most simple case there is only one upload request into a changeset:

This is the standard configuration used by JOSM. It is the preferred configuration

• for users uploading the result of converting a few GPS traces to OSM geo data
• for users uploading the result of tracing a few hours over aerial photos
• for users uploading the result of entering local knowledge about street names, points of interests, etc.

Multiple uploads into one changeset

This is an advanced configuration option which most users don't have to enable. It can be useful:

• for users who map using multiple data layer in JOSM and who want to upload the result of their work into one changeset
• 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 whole 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.

JOSM still supports to upload each object individually.

Please 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 50'000 objects. For the casual and normal user it is almost obsolete. In rare cases, it could be useful for power users.

Uploading large datasets into multiple changeset

JOSM also supports uploading large dataset which don't fit into one changset only.

This is an advanced option which only useful for power users. They can select this configuration if they have to upload a dataset with more than 50'000 new, modified, or deleted objects.

Choosing your upload strategy - when and how often to upload

There is no simple answer to the question when and how often to upload. You neither should edit the whole day and then upload everything at one nor upload every minute after adding a way.

Here are some rules of thumb:

• 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 with 100 individual upload requests than to upload them in one request including 100 objects.

• Collisions with others: 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. One has to fix the problem (i.e. by resolving a conflict) and restart uploading. The whole 30'000 objects will have to be uploaded again. On the other hand, if you upload 30'000 object with 10 request à 1000 objects and if the server encounters a problem on the 29'999th object then you only have to repeat the last upload request including the 29000th to the 30000 objects. Object 1-28999 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.

The Upload Dialog

Invoking

• Keyboard shortcut: CTRL+SHIFT+U
• Menü item File-> Upload
• Toolbar button

Checks before uploading

If the ​Validator plugin is installed, JOSM performs a quick check on the data. If it finds warnings or errors you'll be presented with a list of them and get the chance to correct the problems and try again or upload anyway. It's not necessary to fix all of that, but please don't go over it easily, especially not the errors.

JOSM also checks for limititations imposed by the OSM server:

• tag names and tag values must be shorter than 255 characters
• ways can't consist of too many nodes

If the objects you're uploading have cyclic dependencies (relation 1 refers to relation 2, relation 2 refers to relation 3, relation 3 refers to relation 1) JOSM can't upload them. JOSM will ask you to break up these dependencies first.

Error and Warning messages

Deleting node which is still in use

If your upload includes a deleted 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.

If the OSM server detects that the node is still in use it replies an error message which JOSM displays as follows:

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 conflict which you have to resolve manually.

After 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.