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 <and...@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 <and...@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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
