Re: [Tagging] New key proposal - paved=yes/no

2014-09-30 Thread Erik Johansson
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

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named

2014-09-30 Thread Janko Mihelić
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

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named

2014-09-30 Thread Lukas Sommer
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:

Re: [Tagging] tagging for graves?

2014-09-30 Thread Pieren
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

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named

2014-09-30 Thread Lukas Sommer
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