Re: [Tagging] Traffic sign direction tagging..

[yo paseopor]

>
> There's no reason to reinvent the wheel here. Plus, as far as I can tell,
> the suffix (:2) solution doesn't  work when there's more than one "main"
> traffic sign.
>

I dont reinvent anything. Multivalues are hard to manage but also you don't
have more than one "main" traffic signs. European conventions recommends no
more than three values at the same pole, and no more than three
destinations in a sign so a multivalue does not the best solution. Every
sign has its meaning and the combination of the second position for a
traffic sign says you the limit of the first traffic sign, so it is
important to remark the position of the traffic sign. As Finnish people
demonstrate traffic sign second position can be managed without problems.
For example, in the style or the recreation of Kendzi3Ds plugin of JOSM you
can have two or three positions of every traffic sign without problem.

yopaseopor

On Tue, Oct 2, 2018 at 5:55 PM Tobias Knerr  wrote:

> On 02.10.2018 16:44, yo paseopor wrote:
> > Also it is not the best call "undersigns" . There are signs too, with
> > their code, and you can put in on second place or third place , like
> > traffic_sign:2 as Finnish people does.
>
> Or put them in a comma-separated list, which is the international
> standard tagging that's documented on
> https://wiki.osm.org/Key:traffic_sign
>
> There's no reason to reinvent the wheel here. Plus, as far as I can
> tell, the suffix (:2) solution doesn't  work when there's more than one
> "main" traffic sign.
>
> ___
> 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 direction tagging..

[Tobias Knerr]

On 02.10.2018 16:44, yo paseopor wrote:
> Also it is not the best call "undersigns" . There are signs too, with
> their code, and you can put in on second place or third place , like
> traffic_sign:2 as Finnish people does.

Or put them in a comma-separated list, which is the international
standard tagging that's documented on
https://wiki.osm.org/Key:traffic_sign

There's no reason to reinvent the wheel here. Plus, as far as I can
tell, the suffix (:2) solution doesn't  work when there's more than one
"main" traffic sign.

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

Re: [Tagging] Traffic sign direction tagging..

[yo paseopor]

It is not the better thing to say " we can't control the tagging of an item
so we can map it".  Why we can't control them? Can we control the trees you
have on the map? Can we control the street lamps of the map?...so we can
control EVERYTHING on the map and its orientation (of course with the
correct technology now we have, like Mapillary's and others). Traffic signs
informs you about something specific of the way, example, the end of the
cycle way, so you can see where the traffic sign is correct to put on.

Also it is not the best call "undersigns" . There are signs too, with their
code, and you can put in on second place or third place , like
traffic_sign:2 as Finnish people does. And as you say second position
traffic sign will be so important as the first position is.

It is difficult to have two traffic signs in both directions with the same
meaning so you don't need traffic_sign:2:direction. If you need so you can
put a node next to or above or beside to the other with all that other
directions' info

Also don't forget the tag side=  and all of their values

yopaseopor

On Tue, Oct 2, 2018 at 4:03 PM Allroads  wrote:

> Traffic_sign is on a node beside of above a road. There where, it is.
> This is the basis, the derivative is tagged on the road, as ...
>
> The direction=* says, the facing direction of the sign/shield. Important:
> indicates the direction in which the law applies. This could be various.
> Depends on sign and undersign.
> A combination of trafficsign and undersign is important, it indicates a
> combined rule, summarized in a value.
> But there could be more trafficsigns on a node even a highway=street_lamp,
> the direction=* can not be used.
> traffic_sign:1:direction=*  facing direction is used.
> traffic_sign:2:direction=*
> street_lamp:direction=*
>
> Then the derivated on the way.
>
> This could be the whole way.
> motor_vehicle:forward=no
>
> But also on a node of a way ( not the first and last node) like give_way.
> The most directly derived tagging is tagging the traffic sign itself.
> First
> degree derived tagging.
> Second degree tagging are the access tags.
> If you have first degree tagging, the second degree could be controlled,
> if
> it is correct.
> In the Netherlands we started to tag the traffic_sign on a cycleway, then
> knowing which vehicle key/value is needed
> Now with overpass we can control if tagging is correct on the cycleway G11
> (mofa designated), G12a (mofa mofa designated), G13.
> This way we get more qualitative data.
>
> http://mijndev.openstreetmap.nl/~peewee32/traffic_sign/traffic_sign.htm?map=cycleways=16=52.13023=5.41893=B000FFTFTFFF
>
> Then on a waynode. like give_way.
> C6 traffic_sign.
>
> https://wiki.openstreetmap.org/wiki/NL:Overzicht_Nederlandse_Verkeersborden#C:_Geslotenverklaring
> The working-out of the law, says, that goes into effect when you pass the
> shield at the front. And must be repeated after each crossing.
> This traffic sign can stand on one side of the road.
> If you come from the other side, there is no shield, drive in and you
> visit
> a house, a plot, or you decide to turn around, this is allowed by law.
> This you could do, for example 10 meters from the back of the shield, turn
> around.
>
> This place is a like a give-way construction on a node., with access
> traffic_sign:forward=NL:C6  (first derivated tagging, could used to
> control
> the other tags)
> motor_vehicle:forward=no
> motorcycle:forward=yes
> moped:forward=yes
> mofa:forward=yes
>
> some use a 10 meters way to set the tags.
>
> forward, indicates the direction of operation of the law in relation to
> the
> Openstreetmap drawing direction.
>
> >> `traffic_sign:direction=forward/backward`
> Here direction is facing direction on the sign.
> And can not be used a working-out direction of the law.
> traffic: forward= and traffic_sign:backward is correct.
>
> I do not agree!
>
> In combination with traffic_sign, direction can only be used  on separated
> node besides the road (or above), given the facing direction, there are
> signs with undersign with a left or right arrow, indicating in which
> direction the sign works,
> then the facing direction must be correct, often this is 90 degrees on the
> driving direction, or on other side of a T junction.
>
> If the traffic_sign (first degree derivated) is not tagged it is almost
> impossible to control tagging. With all combinations and undersigns.
>
> Regards.
> Allroads
>
>
>
> -Oorspronkelijk bericht-
> From: Marc Gemis
> Sent: Tuesday, October 2, 2018 2:04 PM
> To: Tag discussion, strategy and related tools
> Subject: Re: [Tagging] Traffic sign direction tagging..
>
> >>
&

Re: [Tagging] Traffic sign direction tagging..

[Allroads]

Traffic_sign is on a node beside of above a road. There where, it is.
This is the basis, the derivative is tagged on the road, as ...

The direction=* says, the facing direction of the sign/shield. Important: 
indicates the direction in which the law applies. This could be various. 
Depends on sign and undersign.
A combination of trafficsign and undersign is important, it indicates a 
combined rule, summarized in a value.
But there could be more trafficsigns on a node even a highway=street_lamp, 
the direction=* can not be used.

traffic_sign:1:direction=*  facing direction is used.
traffic_sign:2:direction=*
street_lamp:direction=*

Then the derivated on the way.

This could be the whole way.
motor_vehicle:forward=no

But also on a node of a way ( not the first and last node) like give_way.
The most directly derived tagging is tagging the traffic sign itself. First 
degree derived tagging.

Second degree tagging are the access tags.
If you have first degree tagging, the second degree could be controlled, if 
it is correct.
In the Netherlands we started to tag the traffic_sign on a cycleway, then 
knowing which vehicle key/value is needed
Now with overpass we can control if tagging is correct on the cycleway G11 
(mofa designated), G12a (mofa mofa designated), G13.

This way we get more qualitative data.
http://mijndev.openstreetmap.nl/~peewee32/traffic_sign/traffic_sign.htm?map=cycleways=16=52.13023=5.41893=B000FFTFTFFF

Then on a waynode. like give_way.
C6 traffic_sign. 
https://wiki.openstreetmap.org/wiki/NL:Overzicht_Nederlandse_Verkeersborden#C:_Geslotenverklaring
The working-out of the law, says, that goes into effect when you pass the 
shield at the front. And must be repeated after each crossing.

This traffic sign can stand on one side of the road.
If you come from the other side, there is no shield, drive in and you visit 
a house, a plot, or you decide to turn around, this is allowed by law.
This you could do, for example 10 meters from the back of the shield, turn 
around.


This place is a like a give-way construction on a node., with access
traffic_sign:forward=NL:C6  (first derivated tagging, could used to control 
the other tags)

motor_vehicle:forward=no
motorcycle:forward=yes
moped:forward=yes
mofa:forward=yes

some use a 10 meters way to set the tags.

forward, indicates the direction of operation of the law in relation to the 
Openstreetmap drawing direction.



`traffic_sign:direction=forward/backward`

Here direction is facing direction on the sign.
And can not be used a working-out direction of the law.
traffic: forward= and traffic_sign:backward is correct.

I do not agree!

In combination with traffic_sign, direction can only be used  on separated 
node besides the road (or above), given the facing direction, there are 
signs with undersign with a left or right arrow, indicating in which 
direction the sign works,
then the facing direction must be correct, often this is 90 degrees on the 
driving direction, or on other side of a T junction.


If the traffic_sign (first degree derivated) is not tagged it is almost 
impossible to control tagging. With all combinations and undersigns.


Regards.
Allroads



-Oorspronkelijk bericht- 
From: Marc Gemis

Sent: Tuesday, October 2, 2018 2:04 PM
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] Traffic sign direction tagging..



>  To keep things simple, we'll do the same thing for traffic signs:
`traffic_sign:direction=forward/backward`



Please , for doing traffic_sign:direction is better to put direction=* 
tag.



> I still highway=give_way and highway=stop with
direction=forward/backward (which is used by OsmAnd AFAIK).



And what about the other traffic signs. Are they not important? Why don't 
erase it...from the World if they are not important?


I don't map other signs, for most other signs I map the result on the
way (e.g. maxspeed sign, no overtaking). Why would I map the sign
separately ?
Give ways and stop signs are slightly different, because they usually
indicate a single place on the road where one has to stop. The result
of the sign is commonly mapped as a node, not as a tag on the way
(yes, I know there are cases where a relation might be needed).

So yes, for me the position of the other signs is not important. Feel
free to add them if you feel they are important.

regards

m.

___
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 direction tagging..

[yo paseopor]

Ok

Are you agree with the tag traffic_sign:direction=forward/backward?

If you are agree please change "automatically" all the
traffic_signs:forward/backward to the new
traffic_sign:direction)=forward/backward
If you do that I would change all the presets, the styles and the kendzi3D
instructions for JOSM, Taginfo projects info and all the maps done with
these codes.

salut i senyals de trànsit (health and traffic signs)
yopaseopor




On Tue, Oct 2, 2018 at 12:45 AM Bryan Housel  wrote:

> On Oct 1, 2018, at 5:23 PM, yo paseopor  wrote:
>
>  > ^ This is the problem.  The wiki says we are supposed to do something
>> like `traffic_sign:forward=US:R1`, and we can't really do that. A preset
>> needs to be based on a "toplevel" tag like `traffic_sign=*` not
>> `traffic_sign:forward=*` or `traffic_sign:backward=*` (remember seamark?
>> many of their tags have this issue too, where they put a value in the key
>> part, and so we can’t turn it into a preset).
>>
>
>  JOSM can do this change (when you change a way) as you can see on
> https://i.imgur.com/NnLpKWR.jpg
>
>
> iD will also do this change when reversing a way.  That’s not what my
> email is about.
>
>
>  If you read taginfo you can find for forward subtags
> https://taginfo.openstreetmap.org/search?q=%3Aforward more than 80
> nodes. If you read taginfo for backward
> https://taginfo.openstreetmap.org/search?q=%3Abackward you can find more
> than 80 nodes. Are you saying iD doesn't recognise all these tags with
> forward and backward subtags?
>
>
> Nope, not saying that at all.
>
>
>  I give you a solution: make two presets: one for traffic_sign:backward
> and other with the same values for traffic_sign:forward.
>
>
> That’s a bad solution, so instead we’re going to solve the problem of
> indicating traffic sign direction the same way it’s already solved for
> traffic signals.  `traffic_sign:direction=forward/backward` - simple.  I
> will even convert all the existing traffic signs tagged with
> `traffic_sign:forward` or `traffic_sign:backward` to work this way if you
> want.  It’s an unambiguous tag change.
>
> I wouldn't know how to explain to mappers when to use a “Traffic Sign” vs
> a “Forward Facing Traffic Sign” vs a “Backward Facing Traffic Sign” much
> less translating these concepts to dozens of different languages.
>
>
> Thanks, Bryan
>
> ___
> 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 direction tagging..

[Marc Gemis]

>>
>> >  To keep things simple, we'll do the same thing for traffic signs:
>> `traffic_sign:direction=forward/backward`
>
>
> Please , for doing traffic_sign:direction is better to put direction=* tag.
>
>> > I still highway=give_way and highway=stop with
>> direction=forward/backward (which is used by OsmAnd AFAIK).
>
>
> And what about the other traffic signs. Are they not important? Why don't 
> erase it...from the World if they are not important?

I don't map other signs, for most other signs I map the result on the
way (e.g. maxspeed sign, no overtaking). Why would I map the sign
separately ?
Give ways and stop signs are slightly different, because they usually
indicate a single place on the road where one has to stop. The result
of the sign is commonly mapped as a node, not as a tag on the way
(yes, I know there are cases where a relation might be needed).

So yes, for me the position of the other signs is not important. Feel
free to add them if you feel they are important.

regards

m.

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

Re: [Tagging] Traffic sign direction tagging..

[Robert Skedgell]

On 01/10/18 22:23, yo paseopor wrote:
> Technically markings painted on the road are...traffic signs itself (in
> some countries there are specific codes to this items) and also they
> have their importance , you cannot ignore them

This is certainly the case in the UK. A highway=give_way is generally
indicated by the transverse line marking (= = = =) on the carriageway,
traffic_sign=GB:1003A. There is also the upright inverted red triangle
traffic_sign=GB:602, which does not need to be present. Failure to
comply with either is an offence.

-- 
Robert Skedgell (rskedgell)


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

Re: [Tagging] Traffic sign direction tagging..

[Paul Johnson]

On Mon, Oct 1, 2018 at 4:24 PM yo paseopor  wrote:

>  > ^ This is the problem.  The wiki says we are supposed to do something
>> like `traffic_sign:forward=US:R1`, and we can't really do that. A preset
>> needs to be based on a "toplevel" tag like `traffic_sign=*` not
>> `traffic_sign:forward=*` or `traffic_sign:backward=*` (remember seamark?
>> many of their tags have this issue too, where they put a value in the key
>> part, and so we can’t turn it into a preset).
>>
>
>  JOSM can do this change (when you change a way) as you can see on
> https://i.imgur.com/NnLpKWR.jpg
>  If you read taginfo you can find for forward subtags
> https://taginfo.openstreetmap.org/search?q=%3Aforward more than 80
> nodes. If you read taginfo for backward
> https://taginfo.openstreetmap.org/search?q=%3Abackward you can find more
> than 80 nodes. Are you saying iD doesn't recognise all these tags with
> forward and backward subtags?
>  I give you a solution: make two presets: one for traffic_sign:backward
> and other with the same values for traffic_sign:forward.
>

This brings up another issue i have with this forward/backward scheme.
Most traffic_signs are tagged where they stand.  They're not a member of a
way, just adjacent.  What now?


> > Describing what a driver might see when approaching a turn would be an
>> effective use of traffic_sign, but 'node near the way' is pretty useless
>> for routing. For maximal detail you'd need both, but if you're only going
>> to add one, the highway=stop is far more useful.
>>
>
> Best approach is to have the traffic sign "inside" the way because the
> traffic sign is relative to the way. If the way doesn't exist, traffic sign
> is useless, so it is better to map it as a node on the way. Also then you
> have the direction of the way to make relative the traffic sign to the
> direction of driving.
>

This makes sense for on-the-pavement markings, but doesn't really work for
way-adjacent objects.  See also: Why transit tagging is quite complex.


> > OSMand also warns of traffic calming, toll barriers, level crossing,
>> pedestrian crossings and enforcement cameras.
>>
>
> OsmAnd can show some traffic signs in certain moments or resolutions or
> guiding, as they do with maxspeed info.
>

And, weirdly, for tunnels (apparently just plain pulling a sign out of it's
butt for this, too, instead of using the regionally standard sign on
screen), even though it's bloody obvious that you're about to head into a
tunnel (of which there's like, 5 highway tunnels statewide for me, 4 of
which are newly open this month).  But not rumble strips, even though those
can be a critical hazard and are not easy to see before you hit them here.
Yes, this really bothers me because not having a warning in advance on
these invisible things is a bad thing consider that they're often brutal
enough to present the same hazard potential as a cattle grid to cyclists,
motorcycles and really light cars (in my pickup, not so much of an issue,
but still practically heart-attack inducing like a jumpscare out of
nowhere).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign direction tagging..

[Paul Johnson]

On Sat, Sep 29, 2018 at 8:41 PM Kevin Kenny  wrote:

> On Sat, Sep 29, 2018 at 6:58 PM Paul Johnson  wrote:
> > I'm still against using forward/backward on nodes, it really feels like
> a hacky way to avoid using a relation (up there with using ref=* on ways to
> describe routes), which would disambiguate things without being so brittle
> just because a way reversed, and handle more complex situations like "right
> turn permitted without stopping" sign below a "stop" sign, or allow a data
> consumer to be able to display a diagram indicating which ways a stop
> applies to (handy if you encounter, say, a six way intersection with a four
> way stop).
> >
> > I honestly don't understand why, ten years since it's introduction as
> OSM's third basic primitive, there's still this weirdly unnatural aversion
> to relations, even though they're quite a powerful primitive in our toolbox.
>
> I agree with you that we need to design relations for the complex
> cases such as what you describe, but I've no problem with the 'hacky'
> approach as well - on the principle of 'make simple things easy and
> complex things possible'. JOSM (and from what I understand, iD, but I
> rarely use it) handles directional nodes on ways fairly competently,
> detecting that the mapper is reversing a way that has such nodes
> attached and asking what to do about them.
>

It still feels a bit brittle, especially if the data consumer is assuming
(correctly) that nodes by themselves lack a direction.  Which is fine when
the traffic control applies to all possible ways and approaches connected
to a node.  A relation does explicitly define how it applies, however, by
defining which nodes are affecting which ways and how without having to
make a lot of assumptions.


> As far as the aversion to relations goes, I think a big part of it is
> simply that the downstream support just isn't there.  The tools do
> multipolygons fairly well, but that is the only relation that is
> really handled well. A bit part of that is that once OSM data has been
> through a stock osm2pgsql, there are no relations any more.
> Multipolygons become first class objects, and all other relations are
> handled at best by devolving their tags upon their components.
>
> (The rest of this message is off the topic of stop signs.)
>

I don't see a regression in some downstream application as being a reason
not to do it.


> You raise the issue of ref=* on ways, and why we still use it. That's
> a clear case where we use it because the downstream systems can't do
> route relations.


Osmand handles it fine.


> I've been trying to help with this - at least to the
> extent of trying to revive Phil! Gold's route relation processing. My
> version is at https://github.com/kennykb/osm-shields, and you can see
> one rendering with shaped shields based on relations at
> https://kbk.is-a-geek.net/catskills/test4.html?la=42.7440=-72.4830=11
> .
> That link is chosen to illustrate an area that intermixes 'tag on way'
> with 'tag on relation'. Unfortunately, my time is limited, so the
> project has stagnated for a few weeks.  I've not given up, though; the
> next task will have to be to generate a pull request to adapt
> osm2pgsql optionally to preserve relations, with two new tables to
> track them.
>

Doing good work there, fixing the problem.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign direction tagging..

[Paul Johnson]

On Sat, Sep 29, 2018 at 8:23 PM Graeme Fitzpatrick 
wrote:

>
>
>
> On Sun, 30 Sep 2018 at 08:58, Paul Johnson  wrote:
>
>>
>> I honestly don't understand why, ten years since it's introduction as
>> OSM's third basic primitive, there's still this weirdly unnatural aversion
>> to relations, even though they're quite a powerful primitive in our toolbox.
>>
>
> Maybe because people don't understand how to use them properly (I know I
> don't?), so they're scared of them?
>
> Some very simple, easily found, instructions / guidelines would be handy.
>

I'll look into adapting the scheme used for traffic enforcement to traffic
control later this week or this weekend.  This has been a peeve of mine for
a while now.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign direction tagging..

[Bryan Housel]

> On Oct 1, 2018, at 5:23 PM, yo paseopor  wrote:
> 
>  > ^ This is the problem.  The wiki says we are supposed to do something like 
> `traffic_sign:forward=US:R1`, and we can't really do that. A preset needs to 
> be based on a "toplevel" tag like `traffic_sign=*` not 
> `traffic_sign:forward=*` or `traffic_sign:backward=*` (remember seamark? many 
> of their tags have this issue too, where they put a value in the key part, 
> and so we can’t turn it into a preset).
>  
>  JOSM can do this change (when you change a way) as you can see on 
> https://i.imgur.com/NnLpKWR.jpg 

iD will also do this change when reversing a way.  That’s not what my email is 
about.


>  If you read taginfo you can find for forward subtags 
> https://taginfo.openstreetmap.org/search?q=%3Aforward 
>  more than 80 
> nodes. If you read taginfo for backward 
> https://taginfo.openstreetmap.org/search?q=%3Abackward 
>  you can find more 
> than 80 nodes. Are you saying iD doesn't recognise all these tags with 
> forward and backward subtags?

Nope, not saying that at all.


>  I give you a solution: make two presets: one for traffic_sign:backward and 
> other with the same values for traffic_sign:forward. 

That’s a bad solution, so instead we’re going to solve the problem of 
indicating traffic sign direction the same way it’s already solved for traffic 
signals.  `traffic_sign:direction=forward/backward` - simple.  I will even 
convert all the existing traffic signs tagged with `traffic_sign:forward` or 
`traffic_sign:backward` to work this way if you want.  It’s an unambiguous tag 
change.

I wouldn't know how to explain to mappers when to use a “Traffic Sign” vs a 
“Forward Facing Traffic Sign” vs a “Backward Facing Traffic Sign” much less 
translating these concepts to dozens of different languages.


Thanks, Bryan

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

Re: [Tagging] Traffic sign direction tagging..

[yo paseopor]

>
>  > ^ This is the problem.  The wiki says we are supposed to do something
> like `traffic_sign:forward=US:R1`, and we can't really do that. A preset
> needs to be based on a "toplevel" tag like `traffic_sign=*` not
> `traffic_sign:forward=*` or `traffic_sign:backward=*` (remember seamark?
> many of their tags have this issue too, where they put a value in the key
> part, and so we can’t turn it into a preset).
>

 JOSM can do this change (when you change a way) as you can see on
https://i.imgur.com/NnLpKWR.jpg
 If you read taginfo you can find for forward subtags
https://taginfo.openstreetmap.org/search?q=%3Aforward more than 80
nodes. If you read taginfo for backward
https://taginfo.openstreetmap.org/search?q=%3Abackward you can find more
than 80 nodes. Are you saying iD doesn't recognise all these tags with
forward and backward subtags?
 I give you a solution: make two presets: one for traffic_sign:backward and
other with the same values for traffic_sign:forward.


> >  To keep things simple, we'll do the same thing for traffic signs:
> `traffic_sign:direction=forward/backward`
>

Please , for doing traffic_sign:direction is better to put direction=* tag.

> I still highway=give_way and highway=stop with
> direction=forward/backward (which is used by OsmAnd AFAIK).
>

And what about the other traffic signs. Are they not important? Why don't
erase it...from the World if they are not important?
I think OsmAnd can decide what data from OSM they want to use, so if they
decide to support traffic signs they will support it. If they don't want to
they won't support it.
Also remember the don't map for the render think (instead is a "render" so
important like OsmAnd).

> Describing what a driver might see when approaching a turn would be an
> effective use of traffic_sign, but 'node near the way' is pretty useless
> for routing. For maximal detail you'd need both, but if you're only going
> to add one, the highway=stop is far more useful.
>

Best approach is to have the traffic sign "inside" the way because the
traffic sign is relative to the way. If the way doesn't exist, traffic sign
is useless, so it is better to map it as a node on the way. Also then you
have the direction of the way to make relative the traffic sign to the
direction of driving.

> OSMand also warns of traffic calming, toll barriers, level crossing,
> pedestrian crossings and enforcement cameras.
>

OsmAnd can show some traffic signs in certain moments or resolutions or
guiding, as they do with maxspeed info.

> Not all give ways have a sign, some are just give way markings painted on
> the road.
>

Technically markings painted on the road are...traffic signs itself (in
some countries there are specific codes to this items) and also they have
their importance , you cannot ignore them

> I'm still against using forward/backward on nodes, it really feels like a
> hacky way to avoid using a relation (up there with using ref=* on ways to
> describe routes), which would disambiguate things without being so brittle
> just because a way reversed, and handle more complex situations like "right
> turn permitted without stopping" sign below a "stop" sign, or allow a data
> consumer to be able to display a diagram indicating which ways a stop
> applies to (handy if you encounter, say, a six way intersection with a four
> way stop).
>

It is not necessary to make a relation if you put on the way the traffic
signs nodes. JOSM reverse them if you reverse the way and things
complicated like "right turn permitted without stopping" are relative to
the direction you are driving (JOSM only shows you a north orientation and
doesn't allow to "rotate" background and data like GMaps style. So forget
the problem of the side inside a instruction because these instructions
will always be relatives to the traffic sign itself, nor the way you see it
in JOSM or iD (iD also doesn't accept rotate background and data.

> Do you have an example of a pedestrian crossing that OSMand warns you of,
> as I don't see (or maybe just don't notice?) crossing warnings, so I'm
> wondering if they may be tagged somehow differently?
>

OpenMapSurfer shows traffic sign for pedestrian crossings so it is about
the render.

That is what I think about this topic
Salut i senyals de trànsit (Health and traffic signs)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign direction tagging..

[Kevin Kenny]

On Mon, Oct 1, 2018 at 4:31 AM Paul Norman  wrote:
> Could you provide a link to the osm2pgql issue tracker with the issue in 
> question? I don't recall it, but I've been away a lot and haven't kept up 
> with everything.

I hadn't opened a fresh ticket, because there are existing tickets
against the tools, notably

https://github.com/openstreetmap/osm2pgsql/issues/230#issuecomment-418517270
https://github.com/gravitystorm/openstreetmap-carto/issues/596#issuecomment-418518388

I also made a query to the 'tile-serving' mailing list.

The proposal can be found here:
https://github.com/kennykb/osm-shields/wiki/Proposal:-add-route-tables-to-osm2pgsql

and I'm asking that comments be posted against this issue:

https://github.com/kennykb/osm-shields/issues/4



Where I've got so far is that I have a stand-alone converter that can
produce the
tables by querying the slim tables (Yes, I understand why that's a bad idea, but
it's what I have to work with before I start bashing away at osm2pgsql, and it
at least gets me rendering. It's also a very fast way to upgrade the
tables without
having to reimport everything.)

I also have a set of stored procedures (insanely complex, but extensively
documented) for placing route markers so that Mapnik can render them, and
a topographic-map rendering that uses the placement.
http://kbk.is-a-geek.net/catskills/test4.html?la=42.7276=-72.4507=12
shows the result. The area that I'm linking to is chosen because it has a mix
of route relations and routes tagged on individual ways, so it demonstrates
that both function.

As far as changes to osm2pgsql go, i looks as if the top-level relation table
 can be handled with fairly light mods to the pathway that imports 'point',
'line', 'polygon' and 'roads'. It essentially could use the same sort of
conversion rules for tags. The big difference is that a relation would have
no geometry.  (This similarity extends to the Lua code for filtering objects,
as well, which appears to be relatively ignorant of geometry in any case.)
The relation-member table is its own sort of object. It has no properties
other than 'role', and it must be populated for everything that's in the
relation table, so there's really no opportunity for fine control the way
we do with tagged objects; a member will either be included (because
its relation is) or not.

It's still a bit of a daunting prospect for me, because I'm not yet
intimately familiar with the code, and there doesn't appear to be
a simple 'road map' for what happens where. If your're amenable to
pull requests for simple improvements to commentary, I'll certainly
try to document what I learn as I learn it.

My understanding is that Sarah 'lonvia' Hoffmann has a very
similar structure underlying the rendering on waymarkedtrails.org,
but I've not examined her code.

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

Re: [Tagging] Traffic sign direction tagging..

[Yves]

@Paul
I guess it's this one:
https://github.com/openstreetmap/osm2pgsql/issues/230
Yves ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign direction tagging..

[Paul Norman]

On Sep 29, 2018 9:40 PM, Kevin Kenny  wrote:
Alas, I don't have much hope that the pull request will be accepted.
I've asked the upstream developers several times if they could
possibly review the proposed functionality (I've at least a draft at a
formal proposal -
https://github.com/kennykb/osm-shields/wiki/Proposal:-add-route-tables-to-osm2pgsql)
so that I can know whether I'm entirely wasting my time. I've heard
nothng but silenceCould you provide a link to the osm2pgql issue tracker with the issue in question? I don't recall it, but I've been away a lot and haven't kept up with everything.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign direction tagging..

[Robert Skedgell]

On 28/09/18 22:58, Philip Barnes wrote:
> 
> 
> On 28 September 2018 22:14:03 BST, Simon Poole  wrote:
>>
>>
>> Am 28.09.2018 um 18:07 schrieb Bryan Housel:
 I actually mentioned the issue in Milano. 

 Essentially `traffic_sign`, `traffic_sign:forward` and
 `traffic_sign:backward` need to be treated as "object" tags as
>> things
 are now.

>>> Let’s just do `traffic_sign=*` and consider the others an unfortunate
>>> mistake that can go away.
>> 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.
> 
> Not all give ways have a sign, some are just give way markings painted on the 
> road. 

As far as the law is concerned, that is also a traffic sign, diagram
1003A in TSRGD 2016 (see
http://www.legislation.gov.uk/uksi/2016/362/schedule/9/made ). Failure
to give way is a criminal offence contrary to s. 36 RTA 1988.

> 
> Phil (trigpoint) 
> 

-- 
Robert Skedgell (rskedgell)

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

Re: [Tagging] Traffic sign direction tagging..

[Paul Allen]

On Sun, Sep 30, 2018 at 2:23 AM Graeme Fitzpatrick 
wrote:

[relations]
>
> Maybe because people don't understand how to use them properly (I know I
> don't?), so they're scared of them?
>

I thought I was the only one. :)

Some very simple, easily found, instructions / guidelines would be handy.
>

I've only used a couple of types so far.  You're right, the instructions
are scattered around the different
type of relation and so not easily found.  They're also not (generally)
written with the newbie in mind,
so not easily understood.  But the problem is that the different types of
OSM relation, like your
real-life relations, are all different, do different things and behave
somewhat differently.  What you're
asking for is similar to the job interview question "Describe yourself in a
single word" (my answer is
"indescribable") except it's closer "Describe all your relatives in a
single word" (my answer is
"related").

Oh, and never forget that this is OSM.  So you'll find one person saying
that relations of type A, B
and C are not only valid but also vital whilst any other type of relation
is an abomination and another
person saying types A, B and C are unnecessary abominations and all other
types are valid and
essential.  For example, super relations solve several distinct problems
and are, at the same time,
an unnecessary abomination with no conceivable use cases (I thought of a
nifty use for them that
would be useful to me but they are so despised by so many people I'm scared
of even mentioning it).

Right now I can't think of a way of improving the documentation in the way
you (and I) would like
because the relation types differ so much.  All that comes to mind is a
page saying that "relations
relate things" with a list of the different types and a one-line
description.

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

Re: [Tagging] Traffic sign direction tagging..

[Kevin Kenny]

On Sat, Sep 29, 2018 at 6:58 PM Paul Johnson  wrote:
> I'm still against using forward/backward on nodes, it really feels like a 
> hacky way to avoid using a relation (up there with using ref=* on ways to 
> describe routes), which would disambiguate things without being so brittle 
> just because a way reversed, and handle more complex situations like "right 
> turn permitted without stopping" sign below a "stop" sign, or allow a data 
> consumer to be able to display a diagram indicating which ways a stop applies 
> to (handy if you encounter, say, a six way intersection with a four way stop).
>
> I honestly don't understand why, ten years since it's introduction as OSM's 
> third basic primitive, there's still this weirdly unnatural aversion to 
> relations, even though they're quite a powerful primitive in our toolbox.

I agree with you that we need to design relations for the complex
cases such as what you describe, but I've no problem with the 'hacky'
approach as well - on the principle of 'make simple things easy and
complex things possible'. JOSM (and from what I understand, iD, but I
rarely use it) handles directional nodes on ways fairly competently,
detecting that the mapper is reversing a way that has such nodes
attached and asking what to do about them.

As far as the aversion to relations goes, I think a big part of it is
simply that the downstream support just isn't there.  The tools do
multipolygons fairly well, but that is the only relation that is
really handled well. A bit part of that is that once OSM data has been
through a stock osm2pgsql, there are no relations any more.
Multipolygons become first class objects, and all other relations are
handled at best by devolving their tags upon their components.

(The rest of this message is off the topic of stop signs.)

You raise the issue of ref=* on ways, and why we still use it. That's
a clear case where we use it because the downstream systems can't do
route relations.  I've been trying to help with this - at least to the
extent of trying to revive Phil! Gold's route relation processing. My
version is at https://github.com/kennykb/osm-shields, and you can see
one rendering with shaped shields based on relations at
https://kbk.is-a-geek.net/catskills/test4.html?la=42.7440=-72.4830=11.
That link is chosen to illustrate an area that intermixes 'tag on way'
with 'tag on relation'. Unfortunately, my time is limited, so the
project has stagnated for a few weeks.  I've not given up, though; the
next task will have to be to generate a pull request to adapt
osm2pgsql optionally to preserve relations, with two new tables to
track them.

Alas, I don't have much hope that the pull request will be accepted.
I've asked the upstream developers several times if they could
possibly review the proposed functionality (I've at least a draft at a
formal proposal -
https://github.com/kennykb/osm-shields/wiki/Proposal:-add-route-tables-to-osm2pgsql)
so that I can know whether I'm entirely wasting my time. I've heard
nothng but silence.

This silence is understandable. The developers are very, very busy,
with much more urgent issues to address. I've not yet advanced the
idea far enough to merit their attention. But at some point, I will
have to conclude that further advances will simply cost me too much in
time and money to be worth risking, because a likely outcome is that
when I do get someone's attention, the whole idea will be dismissed
out of hand.

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

Re: [Tagging] Traffic sign direction tagging..

[Graeme Fitzpatrick]

On Sat, 29 Sep 2018 at 02:58, Philip Barnes  wrote:

> OSMand also warns of traffic calming, toll barriers, level crossing,
> pedestrian crossings and enforcement cameras.
>

Phil

Do you have an example of a pedestrian crossing that OSMand warns you of,
as I don't see (or maybe just don't notice?) crossing warnings, so I'm
wondering if they may be tagged somehow differently?

Thanks

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

Re: [Tagging] Traffic sign direction tagging..

[Graeme Fitzpatrick]

On Sun, 30 Sep 2018 at 08:58, Paul Johnson  wrote:

>
> I honestly don't understand why, ten years since it's introduction as
> OSM's third basic primitive, there's still this weirdly unnatural aversion
> to relations, even though they're quite a powerful primitive in our toolbox.
>

Maybe because people don't understand how to use them properly (I know I
don't?), so they're scared of them?

Some very simple, easily found, instructions / guidelines would be handy.

Thanks

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

Re: [Tagging] Traffic sign direction tagging..

[Paul Johnson]

On Fri, Sep 28, 2018 at 11:09 AM Bryan Housel  wrote:

> I actually mentioned the issue in Milano.
>
> Essentially `traffic_sign`, `traffic_sign:forward` and
> `traffic_sign:backward` need to be treated as "object" tags as things are
> now.
>
> Let’s just do `traffic_sign=*` and consider the others an unfortunate
> mistake that can go away.
>

I'm still against using forward/backward on nodes, it really feels like a
hacky way to avoid using a relation (up there with using ref=* on ways to
describe routes), which would disambiguate things without being so brittle
just because a way reversed, and handle more complex situations like "right
turn permitted without stopping" sign below a "stop" sign, or allow a data
consumer to be able to display a diagram indicating which ways a stop
applies to (handy if you encounter, say, a six way intersection with a four
way stop).

I honestly don't understand why, ten years since it's introduction as OSM's
third basic primitive, there's still this weirdly unnatural aversion to
relations, even though they're quite a powerful primitive in our toolbox.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign direction tagging..

[Paul Johnson]

On Fri, Sep 28, 2018 at 11:58 AM Philip Barnes  wrote:

>
>
> On 28 September 2018 17:31:18 BST, Kevin Kenny 
> wrote:
> >On Fri, Sep 28, 2018, 5:34 AM Marc Gemis  wrote:
> >
> >> I still highway=give_way and highway=stop with
> >> direction=forward/backward (which is used by OsmAnd AFAIK).
> >
> >
> >Me, too - I went around my neighbourhood last year adding them. OSMand
> >does
> >indeed recognize them.
> >
> >Describing what a driver might see when approaching a turn would be an
> >effective use of traffic_sign, but 'node near the way' is pretty
> >useless
> >for routing. For maximal detail you'd need both, but if you're only
> >going
> >to add one, the highway=stop is far more useful.
> +1
> although also mapping the signs is useful for debugging.
>
> OSMand also warns of traffic calming, toll barriers, level crossing,
> pedestrian crossings and enforcement cameras.
>

Also stopped warning of rumble strips, which is annoying since they're
almost impossible to spot in advance in Oklahoma, as most of them are
unpainted and, depending on the vehicle really try to wrest control of the
steering away from motorists or introduce harmonic oscillation (aka speed
wobbles) in two wheeled vehicles in the worst case, and really give you a
good jumpscare at best.

I honestly miss getting "Attention: Rumble strip" out of Osmand.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign direction tagging..

[Philip Barnes]

On 28 September 2018 22:14:03 BST, Simon Poole  wrote:
>
>
>Am 28.09.2018 um 18:07 schrieb Bryan Housel:
>>> I actually mentioned the issue in Milano. 
>>>
>>> Essentially `traffic_sign`, `traffic_sign:forward` and
>>> `traffic_sign:backward` need to be treated as "object" tags as
>things
>>> are now.
>>>
>> Let’s just do `traffic_sign=*` and consider the others an unfortunate
>> mistake that can go away.
>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.

Not all give ways have a sign, some are just give way markings painted on the 
road. 

Phil (trigpoint) 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: [Tagging] Traffic sign direction tagging..

[Simon Poole]

Am 28.09.2018 um 18:07 schrieb Bryan Housel:
>> I actually mentioned the issue in Milano. 
>>
>> Essentially `traffic_sign`, `traffic_sign:forward` and
>> `traffic_sign:backward` need to be treated as "object" tags as things
>> are now.
>>
> Let’s just do `traffic_sign=*` and consider the others an unfortunate
> mistake that can go away.
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.

>
>
>> See pages 29 and 30
>> https://drive.google.com/open?id=1LVmZIaEvd1K7mYVqDLnrhC5-jHLHy0lQ
>>
>> And I should note that iD has "plot" as such a key which is equally
>> mysterious, but I couldn't quite convince myself to include in the list.
>>
> Not sure.. I just checked and iD don’t have `plot=*` as a key value,
> so maybe there’s an error in whatever process you used to gather the
> data..

Sorry, just confusion on my hand: I was actually referring to
allotments=plot with allotments as the "top-level" key (the plot bit is
what I remembered, but it is still a one off top-level key).

Simon

>
> The “toplevel” key values in iD are really just the names of all the
> folders here: 
> https://github.com/openstreetmap/iD/tree/master/data/presets/presets
>
> Thanks, Bryan
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign direction tagging..

[Johnparis]

Thank you for this, Bryan. One small favor: could you add a "Change
direction" button like you have for one-way streets? It makes it much
easier if I guess wrong :)



On Fri, Sep 28, 2018 at 6:58 PM Philip Barnes  wrote:

>
>
> On 28 September 2018 17:31:18 BST, Kevin Kenny 
> wrote:
> >On Fri, Sep 28, 2018, 5:34 AM Marc Gemis  wrote:
> >
> >> I still highway=give_way and highway=stop with
> >> direction=forward/backward (which is used by OsmAnd AFAIK).
> >
> >
> >Me, too - I went around my neighbourhood last year adding them. OSMand
> >does
> >indeed recognize them.
> >
> >Describing what a driver might see when approaching a turn would be an
> >effective use of traffic_sign, but 'node near the way' is pretty
> >useless
> >for routing. For maximal detail you'd need both, but if you're only
> >going
> >to add one, the highway=stop is far more useful.
> +1
> although also mapping the signs is useful for debugging.
>
> OSMand also warns of traffic calming, toll barriers, level crossing,
> pedestrian crossings and enforcement cameras.
>
> Phil (trigpoint)
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> ___
> 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 direction tagging..

[Philip Barnes]

On 28 September 2018 17:31:18 BST, Kevin Kenny  wrote:
>On Fri, Sep 28, 2018, 5:34 AM Marc Gemis  wrote:
>
>> I still highway=give_way and highway=stop with
>> direction=forward/backward (which is used by OsmAnd AFAIK).
>
>
>Me, too - I went around my neighbourhood last year adding them. OSMand
>does
>indeed recognize them.
>
>Describing what a driver might see when approaching a turn would be an
>effective use of traffic_sign, but 'node near the way' is pretty
>useless
>for routing. For maximal detail you'd need both, but if you're only
>going
>to add one, the highway=stop is far more useful.
+1 
although also mapping the signs is useful for debugging. 

OSMand also warns of traffic calming, toll barriers, level crossing, pedestrian 
crossings and enforcement cameras. 

Phil (trigpoint) 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: [Tagging] Traffic sign direction tagging..

[Simon Poole]

I actually mentioned the issue in Milano.

Essentially traffic_sign, traffic_sign:forward and traffic_sign:backward
need to be treated as "object" tags as things are now.

See pages 29 and 30
https://drive.google.com/open?id=1LVmZIaEvd1K7mYVqDLnrhC5-jHLHy0lQ

And I should note that iD has "plot" as such a key which is equally
mysterious, but I couldn't quite convince myself to include in the list.

Simon


Am 28.09.2018 um 04:51 schrieb Bryan Housel:
> Hey Tagging List!
>
> 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 and
> relevant guidance on the OSM wiki is quoted below:
>
>> *Traffic sign as a separate node*
>> https://wiki.openstreetmap.org/wiki/Key:traffic_sign#As_a_separate_node
>> Create a separate node beside the road at the position of the actual
>> sign... You can use the `direction=*` tag to describe the facing
>> orientation of the sign by using an angle or cardinal direction.
>
> ^ This is ok!  iD supports `direction=*` and will even render a view
> cone at higher zooms so mappers can see which direction it points.
>
>> *Traffic sign along a way*
>> https://wiki.openstreetmap.org/wiki/Key:traffic_sign#As_part_of_a_way
>> Create a new node within the relevant way next to the sign... You can
>> use `traffic_sign:forward=*` to specify that this sign affects
>> vehicles moving in the same direction as the OSM way. The opposite
>> direction can be tagged with `traffic_sign:backward=*`. Formerly
>> the `direction=*` key has also been used to describe the affected
>> direction. But its common meaning has changed to Relative to
>> Geographic North.
>
> ^ This is the problem.  The wiki says we are supposed to do something
> like `traffic_sign:forward=US:R1`, and we can't really do that. A
> preset needs to be based on a "toplevel" tag
> like `traffic_sign=*` not `traffic_sign:forward=*` or 
> `traffic_sign:backward=*` (remember
> seamark? many of their tags have this issue too, where they put a
> value in the key part, and so we can’t turn it into a preset).
>
> So instead what we’ve decided to do is:  Support a tag
> `traffic_sign:direction` which works exactly the same as the existing
> and well supported `traffic_signals:direction`
>
> See https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction
> iD already has support for  `traffic_signals:direction=forward/backward`
>
> To keep things simple, we'll do the same thing for traffic signs:
> `traffic_sign:direction=forward/backward`
>
> Thanks,
> Bryan
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign direction tagging..

[Marc Gemis]

I still highway=give_way and highway=stop with
direction=forward/backward (which is used by OsmAnd AFAIK).
On Fri, Sep 28, 2018 at 9:26 AM Anton Klim  wrote:
>
> Missed the point when direction= suddenly became a no go for traffic sign 
> mapping.
>
>
> 28.09.2018, в 3:51, Bryan Housel  написал(а):
>
> Hey Tagging List!
>
> 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 and 
> relevant guidance on the OSM wiki is quoted below:
>
> Traffic sign as a separate node
>
> https://wiki.openstreetmap.org/wiki/Key:traffic_sign#As_a_separate_node
>
> Create a separate node beside the road at the position of the actual sign... 
> You can use the `direction=*` tag to describe the facing orientation of the 
> sign by using an angle or cardinal direction.
>
>
> ^ This is ok!  iD supports `direction=*` and will even render a view cone at 
> higher zooms so mappers can see which direction it points.
>
> Traffic sign along a way
>
> https://wiki.openstreetmap.org/wiki/Key:traffic_sign#As_part_of_a_way
>
> Create a new node within the relevant way next to the sign... You can use 
> `traffic_sign:forward=*` to specify that this sign affects vehicles moving in 
> the same direction as the OSM way. The opposite direction can be tagged with 
> `traffic_sign:backward=*`. Formerly the `direction=*` key has also been used 
> to describe the affected direction. But its common meaning has changed to 
> Relative to Geographic North.
>
>
> ^ This is the problem.  The wiki says we are supposed to do something like 
> `traffic_sign:forward=US:R1`, and we can't really do that. A preset needs to 
> be based on a "toplevel" tag like `traffic_sign=*` not 
> `traffic_sign:forward=*` or `traffic_sign:backward=*` (remember seamark? many 
> of their tags have this issue too, where they put a value in the key part, 
> and so we can’t turn it into a preset).
>
> So instead what we’ve decided to do is:  Support a tag 
> `traffic_sign:direction` which works exactly the same as the existing and 
> well supported `traffic_signals:direction`
>
> See https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction
> iD already has support for  `traffic_signals:direction=forward/backward`
>
> To keep things simple, we'll do the same thing for traffic signs:
> `traffic_sign:direction=forward/backward`
>
> Thanks,
> Bryan
>
> ___
> 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 direction tagging..

[Anton Klim]

Missed the point when direction= suddenly became a no go for traffic sign 
mapping. 


28.09.2018, в 3:51, Bryan Housel  написал(а):

> Hey Tagging List!
> 
> 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 and 
> relevant guidance on the OSM wiki is quoted below: 
> 
>> Traffic sign as a separate node
>> https://wiki.openstreetmap.org/wiki/Key:traffic_sign#As_a_separate_node
>> Create a separate node beside the road at the position of the actual sign... 
>> You can use the `direction=*` tag to describe the facing orientation of the 
>> sign by using an angle or cardinal direction.
> 
> ^ This is ok!  iD supports `direction=*` and will even render a view cone at 
> higher zooms so mappers can see which direction it points.
> 
>> Traffic sign along a way
>> https://wiki.openstreetmap.org/wiki/Key:traffic_sign#As_part_of_a_way
>> Create a new node within the relevant way next to the sign... You can use 
>> `traffic_sign:forward=*` to specify that this sign affects vehicles moving 
>> in the same direction as the OSM way. The opposite direction can be tagged 
>> with `traffic_sign:backward=*`. Formerly the `direction=*` key has also been 
>> used to describe the affected direction. But its common meaning has changed 
>> to Relative to Geographic North.
> 
> ^ This is the problem.  The wiki says we are supposed to do something like 
> `traffic_sign:forward=US:R1`, and we can't really do that. A preset needs to 
> be based on a "toplevel" tag like `traffic_sign=*` not 
> `traffic_sign:forward=*` or `traffic_sign:backward=*` (remember seamark? many 
> of their tags have this issue too, where they put a value in the key part, 
> and so we can’t turn it into a preset).
> 
> So instead what we’ve decided to do is:  Support a tag 
> `traffic_sign:direction` which works exactly the same as the existing and 
> well supported `traffic_signals:direction`
> 
> See https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction
> iD already has support for  `traffic_signals:direction=forward/backward`
> 
> To keep things simple, we'll do the same thing for traffic signs:
> `traffic_sign:direction=forward/backward`
> 
> Thanks,
> Bryan
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging