[Tagging] natural=ridge vs natural=arete

Mateusz Konieczny matkoniecz at gmail.com
Wed Nov 5 06:19:52 UTC 2014


"Whether to use subtags is mainly a matter of taste."

No. Lets say that there is something with four main values that are
noticeable for general public and several subtypes, important for
specialists.

For data consumers interested in just four values version with subtags
is vastly easier to use cascading tagging scheme.

main_tag=first_value
main_tag=second_value
main_tag=third_value
main_tag=fourth_value

with subkeys, ignored by this general purpose renderer
first_value=a
first_value=b
(...)
fourth_value=z

Scheme with placing everything into main tag is much harder to support:

main_tag=a
main_tag=b
main_tag=c
(...)
main_tag=z

And it is not just because with the second solution new values
for main tag will quickly appear (see building=*). With second
scheme there is much smaller pool of people that really understand how
main_tag should be processed and tagged.

For example I have enough general knowledge to implement support for
natural=ridge (everybody knows what it means), but with natural=arete it
would require at least some learning about specialist terms. Currently I
have no idea is this tag is even correctly spelled - Wikipedia defines
arete
as "term meaning "virtue" or "excellence"." - and ridge related article is
titled "arête". I also have not enough knowledge to decide whatever
something is ridge or arête, is it clear term or something fuzzy.

Yes, I can learn about it - but I worry about the same happening for more
things. I am NOT interested in learning about how to recognize different
different power tower types, I want to tag just power=tower and leave
further classification to power enthusiast that will use subkeys so
rendering power towers on my map will be easy to implement.

On the other hand I am interested in cycling infrastructure and tag it to
absurd detail. But I am using

[amenity=bicycle_parking; bicycle_parking=stands]
[amenity=bicycle_parking; bicycle_parking=wall_loops]
not
[amenity=bicycle_stands]
[amenity=wall_loops]

-

[oneway=yes; oneway:bicycle=no]
not
[oneway=yes;bicycle:no]

And yes, I am considering usability of oneway=yes;bicycle:no
and natural=arete as similar. natural=arete in fact is even worse
as in the first case everything starting from ; sign may be
safely dropped what allows adding new details without breaking
more general rendering, and once somebody changed natural=ridge
to natural=overly_specific_value it is impossible to recover
information that it is ridge, without manually adding support to new tags.

So I will tag ridges as natural=ridge (also arêtes and other subtypes),
I will not use natural=arete as user of OSM data and I consider existence
of this tag as a really poor idea.

Maybe it is matter of taste but I have yet to see arguments why flat
tagging
is superior.

2014-11-04 22:56 GMT+01:00 Friedrich Volkmann <bsd at volki.at>:

> On 04.11.2014 14:04, Mateusz Konieczny wrote:
> > I think that natural=arete should be rather subtag of natural=ridge
> > (natural=ridge; ridge=arete).
>
> This discussion comes late. Both natural=ridge and natural=arete have been
> approved by voting just 2 years ago. And I think that there's nothing wrong
> with them. Whether to use subtags is mainly a matter of taste.
>
> --
> Friedrich K. Volkmann       http://www.volki.at/
> Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
>
> _______________________________________________
> 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/20141105/e7c0fea8/attachment.html>


More information about the Tagging mailing list