<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.</p>
<p>Example query for South-Sweden: <a class="moz-txt-link-freetext" href="https://overpass-turbo.eu/s/119b">https://overpass-turbo.eu/s/119b</a></p>
<p>Kind regards,<br>
<i>Hidde Wieringa</i><br>
</p>
<p>[1] <a class="moz-txt-link-freetext" href="https://wiki.openstreetmap.org/wiki/Relation:site">https://wiki.openstreetmap.org/wiki/Relation:site</a><br>
[2] <a class="moz-txt-link-freetext" href="https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site">https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site</a></p>
<p><br>
</p>
<div class="moz-cite-prefix">On 13-12-2020 11:28, Anders Torger
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:549db8f476cef77a8fe6d8e30e25cb85@torger.se">Here's a
real example of how this naming scheme ends up looking:
<br>
<br>
<a class="moz-txt-link-freetext" href="https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png">https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png</a>
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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...
<br>
<br>
/Anders
<br>
<br>
On 2020-12-13 00:55, stevea wrote:
<br>
<blockquote type="cite">I don't approach this as getting solved in
one multipolygon. I might
<br>
use two multipolygons, one tagged wetland=bog, another tagged
<br>
wetland=marsh, both tagged natural=wetland. Add name=* as
<br>
appropriate. Closed ways (plus other things, with other tags)
do
<br>
overlap (these two seem they should not). Let renderers deal
with
<br>
such issues.
<br>
<br>
Different than natural=* tagging, there is also a proposal that
<br>
includes an "unadorned" boundary=protected_area tag (on a closed
way
<br>
or a relation), without a protect_class tag (one is not known or
is
<br>
"less known"). This might, someday, render as a simple green
line.
<br>
This conveys what is (an often legal) boundary, so it isn't
natural=*.
<br>
See if this proposal
<br>
(<a class="moz-txt-link-freetext" href="https://wiki.osm.org/wiki/Proposed_features/Park_boundary">https://wiki.osm.org/wiki/Proposed_features/Park_boundary</a>)
helps wrap
<br>
your logic (and OSM's syntax, a boundary=protected_area tag, or
its
<br>
semantics, a perhaps-someday-drawn rendered green line) around
this.
<br>
Untangling natural, leisure and boundary tagging is ahead in
OSM,
<br>
things do get better.
<br>
<br>
How (the Carto, for example) renderers draw natural=* on top of
one
<br>
another is actually a rich topic: it can be said these
behaviors are
<br>
renderer specific. (Yes, Carto "drawing order" is not
necessarily
<br>
perfectly defined). These are complex topics, getting better as
<br>
proposals gain approval (a working strategy so far). The
example of
<br>
natural=* tagging below is a topic of some confusion among
mappers.
<br>
For example, I don't believe Carto rendering is perfectly
predictable
<br>
without first knowing "size of all overlapping polygons." This
can
<br>
make "accurate" (or pleasing) natural tagging challenging or
<br>
unpredictable in some circumstances. I believe at least some of
what
<br>
is rendered has to do with the size (and order entered?) of
<br>
overlapping polygons.
<br>
<br>
In short, I "tag the data I know" at the complexity I'm
comfortable
<br>
tagging them, as accurately as I know how, using OSM's wiki to
<br>
describe tagging. Multipolygons differ from relations like them
which
<br>
aren't (like those tagged boundary=*), independently as far as
<br>
renderers are concerned. It is easy to get confused, confusion
exists
<br>
in the map: semantics are blurry in some cases. This gets
better
<br>
with worldwide consensus, over years. This (how we learn to
best tag
<br>
and render) is an ongoing long-term OSM process. As a mapper,
"tag
<br>
accurately first," then let renderers interpret.
<br>
<br>
SteveA
<br>
<br>
<blockquote type="cite">On Dec 11, 2020, at 11:53 AM, Anders
Torger <a class="moz-txt-link-rfc2396E" href="mailto:anders@torger.se"><anders@torger.se></a> wrote:
<br>
<br>
Unfortunately I don't think that is possible.
<br>
<br>
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?
<br>
<br>
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).
<br>
<br>
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).
<br>
<br>
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.
<br>
<br>
On 2020-12-11 18:09, Brian M. Sperlongano wrote:
<br>
<br>
<blockquote type="cite">Hello Anders,
<br>
<br>
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.
<br>
<br>
On Fri, Dec 11, 2020, 11:11 AM Anders Torger
<a class="moz-txt-link-rfc2396E" href="mailto:anders@torger.se"><anders@torger.se></a> wrote:
<br>
Hello,
<br>
<br>
I was on this list a while back expressing some frustration
over
<br>
limitations when tagging nature and thought about getting
involved in a
<br>
process for change, but I came to realize that it's not
feasible for me
<br>
in my current life situation, so I've decided to continue be
a normal
<br>
mapper as before, doing what I can do with features that
exist today.
<br>
<br>
Anyway, if to be a mapper at all, I still like to solve some
of my
<br>
naming issues in the best/least bad ways possible today. I'm
currently
<br>
mapping a national park in Sweden, Muddus. It's in Laponia
and consists
<br>
of mighty wetlands and old forest. These wetlands are named,
like is
<br>
common in Sweden and Sami lands. For us navigating in
wildlife, names in
<br>
nature are important.
<br>
<br>
A wetland polygon can be named in OSM, so the situation is
better than
<br>
for example for named slopes (also common). However, a
wetland here can
<br>
consist of both bog and marsh (and it's important to make
the
<br>
difference, since one is easy to walk on, the other not so
much). That's
<br>
two different natural types and thus can't be in the same
multipolygon
<br>
(as outers).
<br>
<br>
Asking on OSM Help website for a solution I got the answer
to make a new
<br>
containing multipolygon and set the name on that. That would
be quite
<br>
elegant for sure, but JOSM warns about that, can't have a
name without a
<br>
type, and if I set the type, say natural=wetland without any
subtype, I
<br>
get a JOSM warning that I have natural features on top of
eachother. If
<br>
I still upload it OSM-Carto does render out the name but you
can see
<br>
that the wetland pattern of the outer polygon is drawn on
top of the
<br>
contained polygons, so it does not seem to be the way to do
it.
<br>
<br>
The least bad way I've come up with is to just name all
polygons
<br>
belonging to the same wetlands the same, and hope for that
in the future
<br>
smart renderers will understand that polygons with shared
borders and
<br>
shared name is the same named entity.
<br>
<br>
Any ideas or suggestions?
<br>
<br>
/Anders
<br>
<br>
_______________________________________________
<br>
Tagging mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a>
<br>
<br>
_______________________________________________
<br>
Tagging mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a>
<br>
</blockquote>
<br>
<br>
_______________________________________________
<br>
Tagging mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a>
<br>
</blockquote>
<br>
<br>
_______________________________________________
<br>
Tagging mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a>
<br>
</blockquote>
<br>
_______________________________________________
<br>
Tagging mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a>
<br>
</blockquote>
</body>
</html>