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

Sun Dec 13 10:58:20 UTC 2020

I just wanted to add `Relation:site` [1] to this topic. This is not an 
approved tag (proposal [2], seems abandoned), but it is used to group 
'things' together which cannot be grouped simply with a multipolygon. I 
do not expect this relation type to be rendered 'correctly' (whatever 
that may mean without a good proposal and definition) in many renderers, 
but the information will exist in OSM in a structured way for future 
renderers.

Example query for South-Sweden: https://overpass-turbo.eu/s/119b

Kind regards,
/Hidde Wieringa/

[1] https://wiki.openstreetmap.org/wiki/Relation:site
[2] https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site

On 13-12-2020 11:28, Anders Torger wrote:
> 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
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201213/d91dad05/attachment-0001.htm>