Openstreetmap-website: add link to open view in OSMCha, from changesets history pge

[mikelmaron]

OSMCha has a simple and full featured to examine the details of changesets. The OSM.org history page for changesets in a bbox or by a user is somewhat functionally limited. Adding a small link to OSMCha from the history page would make this service more discoverable and convenient.

Implementation (which myself or @willemarcel would look into) looks to only require a small modification to the view to add in links along the lines of these

https://osmcha.org/?filters={%22users%22:[{%22label%22:%22wille%22,%22value%22:%22wille%22}]}
https://osmcha.org/?filters=%7B%22in_bbox%22%3A%5B%7B%22label%22%3A%22-77.1593%2C38.8073%2C-76.9011%2C39.0082%22%2C%22value%22%3A%22-77.1593%2C38.8073%2C-76.9011%2C39.0082%22%7D%5D%7D

[tomhughes]

Our general policy is not to rely on third party sites that we don't control in this way - there are a few cases where we do so it's not impossible we could be convinced.

[mikelmaron]

I think the best comparison is the Exports page, which links to several resources including Overpass and GeoFabrik. The osm.org exports functionality is limited, and these third party services provide useful ways to get OSM data. Ideally osm.org could have an instance of Overpass, but would require the associated infrastructure work.

OSMCha is similar. osm.org changesets history view is limited in functionality, OSMCha provides something useful. Ideally, osm.org could host an instance of OSMCha, but would require additional infrastructure work.

[tomhughes]

It does indeed link to those resources and I'm pretty sure I was nervous about doing that...

The issue with adding links is a bit different actually to whether we relying on something we don't control - that is an issue but it's relatively minor because a link can easily be removed. It's not like the way the query tool relies on overpass for example.

The issue with links is more that once you add one everybody will want links to their own favourite tools adding.

[mikelmaron]

everybody will want links to their own favourite tools adding

Is that a bad thing? With some standards of expectations from the tools, shouldn't that make OSM.org more useful?

Specifically for changeset history, are there other tools to consider? I can't think of any off hand, though that doesn't mean there are not useful ones out there.

[woodpeck]

The bit I am concerned with about OSMCha is that it requires authentication even for simple read-only operations, and because it has the option of issuing changeset comments, it requests permission to "read your user preferences" and "modify the map". The good thing is that it still works for read-only stuff if you do not grant "modify the map", but still, we'd be sending everyone and their dog to a third-party platform which recommends that before they can see anything they grant the third party permission to "modify the map" in their name. I wonder if before proceeding with this, we should ask OSMCha if they can provide a modified entry URL (something with ?readonly=yes or whatever) that would not ask for the "modify the map" permission.

[woodpeck]

Specifically for changeset history, are there other tools to consider?

"Achavi" comes to mind.

[mmd-osm]

The bit I am concerned with about OSMCha is that it requires authentication even for simple read-only operations...

OSMCha already implemented some of the GDPR recommendations. "modify the map" shouldn't be required for read only activities, though.

"Achavi" comes to mind.

Achavi would be good, if we had some specific changes for very large changesets (bbox and timespan wise) merged. Handling such changesets isn't at all impossible (see example: http://dev.overpass-api.de/achavi/index.html?changeset=28764270), but requires some available time to actually integrate the changes.

Hardware wise, lz4 is a bit tight on CPU, z.overpass-api.de is almost 100% busy all the time. So before integrating Achavi on the main page, a bit of extra work would be needed.

[willemarcel]

@woodpeck the "modify the map" permission is required to post comments to a changeset from OSMCha.

About the authentication, we started requiring it because the LWG position paper about GDPR recommended to expose metadata only to authenticated users. As OSMCha shows metadata both from changesets and from each map feature and hide metadata from anonymous users would mean like build a new system, we decided to simply require authentication for everything.

[woodpeck]

Yes, I think that requiring the login to view details is sensible, sorry if that sounded like a critique. It is a nuisance but a necessary one IMHO and sooner or later the OSM web site will also do it. It's just that the permission granting is a bit intransparent - for a long time I never even used OSMCha because I didn't trust it (a bit like if you install a simple stopwatch app on your mobile phone and it requests permission to use your camera and you go WTF I only wanted to use a stopwatch). Someone then told me that I can simply deselect the "modify the map" and it will still work ;)

[mmd-osm]

Would replicating OSMCha on osm.org infrastructure even be possible? The changeset map depends on an external aws s3 bucket (https://s3.amazonaws.com/mapbox/real-changesets/production/) and I don’t remember seeing this part of the process being open source. This may not be a big deal, though it means that osm.org still wouldn’t have full control over the whole process and needs to open up GitHub issues with external parties in case the process broke down.

[mikelmaron]

@mmd-osm the real changesets are produced by an instance of Overpass. So it's possible to redeploy the entirety of OSMCha. And that could be a good thing. But a lot of work, certainly a lot more than a link. For now, I'd like to focus on integration through links, and have complete hosting as a possible longer term effort.

[andrewharvey]

I've been wishing for this for a long time. I think an "open with" menu that then list all the options like OSMCha, achavi is best. Same goes for other pages like node/way/relation details which would have "open with" linking to http://osmlab.github.io/osm-deep-history/ etc.

1. It helps bring awareness to these tools to people who would otherwise not know they existed
2. Makes it easier for less technical people (who might know know exactly how to copy and paste the changeset id and construct the URL for OSM cha.
3. Makes it much faster and easier for even expect OSMers.

So long as the 3rd party service is happy to be linked to and accept the traffic and there are no grave concerns about privacy, I don't see why we shouldn't provide a link.

[lectrician1]

If OSM doesn't want to link it, then I think development of better Changeset analysis tools needs to happen.

Possible changes:

• Changeset changed element geometries should viewable (like OSMcha)
• When you click on an edited node/way/relation in the list for a Changeset page, it shouldn't bring you to page for that element, but rather a page that compares the previous and next Version of that element from the Changeset.
• The the Version comparison should show changed geometries of elements (like OSMcha).
• The the Version comparison and All Versions page should highlight the changed tags of elements (like OSMcha).
• The "View History" link should not be tucked at the bottom of every element page next to "Download XML". It's barely visible.

Also, new mappers don't even know what OSMcha is.

[RobJN]

Links to OSMCha and Achavi would be useful. We have a guideline for adding featured tile layers to osm.org so it feels like we need a similar guidance document for "linked to"/"open with" urls.

As a started, may I suggest the following. If we are worried about adding too many services then we could ask for usage stats to be shared in advance and only accept links to services that have at least 3000 users per year.

Would this work for OSMCha @mikelmaron? And does it work for the existing GeoFabrik link @woodpeck?

Must have:

• Internally supported. The service provider/author must be in favor of having their service linked to from the website.

• Global scope and coverage. The proposed service must cover the whole earth (well, except for the polar regions that are cut off because of the square Mercator projection).

• Capable of meeting traffic demands. The proposed service must be capable of accepting the traffic volume from the OpenStreetMap website.

• Reliable service. The proposed linked to service must be reliable in terms of uptime and availability.

• Up-to-date data. Services maintaining minutely updates are preferred, but update periods of up to two weeks may be acceptable depending on the content of the map. Services intended for quality assurance must be generally no more than one day out of date.

• Open data. The proposed service must not use any non-free data in a way that presents it as open data to the average user (this is to prevent non-free data being coped into OSM by unsuspecting users).

Should have:

• Unique. The proposed service should offer something unique in approach or execution. For example, this could be based on particular theme or created using a particular set of software/technology which is not currently represented.

• Interesting. This hugely arbitrary criterion includes pleasing aesthetics, social significance and benefit, humour, timeliness, newsworthiness, appeal to the community, and many other arbitrary value judgements. To assess appeal to the community, it may be required that basic usage stats are shared.

• Non-commercial. Non-commercial services are preferred. However, commercial services which provide benefit to the community will be considered.

• Free and Open. Free and Open services are preferred.

• Data protection. The linked to service follows the LWG position paper about GDPR recommended to expose metadata only to authenticated users.

[mikelmaron]

@RobJN nothing objectionable there to me in that policy proposal