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

Sun Dec 13 11:23:58 UTC 2020

Thanks.

There are quite many abandoned tags for grouping things together, so 
site is in good company. It seems like site is mostly used for 
human-made features though, so I'm not sure it's suitable for natural 
features. For now I don't have the intention that the "natural" relation 
is going to be used by any renderer though, it's just to make it easy in 
JOSM to find all parts belonging to it. If some official method appears 
in the future it will be easy to do search and replace.

/Anders

On 2020-12-13 11:58, Hidde Wieringa wrote:

> 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
_______________________________________________
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/131ef74e/attachment-0001.htm>