Traffic_sign discussion

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Traffic_sign discussion

yo paseopor

I want to start the mother of all discussions about traffic signs

It is not the first attempt to do that. Last days, with iD implementation and my message I have think it was the solution. Also I have waited some days and communicate to this list my intentions to adopt the proposed iD scheme. But when I start to do the modifications... People complains about it (I am sorry if there was some errors "translating" to the new scheme).

So Please , let's talk about it. What will be the correct way to tag a traffic sign?

I start with my option. Traffic sign as a NODE on the way x direction. Because traffic sign is relative to the way, the road, not the building or the street itselfs, it is located above, as a road mark, on the right of the road or on the left of the road (or both of them).

I'm interested in all countries so a good way to do it is with the country code for every traffic sign you can find in every traffic law in every country. 
It would be interesting also to develope a generic scheme for tagging it (not only the country/code)

traffic_sign=XX:yyy (XX Country ISO code):(yyy ref or number in specific of each country traffic signs law)

Also it is facing to the direction of the way (forward and backward). In OSM ways have the direction you have drawn it. So the info is relative to this direction.

As an issue detected in iD with it to make possible the edition of traffic signs good way was the traffic_signals solution: an specific key.

traffic_sign:direction=forward/backward/both

Also accepts other facing directions like 90/270...

Also we need the info relative to the way of its location , the side where it is: Is it on the right? Is it on the left? 

side=right/left/both

And also position, because you can have more than one traffic sign. Finnish people give the solution :2

traffic_sign:2=*

To tag this we have some informations sources (of course first of all local knowledge) like Mapillary or OpenStreetCam.

Tools we have now:

JOSM preset
JOSM style
JOSM Kendzi3D's configuration files and models
Leaflet traffic signs map
Taginfo stats

More info about it :


Main characteristics of the scheme:

-Scalable (you can locate every traffic sign in every place)
-Exportable (you can locate every traffic sign of every country in the World, with or without JOSM wizards)
-1 key / 1 value (for making the renders easy to adopt it)

yopaseopor

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic_sign discussion

Paul Johnson-3
Why not map traffic signs the way enforcement devices are currently mapped in relations?  That's more foolproof than relying on nodes having nonextant direction, especially when most traffic signs aren't even members of ways.

On Tue, Oct 9, 2018, 10:46 yo paseopor <[hidden email]> wrote:

I want to start the mother of all discussions about traffic signs

It is not the first attempt to do that. Last days, with iD implementation and my message I have think it was the solution. Also I have waited some days and communicate to this list my intentions to adopt the proposed iD scheme. But when I start to do the modifications... People complains about it (I am sorry if there was some errors "translating" to the new scheme).

So Please , let's talk about it. What will be the correct way to tag a traffic sign?

I start with my option. Traffic sign as a NODE on the way x direction. Because traffic sign is relative to the way, the road, not the building or the street itselfs, it is located above, as a road mark, on the right of the road or on the left of the road (or both of them).

I'm interested in all countries so a good way to do it is with the country code for every traffic sign you can find in every traffic law in every country. 
It would be interesting also to develope a generic scheme for tagging it (not only the country/code)

traffic_sign=XX:yyy (XX Country ISO code):(yyy ref or number in specific of each country traffic signs law)

Also it is facing to the direction of the way (forward and backward). In OSM ways have the direction you have drawn it. So the info is relative to this direction.

As an issue detected in iD with it to make possible the edition of traffic signs good way was the traffic_signals solution: an specific key.

traffic_sign:direction=forward/backward/both

Also accepts other facing directions like 90/270...

Also we need the info relative to the way of its location , the side where it is: Is it on the right? Is it on the left? 

side=right/left/both

And also position, because you can have more than one traffic sign. Finnish people give the solution :2

traffic_sign:2=*

To tag this we have some informations sources (of course first of all local knowledge) like Mapillary or OpenStreetCam.

Tools we have now:

JOSM preset
JOSM style
JOSM Kendzi3D's configuration files and models
Leaflet traffic signs map
Taginfo stats

More info about it :


Main characteristics of the scheme:

-Scalable (you can locate every traffic sign in every place)
-Exportable (you can locate every traffic sign of every country in the World, with or without JOSM wizards)
-1 key / 1 value (for making the renders easy to adopt it)

yopaseopor
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic_sign discussion

Colin Smale
In reply to this post by yo paseopor

I can think of a couple of non-trivial cases which will need to be handled:

1) multiple signs on a single post

2) signs with a dependent (qualifier) sign, such as "except for buses"

3) one or more signs on a larger panel - too large to represent as a node

4) signs applying only to certain lanes

5) signs on a gantry above (half of) the road

I can understand the argument for mapping the signs as objects in their own right. This would be limited to being a database of street furniture, unless and until the effect of the signs can be linked to the effect they have on traffic (in the broadest sense), which is the starting point for the present discussion. This is of course a serious exercise to ensure the link from the sign to the effect is represented unambiguously.

We already have turn restrictions, maxspeed, maxheight etc on the ways themselves (without needing to have any link to a sign). This model works reasonably well for routing applications, albeit not without some discussion about the types of "weight" and so on.

The point I am trying to make, is that there might not be much of a "business case" for linking the signs/posts to their effects, and that mapping them as "street furniture" might be going far enough...


On 2018-10-09 17:42, yo paseopor wrote:

 
I want to start the mother of all discussions about traffic signs
 
It is not the first attempt to do that. Last days, with iD implementation and my message I have think it was the solution. Also I have waited some days and communicate to this list my intentions to adopt the proposed iD scheme. But when I start to do the modifications... People complains about it (I am sorry if there was some errors "translating" to the new scheme).
 
So Please , let's talk about it. What will be the correct way to tag a traffic sign?
 
I start with my option. Traffic sign as a NODE on the way x direction. Because traffic sign is relative to the way, the road, not the building or the street itselfs, it is located above, as a road mark, on the right of the road or on the left of the road (or both of them).
 
I'm interested in all countries so a good way to do it is with the country code for every traffic sign you can find in every traffic law in every country. 
It would be interesting also to develope a generic scheme for tagging it (not only the country/code)
 
traffic_sign=XX:yyy (XX Country ISO code):(yyy ref or number in specific of each country traffic signs law)
 
Also it is facing to the direction of the way (forward and backward). In OSM ways have the direction you have drawn it. So the info is relative to this direction.
 
As an issue detected in iD with it to make possible the edition of traffic signs good way was the traffic_signals solution: an specific key.
 
traffic_sign:direction=forward/backward/both
 
Also accepts other facing directions like 90/270...
 
Also we need the info relative to the way of its location , the side where it is: Is it on the right? Is it on the left? 
 
side=right/left/both
 
And also position, because you can have more than one traffic sign. Finnish people give the solution :2
 
traffic_sign:2=*
 
To tag this we have some informations sources (of course first of all local knowledge) like Mapillary or OpenStreetCam.
 
Tools we have now:
 
JOSM preset
JOSM style
JOSM Kendzi3D's configuration files and models
Leaflet traffic signs map
Taginfo stats
 
More info about it :
 
 
Main characteristics of the scheme:
 
-Scalable (you can locate every traffic sign in every place)
-Exportable (you can locate every traffic sign of every country in the World, with or without JOSM wizards)
-1 key / 1 value (for making the renders easy to adopt it)
 
yopaseopor

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic_sign discussion

Tordanik
In reply to this post by yo paseopor
On 09.10.2018 17:42, yo paseopor wrote:
> So Please , let's talk about it. What will be the correct way to tag a
> traffic sign?

How about the existing tagging scheme for traffic signs on nodes,
documented at https://wiki.osm.org/Key:traffic_sign ?

To sum it up:

- Place a node for the traffic sign into the highway=* way.¹
- Tag the node as traffic_sign=<ISO>:<ids>.
- As with your suggestion, <ISO> is the ISO country code.
- <ids> is composed of one or more country-specific traffic sign ids, as
an ordered list separated by commas.
- If there are multiple groups of traffic signs, these groups are
separated by semicolons.
- Custom inscriptions on a sign are appended to the sign id in square
brackets [].

¹ The page also documents how to map traffic signs next to the way, but
I understand you would like to talk about mapping them as part of the way.

I haven't seen a convincing reason for changing this yet. I'm aware of
the general argument against semicolon-separated or comma-separated
lists of values, but imo this is less critical for keys that have
well-defined semantics for such characters.

> traffic_sign:direction=forward/backward/both
>
> Also accepts other facing directions like 90/270...

In my opinion, traffic signs should use the normal direction=* key for
angles such as 90 or 270. This usage is part of the approved proposal of
that key:

https://wiki.osm.org/Proposed_features/direction#Point_features

Using traffic_sign:direction specifically for the "forward" and
"backward" values, as discussed in the recent iD-related thread, is fine.

> https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging

I find it hard to discuss this proposal because it includes so many
different ideas:

- introducing a system of "categories" for signs: caution, warning, etc.
- using :2, :3 etc. instead of comma-separated ids
- using human-readable values instead of unambiguous national IDs
- re-purposing maxspeed (and maxspeed:hgv etc.) for traffic sign mapping
- adding a side=* key
- improving destination sign and roundabout mapping

Trying to change all that at once likely leads to discussions that mix
all sorts of loosely related topics. And there's not really a reason why
e.g. introducing the side=* key would also require using numeric
suffixes. These are independent changes that could easily be discussed
separately.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic_sign discussion

Frederik Ramm
In reply to this post by yo paseopor
Hi,

On 10/09/2018 05:42 PM, yo paseopor wrote:
> It is not the first attempt to do that. Last days, with iD
> implementation and my message I have think it was the solution. Also I
> have waited some days and communicate to this list my intentions to
> adopt the proposed iD scheme. But when I start to do the
> modifications... People complains about it (I am sorry if there was some
> errors "translating" to the new scheme).

Yes, DWG has also received complaints about these edits, and I am in the
process of reverting them.

At the very least you should have established a consensus on this list
for the precise edit you want to perform. You should have said: I am
going to load objects tagged so-and-so, and I am going to apply these
modifications using these tools.  (consensus doesn't mean everyone has
to be in favour, but you simply went ahead and changed things and wrote
in your changeset comment "#fastag #traffic_signs Apply
traffic_sign:direction tag to avoid problems with new iD editor as an
agreement on tagging list" which almost sounds like you were fixing a
bug and there was consensus, neither of which is strictly true.

I'm not saying these edits cannot ever be made, but they can certainly
not be made in a buggy fashion after a half-hearted attempt at
discussion with no discernible outcome.

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic_sign discussion

yo paseopor
In reply to this post by Paul Johnson-3
for this reason the solution of tag the traffic signs ON the way it's the best way to do it. Traffic signs are relative to their ways (because if the way does not exist the existance of traffic sign is non-sense). Ways have direction, also their nodes can have this reference.

Relations are complex and also are an item not all the mappers can do. Why don't accept the easiest way to get this information?
(Now it works without relations)

yopaseopor

On Tue, Oct 9, 2018 at 7:53 PM Paul Johnson <[hidden email]> wrote:
Why not map traffic signs the way enforcement devices are currently mapped in relations?  That's more foolproof than relying on nodes having nonextant direction, especially when most traffic signs aren't even members of ways.

On Tue, Oct 9, 2018, 10:46 yo paseopor <[hidden email]> wrote:

I want to start the mother of all discussions about traffic signs

It is not the first attempt to do that. Last days, with iD implementation and my message I have think it was the solution. Also I have waited some days and communicate to this list my intentions to adopt the proposed iD scheme. But when I start to do the modifications... People complains about it (I am sorry if there was some errors "translating" to the new scheme).

So Please , let's talk about it. What will be the correct way to tag a traffic sign?

I start with my option. Traffic sign as a NODE on the way x direction. Because traffic sign is relative to the way, the road, not the building or the street itselfs, it is located above, as a road mark, on the right of the road or on the left of the road (or both of them).

I'm interested in all countries so a good way to do it is with the country code for every traffic sign you can find in every traffic law in every country. 
It would be interesting also to develope a generic scheme for tagging it (not only the country/code)

traffic_sign=XX:yyy (XX Country ISO code):(yyy ref or number in specific of each country traffic signs law)

Also it is facing to the direction of the way (forward and backward). In OSM ways have the direction you have drawn it. So the info is relative to this direction.

As an issue detected in iD with it to make possible the edition of traffic signs good way was the traffic_signals solution: an specific key.

traffic_sign:direction=forward/backward/both

Also accepts other facing directions like 90/270...

Also we need the info relative to the way of its location , the side where it is: Is it on the right? Is it on the left? 

side=right/left/both

And also position, because you can have more than one traffic sign. Finnish people give the solution :2

traffic_sign:2=*

To tag this we have some informations sources (of course first of all local knowledge) like Mapillary or OpenStreetCam.

Tools we have now:

JOSM preset
JOSM style
JOSM Kendzi3D's configuration files and models
Leaflet traffic signs map
Taginfo stats

More info about it :


Main characteristics of the scheme:

-Scalable (you can locate every traffic sign in every place)
-Exportable (you can locate every traffic sign of every country in the World, with or without JOSM wizards)
-1 key / 1 value (for making the renders easy to adopt it)

yopaseopor
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic_sign discussion

Paul Johnson-3


On Tue, Oct 9, 2018, 16:05 yo paseopor <[hidden email]> wrote:
for this reason the solution of tag the traffic signs ON the way it's the best way to do it. Traffic signs are relative to their ways (because if the way does not exist the existance of traffic sign is non-sense). Ways have direction, also their nodes can have this reference.

It's also not correct, that's not where the sign is.

Relations are complex and also are an item not all the mappers can do.

Only if the editor makes it hard.  See also: Turn restrictions, routes.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic_sign discussion

yo paseopor
In reply to this post by Colin Smale


On Tue, Oct 9, 2018 at 8:16 PM Colin Smale <[hidden email]> wrote:

I can think of a couple of non-trivial cases which will need to be handled:

1) multiple signs on a single post

  As Finnish people do we can add subkey :2 :3 :4... (European regulations does nit recommend more than 3 traffic_signs together to make better their readibility.


2) signs with a dependent (qualifier) sign, such as "except for buses"

 Complementary signs are also traffic signs (in second, in third position) with its own code, so they need their information (the same osm tags we have for ways?)  and position. A few weeks ago in this list I talk about the possible changes for "designation" value to make a key with this more specific information

3) one or more signs on a larger panel - too large to represent as a node

Sorry but I don't agree with you... because I test it...and it works. Example for a complete destination traffic sign

colour:arrow black
colour:arrow:lower_panel white
colour:back white
colour:back:lower_panel blue
colour:ref red
colour:ref:lower_panel blue
colour:text white
colour:text:lower_panel white
destination:lower Coma-ruga
destination:lower_panel Barcelona
destination:lower_panel:lower Aeroport
destination:lower_panel:upper Vilanova i la Geltrú
destination:symbol:lower_panel:lower airport
destination:upper El Vendrell
length 500
ref N-340
ref:lower_panel C-32
side up
time:1 00:05
time:3 00:05
time:b 01:00
time:b:1 00:20
time:b:3 00:45
traffic_sign:2:forward ES:S235a
traffic_sign:forward ES:S235a
turn:destination under
turn:destination:lower_panel under
type destination_sign
 

4) signs applying only to certain lanes

you can specify the lanes and the exact information with all these tags (lanes scheme already exists)

5) signs on a gantry above (half of) the road

The example above is like the granty sign (with the same tags)

I can understand the argument for mapping the signs as objects in their own right. This would be limited to being a database of street furniture, unless and until the effect of the signs can be linked to the effect they have on traffic (in the broadest sense), which is the starting point for the present discussion. This is of course a serious exercise to ensure the link from the sign to the effect is represented unambiguously.

Barrier nodes acts in routing, why not the prohibition in overtaking? or the city limit? or the warnings?
 

We already have turn restrictions, maxspeed, maxheight etc on the ways themselves (without needing to have any link to a sign). This model works reasonably well for routing applications, albeit not without some discussion about the types of "weight" and so on.

Signs are a next level for routing, for GPS software. Why Street View cars and software wants to recognize traffic signs? Why don't you have the possibility to have the traffic signs recreated in your own screen, with only OSM data in a node?

 

The point I am trying to make, is that there might not be much of a "business case" for linking the signs/posts to their effects, and that mapping them as "street furniture" might be going far enough...

More than 30 countries, more than 24000 different traffic signs. In each country with their own traffic signs...why not? Are street lamps important? Are recycle bins important? Are Benchs important?
 
yopaseopor

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic_sign discussion

yo paseopor
In reply to this post by Tordanik


On Tue, Oct 9, 2018 at 8:37 PM Tobias Knerr <[hidden email]> wrote:
On 09.10.2018 17:42, yo paseopor wrote:
> So Please , let's talk about it. What will be the correct way to tag a
> traffic sign?

How about the existing tagging scheme for traffic signs on nodes,
documented at https://wiki.osm.org/Key:traffic_sign ?

To sum it up:

- Place a node for the traffic sign into the highway=* way.¹
It is
- Tag the node as traffic_sign=<ISO>:<ids>.
It is
- As with your suggestion, <ISO> is the ISO country code.
It is
- <ids> is composed of one or more country-specific traffic sign ids, as
an ordered list separated by commas.
It is better to manage the information with each position to avoid the mixtures. One of the errors of the mass edition were the edition of ways...with traffic signs tag. If any way would not have this key dedicated to the nodes there weren't these errors.
- If there are multiple groups of traffic signs, these groups are
separated by semicolons.
Each traffic sign can have its position like Finnish people do , with :2 :3 :4 subkeys
- Custom inscriptions on a sign are appended to the sign id in square
brackets [].
but which information are these brackets? Are maxspeed values? Are maxleght values? Are custom inscriptions or designations? It is better to expose this information with their own keys to process it by the renders

¹ The page also documents how to map traffic signs next to the way, but
I understand you would like to talk about mapping them as part of the way.
Thanks for this consideration

I haven't seen a convincing reason for changing this yet. I'm aware of
the general argument against semicolon-separated or comma-separated
lists of values, but imo this is less critical for keys that have
well-defined semantics for such characters.
multiple values are a problem for the processing of the data. Nowadays a lot of values are yes/no, etc. In this way of tagging it is logic to make the pairs :2 :3 or  :forward    :backward    , etc.

> traffic_sign:direction=forward/backward/both
>
> Also accepts other facing directions like 90/270...

In my opinion, traffic signs should use the normal direction=* key for
angles such as 90 or 270. This usage is part of the approved proposal of
that key:

If direction=0 is forward and direction=180 is =  backward ok I'm agree. Because if it marks the cardinal orientation these direction would change in every curve making less intuitive the tagging of the direction.

https://wiki.osm.org/Proposed_features/direction#Point_features

Using traffic_sign:direction specifically for the "forward" and
"backward" values, as discussed in the recent iD-related thread, is fine.

Some people does not agree and says the reason of the edition (make the scheme compatible with iD solution) sucks.
 

> https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging

I find it hard to discuss this proposal because it includes so many
different ideas:

- introducing a system of "categories" for signs: caution, warning, etc.
All these categories you can find in every traffic sign's law and also on the API of one of the possible sources: Mapillary. These keys help to make human-readable values and also international (because of the people does not want to use ISO codes) . There are also in OSM some categories like maxspeed , restriction...
 
- using :2, :3 etc. instead of comma-separated ids

Finnish people do so well
 
- using human-readable values instead of unambiguous national IDs

It would be an important decision because with country codes we can show exact traffic sign as it is for the country, not similar: equal.
- re-purposing maxspeed (and maxspeed:hgv etc.) for traffic sign mapping
Reusing tags for OSM. Only we have to change some options for validators
- adding a side=* key
For making a exact position using relatives to the way
- improving destination sign and roundabout mapping
Destination signs are one of the more important traffic signs because they show towns, local places  which connects to data in real place.

Trying to change all that at once likely leads to discussions that mix
all sorts of loosely related topics.
It is true it is complex. But as the topic for me is so important (making a tagging scheme for a World collaborative project like OSM) that I try to think ( I have started with this in 2011) how to do it and try and establish a complete (4 position, 3 panels (12 localizations) in two directions and two sides with basic colors)
Now we can discuss with a base that works. We can modify all we want, all we agree, all we think,  but we have the base.
 
And there's not really a reason why
e.g. introducing the side=* key would also require using numeric
suffixes. These are independent changes that could easily be discussed
separately.

Well this time I will start all the discussions to find a solution. I don't want to fight or read things like "sucks" or "stinky". I have dedicate lots of time, like other people and I don't think I deserve these words.

yopaseopor
 

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic_sign discussion

Paul Johnson-3
This whole "trying to cram everything including direction and how it relates to everything into a node" idea is fundamentally hosed.  Also literally why relations are a thing that exist.

On Tue, Oct 9, 2018 at 5:26 PM yo paseopor <[hidden email]> wrote:


On Tue, Oct 9, 2018 at 8:37 PM Tobias Knerr <[hidden email]> wrote:
On 09.10.2018 17:42, yo paseopor wrote:
> So Please , let's talk about it. What will be the correct way to tag a
> traffic sign?

How about the existing tagging scheme for traffic signs on nodes,
documented at https://wiki.osm.org/Key:traffic_sign ?

To sum it up:

- Place a node for the traffic sign into the highway=* way.¹
It is
- Tag the node as traffic_sign=<ISO>:<ids>.
It is
- As with your suggestion, <ISO> is the ISO country code.
It is
- <ids> is composed of one or more country-specific traffic sign ids, as
an ordered list separated by commas.
It is better to manage the information with each position to avoid the mixtures. One of the errors of the mass edition were the edition of ways...with traffic signs tag. If any way would not have this key dedicated to the nodes there weren't these errors.
- If there are multiple groups of traffic signs, these groups are
separated by semicolons.
Each traffic sign can have its position like Finnish people do , with :2 :3 :4 subkeys
- Custom inscriptions on a sign are appended to the sign id in square
brackets [].
but which information are these brackets? Are maxspeed values? Are maxleght values? Are custom inscriptions or designations? It is better to expose this information with their own keys to process it by the renders

¹ The page also documents how to map traffic signs next to the way, but
I understand you would like to talk about mapping them as part of the way.
Thanks for this consideration

I haven't seen a convincing reason for changing this yet. I'm aware of
the general argument against semicolon-separated or comma-separated
lists of values, but imo this is less critical for keys that have
well-defined semantics for such characters.
multiple values are a problem for the processing of the data. Nowadays a lot of values are yes/no, etc. In this way of tagging it is logic to make the pairs :2 :3 or  :forward    :backward    , etc.

> traffic_sign:direction=forward/backward/both
>
> Also accepts other facing directions like 90/270...

In my opinion, traffic signs should use the normal direction=* key for
angles such as 90 or 270. This usage is part of the approved proposal of
that key:

If direction=0 is forward and direction=180 is =  backward ok I'm agree. Because if it marks the cardinal orientation these direction would change in every curve making less intuitive the tagging of the direction.

https://wiki.osm.org/Proposed_features/direction#Point_features

Using traffic_sign:direction specifically for the "forward" and
"backward" values, as discussed in the recent iD-related thread, is fine.

Some people does not agree and says the reason of the edition (make the scheme compatible with iD solution) sucks.
 

> https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging

I find it hard to discuss this proposal because it includes so many
different ideas:

- introducing a system of "categories" for signs: caution, warning, etc.
All these categories you can find in every traffic sign's law and also on the API of one of the possible sources: Mapillary. These keys help to make human-readable values and also international (because of the people does not want to use ISO codes) . There are also in OSM some categories like maxspeed , restriction...
 
- using :2, :3 etc. instead of comma-separated ids

Finnish people do so well
 
- using human-readable values instead of unambiguous national IDs

It would be an important decision because with country codes we can show exact traffic sign as it is for the country, not similar: equal.
- re-purposing maxspeed (and maxspeed:hgv etc.) for traffic sign mapping
Reusing tags for OSM. Only we have to change some options for validators
- adding a side=* key
For making a exact position using relatives to the way
- improving destination sign and roundabout mapping
Destination signs are one of the more important traffic signs because they show towns, local places  which connects to data in real place.

Trying to change all that at once likely leads to discussions that mix
all sorts of loosely related topics.
It is true it is complex. But as the topic for me is so important (making a tagging scheme for a World collaborative project like OSM) that I try to think ( I have started with this in 2011) how to do it and try and establish a complete (4 position, 3 panels (12 localizations) in two directions and two sides with basic colors)
Now we can discuss with a base that works. We can modify all we want, all we agree, all we think,  but we have the base.
 
And there's not really a reason why
e.g. introducing the side=* key would also require using numeric
suffixes. These are independent changes that could easily be discussed
separately.

Well this time I will start all the discussions to find a solution. I don't want to fight or read things like "sucks" or "stinky". I have dedicate lots of time, like other people and I don't think I deserve these words.

yopaseopor
 

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic_sign discussion

Colin Smale
In reply to this post by yo paseopor

I am not saying these cases are impossible, only that they have to be accommodated, preferably as uniformly as possible. It is not intended as criticism, but as a critical test of fitness for purpose. If the tagging scheme can't handle these real-world situations, it's not ready for go-live yet.

 

On 2018-10-09 23:40, yo paseopor wrote:



On Tue, Oct 9, 2018 at 8:16 PM Colin Smale <[hidden email]> wrote:

I can think of a couple of non-trivial cases which will need to be handled:

1) multiple signs on a single post

  As Finnish people do we can add subkey :2 :3 :4... (European regulations does nit recommend more than 3 traffic_signs together to make better their readibility.

This is of course a fairly easy one. What European regulations are you referring to here by the way?


2) signs with a dependent (qualifier) sign, such as "except for buses"

 Complementary signs are also traffic signs (in second, in third position) with its own code, so they need their information (the same osm tags we have for ways?)  and position. A few weeks ago in this list I talk about the possible changes for "designation" value to make a key with this more specific information
How do you make the link between the qualifier and the main sign it applies to? Does it only apply to the one sign immediately above? Or to all signs above? Or the sign(s) below? How would these links work for multiple qualifier signs, like "except for buses" / "except with permit"?
 

3) one or more signs on a larger panel - too large to represent as a node

Sorry but I don't agree with you... because I test it...and it works. Example for a complete destination traffic sign
 
colour:arrow black
colour:arrow:lower_panel white
colour:back white
colour:back:lower_panel blue
colour:ref red
colour:ref:lower_panel blue
colour:text white
colour:text:lower_panel white
destination:lower Coma-ruga
destination:lower_panel Barcelona
destination:lower_panel:lower Aeroport
destination:lower_panel:upper Vilanova i la Geltrú
destination:symbol:lower_panel:lower airport
destination:upper El Vendrell
length 500
ref N-340
ref:lower_panel C-32
side up
time:1 00:05
time:3 00:05
time:b 01:00
time:b:1 00:20
time:b:3 00:45
traffic_sign:2:forward ES:S235a
traffic_sign:forward ES:S235a
turn:destination under
turn:destination:lower_panel under
type destination_sign

How does anyone or anything (a data consumer) connect the "traffic_sign:forward=ES:S235a" to the way that it applies to? Not all junctions are nice 4-way 90-degree junctions. What have you "tested" exactly? Where do you place the node for this sign in relation to the way? Maybe if you could give a link or an exact location of this sign, then we could have a look and see what you intend.


4) signs applying only to certain lanes

you can specify the lanes and the exact information with all these tags (lanes scheme already exists)
 
Of course the lanes scheme exists, but it is currently applied to ways. Should we indicate a bus lane by a node representing the sign, or as an attribute of the way? Surely not as both. No trucks in the left hand lane? Easy to tag on the way with lanes tagging, but what about the sign, which might also say "buses only in the second lane except on Tuesday" etc etc. I am not trying to be difficult here - these crazy scenarios really do occur, and OSM needs to be able to deal with them. You are suggesting encoding this information as tagging on a single node; I think that's a challenge if you expect anyone/anything to be able to interpret it properly.
 

5) signs on a gantry above (half of) the road

The example above is like the granty sign (with the same tags)
 
Is a gantry tagged as a single node, or a "way" crossing the highway? The gantry may cross the entire highway, but the signs are only in one direction. How to handle that?
 

I can understand the argument for mapping the signs as objects in their own right. This would be limited to being a database of street furniture, unless and until the effect of the signs can be linked to the effect they have on traffic (in the broadest sense), which is the starting point for the present discussion. This is of course a serious exercise to ensure the link from the sign to the effect is represented unambiguously.

Barrier nodes acts in routing, why not the prohibition in overtaking? or the city limit? or the warnings?
 
Indeed, but we are talking about traffic signs here. How would you propose to 

We already have turn restrictions, maxspeed, maxheight etc on the ways themselves (without needing to have any link to a sign). This model works reasonably well for routing applications, albeit not without some discussion about the types of "weight" and so on.

Signs are a next level for routing, for GPS software. Why Street View cars and software wants to recognize traffic signs? Why don't you have the possibility to have the traffic signs recreated in your own screen, with only OSM data in a node?
 
I have experienced traffic sign recognition (in a recent BMW) and I wasn't very impressed. The signs are not used for real navigation, only for information. The routing is done in the old-fashioned way. Traffic sign recognition can only ever be an additional source of hints, and cannot be relied upon as the only basis for routing decisions.
 

The point I am trying to make, is that there might not be much of a "business case" for linking the signs/posts to their effects, and that mapping them as "street furniture" might be going far enough...

More than 30 countries, more than 24000 different traffic signs. In each country with their own traffic signs...why not? Are street lamps important? Are recycle bins important? Are Benchs important?
 
Important is not the right word here, that's too subjective. I am making the assumption that you are thinking of being able to use the traffic sign information for routing. Maybe that assumption is wrong, I am not sure any more. But for the foreseeable future routing will be graph-based, which means understanding the attributes that apply to way segments and junctions. The current model is workable - there are many examples of routing based on OSM data. I assume you want the routers to be able to understand the traffic sign information, to reduce the necessity for redundant information in OSM.
 

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic_sign discussion

dieterdreist
In reply to this post by yo paseopor


sent from a phone

> On 9. Oct 2018, at 23:03, yo paseopor <[hidden email]> wrote:
>
> for this reason the solution of tag the traffic signs ON the way it's the best way to do it. Traffic signs are relative to their ways (because if the way does not exist the existance of traffic sign is non-sense). Ways have direction, also their nodes can have this reference.


to me there is no point in mapping traffic signs on ways. Traffic signs are punctual items, their supposed effect (our interpretation what they imply for which way) is already mapped with established tags on the way. It is more accurate and more useful (for finding problems and inconsistencies) to have the signs mapped as nodes.

Let me give you an example: I do find it helpful to map maxspeed signs on nodes (doing it at the side of the highway because this implies the direction), because it helps to verify and maintain the speed limit data on the highway. If these were replaced by tags on the highway it would be less useful, because they would merely repeat the information that maxspeed already gives, and you won’t have neither the confirmation of repeated max speed signs nor would you know until where a later discovered sign with a different maxspeed is “at most” valid. Every time you discover a new sign, with the tag on the way method you start again “from scratch”.

Adding traffic sign ids to ways makes only sense if you mistrust the osm tags, e.g. because there aren’t the exact tags you would need to describe the effect of a sign. My suggestion would be to improve/amend the system of human readable tags in this case, so that they fulfill your local requirements.

I do recognize there can be some usefulness in both information (actual signs and their position=nodes, and the actual signs that led to certain tags being applied on an object (=ways)). I am not sure it is a good idea to use the same tags for it.


Cheers,
Martin


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic_sign discussion

yo paseopor
In reply to this post by Frederik Ramm
I will explain the things from my point of view.

There was a discussion about direction in traffic signs because a problem in major online editor iD.

32 messages that starts Fri, Sep 28, 4:52 AM (12 days ago) and finnish Oct 3, 2018, 12:04 AM (7 days ago) . Five days of discussion.

-In the first message Bryan Housel comments a problem "While reviewing a pull request to add Traffic Sign presets to iD, I came across a tagging issue with how traffic sign directions are tagged.
The details are here https://github.com/openstreetmap/iD/pull/5333"

-On 4th message Simon Poole comments "I actually mentioned the issue in Milano. "

-On 9th message Simon Poole says "There are a total of 37'000 forward / backward variants that would have to be migrated to  traffic_sign + a suitable sub tag, not an awful lot in the grand scheme of things, but needs to be done."

So the need for a big change in existing traffic signs was written in tagging list, and nobody's says "No, it is not a good idea". Well, I did not agree with that.

I have talk for first time in message number 21. Instead I manage 40 presets ,3 styles and more than 10 configuration files for Kendzi3D plugin in JOSM, and 3 projects in taginfo with more than 24000 pairs (key=value) I don't talk. Until I want to justify the nowadays proposal because if you read it is assumed the change will be done in iD - major online editor of OSM. Also I was thinking: I don't like changes but what can I do? Fight against iD solution(the major editor) (Remember the Mapsme subway solution, isn't it) ?
In 28th message I have said Ok, make you the changes -ironically- (there was a way to say Hey! There are a lot of changes to do, are you sure? Changing 30000+ nodes, are you nuts?)

Weekend arrives . I have a little free time so...Really Do I have to fight against iD proposal? (I see the pull request merged in their github). Or say the opposite to Simon Poole? Ok, I will give up. Discussion is ended (there were no more messages). iD pull request was applied so it is imminent the edition of traffic signs...with two different schemes.
It is better to help, so I have edited all the presets (I'm not a programmer so for me it is a difficult thing, a pain in the ass if you want to tell it) , the styles, taginfo (goodbye to the forward backward subkey , but hey! traffic signs now will be edited via iD so a lot of people would edit them .

And after the tool work...why I can't help more? There is more than 24000 nodes (reading taginfo). Ok, but for not having problems the changeset message will be very clear: "#fastag #traffic_signs Apply traffic_sign:direction tag to avoid problems with new iD editor as an agreement on tagging list". The way to do is simple: I would have only made a simple translation: traffic_sign:forward=* to traffic_sign=* and traffic_sign:direction=forward, and the same for backward.Traffic signals have also this solution so It can not be so bad after all. And now traffic signs will be edited by iD. It is a win-win thing.

I have made the first changes in nodes and then check presets, styles -the day after I have checked taginfo- and it works. Also I have checked my email and OSM profile and there was not any message. So I think I was in the good way - I was helping to do this big change at all.
And going zone by zone making specific overpass queries to make the things the best as I could with a little computer and low programming knowledge.
When I put the new tags style were working and it shows every traffic sign different in every country. It was a hard task : 55 changesets with about 16000+ traffic signs modified to the new scheme. Heavy work done.

Then "shit happens" . Mknight says "Wäre es nicht irgendwie sinnvoller, ein issue für iD zu schreiben, statt etabliertes Tagging zu ändern?" Well, I'm not German so I have used Google Translator to guess the idea was not of his agreement. Well, in tagging there is not more messages at all and people are agree with the change proposed by iD people. In a big thing like OSM not every one can be agree with it and Mknight does not participate on the discussion. I hope some people of their community explain to him the possibility to edit with iD thanks to this change.

But then Mueschel says something similar...D'Oh! "The discussion ended with your question about the change, not a single answer approving it. Mass edits should be announced and agreed on in a broader community, and not in the depth of a thread without anybody noticing."

What? The discussion was ended without nobody against it, Simon Poole saying there is big change to do, people congrats and making petitions to iD people...and I assuming before or later I would have to change all the JOSM stuff. Ok. In +16000 and 55 changesets there were some errors surely, but what percentatge? How many nodes do I have modified by error...because...ways does not have a traffic_sign key, isn't it ?

Well. I want to publish the messages people says to me on the changesets:

Mknight "Wäre es nicht irgendwie sinnvoller, ein issue für iD zu schreiben, statt etabliertes Tagging zu ändern?"
Mueschel "Please stop this undiscussed mechanical edit until further discussion.It breaks many cases of traffic sign tagging."
Mueschel "The discussion ended with your question about the change, not a single answer approving it. Mass edits should be announced and agreed on in a broader community, and not in the depth of a thread without anybody noticing. You also edited ways with traffic_sign:* tags, where this scheme will not work at all."
Peilscheibe "I reverted this changeset because diligent tagging (e.g. about different traffic signs per direction) was removed and replaced by wrong information. This is not acceptable at all."
Peilscheibe "Just a few examples:
http://osmlab.github.io/osm-deep-history/#/way/25717685
http://osmlab.github.io/osm-deep-history/#/way/629964077
http://osmlab.github.io/osm-deep-history/#/way/629964082
On this ways (and a lot of others) there was a different traffic sign tagging per direction.
Why? Because in reality the ways are differently signposted per direction which has de facto and de jure implications on traffic members.
Your edit removed this diligent tagging and wrong values were contributed. This is a blatant information loss and it is wrong."
geri-oc "Du hast hier Änderungen vor genommen die nicht zutreffend sin. Die Richtung in Sinne des Weges ist backwart oder forwart. direction gibt eine Richtung in Grad oder Himmelsrichtung an.

Ich erwarte eine Revert in angemessener Zeit von dir - zu mindest für diesen Änderungssatz. Über andere unberechtigte Änderungen kannst du gern im Forum weiter diskutieren, wo ein Revert deiner Änderungssätze ebenfalls diskutiert wird:
https://forum.openstreetmap.org/viewtopic.php?id=64028

Gruß Gerd - geri-oc"
geri-oc "direction ist ein verkehrter Schlüssel in Bezug auf die Wegrichtung von Verkehrszeichen. Die Änderungen sind alle falsch, da direction in Grad oder Himmelsrichtung angegeben wird."
geri-oc "Also, the specification direction is correct only with degrees or compass. forward or backward is related to the direction of the path in OSM.I am for a revert of these changes (worldwide)."
geri-oc "57,7274424, 16,5246249 ist nach den richtigen Angaben laut WIKI und JOSM-Plugin gemappt:
57,7273945, 16,5241181 hast du geändert.
Es existieren zwei verschieden Schlüssel in unmittelbarer Nachbarschaft und nach der alten Auswertung erscheint der zweite Node nicht mehr. Ich werden den CS reverten, falls du es nicht selbst machst. Deine Quelle Mapillary kann auch nicht stimmen, da einige Schilder gar nicht in Mapillary sind, sondern vor Ort erfasst wurden."

geow "I asked the data working group to revert all changesets of user https://www.openstreetmap.org/user/yopaseopor/history where the cS comment is: "#fastag #traffic_signs Apply traffic_sign:direction tag to avoid problems with new iD editor as an agreement on tagging list“
Thanks
geow"

and then Streckenkundler "It sucks to adjust the data to the Editor. I have chosen this worde deliberately. This is the best way to scare mappers from OSM. In my opinion, all your changes must be reset immediately and promptly. Stinky Greetings..."

Hey! I can be wrong but don't insult me!

Streckenkundler "Whether iD is bad or not, I can't say. Your way of pushing your ideas was Bad. First a huge proposal, where hardly any one looks through and it is not yet Decided. Then quickly change data to match the programming of iD to create Facts.
That's not how it works. Thanks to woodpeck for the Revert."

Well, it was a disaster for me, people claiming "my head", etc.but... Crisis also means opportunity. So first of all: what is the people wants about traffic signs? It is the moment to have a big consensus and avoid these kind of episodes. So I send this message to the tag list. And I hope some day before or later we have a complete traffic sign scheme.

But I have to say I'm sorry for the misunderstanding of what a consensus is in a tagging list... but What is a consensus in this list?

yopaseopor

On Tue, Oct 9, 2018 at 10:28 PM Frederik Ramm <[hidden email]> wrote:
Hi,

On 10/09/2018 05:42 PM, yo paseopor wrote:
> It is not the first attempt to do that. Last days, with iD
> implementation and my message I have think it was the solution. Also I
> have waited some days and communicate to this list my intentions to
> adopt the proposed iD scheme. But when I start to do the
> modifications... People complains about it (I am sorry if there was some
> errors "translating" to the new scheme).

Yes, DWG has also received complaints about these edits, and I am in the
process of reverting them.

At the very least you should have established a consensus on this list
for the precise edit you want to perform. You should have said: I am
going to load objects tagged so-and-so, and I am going to apply these
modifications using these tools.  (consensus doesn't mean everyone has
to be in favour, but you simply went ahead and changed things and wrote
in your changeset comment "#fastag #traffic_signs Apply
traffic_sign:direction tag to avoid problems with new iD editor as an
agreement on tagging list" which almost sounds like you were fixing a
bug and there was consensus, neither of which is strictly true.

I'm not saying these edits cannot ever be made, but they can certainly
not be made in a buggy fashion after a half-hearted attempt at
discussion with no discernible outcome.

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic_sign discussion

dieterdreist


sent from a phone

On 10. Oct 2018, at 21:22, yo paseopor <[hidden email]> wrote:

But I have to say I'm sorry for the misunderstanding of what a consensus is in a tagging list... but What is a consensus in this list?


actually the automated edits (which explicitly includes search and replace with tools like josm) must be documented beforehand and discussed on talk or imports according to the guidelines:

Tagging is for discussing the development and meaning of tags. 

Cheers,
Martin

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic_sign discussion

yo paseopor
Tagging is for discussing the development and meaning of tags. 
So this list is about the meaning but has no power or decision about how to apply the decisions about we write here?
Is it correct?

yopaseopor

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic_sign discussion

dieterdreist


sent from a phone

> On 10. Oct 2018, at 23:49, yo paseopor <[hidden email]> wrote:
>
> So this list is about the meaning but has no power or decision about how to apply the decisions about we write here?
> Is it correct?


yes, I would see it like this, tagging ml has no power or decision on map data, just like a wiki vote has not.


Cheers, Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic_sign discussion

Yves-2
That doesn't mean no decision can never be taken. Just that as there is no way to enforce any, it is necessary to discuss it here and elsewhere to seek consensus.
It is necessarily slower than the time for a commit to be merged into iD or a busy weekend retagging. Such a change can take month.
Yves
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Cafe / Coffee shop tags?

Joseph Eisenberg
There was a question on the Help pages about the right tags for certain cafe features, found also in shops that sell or roast coffee: https://help.openstreetmap.org/questions/66279/what-coffee-shop-data-to-add-to-osm?


1. Tag for a cafe that sells espresso-based drinks:
I suggested taht "drink:espresso=yes" should work; it fits with the pattern on this page: https://wiki.openstreetmap.org/wiki/Key:drink

2. Tag for a place that sells brewed coffee (eg aeropress, pour-over, drip, etc)

I think this may need a new tag, but it's a good idea. I might use "drink:brewed_coffee=yes" or "drink:pourover_coffee=yes". 

Any other ideas?

3. Tag for a coffee shop that roasts it own coffee (and sells wholebean coffee)

This is similar to a microbrewery. A big coffee roaster than focused on this could be craft=roaster. But more often a cafe (or shop=coffee) might also roast small batches of coffee for retail sale (and perhaps local wholesale to cafes). 

Should this be similar to microbrewery=yes with a tag like coffee_roaster=yes ?

-Joseph

 

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Cafe / Coffee shop tags?

dieterdreist
Am Do., 11. Okt. 2018 um 10:19 Uhr schrieb Joseph Eisenberg <[hidden email]>:
There was a question on the Help pages about the right tags for certain cafe features, found also in shops that sell or roast coffee: https://help.openstreetmap.org/questions/66279/what-coffee-shop-data-to-add-to-osm?

1. Tag for a cafe that sells espresso-based drinks:
I suggested taht "drink:espresso=yes" should work; it fits with the pattern on this page: https://wiki.openstreetmap.org/wiki/Key:drink


in Europe it will be hard to find a cafe that doesn't offer espresso based drinks, but feel free to add it if you see the need.

 

2. Tag for a place that sells brewed coffee (eg aeropress, pour-over, drip, etc)

I think this may need a new tag, but it's a good idea. I might use "drink:brewed_coffee=yes" or "drink:pourover_coffee=yes". 

Any other ideas?



I'd prefer brewed from these 2


 

3. Tag for a coffee shop that roasts it own coffee (and sells wholebean coffee)

This is similar to a microbrewery. A big coffee roaster than focused on this could be craft=roaster. But more often a cafe (or shop=coffee) might also roast small batches of coffee for retail sale (and perhaps local wholesale to cafes). 

Should this be similar to microbrewery=yes with a tag like coffee_roaster=yes ?




there's microroasting=yes (2 times, now 3), e.g.

Cheers,
Martin

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Cafe / Coffee shop tags?

dieterdreist
In reply to this post by Joseph Eisenberg
Am Do., 11. Okt. 2018 um 10:19 Uhr schrieb Joseph Eisenberg <[hidden email]>:
This is similar to a microbrewery. A big coffee roaster than focused on this could be craft=roaster. But more often a cafe (or shop=coffee) might also roast small batches of coffee for retail sale (and perhaps local wholesale to cafes).


a big coffee roaster should better get man_made=works and subtags. Craft is not intended for industrial scale production.

Cheers,
Martin

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
12