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

[stevea]

Anders, once again, our posts crossed each other!

Thank you for the example – Nominatim helped me find their location immediately!  The rendering of swamp distinct from bog "happens to my eyes," quite nicely.  I only MIGHT see the problem with the naming being "repeated" — it might be correct, it might be incorrect, it might be "different from a preference you expect."

Using JOSM, I took a look at the underlying data.  A westerly object, relation/11998254 (a typical way of referring to an object in OSM in a realm like a mail-list) seems to make perfect sense:  a multipolygon relation tagged natural=wetland + wetland=bog + name=Rijmmoáhpe.  A smallish, center-oriented, similar relation (same tags), relation/11998257 also has apparently correct tagging, except that it also has name=Rijmmoáhpe.  Easterly, similar relation/11998253, too.

As I examine the topology (complexities of outers and inners that make the combination of all of these together in to one single relation difficult or impossible), I think I understand how this presents difficulties.

I might suggest that such topologically complex objects in OSM be handled with a super-relation (in this case, a relation of the three relations) where all three of the current relations might have their name=Rijmmoáhpe tag removed, but the super-relation includes the name and the natural=wetland + wetland=bog tags.  Other combinations (of tags on relations, relation objects, or the super-relation) might make more sense.  This either does or gets close to tagging for the renderer, and I feel I would have to experiment a bit to get the desired effect in Carto (I don't know exactly what you are trying to achieve along those lines that is different from how Carto renders now).

Regarding "hard to keep track of all parts big and small," I might recommend good facility with a quality editor.  When things ARE in a relation, it's hard to beat JOSM for keeping track of the parts, I feel its relation editor is excellent:  straightforward and visually understandable.  (Quietly, I will say I do NOT feel iD's relation editor is even close to this level of facility for relation editing; I seem to always be confused editing relations with iD, so I have stopped doing so).

You mention "naming problems for which there is no documented way to do."  I'd like to understand better what you mean by this, as I believe other readers on this list would, too.  Again, I am sorry you find this frustrating and apologize if you find you are repeating yourself.  It may be that "drawing out" (extracting) what you mean and mean to do (have OSM render) are still underway and we will eventually better understand what you believe is "wrong."

"Least bad" is appreciated.  However, I think you may be using "how this renders in Carto" for at least a PART of why you say that.  I think it is better to understand that the tagging that it takes for that to happen might not be the best for OSM, the best for Carto, or both.  This is why we say "don't tag for the renderer," because (largely speaking) OSM is a data project.  The renderers do their best, but the "feedback loop" that it takes for data and renderings to harmonize is a long-term, ongoing process.  It has its complexities, it has simultaneous new proposals and tagging happening.  It has good mappers trying to pay attention and learn new things and stop doing things old ways (which used to work, but are either being phased out or no longer work).

When you say "stumble into the same issues," again, I'm sorry if you feel you are repeating yourself, I don't know exactly what the issues are.  Or, rather, we (on this mail-list) are learning them (well) only now, in that "drawing out" process.  When you say "looks horrible," I honestly don't know what you mean.  "Naming nature" in OSM seems possible to me. It could be that we have to be specific with complex topologies.  It could be that we need to fix something, but I'm not sure yet.  If you see how our relation:multipolygon wiki takes great pains to describe these mathematically complex topics in detail, I think you'll agree that this is fairly "tightly" defined:  for example, "valid multipolygon conditions" are strict.  When you strictly follow these definitions (including name=* tags), does Carto have "issues"?  If so, we want to know!

In the meantime, let us know what is "horrible" about these renderings, given the tagging.  I disagree with you that "mappers won't map things that don't show up on any renderer" because I do that all the time, knowing that OSM is a DATA project, not about a particular renderer looking a certain way.  Sure, it would be helpful if renderers "read your mind" and "didn't look horrible," but they don't, so they can't.  Instead, I'm asking you to be more descriptive, so we can both understand what might be done to assuage your sense that OSM is "broken."  In a broad sense, it isn't.  (It is broken in minor senses here and there, we hope to document and fix those).  Understandings might be broken, even among its contributors (and that's OK) — those can be fixed without coding or extensive (re-)documentation, but with good dialog like we have here.

"Mappers should take the lead," yes, of course:  that is the spirit of the project.  Renderers are "here to help," it's true, but they are not "wish factories" that "turn on a spot" (make significant change on short notice or with poor specification).  "That we still lack 'these' features 14 years in..." is not "witness to that" and I've been here for going on 12 years.  An "aircraft carrier" like OSM (meaning it has great mass and momentum in a certain direction) does not change bearing immediately, it takes a certain time and distance to "turn."  If we "need a render engine to take the lead," be that lead, don't wish for it.  If we need to define "how to arrange the data," then spend some time putting together proposals, and/or adding thoughtful, sane, sensible tags to the map and wiki-document them.  That's how this works.

It is helpful to remind us that "four or five methods of naming" results in confusion.  We know that.  Sometimes (as with landuse=forest), these persist:  that wiki says there are SIX widely-tagged meanings for this tagging.  (And yes, that's messy).  We endeavor to get better with this and other ambiguities, but it isn't always easy, or it would be done by now.

What doesn't work is to unhelpfully say "it's messy" without either saying EXACTLY why, or complaining about it.  Trying different things to see what happens is a good first foray into adding helpful suggestions (and "here are my experiences with Carto when I tried tagging methods x, y and z").  Putting on your thinking cap (maybe collaborating with another local mapper thinking about and trying to solve the same things) about coming up with solutions are good next steps.  Eventually, you might put a proposal together to share with the wider community (like us, here).  This is OSM.  It's a process of always improving.  Because OSM can improve, and often does.  Largely, it does so through good, productive dialog (like us, here).  We're listening, really.  (I am, and I have invited you and invite you again to contact me off-list).

SteveA

> On Dec 13, 2020, at 2:28 AM, Anders Torger <anders at torger.se> 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
<remainder redacted for brevity>