Re: [Tagging] New key proposal - paved=yes/no
These are more than 90% of values for surface, categorize them as paved/unpaved the rest as unpaved. surface= asphalt unpaved paved gravel ground dirt grass concrete paving_stones sand cobblestone compacted paved=yes will remove then need for parsing those last % of surface=* values, not sure it's worth it. To think that there is only one definition of paved=yes, is a big mistake. There are few tags in OSM that are specific enough to mean the same thing all over the world. On Mon, Sep 22, 2014 at 1:42 AM, David Bannon dban...@internode.on.net wrote: On Mon, 2014-09-22 at 00:23 +0200, Tomasz Kaźmierczak wrote: ..A good suggestion ... So it seems that yet again, we are going to reject this attempt to solve a real problem. Looking at the neg replies, because its not useful for bike riders; not useful for a number of undefined edge cases; is a duplicate of surface=. Thats just plain not true ! There is no suggestion that paved= should be used instead of surface=. I use surface= on all unsealed roads I map and would continue to do so if I also used paved=no. But there are 34 official values for surface= and 3581 values used. It is very plain that the mapping community want surface= as a fine grained, very detailed key. And thats great, people making specialised maps or engines can use those values, display them in a meaningful way to people they understand. My data will help them. But the vast majority of people just want to know that the road may not be what they are used to. Thats all. And paved= does that easily. In places like Australia, that information can be a life or death thing. People die here because they are inexperienced or ill equipped for roads they tackle. Generally visitors from Europe or North America. Please folks, think of the big picture, not the edge cases. David ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- /emj ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named
2014-09-29 23:45 GMT+02:00 Lukas Sommer sommer...@gmail.com: The case of Japan is different. In Japan, the name belongs to the _traffic signal_, and _not_ to the junction. We need to distinguish this, because they are usually differently rendered (traffic signal names usually with an icon and junction names usually without an icon). But what would we gain when we distinguish between th:junction_area and kr:junction_area - because here we have two values for the same feature. If there is a need to tag traffic signal names and junction names on the same node, then the logical solution is junction:name=* and traffic_signals:name=*. Or in different languages: junction:name:th=* and traffic_signals:name:kr=*. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named
Oh, sorry, Pieren was faster… ;-) Lukas Sommer 2014-09-30 12:34 GMT+00:00 Lukas Sommer sommer...@gmail.com: If there is a need to tag traffic signal names and junction names on the same node, then the logical solution is junction:name=* and traffic_signals:name=*. Or in different languages: junction:name:th=* and traffic_signals:name:kr=*. Different names for junction and traffic signal are probably not a real-world case. Lukas Sommer 2014-09-30 12:21 GMT+00:00 Janko Mihelić jan...@gmail.com: 2014-09-29 23:45 GMT+02:00 Lukas Sommer sommer...@gmail.com: The case of Japan is different. In Japan, the name belongs to the _traffic signal_, and _not_ to the junction. We need to distinguish this, because they are usually differently rendered (traffic signal names usually with an icon and junction names usually without an icon). But what would we gain when we distinguish between th:junction_area and kr:junction_area - because here we have two values for the same feature. If there is a need to tag traffic signal names and junction names on the same node, then the logical solution is junction:name=* and traffic_signals:name=*. Or in different languages: junction:name:th=* and traffic_signals:name:kr=*. ___ 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] tagging for graves?
On Tue, Sep 30, 2014 at 6:04 PM, Brad Neuhauser brad.neuhau...@gmail.com wrote: In addition, there is a type=person relationship [4] which appears to be recommended for this kind of use. This is typically stuff that are not related to any geographic feature. It's really using OSM just as a free access database, bypassing the restrictions of wikipedia. Something that could be deleted without regret on both database and wiki. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named
What would also be no problem, because you can give an individual name=* tag to each node with highway=traffic_signals and another name=* tag to the area. Lukas Sommer 2014-09-30 18:56 GMT+00:00 fly lowfligh...@googlemail.com: Am 30.09.2014 14:34, schrieb Lukas Sommer: If there is a need to tag traffic signal names and junction names on the same node, then the logical solution is junction:name=* and traffic_signals:name=*. Or in different languages: junction:name:th=* and traffic_signals:name:kr=*. Different names for junction and traffic signal are probably not a real-world case. Once more cite a mail on the previous thread [1] Seems to be a real world example, which is mappable with nodes for the traffic_signals and an area for the junction. cu fly [1] https://lists.openstreetmap.org/pipermail/tagging/2014-September/019349.html ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
