PoC: Automatically split geographically distant edits into linked changesets\

[Sembauke]

This change starts from one practical problem that is most visible with new users: a single editing session can contain unrelated edits spread far apart, and uploading them as one changeset makes review noisy, confusing, and harder to trust. New mappers often make exploratory edits in multiple places before saving, so they are the group most likely to run into this.

The goal here was to let iD separate those edits automatically, while still keeping dependent objects together so uploads remain valid.

The core of that work is a new splitter in modules/core/changeset_splitter.js, exported from modules/core/index.js as coreChangesetSplitter. It builds connected components from the changed entities with union-find, linking ways to their nodes and relations to their members. After that, it uses location data and extent checks to cluster components geographically. It keeps an early return for small local edits, handles deleted entities by resolving locations from changed data when graph entities are missing, and includes cycle-safe traversal for relation membership.

modules/core/uploader.js now uses that splitter before upload. Instead of one putChangeset call with everything, it uploads groups sequentially. It tracks split state and uploaded entity IDs so local history can be reverted group by group as each part succeeds. Comment text is also annotated with part information, and later parts reference the first uploaded changeset URL. This gives clearer auditability when one editing session becomes multiple uploads.

On the Save screen, modules/ui/sections/changes.js now renders grouped change lists when splitting occurs, rather than a single flat list. The warning message was updated to explicitly tell the mapper that edits are too far apart and will be uploaded separately. Related strings were added in data/core.yaml, and css/80_app.css adds spacing and titles for grouped sections so the layout stays readable.

The test coverage for this feature was built out in three new files: test/spec/core/changeset_splitter.js, test/spec/core/uploader.js, and test/spec/ui/sections/changes.js. The splitter tests cover structural integrity, geographic partitioning, deleted-entity behavior, cycle handling, and edge cases. The uploader tests cover sequential multi-group behavior and split comment linking. The UI tests cover split messaging and grouped rendering behavior.

ref: #5424

[k-yle]

this is already extremely complex, and will get even more complex once we consider split merge conflicts.

For example, if the first changeset chunk has a conflict, and while resolving that conflict, it introduces a new merge conflict with the second changeset chunk (which has to be "rebased"¹). I can imagine this happening for very long route relations, or relations that contain coastline segments.

---

I think a much simpler alternative would be to teach new users how to edit well, instead of trying to repair the situation.

For example, if they navigate too far away from the centroid of their current changeset, then show a warning like this which blocks futher editing:

This works nicely because it allows the user to gradually increase the size of their changeset (for example, extending a bus route relation), but they can't "jump" to a completely different place

Footnotes

1. by prompting the user again to resolve the same conflict? ↩

[Sembauke]

Sure I will take another look at this and simplify it when I have time.