Show new/modified/deleted count in place of "<edits> 🖊" in changeset card

[andrewharvey]

Problem

The current " 🖊" count in the changesets cards makes it hard to know exactly what type of edits were made.

Description

In OSMCha it shows added/modified/deleted feature counts as which is very clear, it makes it easy to scan through a list of changesets for example to spot only new features, vs deletions or modifications. I suggest to change " 🖊" count to something like OSMCha with | |

Screenshots

[tomhughes]

I think it would be very hard to fit in that much information in the space available - using colour would probably make what is currently a very subtle indication into something much more garish that wouldn't really fit with the surrounding design.

[mmd-osm]

I suppose this will be rather slow, because we don’t store this information on changeset level.

[AntonKhorev]

We can start storing these counts for new changesets.

[mmd-osm]

I’m sure you’d need to backfill this information for all changesets, if you don’t like users complaining about inconsistent numbers in the future.

[AntonKhorev]

We can backfill it as slow as we need and tell the complaining users to use osmcha during that time.

[mmd-osm]

I just checked this topic from cgimap side. It shouldn't be too much effort. We anyway have all details about created/modified/deleted nodes/way/relations. It boils down to an additional UPDATE changesets SET created_objs = created_obj + $1, ... WHERE id = $n during diff upload, which can be enabled by some new feature flag.

Not sure if we want to expose these new values through the API, or changeset dumps. Maybe later.

[maro-21]

In OSMCha it shows added/modified/deleted feature counts as

If OSMCha has it, why copy the same thing to osm.org? If someone needs accurate data, that's what OSMCha is for.

[andrewharvey]

If OSMCha has it, why copy the same thing to osm.org? If someone needs accurate data, that's what OSMCha is for.

Better to have this by default on OSM.org in my opinion. Fragmenting into many different tools makes the learning curve harder and many people won't discover those tools. Then you had the add challenge of needing to copy paste changeset IDs all the time because all you have is a link to osm.org.

Currently OSMCha is very painful to use, 18 seconds load time for each changeset to review, 40 seconds to load the list of changesets, if they have a useful feature then that's more the reason to add it back into OSM.org.

[mmd-osm]

OSMCha is very painful to use, 18 seconds load time for each changeset to review, 40 seconds to load the list of changesets

If there's a performance issue with OSMCha, why not report it in their repo in the first place? https://github.com/OSMCha/osmcha-frontend/issues

[andrewharvey]

If there's a performance issue with OSMCha, why not report it in their repo in the first place? https://github.com/OSMCha/osmcha-frontend/issues

Already has been OSMCha/osmcha-frontend#725 OSMCha/osmcha-frontend#719

[mmd-osm]

Yes, I know those. I guess you need to keep bugging folks over at OSMUS: https://openstreetmap.us/our-work/charter-projects/osmcha/

[matkoniecz]

If OSMCha has it, why copy the same thing to osm.org? If someone needs accurate data, that's what OSMCha is for.

By that logic we should also remove map display, as there are already sites displaying osm-based maps.

And editor, as there also third-part sites with osm editor.

And basically everything else.

Just because some other site has something it does not mean that osm.org would not benefit from it. Also osmcha is poorly maintained and broken is several ways (yes, there are issues and reports dating back months/years at this point - see say OSMCha/osmcha-frontend#492 OSMCha/osmcha-frontend#265 - and not even closing one of reports of duplicate was done)

[mmd-osm]

The most notable thing I find worth porting over from osmcha is the changeset visualization. Other projects are facing significant efforts to generate augmented diffs (in particular by keeping a local copy of all data up to date). We have direct access to all relevant data and could probably do with much less effort. Not a topic for Rails but maybe cgimap.

[mmd-osm]

@AntonKhorev : I propose to get started with additional columns for the changesets table. It should be similar to the existing num_changes column, and ideally supports something like:

        UPDATE changesets
        SET num_create = num_create + $1,
            num_modify = num_modify + $2,
            num_delete = num_delete + $3
        WHERE id = $4