[Tagging] How to put a name tag on an area with more than one type?

Sun Dec 13 10:28:12 UTC 2020

Here's a real example of how this naming scheme ends up looking:

https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png

I have put the name on each part which is the enduring recommendation 
I've got. Some parts are multipolygons, some are just closed ways, as 
required.

I also added a relation on top. I've got advice against that as no 
renderer will ever care, but I found that when editing it's hard to keep 
track of all parts big and small if there is no relation, so I added it 
as a help for the mapper. I set type=natural (to indicate that it's a 
natural object) and natural=wetland (to indicate what type of natural it 
is, without having to deduce from its members) and name on that 
relation. Nothing official, but at least easy to filter out and find.

In Sweden the land cover mapping is heavily behind so I've started a 
mapping effort for natural areas and there are a bunch of naming 
problems to solve for which there is no documented way to do. So I do 
these reference areas and try to come up with the best methods (=least 
bad in some cases) so we in the local Swedish OSM community have 
something to refer to when new mappers want to help out and stumble into 
the same issues.

As seen on the screenshot, the result in OSM-Carto looks pretty 
horrible, and to my knowledge it will be as horrible in any other 
renderer out there as the feature of naming "complex" nature just don't 
exist. It's the usual problem: mappers won't map things that don't show 
up on any renderer (or displays horribly like this), and renderers won't 
implement functions for things that aren't mapped. The OSM way is that 
mappers should take the lead and renderers will eventually follow 
(maybe). I think that process works really poorly today (the main reason 
being that OSM is just too large and diverse now for the original 
processes to work, in global scope every feature becomes just a tiny 
special interest not worth considering). That we still lack these 
cartography features 14 years into the project is witness to that. We 
need a render engine to take the lead, and more well-defined standard of 
how to arrange the data. I've got 4 - 5 different suggestions of how to 
put a name on this wetland. Imagine if all those naming schemes gets 
used, what a mess to implement a renderer...

/Anders

On 2020-12-13 00:55, stevea wrote:
> I don't approach this as getting solved in one multipolygon.  I might
> use two multipolygons, one tagged wetland=bog, another tagged
> wetland=marsh, both tagged natural=wetland.  Add name=* as
> appropriate.  Closed ways (plus other things, with other tags) do
> overlap (these two seem they should not).  Let renderers deal with
> such issues.
> 
> Different than natural=* tagging, there is also a proposal that
> includes an "unadorned" boundary=protected_area tag (on a closed way
> or a relation), without a protect_class tag (one is not known or is
> "less known").  This might, someday, render as a simple green line.
> This conveys what is (an often legal) boundary, so it isn't natural=*.
>  See if this proposal
> (https://wiki.osm.org/wiki/Proposed_features/Park_boundary) helps wrap
> your logic (and OSM's syntax, a boundary=protected_area tag, or its
> semantics, a perhaps-someday-drawn rendered green line) around this.
> Untangling natural, leisure and boundary tagging is ahead in OSM,
> things do get better.
> 
> How (the Carto, for example) renderers draw natural=* on top of one
> another is actually a rich topic:  it can be said these behaviors are
> renderer specific.  (Yes, Carto "drawing order" is not necessarily
> perfectly defined).  These are complex topics, getting better as
> proposals gain approval (a working strategy so far).  The example of
> natural=* tagging below is a topic of some confusion among mappers.
> For example, I don't believe Carto rendering is perfectly predictable
> without first knowing "size of all overlapping polygons."  This can
> make "accurate" (or pleasing) natural tagging challenging or
> unpredictable in some circumstances.  I believe at least some of what
> is rendered has to do with the size (and order entered?) of
> overlapping polygons.
> 
> In short, I "tag the data I know" at the complexity I'm comfortable
> tagging them, as accurately as I know how, using OSM's wiki to
> describe tagging.  Multipolygons differ from relations like them which
> aren't (like those tagged boundary=*), independently as far as
> renderers are concerned.  It is easy to get confused, confusion exists
> in the map:  semantics are blurry in some cases.  This gets better
> with worldwide consensus, over years.  This (how we learn to best tag
> and render) is an ongoing long-term OSM process.  As a mapper, "tag
> accurately first," then let renderers interpret.
> 
> SteveA
> 
>> On Dec 11, 2020, at 11:53 AM, Anders Torger <anders at torger.se> wrote:
>> 
>> Unfortunately I don't think that is possible.
>> 
>> Multipolygons may only contain ways that have either role as inner or 
>> as outer. It may not contain other relations (still possible to 
>> upload, but not considered right according to the wiki). What should 
>> the ways be?
>> 
>> We can't make the separate wetland parts as inner ways, (as areas 
>> formed by the inner ways are subtracted from the multipolygon), and 
>> even if we try it becomes illegal as inner ways cannot share segments 
>> with the outer way. We can't make the parts as outers either as they 
>> share segments. The outer must be the surrounding outline without the 
>> shared segments splitting the wetland in parts, and there are no 
>> inners (unless the parts themselves has inners).
>> 
>> So then we have a multipolygon with just an outer. I could just as 
>> well be a plain polygon made from a single closed way. This would work 
>> if drawing order was defined, and that was the method I tried first. 
>> The container polygon must have a natural tag as well (the logical 
>> would be wetland here without further sub-classification).
>> 
>> However the drawing order is not defined (I think, not 100% sure), so 
>> this is by the renderer interpreted as a wetland lying on top of the 
>> other wetlands. OSM-Carto will still render the insides, but the fill 
>> pattern of the outer polygon is drawn on top.
>> 
>> On 2020-12-11 18:09, Brian M. Sperlongano wrote:
>> 
>>> Hello Anders,
>>> 
>>> I would recommend creating a multipolygon relation 
>>> (type=multipolygon) with each of the wetland pieces, and set the 
>>> name= and appropriate natural= and wetland= tags on the relation.
>>> 
>>> On Fri, Dec 11, 2020, 11:11 AM Anders Torger <anders at torger.se> 
>>> wrote:
>>> Hello,
>>> 
>>> I was on this list a while back expressing some frustration over
>>> limitations when tagging nature and thought about getting involved in 
>>> a
>>> process for change, but I came to realize that it's not feasible for 
>>> me
>>> in my current life situation, so I've decided to continue be a normal
>>> mapper as before, doing what I can do with features that exist today.
>>> 
>>> Anyway, if to be a mapper at all, I still like to solve some of my
>>> naming issues in the best/least bad ways possible today. I'm 
>>> currently
>>> mapping a national park in Sweden, Muddus. It's in Laponia and 
>>> consists
>>> of mighty wetlands and old forest. These wetlands are named, like is
>>> common in Sweden and Sami lands. For us navigating in wildlife, names 
>>> in
>>> nature are important.
>>> 
>>> A wetland polygon can be named in OSM, so the situation is better 
>>> than
>>> for example for named slopes (also common). However, a wetland here 
>>> can
>>> consist of both bog and marsh (and it's important to make the
>>> difference, since one is easy to walk on, the other not so much). 
>>> That's
>>> two different natural types and thus can't be in the same 
>>> multipolygon
>>> (as outers).
>>> 
>>> Asking on OSM Help website for a solution I got the answer to make a 
>>> new
>>> containing multipolygon and set the name on that. That would be quite
>>> elegant for sure, but JOSM warns about that, can't have a name 
>>> without a
>>> type, and if I set the type, say natural=wetland without any subtype, 
>>> I
>>> get a JOSM warning that I have natural features on top of eachother. 
>>> If
>>> I still upload it OSM-Carto does render out the name but you can see
>>> that the wetland pattern of the outer polygon is drawn on top of the
>>> contained polygons, so it does not seem to be the way to do it.
>>> 
>>> The least bad way I've come up with is to just name all polygons
>>> belonging to the same wetlands the same, and hope for that in the 
>>> future
>>> smart renderers will understand that polygons with shared borders and
>>> shared name is the same named entity.
>>> 
>>> Any ideas or suggestions?
>>> 
>>> /Anders
>>> 
>>> _______________________________________________
>>> Tagging mailing list
>>> Tagging at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>> 
>>> _______________________________________________
>>> Tagging mailing list
>>> Tagging at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>> 
>> 
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging