I am a French contributor and I noticed that it is very complex, if not impossible, to determine what changes have been made on OSM, even on a rather small zone.
This is because, using tools such as OSMCha, we are in fact polluted by a lot of changesets that have a bounding box very wide that unfortunately include our area of interest, without having any change within it.
I understand that sometimes these kind of edits are needed (well even this is debatable, why couldn’t they be splitted) during large scale integration. However all those commits do not all fall under this reason.
Should we adapt tooling as suggested in this enhancement proposal of OSMCha to be able to observe history of a zone with changes only within a bounding box ? (And sorry if this tool exists and I was not able to find it).
Or should OSM be more restrictive and reject with an error instead of a warning changes with a large bounding box ?
Meta’s Daylight maps introduced the concept of logical changesets (“LoChas”) that break a changeset into smaller, spatially related units. Clearance carries this idea forward. It may make sense to implement this in OSMCha (or in OSM itself).
If we remove bboxes, we would need another spatial indexing method for changesets (could DGGs work? Something like: this changeset touched x, y, z grid cells, and nothing in between). Bboxes are small in size to store, and easy to compute, so any other indexing method would have its own cons.
The way I understand this feature was kind of the opposite of what we need here. Isn’t in contrary filter out changeset that are too “small” compared to the search area?
This seems like the perfect exemple of the kind of things we don’t want. Changeset with huge bbox are harder to review, harder to revert and pollute the history view of large area.
In my opinion, the way to go forward should not necessarily be to update the tooling to be able to better view history depending on area of interest, but we should find a way to restrict and prevent such change with large bbox when not properly justified.
Then I guess saying the above is the easy part, the effort lease in defining criteria and means to prevent this kind of bad changeset, and for that my technical knowledge of OSM is not deep enough to propose interesting options.
In my opinion, this is exactly the kind of changeset that is easier to review and easier to revert. With one glance you can see that the same edit has been made to many restaurants of the same chain. If this is a bad edit, there’s one changeset to revert.
If this was done in ten individual changesets, a reviewer would have a hard time figuring out what exactly happened. No need to search for other similar changes in other changesets, no need to compile a long list of changeset ids in case of problems.
What would be bad is a changeset that changed different things on independent restaurants.
IMHO this is a usability issue of changeset browsers which should break down huge bboxes into several smaller ones which can be done with a small computing effort.
I mean, what might be a solution is tackling the problem from an editor side. Like the editor could cluster the objects, which a user want to edit and split the upload in multiple changesets. If those objects are too far apart. Still if I change France, Russia,… it will cover “whole” world. But if I change a restaurant in Spain and a hotel in Canada, the editor will “force” me to create 2 dedicated changesets.
Though as a downside, it will be pretty hard to find mass-edits anymore, as a change to all McDonalds will be split over thousands of changes.
There is https://simon04.dev.openstreetmap.org/whodidit/ which does just that: Shows only tiles where there have been changes. To review the actual changes, it still forwards to achavi or osmcha, which may struggle with large regions affected.
OSM latest changes might be of help. While it can only look back 30 days (and only filter by user or comment, so best used without a filter), even without filters you could e.g. do a check and load all changes for that area (which is defined by the viewbox of the map as bounding box) every 4 weeks and be fine.
if, for example, you want to filter changesets by bounding box or City name (city doesn’t work always… bounding box seems more solid) try to write anything in the “Changeset size bound” field. If You write “1” or “2” in the size bound field this will filter out all the changesets bigger than 1 or 2 times the bounding box.
It works for me give it a try ! Don’t leave the field empty
You are correct. To be fair, the wording is very confusing. It says it will “Filter changesets that have an area lower than X times the area of your BBox” which I would interpret to mean it filters out those changesets, but it’s actually intended to mean that it will filter for those changesets. The help text for the other boxes are worded the same way, but in those cases it’s more obvious that “filter out” is not the intended meaning.
It’s also worth noting that this risks missing changes that are within the area you’re filtering on if the changeset also changes something far away.
To point out the obvious: this issue has been discussed many times and the solution is to extend the data model and the API to allow for multiple bounding boxes per changeset (for backwards compatibility reasons a single bounding box version should likely be retained). Editors can then split changesets up as they deem sensible, still maintaining a single reference for the whole session.
Simply nobody has got around to doing it yet and naturally the implementation is not really the problem, the larger hurdle is bumping the API version (which might be insurmountable).
The other option is for changeset analysis tools to do more work to give users the option to filter out larger changesets when they search for a given area.
In theory, such a tool could first find all changesets with an intersecting bounding box, keep all those wholly within the area of interest, and do additional checks on the others to see if any affected objects are within the area of interest. If might be too computationally intensive to be feasible though…
