<p></p>
<p><a class="user-mention" data-hovercard-type="user" data-hovercard-url="/users/Marc-marc-marc/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/Marc-marc-marc">@Marc-marc-marc</a></p>
<blockquote>
<p>I think the arguments against have not been heard, I try to summarize</p>
</blockquote>
<p>An interesting summary of the arguments against. :)</p>
<blockquote>
<p>avoid having to work each time the link changes or each new request like</p>
</blockquote>
<p>That's a fair point.  It's extra work.  I don't like extra work.  Not even when somebody else is doing it.</p>
<blockquote>
<p>could be solved with a PR externalizing the "osm tag -> web link" code#<br>
as <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/users/grischard/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/grischard">@grischard</a> suggests</p>
</blockquote>
<p>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."</p>
<blockquote>
<p>the links on osm.org are made for a return to the contributor. therefore<br>
saying that it allows access to a text of more than 255 characters makes<br>
no sense. reading the full content of the plate does not help the osm<br>
contribution. this is for the end user.</p>
</blockquote>
<p>That is a valid point.  However, isn't aiding the contributors the <em>primary</em> purpose, not the <em>only</em> purpose?  I refer you to the <a href="https://operations.osmfoundation.org/policies/tiles/" rel="nofollow">tile usage policy</a> which states "We are in principle happy for our map tiles to be used by external users for creative and unexpected uses".</p>
<p>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.</p>
<p>In the end, though, it boils down to human nature and the prime directive of OSM: "any tag you like."  Some mappers <strong>will</strong> 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.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/openstreetmap/openstreetmap-website/issues/2405#issuecomment-623675539">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAK2OLOXJ5XTLB2MWNQXQG3RP4NK7ANCNFSM4JCRVP7Q">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AAK2OLM7BYGRNGRXGNIDKFDRP4NK7A5CNFSM4JCRVP72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEUWIREY.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/openstreetmap/openstreetmap-website/issues/2405#issuecomment-623675539",
"url": "https://github.com/openstreetmap/openstreetmap-website/issues/2405#issuecomment-623675539",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>