<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>Thanks.</p>
<p>I also think that only having them tied by name is not a good concept.</p>
<p>So what I've settled for (for now) is as follows:</p>
<p>- same name on each part (the only way to get the data useful *today*)<br />- a new relation with all parts as members (role unset), type=natural, natural=wetland, name=<the name></p>
<p>I don't intend this to be a final solution, but if that ever comes, having some sort of relation there makes it much easier to find and upgrade the tags.</p>
<p>I'm unfortunately not in capacity to work with a pilot project, so this have to be done by "someone else" :-/. I also think that a "pilot project" should not really just look at one particular problem like this. There's a family of problems around mapping nature with high detail, and providing data that can be used to generate maps at different zoom levels. These are not unique to Sweden, but it's just basic cartography. The reason I stumble into these is not because I'm mapping in Sweden, it's because I'm mapping with high detail and have good data sources with access to those names (and also personal experience of using them and maps with them as I engage in outdoor activities).</p>
<p>Norway has already come far with high detail land cover mapping here in rural north, much longer than we have in Sweden. They also have named nature, much of the naming is actually of the same type as this is part of Sami lands. How have our Norwegian friends solved the naming problem? Easy: by not putting any names in the map, except for lakes and stuff that is supported by OSM today.</p>
<p>And this is of course what happens, and it's so frustrating. The inability of the OSM community to identify, implement and document basic cartography features leaves the geo data of lower quality than it could have been if these features would have been readily available for mappers to use *now*.</p>
<p>It simply does not work that if a mapper needs a basic feature, he or she should then personally engage into OSM politics for many years(!) to *maybe* see it implemented. So instead most mappers just think "well, maybe I just skip that" and you don't get to hear about it and we can still pretend that noone actually needs the feature.... it's not realistic to think that OSM mappers in general should be persons deeply invested in how OSM community is organized and just jump right into the processes whenever needed. I think what mappers want to do is to map, and see their data on display *now*.</p>
<p>I'm not blaming anyone, it's just an observation. I'm myself part of the OSM community, and I just said that I don't have the capacity to pull any strings in this type of pilot project, so I'm just as much to blame as any other. But now I'm at least putting the data in, so if someone eventually fixes this, the tags can be upgraded accordingly if needed.</p>
<p>Before I did just like the typical mapper, I just skipped the names that couldn't be mapped properly, regardless of their importance. Now I try to put them in, in some way or another.</p>
<p>/Anders</p>
<p id="reply-intro">On 2020-12-13 12:26, Peter Elderson wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div id="replybody1">
<div dir="ltr">My answer only targets the question in the subject.
<div> </div>
<div>No matter whether you put the same name on all parts, or on or some kind of collective, you need a way for data users to know that all the parts together have a name. </div>
<div>Tagging the same name on all parts makes the name a free text id needing uniqueness - for me a bad choice. </div>
<div>Yet another polygon around the area, don't like that. I think we have too many of those already. </div>
<div>Tagging all parts with a truly unique Id in a special key could do the trick, but who issues/manages the unique ids? <br clear="all" />
<div>
<div>Putting the parts as members in a relation achieves the same: a unique Id common to all the parts; the name tag and possible other common attributes go on the relation. </div>
<div>This gives renderers the exact extent of the total area, and the extents of the subareas, which can have names and other attributes of their own. </div>
<div>Since an MP does not cover all possible layouts, you would need a different type of relation. Maybe an existing type can be used, or a specialised type can be defined.</div>
<div> </div>
<div>I would think a pilot project could test the concept for mappers, renderers and other data users. If succesful, showcase. If not, document and delete.</div>
<div> </div>
<div>Peter Elderson</div>
</div>
</div>
<br />
<div class="v1gmail_quote">
<div class="v1gmail_attr" dir="ltr">Op vr 11 dec. 2020 om 17:11 schreef Anders Torger <<a href="mailto:anders@torger.se" rel="noreferrer">anders@torger.se</a>>:</div>
<blockquote class="v1gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid #cccccc; padding-left: 1ex;">Hello,<br /><br />I was on this list a while back expressing some frustration over <br />limitations when tagging nature and thought about getting involved in a <br />process for change, but I came to realize that it's not feasible for me <br />in my current life situation, so I've decided to continue be a normal <br />mapper as before, doing what I can do with features that exist today.<br /><br />Anyway, if to be a mapper at all, I still like to solve some of my <br />naming issues in the best/least bad ways possible today. I'm currently <br />mapping a national park in Sweden, Muddus. It's in Laponia and consists <br />of mighty wetlands and old forest. These wetlands are named, like is <br />common in Sweden and Sami lands. For us navigating in wildlife, names in <br />nature are important.<br /><br />A wetland polygon can be named in OSM, so the situation is better than <br />for example for named slopes (also common). However, a wetland here can <br />consist of both bog and marsh (and it's important to make the <br />difference, since one is easy to walk on, the other not so much). That's <br />two different natural types and thus can't be in the same multipolygon <br />(as outers).<br /><br />Asking on OSM Help website for a solution I got the answer to make a new <br />containing multipolygon and set the name on that. That would be quite <br />elegant for sure, but JOSM warns about that, can't have a name without a <br />type, and if I set the type, say natural=wetland without any subtype, I <br />get a JOSM warning that I have natural features on top of eachother. If <br />I still upload it OSM-Carto does render out the name but you can see <br />that the wetland pattern of the outer polygon is drawn on top of the <br />contained polygons, so it does not seem to be the way to do it.<br /><br />The least bad way I've come up with is to just name all polygons <br />belonging to the same wetlands the same, and hope for that in the future <br />smart renderers will understand that polygons with shared borders and <br />shared name is the same named entity.<br /><br />Any ideas or suggestions?<br /><br />/Anders<br /><br />_______________________________________________<br />Tagging mailing list<br /><a href="mailto:Tagging@openstreetmap.org" rel="noreferrer">Tagging@openstreetmap.org</a><br /><a href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank" rel="noopener noreferrer">https://lists.openstreetmap.org/listinfo/tagging</a></blockquote>
</div>
</div>
</div>
<br />
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">_______________________________________________<br />Tagging mailing list<br /><a href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a><br /><a href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank" rel="noopener noreferrer">https://lists.openstreetmap.org/listinfo/tagging</a></div>
</blockquote>
<p><br /></p>
</body></html>