Re: [Tagging] natural=ridge vs natural=arete
2014-11-04 22:56 GMT+01:00 Friedrich Volkmann b...@volki.at: This discussion comes late. Both natural=ridge and natural=arete have been approved by voting just 2 years ago. arguably it is not too late, there are only 450 uses of arete by now (and 17K+ ridges). Please also note that the tag natural=arete was formally rejected (not enough votes: http://wiki.osm.org/wiki/Proposed_features/arete ) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=ridge vs natural=arete
On Wed, Nov 05, 2014 at 10:01:47AM +0100, Martin Koppenhoefer wrote: 2014-11-04 22:56 GMT+01:00 Friedrich Volkmann b...@volki.at: This discussion comes late. Both natural=ridge and natural=arete have been approved by voting just 2 years ago. arguably it is not too late, there are only 450 uses of arete by now (and 17K+ ridges). Please also note that the tag natural=arete was formally rejected (not enough votes: http://wiki.osm.org/wiki/Proposed_features/arete ) after two years in the wiki where it was marked as approved and active it would not appear as a great idea to declare the vote for invalid based on nitpicking formalities, how many votes were missing for approval? Would be better to make a new proposal including details of a transition path. Another reason I don't like current arete/ridge state is that some ridges are very long - and they may be partially arete and ridge in different segments. Having a way that is tagged partially as natural=ridge and partially as natural=arete seems like a bad idea. Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=ridge vs natural=arete
2014-11-05 12:23 GMT+01:00 Richard Z. ricoz@gmail.com: after two years in the wiki where it was marked as approved and active it would not appear as a great idea to declare the vote for invalid based on nitpicking formalities, how many votes were missing for approval? it was 50% missing (5 people) Another reason I don't like current arete/ridge state is that some ridges are very long - and they may be partially arete and ridge in different segments. you can split them ;-) Having a way that is tagged partially as natural=ridge and partially as natural=arete seems like a bad idea. it won't be a way, it will be several ways. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=ridge vs natural=arete
On 05.11.2014 10:01, Martin Koppenhoefer wrote: arguably it is not too late, there are only 450 uses of arete by now (and 17K+ ridges). 450 uses are quite a lot for a feature that is constantly ignored by renderers. For the same reason, I suppose that some of the 17K+ ridges were created by imports. Please also note that the tag natural=arete was formally rejected (not enough votes: http://wiki.osm.org/wiki/Proposed_features/arete ) http://wiki.openstreetmap.org/wiki/Proposal_process#Voting: A rule of thumb for enough support is 8 unanimous approval votes or 15 total votes with a majority approval It got 10 unanimous approval votes, which is obviously even better than 8. Therefore, it clearly was approved. And, by the way, there was more than enough time for critics to object. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=ridge vs natural=arete
On 05.11.2014 12:23, Richard Z. wrote: Another reason I don't like current arete/ridge state is that some ridges are very long - and they may be partially arete and ridge in different segments. Having a way that is tagged partially as natural=ridge and partially as natural=arete seems like a bad idea. Subtags make it even worse, because they require to split the way a couple of times. Most renderers label every part separately; and whenever someone searches for the ridge name, Nominatim will deliver multiple parts instead of the whole ridge. Therefore, it's better to tag the name on one long way, and you may make it natural=ridge and add some additional and nameless natural=arete where you want renderers to display arete signatures (i.e. double sided cliffs). -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=ridge vs natural=arete
This doesn't matter in this particular case, because natural=ridge and natural=arete were approved at the same time. It is about futureproof solution - new values may appear and break existing data consumers. Adding subtags would not cause problems like this. That's why we have a wiki with descriptions. Is is better to have general tags that are usable without checking wikis. Also, definition of arete is fuzzy by itself (see post by Alan Trick Most of the things that the Wikipedia refers to as aretes are coloquially called ridges here) Your argumentation is based on practical issues, but essentially your considerations are merely theoretical. No, I am using OSM data in two projects - map of cycleway-related data, currently in planning stages ( https://github.com/mkoniecz/bicycle_map_of_Krakow ) - contributing to Default style ( https://github.com/gravitystorm/openstreetmap-carto/ ) I can assure you that cascading tag scheme is way easier to support, at least in my opinion. 2014-11-06 6:38 GMT+01:00 Friedrich Volkmann b...@volki.at: On 05.11.2014 07:19, Mateusz Konieczny wrote: And it is not just because with the second solution new values for main tag will quickly appear (see building=*). This doesn't matter in this particular case, because natural=ridge and natural=arete were approved at the same time. 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. That's why we have a wiki with descriptions. When you find a description fuzzy or misleading, please improve it. 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. Your argumentation is based on practical issues, but essentially your considerations are merely theoretical. As a data consumer, e.g. when you want to render power towers in a 1:25000 map, you are well advised to have a look at the subtags. Maybe there are power tower types which represent power towers so small and unimportant that you find it better to omit those on your 1:25000 map. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=ridge vs natural=arete
I think that natural=arete should be rather subtag of natural=ridge (natural=ridge; ridge=arete). It is opening way for next specialized tags - what will make using data significantly harder. 2014-11-04 13:58 GMT+01:00 Richard Z. ricoz@gmail.com: Hi, following some discussions on github (1) and talk-at (2) I have tried to clarify the definition of natural=ridge in the wiki http://wiki.openstreetmap.org/w/index.php?title=Tag:natural%3Dridgediff=1104725oldid=998905 Not sure if this is good enough, personaly I would prefer a single ridge key with additional subkeys denoting properties such as gentle,sharp, cliff ridges. 1. https://github.com/gravitystorm/openstreetmap-carto/issues/1097 2. https://lists.openstreetmap.org/pipermail/talk-at/2014-November/007058.html Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=ridge vs natural=arete
2014-11-04 13:58 GMT+01:00 Richard Z. ricoz@gmail.com: personaly I would prefer a single ridge key with additional subkeys denoting properties such as gentle,sharp, cliff ridges. +1 or the subkey variant Mateusz has offered. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=ridge vs natural=arete
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@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=ridge vs natural=arete
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 b...@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@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
