Cool! It would be really nice to see a demo :-)
I would be fine with your naming scheme, however you'll have to rely on
the adjacent rendering as I will be removing all relations per request.
As said I actually had them mostly for make my editing easier (without
them it becomes harder to manage all tiny parts in JOSM), so it was a
mistake by me to mention possible advantages for renderers too, but as
I'm also a programmer it's hard not to think about those things in
parallel.
That it requires an merge-adjacent despite different natural tags and
instead matching name makes me think that your renderer will probably be
the first one implementing this, despite the claims that this is an
established method... but I hope I'm wrong.
/Anders
On 2020-12-14 19:06, Ture Pålsson via Tagging wrote:
14 dec. 2020 kl. 15:49 skrev Anders Torger <and...@torger.se>:
Okay, but why does the OSM-Carto renderer, and all other renderers
known to man(?) make multiple text labels then, when it should be a
single one? Look at the result, it looks horrible. Do you really think
this is the way it should be done, also long-term? Also note that the
tags do differ, otherwise it would be a single multipolygon, it's both
wetland=bog and wetland=marsh.
I have implemented the merge-adjacent-areas scheme in my renderer.
I’ll try to get a demo up… :-)
Having said that, as a renderer implementer, I have a slight
preference for the relation method. It is s implyeasier to join things
on numeric id than to join them by adjacency.
I noticed that you have tagged the ”name” relation as (if I remember
correctly)
type=natural, natural=wetland, name=Rijmmoáhppe
I think it would be good to keep the set of possible values for the
’type’ tag small, so I’d like to propose another level of indirection;
something like
type=named_area, named_area=natural, natural=wetland, name=Peter’s
Pot
And having said all *that*, on the subject of adjacent-areas vs.
relations, again as a renderer implementer, I very much prefer when
there is one way rather than two of doing something. First of all, if
there are two ways, I need to write code for both of them. Second,
some things invariably end up being tagged with *both* schemes
(adjacent areas with name tags *and* a relation) which means that I
need to detect that case to eliminate duplicate labels. So if a
majority of mappers find relations too hard to use, I think I would
vote for the adjacent-areas method, even though using a relation seems
”cleaner”.
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
