Filter changesets in History by bounding box area

[lectrician1]

A feature such as a slider that can filter the changesets by their bounding box area could help mappers sort through changesets in the area they are looking at without seeing the annoying larger changesets that cover the entire globe.

[tordans]

@lectrician1 do you know osmcha? You can setup filter which only show changes inside a specified bbox. You need to also set "bbox size bound to 1" (see https://github.com/mapbox/osmcha-frontend/search?q=bbox+size&type=issues for more). You can setup an rss feed and such as described in https://www.openstreetmap.org/user/wille/diary/47903.

[nitram9]

@lectrician1 this would be really really great. I have just submitted an issue for iD to have a new 'check' to reduce the number of unintentional large-area edits https://github.com/openstreetmap/iD/issues/8590

[Lee-Carre]

@tordans

osmcha? You can setup filter which only show changes inside a specified bbox.

I have to use OSMCha with the filtering you describe, because the osm.org/history list is flooded with so many non-local changesets as to make it unusable.

The problem, then, is that the behaviour is not as you describe.

While changesets with bounding boxes larger than my area of interest are indeed excluded, also excluded are changesets which do make local changes.

Besides, a tool-dev (@mmd-osm) has said that

Today there's no workable solution available to analyze large changesets.

So, even with OSMCha, I either have to manually wade through dozens of completely irrelevant changesets (which make zero local changes), or have to be unaware of larger bounding-box changesets which do make some local change(s).

While OSMCha is a tool which I generally like, it's also v0, meaning that the developers think it's not yet ready for prime-time (which would be v1+).

[mmd-osm]

For avoidance of doubt, I'm not involved in OSMCha development. The prototype I have presented uses alternative Overpass backends, while leveraging OSMCha's changeset display components to demo improvements.

[boothym]

Yes, a tick box for "only show changesets in view" would be very useful - so if you are looking at one town or city you can see just the ones wholly contained in your current viewport.

[mikelmaron]

While OSMCha is a tool which I generally like, it's also v0, meaning that the developers think it's not yet ready for prime-time (which would be v1+).

I don't think that's quite accurate and depends on what's meant by "prime-time". It's very much in production shape now. Could see it being a great service to integrate into openstreetmap-website. That would need some thinking (and maybe what you mean) -- particularly assessing usage volume and making sure infrastructure is in place, or hosted on OSMF infrastructure itself.

[kallejre]

I had similar issue today where after holiday season i wanted to catch up with changes made in local area over the past few weeks, but sadly there was recently very large undiscussed import, which was promptly followed by series revertions from DWG. So, how about adding option to OSM website's history (osm.org/history) view to hide changesets that don't fit into current bounding box? Luckily there's already this issue, so i won't create a duplicate one.

From technical viewpoint, this seems to be relatively simple change, adding around 10-15 lines of code in backend for how changesets are filtered (just additional nested if-statement and support for two new parameters on ln162), 15-20 lines for adding checkbox to frontend UI and passing checkbox and slider value to API in update() function. I think I'm missing here something from what receives response from API and converts it into pretty html.

Here's quick UI prototype for filtering. Slider could disappear when checkbox is unchecked. Some users might prefer numeric entry for determining how large bounding boxes should be selected, but i felt that having to type some value into the field would feel unnatural and inconsistent with rest of website's mouse-oriented UI. For same reason checkbox and slider don't have "Submit" button, if anyone wonders.

HTML code for the UI prototype below

```html

Hide very large changesets
Select size sensitivity:
Smaller  Larger

```

Another portion is so-called "business decisions" for determining the actual behaviour of the slider. I don't think that hiding a large changeset could hide many relevant changesets mostly due to probability of how changed elements are distributed around changeset area. The larger the changeset area, the less likely it is to contain modifications in currently viewed area. Obviously this should be optional feature deselected by default, but looking at large changesets, here in Estonia they are usually irrelevant changes often focusing on Russia or Norway.

Questionable part is deciding where goes the borderline for selection of the changeset. Initial idea was to show only changesets which fit fully in the viewport. Another suggestion involved calculating area of bounding box and comparing it against area of viewport, but I'm afraid performing such calculations might be too demanding for the server. Also, said area can't be a constant due to map having multiple zoom levels. Perhaps ignore changesets, where current viewport area is less than X% of the changeset area? X is determined by the slider.

Finally, we are talking here about spatial database queries done on server infra possibly millions times per second, meaning the more refined changeset filtering algorithm is selected, more significant performance impact it would have. Computationally least expensive could be following filter (based on existing method):

changesets.where("min_lon < ? and max_lon > ? and min_lat < ? and max_lat > ?",
                         bbox.min_lon.to_i, bbox.max_lon.to_i,
                         bbox.min_lat.to_i, bbox.max_lat.to_i)

PS. Probably I don't know how Ruby works because i have never used it, but shouldn't API changesets endpoint also support URL parameters open/closed=false, currently it seems to only check if parameter is present, not it's value. Therefore code from that part is probably not reusable for the changeset filtering methods.

[Lee-Carre]

@mikelmaron

While OSMCha is a tool which I generally like, it's also v0, meaning that the developers think it's not yet ready for prime-time (which would be v1+).

I don't think that's quite accurate and depends on what's meant by "prime-time". It's very much in production shape now.

From The Art of Unix Programming (§ Part Ⅲ. Implementation § Chapter 16. Reuse) § The Best Things in Life Are Open:

… …. A major consequent difference between open-source practice and elsewhere is that a release level of 1.0 actually means the software is ready to use. In fact, a version number of 0.90 or above is a fairly reliable signal that the code is production-ready, but the developers are not quite ready to bet their reputations on it. …

Authored by Eric Raymond. The same author of The Cathedral and the Bazaar.

I didn't state that I thought it wasn't ready for non-experimental usage, but that the developers didn't yet think it was (by their own standards). Re-read my original.

However, when fixes to mobile layout occurred only recently … well, QED methinks.

More often, version<1 is a comment on feature-completeness, rather than reliability, robustness, refinement (debugging) & such.

That would need some thinking […] -- particularly assessing usage volume and making sure infrastructure is in place …

See above 😄.

[mikelmaron]

@Lee-Carre I know the developers closely. I don't think use of version numbers, wherever they are cited from, is a good way to assess anything here in the OSM ecosystem -- please note the version number of the OSM API ;)

[mmd-osm]

I don't think that's quite accurate and depends on what's meant by "prime-time". It's very much in production shape now.

As long as mappers are facing issues with OSMCha when analyzing large changesets like described in this blog post. there's probably still some room for improvement. In this case OSMCha is not to blame. It's an Overpass limitation as Supaplex correctly noted, that simply needs to get fixed.

[kallejre]

Almost 2 months without any updates. What is current status of this issue? Is it abandoned? What stops it from resolving? If it's no longer wanted, why not close the issue then?

I'd like to see some sort minimalistic feature to filter changesets on website, because unlike other 3rd party tools, OSM website offers seamless transition between 3 main activities mapper would do: viewing, editing and reviewing.

[nitram9]

I can't speak for others but I am still very much in favor of implementation of something along the lines of what @kallejre posted on 06JAN22.

On Wed, Mar 9, 2022 at 9:34 AM kallejre @.***> wrote:

Almost 2 months without any updates. What is current status of this issue? Is it abandoned? What stops it from resolving? If it's no longer wanted, why not close the issue then?

I'd like to see some sort minimalistic feature to filter changesets on website, because unlike other 3rd party tools, OSM website offers seamless transition between 3 main activities mapper would do: viewing, editing and reviewing.

— Reply to this email directly, view it on GitHub https://github.com/openstreetmap/openstreetmap-website/issues/3242#issuecomment-1062675976, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE2AIZ2RMWJUPVZDGQYVZPDU7BPC3ANCNFSM47VPTUVA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[HolgerJeromin]

Almost 2 months without any updates.

I am shocked! (not) The oldest open issue in this repo is over nine years old. No need to panic. Most/all work here is done by unpaid developers.

What is current status of this issue? Is it abandoned? What stops it from resolving?

Interest and time of a developer probably.

I'd like to see...

You can go ahead and implement it yourself! The code is right here. I did not see your PR. But review take spare time, too.

[tomhughes]

To be fair @HolgerJeromin he did open #3417 with a suggested implementation but nobody has had time to review it yet.

It would probably have been more sensible to chase on the PR instead of here though.