id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
17664	Add a possibility to rearrange order of objects for bigger multi-changeset uploads to look more human-friendly	Atakua	team	"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.
"	enhancement	closed	normal		Core	latest	wontfix	upload, changeset