Re: [Tagging] landuse=grass = natural=grass

2014-09-19 Thread Martin Koppenhoefer
2014-09-18 11:44 GMT+02:00 Pieren pier...@gmail.com:

 I think the consensus is to stay as simple as possible and use only
 one tag to say that there is grass on this piece of land.



I think the consensus is to describe any property you like in OSM. Using
only one tag to summarize a lot of aspects is hardly ever a good idea,
because it limits the way to use the data and makes contributors life more
complicated and not easier (because they have to weight a lot of aspects
instead of directly tagging what they see).

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2014-09-19 Thread johnw

On Sep 19, 2014, at 5:59 AM, Lukas Sommer sommer...@gmail.com wrote:

 * Here, I still do not see your point. What would you gain in doing so? You 
 have more tags, which means more work. But can you do anything that you can 
 not do with the current, yet existing tagging?

Differentiated tagging is needed for differentiated rendering.  junction vs 
Signal. a single signal icon needs to be rendered in Japan for intersections. 

 
 * highway=junction is impossible because the OSM database does not allow two 
 tags with the same key on the same element
 
 * junction=traffic_signals would also be problematic because in Japan you can 
 have named traffic signals on straight road, for pedestrian crossing
 , and there is not any road junction.

is there a way to tell the renderer to not render it's icon if it is part of 
another area's way? that would allow the intersection tag to take over for the 
rendering of the signals for it's single icon.  

if that's the case:

landmark=intersection  ?
Intersection=signals for Japan, intersection=junction for korea, or other named 
junctions. 


Javbw___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

2014-09-19 Thread Dan S
Hi all,

I have been fixing some university tagging (Sheffield contained
hundreds of amenity=university!). For student accommodation, I have
been using

 for buildings:   building=residential + residential=university + operator=*
OR
 for sites:   landuse=residential + residential=university + operator=*

Note that the same scheme seems to me to work well for building and for landuse.

I thought this had been discussed on tagging recently, but I can't
find it, all I can find is the RFC for amenity=dormitory, currently
used 263 times. (I will add that dormitory is certainly a little odd
from a British English point of view, notwithstanding the comments
already made to the RFC.)

residential=university has been used by a few people (99 objects, says
overpass). 33 of these are building=residential, 53 are
landuse=residential.

It's clear I'm not the only one using this pattern, though it's not an
approach that's officially adopted as far as I know. To me it seems
very meaningful usage, compatible with existing tagging, and covers
the intended use of amenity=dormitory except for monasteries ;)

Thoughts?

Best
Dan

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2014-09-19 Thread Lukas Sommer
 Differentiated tagging is needed for differentiated rendering.  junction
 vs Signal. a single signal icon needs to be rendered in Japan for
 intersections.


But that is yet working perfectly with the current tagging!

In Korea, we have yet thousands of nodes with junction=yes and name=*, and
they are rendered just with their name (and without any icon) at osm.org.
Example: http://www.openstreetmap.org/#map=17/37.48391/126.65874

In Japan, we have yet thousands of nodes with highway=traffic_signals and
name=*, and they are rendered with their name together with the icon at
osm.org. Example: http://www.openstreetmap.org/#map=17/34.43281/132.46446

(I know that the rendering style is not very “japanese”, but osm.org has
worldwide coverage and has to render something that fits best at least a
big part of the world. But this is a _rendering_ issue, not a _tagging_
issue.)

There is only a problem when you have to tag complex junctions or traffic
signal systems with dual carrigeways, because you want that the icon the
the name show up only _once_ per junction/traffic signal system, and not
_multiple_ times. That’s what is proposal is for.

is there a way to tell the renderer to not render it's icon if it is part
 of another area's way? that would allow the intersection tag to take over
 for the rendering of the signals for it's single icon.


I guess you want to say that we have to supress the rendering of individual
traffic signals (nodes with highway=traffic_signals) if these node are
located within the area element that marks the traffic signal system as a
hole. So we render only the area element and we get only _one_ icon and
name per traffic signal system.

Indeed that is exactly what is necessary, and I’ve made my proposal based
on this assumption.

I assumed that this is tecnically easy, but I’ll check this again…


 if that's the case:

 landmark=intersection  ?
 Intersection=signals for Japan, intersection=junction for korea, or other
 named junctions.


Again, I do not see the point in introducing here a new tag. Using the
existing junction=yes in Korea and the existing highway=traffic_signals in
Japan – just not only on nodes but extending it also also on closed ways
(=areas) – should be fine.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

2014-09-19 Thread Tobias Knerr
On 19.09.2014 14:22 Dan S wrote:
  for buildings:   building=residential + residential=university + operator=*
 OR
  for sites:   landuse=residential + residential=university + operator=*
 
 Note that the same scheme seems to me to work well for building and for 
 landuse.
 
 I thought this had been discussed on tagging recently, but I can't
 find it, all I can find is the RFC for amenity=dormitory, currently
 used 263 times. (I will add that dormitory is certainly a little odd
 from a British English point of view, notwithstanding the comments
 already made to the RFC.)

That proposal now suggests amenity=student_accommodation, precisely
because of the oddness involved with the term dormitory.

Personally, I prefer using the amenity key rather than building or
landuse. Landuse lacks the implication that this is one distinct
facility, and building values are not supposed to represent usage, but
how the building is built.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

2014-09-19 Thread Martin Koppenhoefer
2014-09-19 14:22 GMT+02:00 Dan S danstowell+...@gmail.com:


  for buildings:   building=residential + residential=university +
 operator=*
 OR
  for sites:   landuse=residential + residential=university + operator=*

 Note that the same scheme seems to me to work well for building and for
 landuse.



I am not sure if this works. Have you been looking at current values for
the residential key? These are the ones with more than 100 uses:

rural http://taginfo.openstreetmap.org/tags/residential=rural
78 141

-

urban http://taginfo.openstreetmap.org/tags/residential=urban
12 698

-

garden http://taginfo.openstreetmap.org/tags/residential=garden
3 805

-

gated http://taginfo.openstreetmap.org/tags/residential=gated
884

-

apartments http://taginfo.openstreetmap.org/tags/residential=apartments
231

-

single_family
http://taginfo.openstreetmap.org/tags/residential=single_family
197

-

detached http://taginfo.openstreetmap.org/tags/residential=detached
133



There are already at least 3 different systems (one for rural / urban and
one for the building typology (detached / single_family / apartments) and
one for gated communities (what's this, socio-economic aspect of urbanism
maybe?). Now you seem to be adding yet another one, university for
student's appartments (not really self explaining IMHO).

I would use a specific tag for the building typology (e.g.
building=dormitory or student_accomodation or similar if the building was
built as such) and another one if it is actually used as such (e.g. under
the amenity key as suggested by Tobias).

I don't see this as a case for adding a specific landuse value, but I do
agree that refining the generic residential into more differentiated
values by subtagging might be a general option (regardless of this
particular case of student accomodation), e.g. differentiate according to
density and

structure (open / closed, not sure about the precise term in English, for
reference see these two pictures:
open (=space between buildings)
http://de.wikipedia.org/wiki/Offene_Bauweise_%28Baurecht%29#mediaviewer/File:Offene_Bauweise.png
closed (buildings without space between them):
http://de.wikipedia.org/wiki/Geschlossene_Bauweise_%28Baurecht%29#mediaviewer/File:Geschlossene_Bauweise.png

the above distinction is still quite generic, both of these types also have
a lot of subtypes (ideally, then there are mixed cases).

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The not-shops: industrial, industry, or business

2014-09-19 Thread Michał Brzozowski
I'm surprised nobody so far mentioned Mapbox's Maki icon set:

https://www.mapbox.com/maki/

Another thing maps based on OSM lack is clickability (like Google Maps
or Bing Maps). It's less CPU intensive than placing markers
afterwards. Maybe there's some clever way to embed clickable spots
information (just coordinates) into the tiles themselves.
Michał

On Thu, Sep 18, 2014 at 11:08 PM, John F. Eldredge j...@jfeldredge.com wrote:
 Agreed. The general-purpose renderings, at least those intended for
 small-screen use, should use a limited number of icons, and those should
 each apply to a range of related object types. Large-screen and printed maps
 can use a wider range of icon types, since there is room for a map legend.
 Special-purpose renderings can use more specific icons, but may need to
 either include a legend or provide a link to a legend.



 On September 16, 2014 1:32:29 AM CDT, Frederik Ramm frede...@remote.org
 wrote:

 Hi,

 On 09/15/2014 07:43 PM, Bryce Nesbitt wrote:

  Maybe this is running up on the limit of only rendering shop values with
  100 instances?


 I think that many people think too much information science (how can I
 compress the most information into the smallest room) and too little
 cartography (how can I make a map with a good user interface).

 A map icon is what, 32x32 pixels or so? A couple of millimeters on the
 screen. As long as you stick to 20 POI icons, you will be able to select
 icons that are instantly recognizable. Something with a film strip...
 must be a cinema. Once you introduce 100 icons, your map becomes
 unreadable without a legend. Yes you *can* devise a film-strip-and-pipe
 icon denoting a cinema that uniquely shows crime dramas but you're
 leaving the realm of the easy-to-use map (much like having 5 different
 types of dash-dot patterns for various types of tracks).

 It appears to me that unless the user actively requests to drill down
 deeper on something (and we have the technology to do that), we should
 stick with a very small number of icons.

 Maybe we can find a way to actually detect that shop=bicycle;skateboard
 is some kind of sports-related shop and display a generic
 sports-related-shop icon, the same that we would use for shop=bicycle or
 shop=skateboard alone.

 Bye
 Frederik


 --
 John F. Eldredge -- j...@jfeldredge.com
 Darkness cannot drive out darkness; only light can do that. Hate cannot
 drive out hate; only love can do that.
 Dr. Martin Luther King, Jr.

 ___
 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] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

2014-09-19 Thread Lukas Sommer
 Again, I do not see the point in introducing here a new tag. Using the
 existing junction=yes in Korea and the existing highway=traffic_signals in
 Japan – just not only on nodes but extending it also also on closed ways
 (=areas) – should be fine.


Okay, here I have to correct myself. It may be useful to have a different
tag for the area instead of using the same on the node, especially for
editor software and checking software, but also other software.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2014-09-19 Thread Lukas Sommer
Some random thoughts about names for the area tags:

junction=yes on nodes
For areas:
– something that contains “junction” and “area”
– junction=area ?

highway=traffic_signals on nodes
For areas:
– something that contains “traffic signal system” (also “system”!) and also
“area”
– maybe not traffic_signals=* which seems to have either another meaning
– highway=traffic_signal_system_area (quite long)?

Lukas Sommer

2014-09-19 18:27 GMT+00:00 Lukas Sommer sommer...@gmail.com:


 Again, I do not see the point in introducing here a new tag. Using the
 existing junction=yes in Korea and the existing highway=traffic_signals in
 Japan – just not only on nodes but extending it also also on closed ways
 (=areas) – should be fine.


 Okay, here I have to correct myself. It may be useful to have a different
 tag for the area instead of using the same on the node, especially for
 editor software and checking software, but also other software.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2014-09-19 Thread Lukas Sommer
After thinking more about the tag name question: It may be useful to use
for the complex situation at least the same key as for their conterpart in
simple situations. This is intuitive (usability), and at the same time the
tags for the simple and for the complex situation are mutually exclusive,
which can be practical. Means:

Korea:
– simple: junction=yes
– complex: junction=junction_area

Japan:
– simple: highway=traffic_signals
– complex: highway=traffic_signals_area

I’ve updated the proposal page on the wiki.

Lukas Sommer

2014-09-19 18:32 GMT+00:00 Lukas Sommer sommer...@gmail.com:

 Some random thoughts about names for the area tags:

 junction=yes on nodes
 For areas:
 – something that contains “junction” and “area”
 – junction=area ?

 highway=traffic_signals on nodes
 For areas:
 – something that contains “traffic signal system” (also “system”!) and
 also “area”
 – maybe not traffic_signals=* which seems to have either another meaning
 – highway=traffic_signal_system_area (quite long)?

 Lukas Sommer

 2014-09-19 18:27 GMT+00:00 Lukas Sommer sommer...@gmail.com:


 Again, I do not see the point in introducing here a new tag. Using the
 existing junction=yes in Korea and the existing highway=traffic_signals in
 Japan – just not only on nodes but extending it also also on closed ways
 (=areas) – should be fine.


 Okay, here I have to correct myself. It may be useful to have a different
 tag for the area instead of using the same on the node, especially for
 editor software and checking software, but also other software.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2014-09-19 Thread johnw
I don't know much about how the rendering system parses the tags. I thought t 
would be non-trivial for it to work out how to display signal icons without a 
new tag, so I thought a new tag might be necessary, and  gave my suggestion. 

I'm aware the current system is in use a lot for simple 1 node intersections, 
but as the number of complex intersections increases (?micro-mapping?), so will 
the need for a solution.

Javbw

On Sep 19, 2014, at 11:32 PM, Lukas Sommer sommer...@gmail.com wrote:

 
 Differentiated tagging is needed for differentiated rendering.  junction vs 
 Signal. a single signal icon needs to be rendered in Japan for 
 intersections. 
 
 But that is yet working perfectly with the current tagging!
 
 In Korea, we have yet thousands of nodes with junction=yes and name=*, and 
 they are rendered just with their name (and without any icon) at osm.org. 
 Example: http://www.openstreetmap.org/#map=17/37.48391/126.65874
 
 In Japan, we have yet thousands of nodes with highway=traffic_signals and 
 name=*, and they are rendered with their name together with the icon at 
 osm.org. Example: http://www.openstreetmap.org/#map=17/34.43281/132.46446
 
 (I know that the rendering style is not very “japanese”, but osm.org has 
 worldwide coverage and has to render something that fits best at least a big 
 part of the world. But this is a _rendering_ issue, not a _tagging_ issue.)
 
 There is only a problem when you have to tag complex junctions or traffic 
 signal systems with dual carrigeways, because you want that the icon the the 
 name show up only _once_ per junction/traffic signal system, and not 
 _multiple_ times. That’s what is proposal is for.
 
 is there a way to tell the renderer to not render it's icon if it is part of 
 another area's way? that would allow the intersection tag to take over for 
 the rendering of the signals for it's single icon.  
 
 I guess you want to say that we have to supress the rendering of individual 
 traffic signals (nodes with highway=traffic_signals) if these node are 
 located within the area element that marks the traffic signal system as a 
 hole. So we render only the area element and we get only _one_ icon and name 
 per traffic signal system.
 
 Indeed that is exactly what is necessary, and I’ve made my proposal based on 
 this assumption.
 
 I assumed that this is tecnically easy, but I’ll check this again…
  
 if that's the case:
 
 landmark=intersection  ?
 Intersection=signals for Japan, intersection=junction for korea, or other 
 named junctions.
 
 Again, I do not see the point in introducing here a new tag. Using the 
 existing junction=yes in Korea and the existing highway=traffic_signals in 
 Japan – just not only on nodes but extending it also also on closed ways 
 (=areas) – should be fine.
 ___
 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] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

2014-09-19 Thread johnw

On Sep 20, 2014, at 6:37 AM, Lukas Sommer sommer...@gmail.com wrote:

 After thinking more about the tag name question: It may be useful to use for 
 the complex situation at least the same key as for their conterpart in simple 
 situations. This is intuitive (usability), and at the same time the tags for 
 the simple and for the complex situation are mutually exclusive, which can be 
 practical. Means:
 
 Korea:
 – simple: junction=yes
 – complex: junction=junction_area
 
 Japan:
 – simple: highway=traffic_signals
 – complex: highway=traffic_signals_area

Great solution ^_^

Javbw
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2014-09-19 Thread John Baker
Yeah sadly it is fairly complex to display different icons in different 
locations. Not something we will doing in OSM carto for a good while.

From: jo...@mac.com
Date: Sat, 20 Sep 2014 07:07:56 +0900
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions 
or traffic signals that are named

I don't know much about how the rendering system parses the tags. I thought t 
would be non-trivial for it to work out how to display signal icons without a 
new tag, so I thought a new tag might be necessary, and  gave my suggestion. 
I'm aware the current system is in use a lot for simple 1 node intersections, 
but as the number of complex intersections increases (?micro-mapping?), so will 
the need for a solution.
Javbw
On Sep 19, 2014, at 11:32 PM, Lukas Sommer sommer...@gmail.com wrote:
Differentiated tagging is needed for differentiated rendering.  junction vs 
Signal. a single signal icon needs to be rendered in Japan for intersections. 
But that is yet working perfectly with the current tagging!

In Korea, we have yet thousands of nodes with junction=yes and name=*, and they 
are rendered just with their name (and without any icon) at osm.org. Example: 
http://www.openstreetmap.org/#map=17/37.48391/126.65874

In Japan, we have yet thousands of nodes with highway=traffic_signals and 
name=*, and they are rendered with their name together with the icon at 
osm.org. Example: http://www.openstreetmap.org/#map=17/34.43281/132.46446
(I know that the rendering style is not very “japanese”, but osm.org has 
worldwide coverage and has to render something that fits best at least a big 
part of the world. But this is a _rendering_ issue, not a _tagging_ issue.)

There is only a problem when you have to tag complex junctions or traffic 
signal systems with dual carrigeways, because you want that the icon the the 
name show up only _once_ per junction/traffic signal system, and not _multiple_ 
times. That’s what is proposal is for.

is there a way to tell the renderer to not render it's icon if it is part of 
another area's way? that would allow the intersection tag to take over for the 
rendering of the signals for it's single icon.  
I guess you want to say that we have to supress the rendering of 
individual traffic signals (nodes with highway=traffic_signals) if these
 node are located within the area element that marks the traffic signal 
system as a hole. So we render only the area element and we get only 
_one_ icon and name per traffic signal system.

Indeed that is exactly what is necessary, and I’ve made my proposal based on 
this assumption.

I assumed that this is tecnically easy, but I’ll check this again…
 
if that's the case:
landmark=intersection  ?Intersection=signals for Japan, intersection=junction 
for korea, or other named junctions.

Again, I do not see the point in introducing here a new tag. Using the existing 
junction=yes in Korea and the existing highway=traffic_signals in Japan – just 
not only on nodes but extending it also also on closed ways (=areas) – should 
be fine.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


___
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] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

2014-09-19 Thread johnw
So the solution for a complex intersection is to have a signal_area area with 
an outline that intersects with all the nodes where the signal would affect the 
traffic? This would let the renderer use one icon, and still have the ways 
marked in the proper spot for the intersection, right? (assuming they will 
support signal_area).

Javbw




On Sep 20, 2014, at 8:10 AM, John Baker rovas...@hotmail.com wrote:

 Yeah sadly it is fairly complex to display different icons in different 
 locations. Not something we will doing in OSM carto for a good while.
 
 From: jo...@mac.com
 Date: Sat, 20 Sep 2014 07:07:56 +0900
 To: tagging@openstreetmap.org
 Subject: Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions 
 or traffic signals that are named
 
 I don't know much about how the rendering system parses the tags. I thought t 
 would be non-trivial for it to work out how to display signal icons without a 
 new tag, so I thought a new tag might be necessary, and  gave my suggestion. 
 
 I'm aware the current system is in use a lot for simple 1 node intersections, 
 but as the number of complex intersections increases (?micro-mapping?), so 
 will the need for a solution.
 
 Javbw
 
 On Sep 19, 2014, at 11:32 PM, Lukas Sommer sommer...@gmail.com wrote:
 
 
 Differentiated tagging is needed for differentiated rendering.  junction vs 
 Signal. a single signal icon needs to be rendered in Japan for 
 intersections. 
 
 But that is yet working perfectly with the current tagging!
 
 In Korea, we have yet thousands of nodes with junction=yes and name=*, and 
 they are rendered just with their name (and without any icon) at osm.org. 
 Example: http://www.openstreetmap.org/#map=17/37.48391/126.65874
 
 In Japan, we have yet thousands of nodes with highway=traffic_signals and 
 name=*, and they are rendered with their name together with the icon at 
 osm.org. Example: http://www.openstreetmap.org/#map=17/34.43281/132.46446
 
 (I know that the rendering style is not very “japanese”, but osm.org has 
 worldwide coverage and has to render something that fits best at least a big 
 part of the world. But this is a _rendering_ issue, not a _tagging_ issue.)
 
 There is only a problem when you have to tag complex junctions or traffic 
 signal systems with dual carrigeways, because you want that the icon the the 
 name show up only _once_ per junction/traffic signal system, and not 
 _multiple_ times. That’s what is proposal is for.
 
 is there a way to tell the renderer to not render it's icon if it is part of 
 another area's way? that would allow the intersection tag to take over for 
 the rendering of the signals for it's single icon.  
 
 I guess you want to say that we have to supress the rendering of individual 
 traffic signals (nodes with highway=traffic_signals) if these node are 
 located within the area element that marks the traffic signal system as a 
 hole. So we render only the area element and we get only _one_ icon and name 
 per traffic signal system.
 
 Indeed that is exactly what is necessary, and I’ve made my proposal based on 
 this assumption.
 
 I assumed that this is tecnically easy, but I’ll check this again…
  
 if that's the case:
 
 landmark=intersection  ?
 Intersection=signals for Japan, intersection=junction for korea, or other 
 named junctions.
 
 Again, I do not see the point in introducing here a new tag. Using the 
 existing junction=yes in Korea and the existing highway=traffic_signals in 
 Japan – just not only on nodes but extending it also also on closed ways 
 (=areas) – should be fine.
 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging
 
 
 ___ Tagging mailing list 
 Tagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging