Add a possibility to rearrange order of objects for bigger multi-changeset uploads to look more human-friendly

[Atakua]

When JOSM is used to upload changes that span multiple changesets, the order of objects chosen to
be present in the first and subsequent changesets, while being correct from the referential point of view, does not help with understanding of what geographical objects are about to be added.

For example, this mail post describes one's confusion when seeing that first a large amount of untagged nodes are added, and only consequent changesets bring ways, relations and tags that bind these nodes into polygons: ​https://lists.openstreetmap.org/pipermail/imports/2019-April/005967.html

To quote a Wiki-page ​https://wiki.openstreetmap.org/wiki/Upload.py:

smarter-sort.py
This script re-orders changes in an OsmChange file so that they appear a little more human-like and minimize the probability of conflicts during a multi-part upload.

<...> For example, files produced by osm2change.py will have a suboptimal ordering, with creations first, modifications next, deletions last. Inside creations, relations come after ways, and ways come after nodes. Inside deletions, the order is reversed. If you then split such a file, the first couple of parts will have only nodes, and ways or relations connecting them will come later and in bulk. <...>
When you use this script before splitting the big changeset, then the most independent changes will appear first. A dependency tree is calculated for creations, modifications and deletions. Additionally, each deletion operation must depend on any modification and deletion that appears before it in the original file because there may exist a dependency that is not implied by the contents of the file alone. For example, when a node is removed from a way or relation, the way or relation must first be modified to not include the given node, and the actual deletion of the node must come after it. But since only the new version of the way or relation is present in an .osm or .osc file, the dependency can not be inferred from the contents of the file).

The JOSM uploader would benefit from the same logic of tracking dependencies between nodes, ways and relations. Adding an option/possibility to reorder objects being sent to the database in the first and consequent changesets will simplify reading the history of such changesets.

It may be beneficial to keep both the current and new "smart" uploading order available to the user, in cases when it makes no sense to spend resources of rearranging things.

[stoecker]

Simply upload more often if you want logically related changes. The current upload logic of JOSM is the result of many interations and we wont modify it for optical reasons.

[ggg_mail@…]

Hi, thanks for reaching back! "Upload more often" is not a viable option when one imports data obtained from external sources, then loaded into JOSM for final touch-ups and then uploaded through JOSM UI. Compared to when new objects are created manually one by one in JOSM, all new imported data becomes available simultaneously. Reordering it at the upload time would simulate the expected "manual" object creation pattern expected by many.

An alternative would be simply to prohibit people from uploading more than one changeset at a time, thus forcing them to export prepared data layers into OSM/OSC files and then to use external scripts to finish the job.