Openstreetmap-website: Link to openplaques

[pyrog]

Hi,

Could you add a link to OpenPlaques for keys openplaques:id ?
See Key:openplaques:id

Thanks,

https://github.com/tyrasd/overpass-turbo/issues/443

[tomhughes]

See this is why wikipedia etc were bad precedents to set...

[Bibi56]

What is bad then is to accept to store identifiers (here openplaques:id). If an id exists in the database, it makes sense to refer to the corresponding page on osm.org.

[tomhughes]

Whether it should be in the data is a question that people certainly have opinions on but it's distinct from whether the data browser should link it - there are plenty of other users of the data after all!

The question is, what is the utility of linking it in the data browser given that he data browser is not supposed to be some sort of end user gazetteer. Really the only plausible reason I can think of is to allow people to quickly check that the ID is correct by visiting the link?

[pyrog]

Really the only plausible reason I can think of is to allow people to quickly check that the ID is correct by visiting the link?

Yes. 😄

Other points:

• it help to keep OSM database "clean".
• it limit it maintenance.
• it help to learn easily how to use keys.

OpenPlaques seem to be a good project that could interest history amateur all over the world.
(PS: I'm not implicated in this project)

Wikimedia commons is a "major" project too (18 2830 tags. It pictures help OSM contributors and users. See #834

[Bibi56]

See this is why wikipedia etc were bad precedents to set...

The issue may be that it could mean more maintenance. but the logic is already available and maintained elsewhere, namely in Wikidata. You "just" need to upload and use this table and refresh it from time to time.

[grischard]

We currently have those links hardcoded, which creates work for the maintainers. Would it be a good idea to have those as tag link templates outside of this code base so that they can be maintained externally?

[eehpcm]

@tomhughes

The question is, what is the utility of linking it in the data browser given that he data browser is not supposed to be some sort of end user gazetteer. Really the only plausible reason I can think of is to allow people to quickly check that the ID is correct by visiting the link?

Here is a plausible reason for you. From the wiki page for inscription: "Currently there is a limit of 255 characters for values. However, if this is a commemorative/historical plaque, you can add the full inscription to openplaques.org and then link the entry with the OSM object, using openplaques:id=."

The reason for making the openplaques ID a link is to get around a limitation in the database. It is a workaround I'd prefer not to have to use, but there's no sign the 255-char limit will be lifted any time soon. Currently, it is awkward for data consumers to access the openplaques data for a plaque if that is the only way to include the full inscription. Awkward because they have to cut and paste the ID and know how to use it to form the necessary URL, which means they probably have to google for openplaques and do some thinking.

Or are you arguing that we should not be including the inscription in the first place because OSM is a map not a gazetteer? There are many things OSM records that are not available on a conventional printed map. Most of them are recorded because consumers find them useful. We could remove every feature that is not available on a traditional printed map, but I suspect that more people would then use Google Maps or Bing instead. I'm not convinced that adhering to the model of printed maps is a good idea.

As I see it, there are four options:

• Remove the 255-char limit on inscriptions (I'd prefer this).
• Make the openplaques ID a link (it's more effort for mappers to create an openplaques entry if required, but it works).
• Deprecate inscription=* as well as openplaques:id=* and/or not return that information in response to a query because OSM is a map, not a gazetteer.
• Leave things as they are.

TBH, I see no utility in leaving things as they are. The current handling is equivalent to "There's more information about this object but I'm not going to make it easy for you to find it." Tantalising but unhelpful and frustrating.

[pyrog]

Remove the 255-char limit on inscriptions (I'd prefer this).

💯

Make the openplaques ID a link (it's more effort for mappers to create an openplaques entry if required, but it works).

👍

Also, could you reuse the same "rules" used by JOSM based on Wikidata and OSM data items? 😃

A rule in wikidata already describe how to link to open plaques.

[tomhughes]

The 255 character limit appears completely irrelevant to me, and yes I absolutely think that monumental inscriptions don't belong in OpenStreetMap, any more than the text of war and peace does.

[pyrog]

@grischard Would it be a good idea to have those as tag link templates outside of this code base so that they can be maintained externally?

@tomhughes The 255 character limit appears completely irrelevant to me

So, could you have a look to https://josm.openstreetmap.de/wiki/Help/Action/Tag2Link ? 😉

[eehpcm]

@tomhughes

The 255 character limit appears completely irrelevant to me,

It's relevant to those mapping plaques with inscriptions that are more than 255 characters. Guess who encountered such a plaque recently...

and yes I absolutely think that monumental inscriptions don't belong in OpenStreetMap, any more than the text of war and peace does.

A way of encouraging people not to include the tet of inscriptions would be to make openplaques:id a link. Then the 255-character limit wouldn't matter. Then the text of the inscription wouldn't be in the OSM database. This is why we provide wikipedia/wikidata tags (where available) so that we don't have to provide descriptions of an object.

Or do you mean OSM shouldn't give any hint as to the inscription? So that tourists cannot determine in advance if the plaque is one they're interested in visiting? Maybe we shouldn't even identify it as a plaque. Maybe we shouldn't identify what type of goods a shop sells. Maybe we shouldn't identify shops as anything other than buildings - if people want to know what the building is they have to physically go and look at it.

Slippery-slope arguments are great fun. :) More seriously, having information about objects allows plans to be made. If you're already there and can see for yourself what the object is then you don't need a map.

[tomhughes]

Why would I need to look at what JOSM does? I have no plan to write code to do this.

If somebody else wants to offer a PR to do it then that can be considered when it happens. Until then this issue is just so much hot air.

[gravitystorm]

Slippery-slope arguments are great fun. :)

No they aren't. They are pointless and waste everyone's time. Please do not continue like this - this is an issue tracker, not a debating forum.

[eehpcm]

@gravitystorm

No they aren't.

It wasn't apparent, but I actually agree with you that slippery slope arguments are (usually) a bad idea. Like the implicit, distributed slippery slope argument that went "Wikipedia links -> openplaques links -> War and Peace."

this is an issue tracker, not a debating forum.

This is not a debating forum but feature requests count as issues (or so I thought). If feature requests are dismissed for what the requester feels are poorly-considered reasons, should the requester stay silent?

Turning openplaques:id into a link would permit the deprecation of inscription=* being used with plaques that are suitable candidates for openplaques (not all are). Which seems to be a reason why those who think inscriptions ought not to be in the database would support making openplaques:id a link rather than fight it.

[Marc-marc-marc]

I think the arguments against have not been heard, I try to summarize

• avoid having to work each time the link changes or each new request like -> could be solved with a PR externalizing the "osm tag -> web link" code as @grischard suggests
• the links on osm.org are made for a return to the contributor. therefore saying that it allows access to a text of more than 255 characters makes no sense. reading the full content of the plate does not help the osm contribution. this is for the end user.

PS: It's a very ugly tag for a ref

[eehpcm]

@Marc-marc-marc

I think the arguments against have not been heard, I try to summarize

An interesting summary of the arguments against. :)

avoid having to work each time the link changes or each new request like

That's a fair point. It's extra work. I don't like extra work. Not even when somebody else is doing it.

could be solved with a PR externalizing the "osm tag -> web link" code#
as @grischard suggests

You mean it's not already table-driven? I'm surprised. But your phrasing reads more like an argument for than against. The real argument against this is that it might encourage people to request similar linkages and "taint the purity of the map."

the links on osm.org are made for a return to the contributor. therefore
saying that it allows access to a text of more than 255 characters makes
no sense. reading the full content of the plate does not help the osm
contribution. this is for the end user.

That is a valid point. However, isn't aiding the contributors the _primary_ purpose, not the _only_ purpose? I refer you to the tile usage policy which states "We are in principle happy for our map tiles to be used by external users for creative and unexpected uses".

I would also point out that the standard map being used, and found useful, by end users is a means of recruiting more mappers. Of course, the argument against that is that it will result in more load on the servers.

In the end, though, it boils down to human nature and the prime directive of OSM: "any tag you like." Some mappers will add inscriptions, whether you feel those serve a useful purpose or not. If there's a 255-character limit with no alternative like a link to an openplaques ID then some of them will resort to inscription_1, etc. Deprecate the inscription tag, or even filter it from the results returned by the query tool and they'll just put the inscription in the description. Or put the openplaques link in a url=* or website=*. No standardized approach, just a slew of different bodges.

[Bibi56]

avoid having to work each time the link changes or each new request like

That's a fair point. It's extra work. I don't like extra work. Not even when somebody else is doing it.

+1, but using existing code once (plus glue code), maintained by others, prevents the creation of other requests (the answer, if the question is raised, would be to put the request on the other project).

@tomhughes is not willing to implement that, in a do-ocracy, he is absolutely right.
The issue is more if a PR is made, will it ever be merged? It took nearly 5 years for this PR to get merged. I can't find it, but if I remember right Tom told us it got lost in the cyberspace. So I can understand people got cold feet.
BTW, I disagree to the statement that hyperlinks in osm.org (except the explanations for tag and values) shouldn't belong to osm.org. Querying the database could be restricted to connected contributors and enabling those links helps contributing. IMHO, that would reduce greatly the risk of creating a "end user gazetteer".