<div dir="ltr">It sounds like what we are asking for is the ability to tag a rough polygon in the approximate area where a label should be placed for a known but not strictly bounded toponymic feature (mountain range, water body, etc). That would give a hint to renderers as to the location and most importantly, size, of a label for such features. This would also solve the current problem of tagging large coastline-bounded marine features, such as seas, bays, straits, etc., without creating overly complex polygons resulting from re-use of the coastline ways. It would also fix the inability to tag such basic features as oceans. When you type "Atlantic Ocean" into any map other than OSM, it shows you the ocean. When you type it into <a href="http://openstreetmap.org">openstreetmap.org</a>, it shows you a super-close zoom-in to a single node - not very helpful.<div><br></div><div>It is reductio ad absurdum to say that features like "Pacific Ocean", "Swiss Alps", "Spratley Islands", or "Sahara Desert" don't belong on a project that aims to create a map of the world simply because these features don't have a fence or sign around them to indicate their exact boundary. Features exist in approximation in the real world, and it is a perfectly valid opinion to want those things to appear, also in approximation, on the map. These things are verifiable because people know what these toponyms mean and represent. If it is possible to write a wikipedia article on "Indian Ocean", it is possible to draw a rough polygon in openstreetmap which means "this is roughly where the Indian Ocean is, and renderers should consider drawing a label".</div><div><br></div><div>Note that this is not "tagging for the renderer" (which is often code for "tagging that I don't like"), these are real, major features that actually exist in the real world and their absence makes OSM weaker. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 14, 2020 at 8:04 AM Anders Torger <<a href="mailto:anders@torger.se">anders@torger.se</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">To make a specific answer to "what additional verifiable local <br>
knowledge" this relation is intended to cover, is that the wetland is a <br>
single named entity, not multiple entities named the same.<br>
<br>
And here's some elaboration. This is 4 km wide wetland, in the real <br>
world named as a single entity, but it does consist of both bog and <br>
marsh, in the screenshot named each separate part as you suggested:<br>
<br>
<a href="https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png" rel="noreferrer" target="_blank">https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png</a><br>
<br>
"Verifiable" is tricky in terms of names of natural features as we all <br>
know, as many of those haven't defined borders. Wetlands maybe so, but <br>
even in this case, are the small satellite wetlands part of Rijmmoàhpe <br>
or not? Noone knows, it was never defined. That's the way these names <br>
work. Does that mean that these type of names should not be in OSM at <br>
all? You tell me. I just try to contribute geodata to make maps for <br>
outdoor use. If OSM is not the platform, let me know.<br>
<br>
I'm not particularly experienced in how OSM use relations and why the <br>
are so "obnoxious" as Mateusz put it, but I have worked with arranging <br>
data in many projects and to me this is an obvious case of data that <br>
should be arranged as a container with all its parts. I also think that <br>
it would make it much easier to fix the renderer, it can easily get all <br>
parts for the single name, and as a added bonus get to know the "master <br>
type" (instead of having to go through all parts calculate the area to <br>
figure out which nature that is dominant to get the tag styling right). <br>
Etc.<br>
<br>
I didn't add it thinking about any renderer though, it was actually for <br>
myself to more easily keep track of all parts when editing on JOSM. With <br>
a parent relation I just need to click on one, and then on the parent <br>
relation to get all selected. Otherwise I need to create a filter on the <br>
name or something, so to me it's also more efficient for the mapper.<br>
<br>
And in the end I think that the individual parts should not have name <br>
tags at all, it should only be on the parent relation. The reason we put <br>
it on the individual parts now is to me obviously just because there is <br>
no renderer support available anywhere for naming these type of natural <br>
entities, and probably will stay that way for the foreseeable future.<br>
<br>
Having a relation on these new features makes them easy to find in the <br>
database and one can upgrade the tags later. I suppose it's much more <br>
complicated to make a filter to find parts named the same with shared <br>
borders, I don't really know how to do it in JOSM (but maybe one can?).<br>
<br>
So that's my reasons, but if you think they're bad I'll remove the <br>
relation. I would like to hear how you want to solve the problem instead <br>
though. As you see on the screenshot, the current situation is far from <br>
optimal with lots of tiny name tags where there should be only one.<br>
<br>
/Anders<br>
<br>
On 2020-12-14 13:28, Christoph Hormann wrote:<br>
>> Anders Torger <<a href="mailto:anders@torger.se" target="_blank">anders@torger.se</a>> hat am 14.12.2020 07:59 geschrieben:<br>
>> <br>
>> <br>
>> I'll gladly answer questions, but I think you need to rephrase. I<br>
>> suppose it is some hidden critique in there, but I honestly do not<br>
>> understand the question. It would be better for me if you put words on<br>
>> the critique instead of wrapping it in a question.<br>
> <br>
> There is no critique in there, i have not formed an opinion on the<br>
> concept, i like to understand the reasoning behind this. Hence the<br>
> question.<br>
> <br>
> The premise is that in OSM we record verifiable local knowledge about<br>
> the geography of the world. And we try to record that in a form that<br>
> is most efficient for the mapper. Hence the question what additional<br>
> verifiable knowledge you intend to record with the additional data<br>
> structures you propose to create that is not yet in what we already<br>
> record today.<br>
> <br>
> --<br>
> Christoph Hormann<br>
> <a href="https://www.imagico.de/" rel="noreferrer" target="_blank">https://www.imagico.de/</a><br>
> <br>
> _______________________________________________<br>
> Tagging mailing list<br>
> <a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
<br>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>