Re: [Tagging] Traffic_sign discussion

[Martin Koppenhoefer]

sent from a phone

> On 15. Oct 2018, at 00:52, yo paseopor  wrote:
> 
> I think traffic sign specific tags (traffic_sign, traffic_sign:direction (or 
> backward/forward subkeys) , traffic_sign:side (or side:) would never be used 
> as a tags for the ways.
> -I'm agree with you in that.


great you agree, unfortunately a lot of people don’t, traffic_sign tags on ways 
are quite common:
https://taginfo.openstreetmap.org/keys/traffic_sign

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

Re: [Tagging] Traffic_sign discussion

[yo paseopor]

On Wed, Oct 10, 2018 at 1:30 AM Martin Koppenhoefer 
wrote:

>
>
>
> 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”.
>
-Sorry for my bad English when I was writting about putting signs ON the
way I wanted to say put NODES ON the way (with tag side and tag direction
you can locate the place and the direction is affecting the traffic sign. I
think traffic sign specific tags (traffic_sign, traffic_sign:direction (or
backward/forward subkeys) , traffic_sign:side (or side:) would never be
used as a tags for the ways.
-I'm agree with you in that.


> 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.
>
-Improving everything with the help and participation of all the community
would make better the system because then the system will be usefull and
complete for the maximum number of people. It is not a thing of me, it is a
thing of and for OSM. I am not an strange person, I'm only an OSM mapper.

>
> 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.
>
-I think using the same keys would help the people to understand better the
scheme and to don't duplicate work (if I have lanes: on a way...why can
have ALSO lanes: of a node on the way?) Do I have to "invent
traffic_sign:lanes" ?

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

Re: [Tagging] Traffic_sign discussion

[yo paseopor]

On Wed, Oct 10, 2018 at 1:05 AM Colin Smale  wrote:

> 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.
>
-I think the scheme is ready. If I think about the Spanish law situations I
think with little modifications it is for all the countries around the
World.

> This is of course a fairly easy one. What European regulations are you
> referring to here by the way?
>
-Well, I have to say the first time I heard this european recommendation
was at 2006 in TV news when in Catalonia there was a new plan to put new
destination signs along all Catalonia. It is difficult to find the exact
law it says that.
The first book you can find is the *Manual SENIOR de la senyalització
interurbana de Catalunya de la Generalitat de Catalunya*
It is a PDF . It says basic concepts:
All traffic signs should have Conspicuite ,have to be legible and
recognisable,comprehensible and credible.
Also in Catalonia we have RACC which makes some surveys inside EUROTEST
about traffic signs. Some examples

(estudio señales tráfico RACC)

http://mig.racc.es/pub/ficheros/actualidad/actualidad_dp_ix_encuesta_racc_jzq_5feb3758.pdf
http://imagenes.racc.es/pub/ficheros/adjuntos/adjuntos_dp_senales_de_trafico_2008_jzq_dba4c612.pdf

(Other EURO TEST traffic signs studies)

https://www.yumpu.com/en/document/view/19587284/international-road-signs-eurotest
https://www.theaa.com/public_affairs/reports/EuroTest_Roadworks_2006.pdf
https://www.ttsitalia.it/file/Libreria/Europe/EuroTest05_Mway_Roadworks.pdf

little article in the Spanish DGT magazine
http://www.dgt.es/revista/archivo/pdf/num175-2005-Seniales.pdf

(Other organizations and documents)

UNITED NATIONS ECONOMIC COMMISSION FOR EUROPE

Convenio CEPE de las Naciones Unidas sobre señalización vial
https://www.unece.org/fileadmin/DAM/trans/conventn/Conv_road_traffic_SP.pdf

https://www.unece.org/fileadmin/DAM/trans/roadsafe/publications/docs/Consolidated_Resolution_on_Road_Traffic_RE2_e.pdf

In the 1.3 you can read the conditions United Nations recommends for the
traffic signs of confirmatory direction signs (our destination signs)

"The confirmatory direction signs should possess the following
characteristics:
  (a)
Shape of the sign - As the confirmatory sign falls within the category of
informative
signs, it is rectangular in shape.
  (b)
Colour  of  the  sign  -  The  colours  adopted  are  those  used  for
place  and  route
identification signs.
  (c)
Dimensions of the sign - The dimensions depend on the amount of information
to  be  given  and  on  the  dimensions  adopted  for  place  signs  on
the  route  in
question. If, in addition to the name of the next main town, intermediate
localities
are  also  indicated,  it  is  recommended  that  not  more  than  two
such  localities
should be mentioned, and that their names, and the distances at which they
are
situated, may be indicated in smaller letters and figures (preferably in
the ratio
of 2 to 3) than those relating to the main town."

Fundación Abertis (UNESCOMEDCENTER)
http://www.unescomedcenter.org/es/noticias/20/los-expertos-apuestan-por-mejorar-la-senalizacion-y-sancionar-para-que-el-conductor-tome-conciencia-del-riesgo

ERF Position
https://issuu.com/erf9/docs/erf_position_paper_on_vertical_sign

-Directive 98/34/EC of the European Parliament and of the Council of 22
June 1998
-Regulation (EU) No 1025/2012 of the European Parliament and of the Council
of 25 October 2012 on European standardisation, amending
-Council Directives 89/686/EEC and 93/15/EEC and Directives 94/9/EC,
94/25/EC, 95/16/EC, 97/23/EC, 98/34/EC, 2004/22/EC, 2007/23/EC, 2009/23/EC
and 2009/105/EC of the European Parliament and of the Council

>
> 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"?
>
-Complimentary traffic signs are also traffic signs, with other position
but with all its identity. Here in Spain traffic signs law say second sign
says the condition the first traffic sign is applied.
Also you have some keys to mark or explain the meaning of the complementary
traffic sign. You can translate the information you read into OSM keys and
values

except buses? bus=yes
except with permit? access=designated?

> 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 

Re: [Tagging] Traffic_sign discussion

[Yves]

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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic_sign discussion

[Martin Koppenhoefer]

sent from a phone

> On 10. Oct 2018, at 23:49, yo paseopor  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic_sign discussion

[Martin Koppenhoefer]

sent from a phone

> On 10. Oct 2018, at 21:22, yo paseopor  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:
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

Tagging is for discussing the development and meaning of tags. 

Cheers,
Martin___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic_sign discussion

[yo paseopor]

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 3+ 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:

Re: [Tagging] Traffic_sign discussion

[Martin Koppenhoefer]

sent from a phone

> On 9. Oct 2018, at 23:03, yo paseopor  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic_sign discussion

[Colin Smale]

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  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 [1]
> 500
> 
> REF [2]
> 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 [3]
> 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.

Re: [Tagging] Traffic_sign discussion

[Paul Johnson]

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  wrote:

>
>
> On Tue, Oct 9, 2018 at 8:37 PM Tobias Knerr  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=:.
>>
> It is
>
>> - As with your suggestion,  is the ISO country code.
>>
> It is
>
>> -  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 

Re: [Tagging] Traffic_sign discussion

[Paul Johnson]

On Tue, Oct 9, 2018, 16:05 yo paseopor  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic_sign discussion

[yo paseopor]

On Tue, Oct 9, 2018 at 8:16 PM Colin Smale  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic_sign discussion

[yo paseopor]

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  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  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 :
>>
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging
>>
>> 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
>> 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] Traffic_sign discussion

[Frederik Ramm]

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 frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Tagging] Traffic_sign discussion

[Tobias Knerr]

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=:.
- As with your suggestion,  is the ISO country code.
-  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic_sign discussion

[Colin Smale]

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 : 
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging
>  
> 
> 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
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic_sign discussion

[Paul Johnson]

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  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 :
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging
>
> 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
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging