By default, 'upload of changes in chunks of size' should be geographically close

[merylstreet]

I use this feature to break big changesets into chunks but the upload seemed to pick modified objects at random for each batch. I tried to investigate the code that does this upload but I'm not a professional coder...didn't find answer to my question.
Is there a way to upload chunks by geographical proximity?
I saw the upload order is "all nodes first, then ways, then relations", how does it pick the order of each modified node? By order of appearance in the .osm file or something else?
Sorry if this is not the right way to ask for this feature or if this already exists, I'm new here and didn't find the info in the docs.

[taylor.smock]

Related: #23760

We should probably check to make certain that the bbox is small enough for the API, but I'm not seeing anything that would let us know what the maximum bounding box size is. This might be a deliberate decision on the OSM API end (since it would be trivial to work around if we knew in advance what the maximum bounding box size is).

[merylstreet]

Thanks for your answer, didn't think about the bbox size aspect.
Currently JOSM handles it automatically though when selecting upload by chunk size, right?
I'm really curious how JOSM picks the items to upload when doing in chunks. If OSM API has these limitations and JOSM behaviour cannot be changed due to various reasons, maybe I could pre-process the data to make sure JOSM uploads it by geographical proximity?

[taylor.smock]

JOSM uploads unique id in JOSM. I'd have to check and see if it is sorted by low -> high or high -> low. I'd guess low -> high, which means that the last object you create will be uploaded first, and other objects will be uploaded in the order of their OSM id.

[stoecker]

JOSM does not really care in which order objects are uploaded as long as the order is nodes, ways, relations. For the relations it tries to sort them depending so that referred relations are before their masters.

Seems for nicer style objects are ordered by their ID, but that's only for good looks.

See trunk/src/org/openstreetmap/josm/data/APIDataSet.java​ and the sorters used there. That could be expanded for a regional sorting with lots of effort, but essentially I don't see the need for virtual creating smaller editing footprints. If the user did edit over a large area I don't see a reason to let this appear smaller.

Better strategy is simply to edit smaller areas and upload more often.

[merylstreet]

Thanks for the details. I understand that editing smaller areas is the obvious answer.
I will check further and see if I can find a way to pre-process beforehand, otherwise I might go with another upload tool.
Cheers!

[skyper]

You can always use Upload selection and leave the CS open to add more objects in the next round.