Re: [Tagging] The direction=* tag

[Martin Koppenhoefer]

2017-03-20 19:23 GMT+01:00 yo paseopor :

> whether the node is independent or part of one or more ways depends on the
>> situation and mapper. Even if the node is now part of just one way, in the
>> future this might change and it can become member of more ways (e.g. if the
>> way it is on is split at the node of the stop sign or if another way is
>> connected to the stop sign).
>>
>
> No, nodes for traffic signs has to be of one way.
>


no, it hasn't to be, and I for instance have never ever added a single
traffic sign on a highway. Take traffic_sign=city_limit. You will have to
split the highway at this position (because it is the point where the
settlement legally begins, i.e. typically different maxspeed). If you place
the traffic_sign=city_limit at the side of the road, every mapper will be
able to understand it, if you place it on the road it will be unclear where
outside and inside of the settlement is. And even with "direction"
referring to a different way it will always be unclear, to which way it
refers (because the signs would explicitly be on the endpoints of at least
2 ways, if mapped on the road, as explained above).




> All features of OSM has a good way or good practise to map it, we have to
> decide which one is the most useful , simple, easy and complete.
>


+1. Part of this is understanding that even if there are tens of thousands
of instances of something, and it is demonstrated it doesn't work, that
people have the flexibility to change to something better, easy, simple,
complete and working.


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

Re: [Tagging] The direction=* tag

[yo paseopor]

On Mon, Mar 20, 2017 at 9:57 AM, Martin Koppenhoefer  wrote:
>
> whether the node is independent or part of one or more ways depends on the
> situation and mapper. Even if the node is now part of just one way, in the
> future this might change and it can become member of more ways (e.g. if the
> way it is on is split at the node of the stop sign or if another way is
> connected to the stop sign).
>

No, nodes for traffic signs has to be of one way. When mappers need it
mappers duplicate the node...like ATMs and banks or the poop dog trash.
Traffic signs are also before the cross or the situation you have it (it
make no sense to warning you of a hazard...when the hazard is passed by.
All features of OSM has a good way or good practise to map it, we have to
decide which one is the most useful , simple, easy and complete.

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] The direction=* tag

[yo paseopor]

On Mon, Mar 20, 2017 at 9:46 AM, Topographe Fou 
wrote:

> Hi,
>
> I put stops, give ways and traffic light where the car has to stop/yield
> which can be far from the position of the sign (for instance in the US
> where the light is after the junction, thus may not be crossed if you
> turn). Also on narrow junction you may have the lights at the junction but
> the stop line some meters before to let buses make there turn.
>
> To match all use cases a new scheme has to consider the tagging of both
> stop/yield positions on the road and position of the sign/light (like for
> bus stops). One may think of relations as one explicit way of linking all
> those informations (like restricted turns). Any algorithm which try to
> deduce a position on a road from a position sign will be buggy at some
> points and greedy.
>

It is possible to tag lines. Road marks are also traffic signs (things we
call traffic signs are VERTICAL traffic signs, road marks are HORIZONTAL
traffic signs).

In a lot of countries road marks have their own traffic sign code so we can
use the down value of side key (to know in which side of the street is or
if it is like a vertical motorway panel) to map road marks.

e.g., As you can read on Norway traffic law [1]

traffic_sign:forward=NO:1036
side=down

will be the road mark for give way


> Then we have to consider that at some junctions the direction/orientation
> of 1. The way 2. The stop/yield line (if any) and 3. The sign/light may be
> three different values!
>


Exact position...is exact position, with aerial imagery you can know where
it is road marks. 1 is given by the subkey :forward :backward in relation
to the way.2 can be a node with the traffic sign 3 can be another node with
the road mark code.

Salut i marques vials (Health and road marks)
yopaseopor

[1]
http://www.vegvesen.no/trafikkinformasjon/Lover+og+regler/Trafikkskilt/_attachment/1089676?_ts=1511acde580&fast_title=Skiltbrosjyre-2015.pdf
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The direction=* tag

[Paul Johnson]

Since nodes lack direction, but relations do... seems like a stop sign
relation would be ideal, with multiple ways for the "from" role and the
node where it applies as the "to" role, with the actual stop sign locations
as the "device" role, similar to how enforcement is tagged.

On Mar 19, 2017 14:31, "Tod Fitch"  wrote:

> Unfortunately, I’ve not been able to make the Kendzi3D JOSM plug-in work
> for me. I’ll continue to poke at it from time to time as it looks
> intriguing. I did not feel confident in tagging lanes, especially turn
> lanes, until I found the JOSM plug-in that allowed me to visualize and
> check the tagging before committing the changes. This looks like one that
> would allow me to start looking into 3D tagging at some point in the future.
>
> In the meantime, I notice that the direction on the sign in the image is
> not set with a “direction=*” tag but rather with a
> “traffic_sign:direction=*” tag. Taking a look at taginfo, it seems that
> “traffic_sign:forward=*” and “traffic_sign:backward=*” tags have also been
> invented and the usage tag indicates that “stop” is one of the values used.
> The usage for all three is small, but it seems that for traffic control
> devices and signs we have multiple ways that people have tagged:
>
> “direction= forward | backward” [1]
> “traffic_signals:direction = forward | backward” [2]
> “traffic_sign:direction = forward | backward” [3]
> “traffic_sign:forward=*” [4]
> “traffic_sign:backward=*” [5]
> “stop:direction = forward | backward” [6]
> “give_way:direction = forward | backward” [7]
>
> (There are probably other ways of tagging the direction of a sign that
> I’ve not noticed.)
>
> It seems to me that this area could use some thought and, once
> “bikeshedded” enough, simplified and better documented.
>
> I recall seeing places where a one way street has a stop sign where it
> connects with another street and a single pole has a stop sign on one side
> and a wrong way/do not enter sign on the other. That use case shouldn’t
> affect a router which should be obeying the one way tagging, but for
> micro-mapping there wouldn't be a straight forward way to tag it if we use
> “traffic_sign:direction = forward | backward” or “direction = forward |
> backward” as we can’t tell which sign the direction tag is for.
>
> Maybe the “stop:direction = forward | backward” and “give_way:direction =
> forward | backward” would allow micro-mapping with multiple signs on one
> pole. They also follow the example set by the documented
> “traffic_signals:direction = forward | backward” tagging:
>
> “highway = stop”
> “stop:direction = forward”
>
> Follows the meme set by:
>
> “highway = traffic_signals"
> “traffic_signals:direction = forward”
>
> Cheers!
>
>
> [1] https://taginfo.openstreetmap.org/keys/direction#values
> [2] https://taginfo.openstreetmap.org/keys/traffic_signals%3Adirection
> [3] https://taginfo.openstreetmap.org/keys/traffic_sign%3Adirection
> [4] https://taginfo.openstreetmap.org/keys/traffic_sign%3Aforward
> [5] https://taginfo.openstreetmap.org/keys/traffic_sign%3Abackward
> [6] https://taginfo.openstreetmap.org/keys/stop%3Adirection
> [7] https://taginfo.openstreetmap.org/keys/give_way%3Adirection
>
> On Mar 17, 2017, at 4:28 PM, yo paseopor  wrote:
>
>  But at present I am pretty sure that map rendering can’t use
>> “direction=forward | backward”. It can (and my rendering does) use the
>> compass points and/or degrees values for rotating icons in the point
>> symbolizer.
>
>
> As you can see Kendzi3D plug-in [1] and a style for JOSM [2] do it with
> forward/backward keys.Others do too.
>
>
> Salut i mapes (Health and maps)
> yopaseopor
>
> [1] http://imgur.com/RFVKLGZ
> [2] http://imgur.com/9tCwVBT
>
> On Fri, Mar 17, 2017 at 11:24 PM, Tod Fitch  wrote:
>
>> If micro mapping, then the stop sign is usually not in the center of the
>> traveled way (though I have occasionally seen some there). For micro
>> mapping, place a node for the sign where it exists on the side of the road
>> and then use the compass direction to indicate how it is facing. As it is
>> detached from the highway way forward and backward can have no meaning.
>>
>> The “highway=stop | give_way” tag on a node on way might be used by map
>> rendering, which probably doesn’t care if it has forward or backward
>> tagging. I’ve been using Mapnik XML for rendering my maps and I don’t
>> recall the ability to detect the direction of a way. Or even if something
>> that is being rendered by the point symbolizer can tell if the point is on
>> a way. I could be wrong on that. And even if wrong, maybe some rendering
>> tool chain will support that in the future. But at present I am pretty sure
>> that map rendering can’t use “direction=forward | backward”. It can (and my
>> rendering does) use the compass points and/or degrees values for rotating
>> icons in the point symbolizer.
>>
>> I strongly suspect that tagging the stop/give way sign in the middle of
>> the way is for the use of routing

Re: [Tagging] The direction=* tag

[Marc Gemis]

On Mon, Mar 20, 2017 at 3:39 PM, Paul Johnson  wrote:
> Since nodes lack direction, but relations do... seems like a stop sign
> relation would be ideal, with multiple ways for the "from" role and the node
> where it applies as the "to" role, with the actual stop sign locations as
> the "device" role, similar to how enforcement is tagged.

there is an abandoned proposal for that:
https://wiki.openstreetmap.org/wiki/Proposed_features/Relation:type%3Dstop

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

Re: [Tagging] The direction=* tag

[Martin Koppenhoefer]

2017-03-19 20:55 GMT+01:00 yo paseopor :

> Why you accept a line and not a dot in the same place knowing the
> information of the way the node it is [5]?



because a line/way has a direction, a node hasn't. It is simple as that.

You can continue to insist in mapping directions on nodes, and it might
somehow and in many instances "work", but it is not a really reliable way
to map, and sooner or later it will go away because of this. Just as the
highway=bus_stop on the highway has (mostly) gone away. Some people are
always insisting in alternative methods, we will likely never have a 100%
consensus in OSM on these questions.

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

Re: [Tagging] The direction=* tag

[Martin Koppenhoefer]

2017-03-19 20:55 GMT+01:00 yo paseopor :

> In OSM mappers assume something until this thing has become more important
> and then need to redefine the way the key is applied with subkeys and other
> values.Think about bus stops for example [2]



For bus stops, nothing has really changed in the past decade. In 2008 we
mapped the bus stops at the side of the road with highway=bus_stop and this
is still the best way to do it ;-)

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

Re: [Tagging] The direction=* tag

[Martin Koppenhoefer]

2017-03-19 20:55 GMT+01:00 yo paseopor :

> but the way the node is in yes it does. Node it is not independent. It is
> in a way.



whether the node is independent or part of one or more ways depends on the
situation and mapper. Even if the node is now part of just one way, in the
future this might change and it can become member of more ways (e.g. if the
way it is on is split at the node of the stop sign or if another way is
connected to the stop sign).

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

Re: [Tagging] The direction=* tag

[Topographe Fou]

Hi,

I put stops, give ways and traffic light where the car has to stop/yield which 
can be far from the position of the sign (for instance in the US where the 
light is after the junction, thus may not be crossed if you turn). Also on 
narrow junction you may have the lights at the junction but the stop line some 
meters before to let buses make there turn.

To match all use cases a new scheme has to consider the tagging of both 
stop/yield positions on the road and position of the sign/light (like for bus 
stops). One may think of relations as one explicit way of linking all those 
informations (like restricted turns). Any algorithm which try to deduce a 
position on a road from a position sign will be buggy at some points and greedy.

Then we have to consider that at some junctions the direction/orientation of 1. 
The way 2. The stop/yield line (if any) and 3. The sign/light may be three 
different values!

And yes, OSRM is not the only data consumer to look at (even if it is a good 
one :) ). I dream of a routing app which would warn me of stops/lights in front 
of me or say "At the stop, turn right" instead of "Turn right" .

LeTopographeFou

  Message original  
De: t...@fitchdesign.com
Envoyé: 17 mars 2017 11:26 PM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: Re: [Tagging] The direction=* tag

If micro mapping, then the stop sign is usually not in the center of the 
traveled way (though I have occasionally seen some there). For micro mapping, 
place a node for the sign where it exists on the side of the road and then use 
the compass direction to indicate how it is facing. As it is detached from the 
highway way forward and backward can have no meaning.

The “highway=stop | give_way” tag on a node on way might be used by map 
rendering, which probably doesn’t care if it has forward or backward tagging. 
I’ve been using Mapnik XML for rendering my maps and I don’t recall the ability 
to detect the direction of a way. Or even if something that is being rendered 
by the point symbolizer can tell if the point is on a way. I could be wrong on 
that. And even if wrong, maybe some rendering tool chain will support that in 
the future. But at present I am pretty sure that map rendering can’t use 
“direction=forward | backward”. It can (and my rendering does) use the compass 
points and/or degrees values for rotating icons in the point symbolizer.

I strongly suspect that tagging the stop/give way sign in the middle of the way 
is for the use of routing and route guidance. It might still be of use by 
guidance (though I am not sure the “direction=forward | backward” matters much 
in that case) but what I am hearing is that as implemented/specified now it is 
not useful for routing. Thus my comment about noise.

I have been following the tagging suggested on the wiki [1] and checking the 
direction of the way in order to determine the value to put on the direction 
tag is tedious. If it is not being used, I might well forgo the direction tag. 
Fortunately the same wiki page states direction is only needed if the signs are 
closely spaced and it is not obvious which intersection/direction the sign is 
for, so the direction tag in that case is almost always optional per my 
interpretation of the wiki.

Cheers!

[1] 
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop#Tagging_minor_road_stops

> On Mar 17, 2017, at 2:47 PM, yo paseopor  wrote:
> 
> I don't agree with this: marking the direction of the traffic sign is not 
> noise, for a driver can be VITAL, also with the meaning of the traffic sign 
> (the main purpose of a traffic sign).
> Why? Because in a way with two directions we need to know to what direction 
> traffic sign it is for. It is not the same a road cross with an STOP forward 
> than backward (with micromapping it is not the same one lamp than two)
> Put a key like direction is not the best option, because this information can 
> be inside the key itself like traffic_sign:forward or traffic_sign:backward.
> Also it is a good thing to say of what side of the way the traffic sign is.
> In some countries traffic sign of a side is not the same as the other side 
> specially in streets in a city.
> e.g.
> 
> traffic_sign:forward=ES:R2
> highway=stop
> side=right
> 
> Ok, OSMR do not use that...but other tools uses this information so it is 
> important to keep it at the data.
> In a short-term, people like Mapillary or OSC will give us the opportunity 
> (and the data) to map all the traffic signs in a way. Routers and navigation 
> apps should be prepared for that. OSM is nowadays capable of show all this 
> information. Don't make it disappear.
> 
> Salut i mapes (Health and maps)
> yopaseopor

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

Re: [Tagging] The direction=* tag

[yo paseopor]

On Sun, Mar 19, 2017 at 8:30 PM, Tod Fitch  wrote:

> Unfortunately, I’ve not been able to make the Kendzi3D JOSM plug-in work
> for me. I’ll continue to poke at it from time to time as it looks
> intriguing.
>

I have told Kendzi now it is not working (with version 11425 it does) , but
as you can see in imgur [1] I have done some capture I can assure it works
with more than 9000 traffic signs kinds from 32 countries.


> I did not feel confident in tagging lanes, especially turn lanes, until I
> found the JOSM plug-in that allowed me to visualize and check the tagging
> before committing the changes. This looks like one that would allow me to
> start looking into 3D tagging at some point in the future.
>
> In the meantime, I notice that the direction on the sign in the image is
> not set with a “direction=*” tag but rather with a
> “traffic_sign:direction=*” tag.
>

When I had discover Roadsign plug-in I wanted a complete scheme for my
favourite subject. At first approach in 2013 [2] I know traffic signs need
somewhat to "localize exactly" and the option in Roadsign plug-in was a key
direction= ) .In parallel I have continued with a Style for JOSM. Also I
have found a way to show in "3D" in a plug-in of JOSM called Kendzi3D and
develope the possibility to show this traffic signs with the orientation
with direction= key.

But later, as Roadsign updated were so difficult and I have not control of
it, when I have finished all three legs, I have checked the wiki and
discovered Finnish approach [3] and Deutsch aproach [4] and decided to
start a preset for JOSM, and in the preset and with comments for some user
JOSM did not control direction tag I have changed all the scheme of the
preset to traffic_sign:forward/backward [5]. I have started with my
country: Spain. Last big changes version was in 2016. And one day I saw
someone localized to French some strings. I had checked Taginfo and
Overpass and watch some Spanish traffic signs were around the world (I saw
Spanish traffic signs...in Texas USA ) .So I have started to investigate
other countries. I have took information of other countries as Finland or
Belgium and start with Belgium because they have less traffic signs than
other european countries. But I was so late.

Preset was so huge and also I a bad programmer than it started to make many
problems to JOSM, and in a issue they say me "split the preset" [6] . Now
you have 32 preset from 9000 different traffic signs with forward and
backward.

It seems to me that this area could use some thought and, once
> “bikeshedded” enough, simplified and better documented.
>

I think it is a good opportunity to give traffic signs the importance they
have. The scheme of :forward/backward, the two-letter country code allows
to add any traffic sign of any country.


>
> I recall seeing places where a one way street has a stop sign where it
> connects with another street and a single pole has a stop sign on one side
> and a wrong way/do not enter sign on the other. That use case shouldn’t
> affect a router which should be obeying the one way tagging, but for
> micro-mapping there wouldn't be a straight forward way to tag it if we use
> “traffic_sign:direction = forward | backward” or “direction = forward |
> backward” as we can’t tell which sign the direction tag is for.
>

Thanks to Spanish preset I saw the necessity of make also a destination
tagging scheme, because multiple values does not work well with traffic
signs, also recognition systems from people like Mapillary or OSC use to
identify any traffic sign individually. Proposal is done [7], waiting for
people to watch it and make it yours and better, modify it , ammend it, cut
it, crop it,erase it... Precisely I am not the best programmer in the World
(I'm only a kindergarden teacher) . Make useful all this stuff. Make your
own stuff about that. It is only an idea.


>
> Maybe the “stop:direction = forward | backward” and “give_way:direction =
> forward | backward” would allow micro-mapping with multiple signs on one
> pole. They also follow the example set by the documented
> “traffic_signals:direction = forward | backward” tagging:
>
> “highway = stop”
> “stop:direction = forward”
>
> Follows the meme set by:
>
> “highway = traffic_signals"
> “traffic_signals:direction = forward”
>

I think use subkeys (traffic_sign:forward/backward is better than using
other key as traffic_sign:direction=forward
First option give you the country and the code in one pair of key=value
like this:

traffic_sign=maxspeed
maxspeed:forward=50
traffic_sign:forward=ES:R301
side=right

Also opens the opportunity to use traffic_sign with no subkeys to mark the
kind of traffic sign it is (warning,
complementary,regulatory,compulsory...) as a future scheme to unified
traffic sign international system like Mapillary's [8]

Next moths, next years you will hear about Mapillary, about OSC, about
recognition traffic signs system, about open data agreements with some
goverments (if Spanish governme

Re: [Tagging] The direction=* tag

[John F. Eldredge]

This has the added complication that the way may have two-way traffic, but 
the sign doesn't apply to both directions. In fact, most signs don't apply 
to both sides of a roadway; instead, there will usually be a separate sign 
for both directions of travel.




On March 19, 2017 2:56:02 PM yo paseopor  wrote:



yes, it is important to be able to understand to which way (and traveling
direction) a sign applies, but nodes do not have a forward or backward
direction



but the way the node is in yes it does. Node it is not independent. It is
in a way. with a specific direction (you can revert the direction if you
need it, rivers only flow forward-downward). Wiki says "(i.e., draw the way
in the direction that the river flows)."[1]



, at most they can have an upwards or downwards direction. They also have
a front side and a back side


, but generally I'd assume the tagging is about the front side, without

specifying it.



In OSM mappers assume something until this thing has become more important
and then need to redefine the way the key is applied with subkeys and other
values.Think about bus stops for example [2] [3]...



One way to map the direction in an easy way is to map the sign at the side
of the road.(requires post processing to use the information in a graph
model).



To avoid this complication I can assume the direction of the way the node
it is in. JOSM style recognise it, Kendzi3D plug-in also does with
direction key or :forward/:backward subkey. [4]



For a stop sign you could also make a short way for the part from the stop
line to the actual crossing node, and add stop sign information there
(either with a relation similar to turn restrictions or with direction
dependent tags on the _way_)



Why you accept a line and not a dot in the same place knowing the
information of the way the node it is [5]? Reading OSM wiki Why is possible
to do with traffic lights [6] (you have to put in a way - wiki says "Thus,
because traffic signals can affect routing decisions, it is important that
they are attached to the ways to which they apply, and not placed beside
the way" [5] , you have a specific subkey) or city_limit [7] but not with
the other traffic signs? Do we have to erase and delete all the traffic
signals (907 256) [8] because they are not correct? If we can do with a
traffic light I am sure we can do with other nodes with no lights there but
so important. If traffic signs were not so important governments did not
put in at the roads.

Mapillary and OSC will give us this information through their plug-ins.
Mapillary has a complete scheme of traffic signs recognition [9]. OSC has
an inside editor [10]. Spanish government open a file with more than
500,000 traffic signs relative to the way...and with a specific permission
to use it with OpenStreetMaps [11]. Are we telling other organizations can
give us this data, with this specific information but OSM can't accept it?
Taginfo says it is possible  [12][13]

Salut i senyals de trànsit (Health and traffic signs )
yopaseopor

[1] https://wiki.openstreetmap.org/wiki/Tag:waterway%3Driver
[2] https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position
[3] https://wiki.openstreetmap.org/w/index.php?title=Tag:
highway%3Dbus_stop&offset=&limit=500&action=history
[4] https://wiki.openstreetmap.org/wiki/Proposed_features/
Extended_traffic_signs_tagging#Renders
[5] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop#How_to_map
[6] https://wiki.openstreetmap.org/wiki/Tag:highway%
3Dtraffic_signals#Traffic_signals_for_cars
[7] https://wiki.openstreetmap.org/wiki/Tag:traffic_sign%3Dcity_limit
[8] https://taginfo.openstreetmap.org/tags/?key=highway&;
value=traffic_signals
[9] https://www.mapillary.com/developer/api-documentation/#traffic-signs
[10]
http://blog.improve-osm.org/en/2016/11/a-glimpse-into-the-future-of-mapmaking-with-osm-2/
[11]
https://wiki.openstreetmap.org/wiki/File:Resoluci%C3%B3n_se%C3%B1ales_de_tr%C3%A1fico_verticales_RCE.pdf
[12] https://taginfo.openstreetmap.org/keys/traffic_sign%3Aforward
[13] https://taginfo.openstreetmap.org/keys/traffic_sign%3Abackward



--
___
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] The direction=* tag

[yo paseopor]

>
> yes, it is important to be able to understand to which way (and traveling
> direction) a sign applies, but nodes do not have a forward or backward
> direction


but the way the node is in yes it does. Node it is not independent. It is
in a way. with a specific direction (you can revert the direction if you
need it, rivers only flow forward-downward). Wiki says "(i.e., draw the way
in the direction that the river flows)."[1]


> , at most they can have an upwards or downwards direction. They also have
> a front side and a back side

, but generally I'd assume the tagging is about the front side, without
> specifying it.
>

In OSM mappers assume something until this thing has become more important
and then need to redefine the way the key is applied with subkeys and other
values.Think about bus stops for example [2] [3]...


> One way to map the direction in an easy way is to map the sign at the side
> of the road.(requires post processing to use the information in a graph
> model).


To avoid this complication I can assume the direction of the way the node
it is in. JOSM style recognise it, Kendzi3D plug-in also does with
direction key or :forward/:backward subkey. [4]


> For a stop sign you could also make a short way for the part from the stop
> line to the actual crossing node, and add stop sign information there
> (either with a relation similar to turn restrictions or with direction
> dependent tags on the _way_)
>

Why you accept a line and not a dot in the same place knowing the
information of the way the node it is [5]? Reading OSM wiki Why is possible
to do with traffic lights [6] (you have to put in a way - wiki says "Thus,
because traffic signals can affect routing decisions, it is important that
they are attached to the ways to which they apply, and not placed beside
the way" [5] , you have a specific subkey) or city_limit [7] but not with
the other traffic signs? Do we have to erase and delete all the traffic
signals (907 256) [8] because they are not correct? If we can do with a
traffic light I am sure we can do with other nodes with no lights there but
so important. If traffic signs were not so important governments did not
put in at the roads.

Mapillary and OSC will give us this information through their plug-ins.
Mapillary has a complete scheme of traffic signs recognition [9]. OSC has
an inside editor [10]. Spanish government open a file with more than
500,000 traffic signs relative to the way...and with a specific permission
to use it with OpenStreetMaps [11]. Are we telling other organizations can
give us this data, with this specific information but OSM can't accept it?
Taginfo says it is possible  [12][13]

Salut i senyals de trànsit (Health and traffic signs )
yopaseopor

[1] https://wiki.openstreetmap.org/wiki/Tag:waterway%3Driver
[2] https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position
[3] https://wiki.openstreetmap.org/w/index.php?title=Tag:
highway%3Dbus_stop&offset=&limit=500&action=history
[4] https://wiki.openstreetmap.org/wiki/Proposed_features/
Extended_traffic_signs_tagging#Renders
[5] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop#How_to_map
[6] https://wiki.openstreetmap.org/wiki/Tag:highway%
3Dtraffic_signals#Traffic_signals_for_cars
[7] https://wiki.openstreetmap.org/wiki/Tag:traffic_sign%3Dcity_limit
[8] https://taginfo.openstreetmap.org/tags/?key=highway&;
value=traffic_signals
[9] https://www.mapillary.com/developer/api-documentation/#traffic-signs
[10]
http://blog.improve-osm.org/en/2016/11/a-glimpse-into-the-future-of-mapmaking-with-osm-2/
[11]
https://wiki.openstreetmap.org/wiki/File:Resoluci%C3%B3n_se%C3%B1ales_de_tr%C3%A1fico_verticales_RCE.pdf
[12] https://taginfo.openstreetmap.org/keys/traffic_sign%3Aforward
[13] https://taginfo.openstreetmap.org/keys/traffic_sign%3Abackward
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The direction=* tag

[Tod Fitch]

Unfortunately, I’ve not been able to make the Kendzi3D JOSM plug-in work for 
me. I’ll continue to poke at it from time to time as it looks intriguing. I did 
not feel confident in tagging lanes, especially turn lanes, until I found the 
JOSM plug-in that allowed me to visualize and check the tagging before 
committing the changes. This looks like one that would allow me to start 
looking into 3D tagging at some point in the future.

In the meantime, I notice that the direction on the sign in the image is not 
set with a “direction=*” tag but rather with a “traffic_sign:direction=*” tag. 
Taking a look at taginfo, it seems that “traffic_sign:forward=*” and 
“traffic_sign:backward=*” tags have also been invented and the usage tag 
indicates that “stop” is one of the values used. The usage for all three is 
small, but it seems that for traffic control devices and signs we have multiple 
ways that people have tagged:

“direction= forward | backward” [1]
“traffic_signals:direction = forward | backward” [2]
“traffic_sign:direction = forward | backward” [3]
“traffic_sign:forward=*” [4]
“traffic_sign:backward=*” [5]
“stop:direction = forward | backward” [6]
“give_way:direction = forward | backward” [7]

(There are probably other ways of tagging the direction of a sign that I’ve not 
noticed.)

It seems to me that this area could use some thought and, once “bikeshedded” 
enough, simplified and better documented.

I recall seeing places where a one way street has a stop sign where it connects 
with another street and a single pole has a stop sign on one side and a wrong 
way/do not enter sign on the other. That use case shouldn’t affect a router 
which should be obeying the one way tagging, but for micro-mapping there 
wouldn't be a straight forward way to tag it if we use “traffic_sign:direction 
= forward | backward” or “direction = forward | backward” as we can’t tell 
which sign the direction tag is for.

Maybe the “stop:direction = forward | backward” and “give_way:direction = 
forward | backward” would allow micro-mapping with multiple signs on one pole. 
They also follow the example set by the documented “traffic_signals:direction = 
forward | backward” tagging:

“highway = stop”
“stop:direction = forward”

Follows the meme set by:

“highway = traffic_signals"
“traffic_signals:direction = forward”

Cheers!


[1] https://taginfo.openstreetmap.org/keys/direction#values
[2] https://taginfo.openstreetmap.org/keys/traffic_signals%3Adirection
[3] https://taginfo.openstreetmap.org/keys/traffic_sign%3Adirection
[4] https://taginfo.openstreetmap.org/keys/traffic_sign%3Aforward
[5] https://taginfo.openstreetmap.org/keys/traffic_sign%3Abackward
[6] https://taginfo.openstreetmap.org/keys/stop%3Adirection
[7] https://taginfo.openstreetmap.org/keys/give_way%3Adirection

> On Mar 17, 2017, at 4:28 PM, yo paseopor  wrote:
> 
>  But at present I am pretty sure that map rendering can’t use 
> “direction=forward | backward”. It can (and my rendering does) use the 
> compass points and/or degrees values for rotating icons in the point 
> symbolizer.
> 
> As you can see Kendzi3D plug-in [1] and a style for JOSM [2] do it with 
> forward/backward keys.Others do too.
> 
> 
> Salut i mapes (Health and maps)
> yopaseopor
> 
> [1] http://imgur.com/RFVKLGZ 
> [2] http://imgur.com/9tCwVBT 
> 
> On Fri, Mar 17, 2017 at 11:24 PM, Tod Fitch  > wrote:
> If micro mapping, then the stop sign is usually not in the center of the 
> traveled way (though I have occasionally seen some there). For micro mapping, 
> place a node for the sign where it exists on the side of the road and then 
> use the compass direction to indicate how it is facing. As it is detached 
> from the highway way forward and backward can have no meaning.
> 
> The “highway=stop | give_way” tag on a node on way might be used by map 
> rendering, which probably doesn’t care if it has forward or backward tagging. 
> I’ve been using Mapnik XML for rendering my maps and I don’t recall the 
> ability to detect the direction of a way. Or even if something that is being 
> rendered by the point symbolizer can tell if the point is on a way. I could 
> be wrong on that. And even if wrong, maybe some rendering tool chain will 
> support that in the future. But at present I am pretty sure that map 
> rendering can’t use “direction=forward | backward”. It can (and my rendering 
> does) use the compass points and/or degrees values for rotating icons in the 
> point symbolizer.
> 
> I strongly suspect that tagging the stop/give way sign in the middle of the 
> way is for the use of routing and route guidance. It might still be of use by 
> guidance (though I am not sure the “direction=forward | backward” matters 
> much in that case) but what I am hearing is that as implemented/specified now 
> it is not useful for routing. Thus my comment about noise.
> 
> I have been following the tagging suggested on the w

Re: [Tagging] The direction=* tag

[Martin Koppenhoefer]

sent from a phone

> On 17 Mar 2017, at 22:47, yo paseopor  wrote:
> 
> I don't agree with this: marking the direction of the traffic sign is not 
> noise, for a driver can be VITAL, also with the meaning of the traffic sign 
> (the main purpose of a traffic sign).


yes, it is important to be able to understand to which way (and traveling 
direction) a sign applies, but nodes do not have a forward or backward 
direction, at most they can have an upwards or downwards direction. They also 
have a front side and a back side, but generally I'd assume the tagging is 
about the front side, without specifying it.

One way to map the direction in an easy way is to map the sign at the side of 
the road.(requires post processing to use the information in a graph model). 
For a stop sign you could also make a short way for the part from the stop line 
to the actual crossing node, and add stop sign information there (either with a 
relation similar to turn restrictions or with direction dependent tags on the 
_way_)

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

Re: [Tagging] The direction=* tag

[yo paseopor]

>
>  But at present I am pretty sure that map rendering can’t use
> “direction=forward | backward”. It can (and my rendering does) use the
> compass points and/or degrees values for rotating icons in the point
> symbolizer.


As you can see Kendzi3D plug-in [1] and a style for JOSM [2] do it with
forward/backward keys.Others do too.


Salut i mapes (Health and maps)
yopaseopor

[1] http://imgur.com/RFVKLGZ
[2] http://imgur.com/9tCwVBT

On Fri, Mar 17, 2017 at 11:24 PM, Tod Fitch  wrote:

> If micro mapping, then the stop sign is usually not in the center of the
> traveled way (though I have occasionally seen some there). For micro
> mapping, place a node for the sign where it exists on the side of the road
> and then use the compass direction to indicate how it is facing. As it is
> detached from the highway way forward and backward can have no meaning.
>
> The “highway=stop | give_way” tag on a node on way might be used by map
> rendering, which probably doesn’t care if it has forward or backward
> tagging. I’ve been using Mapnik XML for rendering my maps and I don’t
> recall the ability to detect the direction of a way. Or even if something
> that is being rendered by the point symbolizer can tell if the point is on
> a way. I could be wrong on that. And even if wrong, maybe some rendering
> tool chain will support that in the future. But at present I am pretty sure
> that map rendering can’t use “direction=forward | backward”. It can (and my
> rendering does) use the compass points and/or degrees values for rotating
> icons in the point symbolizer.
>
> I strongly suspect that tagging the stop/give way sign in the middle of
> the way is for the use of routing and route guidance. It might still be of
> use by guidance (though I am not sure the “direction=forward | backward”
> matters much in that case) but what I am hearing is that as
> implemented/specified now it is not useful for routing. Thus my comment
> about noise.
>
> I have been following the tagging suggested on the wiki [1] and checking
> the direction of the way in order to determine the value to put on the
> direction tag is tedious. If it is not being used, I might well forgo the
> direction tag. Fortunately the same wiki page states direction is only
> needed if the signs are closely spaced and it is not obvious which
> intersection/direction the sign is for, so the direction tag in that case
> is almost always optional per my interpretation of the wiki.
>
> Cheers!
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop#
> Tagging_minor_road_stops
>
> > On Mar 17, 2017, at 2:47 PM, yo paseopor  wrote:
> >
> > I don't agree with this: marking the direction of the traffic sign is
> not noise, for a driver can be VITAL, also with the meaning of the traffic
> sign (the main purpose of a traffic sign).
> > Why? Because in a way with two directions we need to know to what
> direction traffic sign it is for. It is not the same a road cross with an
> STOP forward than backward (with micromapping it is not the same one lamp
> than two)
> > Put a key like direction is not the best option, because this
> information can be inside the key itself like traffic_sign:forward or
> traffic_sign:backward.
> > Also it is a good thing to say of what side of the way the traffic sign
> is.
> > In some countries traffic sign of a side is not the same as the other
> side specially in streets in a city.
> > e.g.
> >
> > traffic_sign:forward=ES:R2
> > highway=stop
> > side=right
> >
> > Ok, OSMR do not use that...but other tools uses this information so it
> is important to keep it at the data.
> > In a short-term, people like Mapillary or OSC will give us the
> opportunity (and the data) to map all the traffic signs in a way. Routers
> and navigation apps should be prepared for that. OSM is nowadays capable of
> show all this information. Don't make it disappear.
> >
> > Salut i mapes (Health and maps)
> > 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] The direction=* tag

[Shawn K. Quinn]

On 03/17/2017 05:24 PM, Tod Fitch wrote:
> The “highway=stop | give_way” tag on a node on way might be used by
> map rendering, which probably doesn’t care if it has forward or
> backward tagging.

OsmAnd does a callout for highway=stop but unfortunately ignores the
direction=* tag as of the version I have.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

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

Re: [Tagging] The direction=* tag

[Tod Fitch]

If micro mapping, then the stop sign is usually not in the center of the 
traveled way (though I have occasionally seen some there). For micro mapping, 
place a node for the sign where it exists on the side of the road and then use 
the compass direction to indicate how it is facing. As it is detached from the 
highway way forward and backward can have no meaning.

The “highway=stop | give_way” tag on a node on way might be used by map 
rendering, which probably doesn’t care if it has forward or backward tagging. 
I’ve been using Mapnik XML for rendering my maps and I don’t recall the ability 
to detect the direction of a way. Or even if something that is being rendered 
by the point symbolizer can tell if the point is on a way. I could be wrong on 
that. And even if wrong, maybe some rendering tool chain will support that in 
the future. But at present I am pretty sure that map rendering can’t use 
“direction=forward | backward”. It can (and my rendering does) use the compass 
points and/or degrees values for rotating icons in the point symbolizer.

I strongly suspect that tagging the stop/give way sign in the middle of the way 
is for the use of routing and route guidance. It might still be of use by 
guidance (though I am not sure the “direction=forward | backward” matters much 
in that case) but what I am hearing is that as implemented/specified now it is 
not useful for routing. Thus my comment about noise.

I have been following the tagging suggested on the wiki [1] and checking the 
direction of the way in order to determine the value to put on the direction 
tag is tedious. If it is not being used, I might well forgo the direction tag. 
Fortunately the same wiki page states direction is only needed if the signs are 
closely spaced and it is not obvious which intersection/direction the sign is 
for, so the direction tag in that case is almost always optional per my 
interpretation of the wiki.

Cheers!

[1] 
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop#Tagging_minor_road_stops

> On Mar 17, 2017, at 2:47 PM, yo paseopor  wrote:
> 
> I don't agree with this: marking the direction of the traffic sign is not 
> noise, for a driver can be VITAL, also with the meaning of the traffic sign 
> (the main purpose of a traffic sign).
> Why? Because in a way with two directions we need to know to what direction 
> traffic sign it is for. It is not the same a road cross with an STOP forward 
> than backward (with micromapping it is not the same one lamp than two)
> Put a key like direction is not the best option, because this information can 
> be inside the key itself like traffic_sign:forward or traffic_sign:backward.
> Also it is a good thing to say of what side of the way the traffic sign is.
> In some countries traffic sign of a side is not the same as the other side 
> specially in streets in a city.
> e.g.
> 
> traffic_sign:forward=ES:R2
> highway=stop
> side=right
> 
> Ok, OSMR do not use that...but other tools uses this information so it is 
> important to keep it at the data.
> In a short-term, people like Mapillary or OSC will give us the opportunity 
> (and the data) to map all the traffic signs in a way. Routers and navigation 
> apps should be prepared for that. OSM is nowadays capable of show all this 
> information. Don't make it disappear.
> 
> Salut i mapes (Health and maps)
> yopaseopor





smime.p7s
Description: S/MIME cryptographic signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The direction=* tag

[yo paseopor]

I don't agree with this: marking the direction of the traffic sign is not
noise, for a driver can be VITAL, also with the meaning of the traffic sign
(the main purpose of a traffic sign).
Why? Because in a way with two directions we need to know to what direction
traffic sign it is for. It is not the same a road cross with an STOP
forward than backward (with micromapping it is not the same one lamp than
two)
Put a key like direction is not the best option, because this information
can be inside the key itself like traffic_sign:forward or
traffic_sign:backward.
Also it is a good thing to say of what side of the way the traffic sign is.
In some countries traffic sign of a side is not the same as the other side
specially in streets in a city.
e.g.

traffic_sign:forward=ES:R2
highway=stop
side=right

Ok, OSMR do not use that...but other tools uses this information so it is
important to keep it at the data.
In a short-term, people like Mapillary or OSC will give us the opportunity
(and the data) to map all the traffic signs in a way. Routers and
navigation apps should be prepared for that. OSM is nowadays capable of
show all this information. Don't make it disappear.

Salut i mapes (Health and maps)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The direction=* tag

[Tod Fitch]

Thank you for the insight. I don’t know that it is off topic though as any 
tagging scheme should be both achievable by a typical mapper and useful to any 
anticipated data consumers. Something that is easy for taggers but not useful 
to data consumers is just noise. Something that is useful for a data consumer 
but hard for a mapper is, well, a hard problem.

In this case, it seems that adding a “direction = forward | backward” tag to a 
node also tagged with “highway=stop | give way” is just noise.

> On Mar 17, 2017, at 7:38 AM, Daniel Hofmann  wrote:
> 
> On the routing engine side these tags will be translated to turn penalties 
> for specific turns, so the matching equivalent would probably be from,via,to 
> relations. Which is not a feasible modelling in OSM realistically speaking. 
> Simple stop signs could go on ways, but fail to capture more complex 
> situations.
> 
> The problem with traffic lights specifically is their interconnectivity: you 
> don't want to add turn penalties multiple times if traffic lights are 
> connected. But you can't tell. This is a bit off-topic, feel free to 
> cross-post to the osrm-talk or routing mailing list, or open an issue in 
> osrm-backend.
> 
> On Fri, Mar 17, 2017 at 3:29 PM, Tod Fitch  > wrote:
> From a data consumer point of view, what type of tagging would be reasonable 
> to indicate the, for lack of a better work, direction of travel a stop, give 
> way or traffic light has effect?
> 
>> On Mar 17, 2017, at 3:54 AM, Daniel Hofmann > > wrote:
>> 
>> Jumping in here to give a perspective from a routing engine (OSRM, 
>> https://github.com/Project-OSRM/osrm-backend#open-source-routing-machine 
>> ). 
>> We do not handle direction tags on nodes which indicate a property for a way 
>> or a turn at an intersection. The example with stop signs and give yield 
>> signs is spot on. Even worse is the assumption that routing engines can just 
>> infer the direction by checking the distance to the nearest intersection. 
>> This is in conflict with how parsing and creating a graph works.
>> 
>> There is a similar problem with exit_to node tags, indicating the exit way 
>> destination - you can read about it here
>> 
>> - https://www.openstreetmap.org/user/daniel-j-h/diary/40555 
>>  (en)
>> - https://www.openstreetmap.org/user/daniel-j-h/diary/40554 
>>  (de)
>> 
>> Cheers,
>> Daniel J H
>> 
>> 
>> On Fri, Mar 17, 2017 at 11:25 AM, Martin Koppenhoefer 
>> mailto:dieterdre...@gmail.com>> wrote:
>> 
>> 2017-03-16 5:13 GMT+01:00 Tod Fitch > >:
>> The “direction” tag [1] has different uses that seem disjoint to me.
>> To specify the orientation (compass point or degrees from north) of an 
>> object (adit or cave entrance, etc.). 
>> 
>> "orientation" would have been a better descriptor IMHO, but the crowd uses 
>> this tag differently (see taginfo, also subtags like roof:orientation, ...). 
>> Direction is working for me nonetheless.
>> 
>> 
>> 2. To specify direction (clockwise/counterclockwise) around a roundabout 
>> (not sure why this is needed as it should be apparent from local laws or 
>> specified with a “oneway=yes”).
>> 
>> 
>> agree with you
>> 
>> 
>> 3. To indicate the direction (forward/backward) a stop or yield (give way) 
>> sign has effect along a way.
>> 
>> 
>> broken. From time to time people are coming up with features to tag on nodes 
>> that require (or seem to require) the information of a direction. Taking the 
>> direction of a different object (e.g. here a way) doesn't seem a healthy way 
>> to represent this. Ways might get split, might get reversed, nodes might be 
>> (or become) part of several ways, etc. Either use a cardinal direction or a 
>> short way stub or a relation, etc., but not "forward" or "backward" tag 
>> values on a node, it simply doesn't make sense. Tags should refer to the 
>> object they are tagged on.
>> 
>> 
>>  
>> Oddly, that third use seems only for stop and yield signs but not for 
>> traffic signals where a “traffic_signals:direction=forward | backward” tag 
>> is to be used. However that seems to be the most used form [2]. Apparently 
>> some have figured that if we have “traffic_signals:direction” there should 
>> be “stop:direction” [3] and “give_way:direction” [4] tags.
>> 
>> 
>> similarly broken
>> 
>>  
>> I would keep the variant 1 and discourage 2 and 3.
>> 
>> Cheers,
>> Martin
>> 
>> 
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/tagging 
>> 
>> 
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstre

Re: [Tagging] The direction=* tag

[Daniel Hofmann]

On the routing engine side these tags will be translated to turn penalties
for specific turns, so the matching equivalent would probably be
from,via,to relations. Which is not a feasible modelling in OSM
realistically speaking. Simple stop signs could go on ways, but fail to
capture more complex situations.

The problem with traffic lights specifically is their interconnectivity:
you don't want to add turn penalties multiple times if traffic lights are
connected. But you can't tell. This is a bit off-topic, feel free to
cross-post to the osrm-talk or routing mailing list, or open an issue in
osrm-backend.

On Fri, Mar 17, 2017 at 3:29 PM, Tod Fitch  wrote:

> From a data consumer point of view, what type of tagging would be
> reasonable to indicate the, for lack of a better work, direction of travel
> a stop, give way or traffic light has effect?
>
> On Mar 17, 2017, at 3:54 AM, Daniel Hofmann  wrote:
>
> Jumping in here to give a perspective from a routing engine (OSRM,
> https://github.com/Project-OSRM/osrm-backend#open-source-routing-machine).
> We do not handle direction tags on nodes which indicate a property for a
> way or a turn at an intersection. The example with stop signs and give
> yield signs is spot on. Even worse is the assumption that routing engines
> can just infer the direction by checking the distance to the nearest
> intersection. This is in conflict with how parsing and creating a graph
> works.
>
> There is a similar problem with exit_to node tags, indicating the exit way
> destination - you can read about it here
>
> - https://www.openstreetmap.org/user/daniel-j-h/diary/40555 (en)
> - https://www.openstreetmap.org/user/daniel-j-h/diary/40554 (de)
>
> Cheers,
> Daniel J H
>
>
> On Fri, Mar 17, 2017 at 11:25 AM, Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
>
>>
>> 2017-03-16 5:13 GMT+01:00 Tod Fitch :
>>
>>> The “direction” tag [1] has different uses that seem disjoint to me.
>>>
>>>1. To specify the orientation (compass point or degrees from north)
>>>of an object (adit or cave entrance, etc.).
>>>
>>>
>> "orientation" would have been a better descriptor IMHO, but the crowd
>> uses this tag differently (see taginfo, also subtags like roof:orientation,
>> ...). Direction is working for me nonetheless.
>>
>>
>> 2. To specify direction (clockwise/counterclockwise) around a roundabout
>>> (not sure why this is needed as it should be apparent from local laws or
>>> specified with a “oneway=yes”).
>>
>>
>>
>> agree with you
>>
>>
>> 3. To indicate the direction (forward/backward) a stop or yield (give
>>> way) sign has effect along a way.
>>
>>
>>
>> broken. From time to time people are coming up with features to tag on
>> nodes that require (or seem to require) the information of a direction.
>> Taking the direction of a different object (e.g. here a way) doesn't seem a
>> healthy way to represent this. Ways might get split, might get reversed,
>> nodes might be (or become) part of several ways, etc. Either use a cardinal
>> direction or a short way stub or a relation, etc., but not "forward" or
>> "backward" tag values on a node, it simply doesn't make sense. Tags should
>> refer to the object they are tagged on.
>>
>>
>>
>>
>>> Oddly, that third use seems only for stop and yield signs but not for
>>> traffic signals where a “traffic_signals:direction=forward | backward”
>>> tag is to be used. However that seems to be the most used form [2].
>>> Apparently some have figured that if we have “traffic_signals:direction”
>>> there should be “stop:direction” [3] and “give_way:direction” [4] tags.
>>>
>>
>>
>> similarly broken
>>
>>
>> I would keep the variant 1 and discourage 2 and 3.
>>
>> Cheers,
>> Martin
>>
>>
>>
>> ___
>> 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
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The direction=* tag

[Tod Fitch]

From a data consumer point of view, what type of tagging would be reasonable to 
indicate the, for lack of a better work, direction of travel a stop, give way 
or traffic light has effect?

> On Mar 17, 2017, at 3:54 AM, Daniel Hofmann  wrote:
> 
> Jumping in here to give a perspective from a routing engine (OSRM, 
> https://github.com/Project-OSRM/osrm-backend#open-source-routing-machine 
> ). 
> We do not handle direction tags on nodes which indicate a property for a way 
> or a turn at an intersection. The example with stop signs and give yield 
> signs is spot on. Even worse is the assumption that routing engines can just 
> infer the direction by checking the distance to the nearest intersection. 
> This is in conflict with how parsing and creating a graph works.
> 
> There is a similar problem with exit_to node tags, indicating the exit way 
> destination - you can read about it here
> 
> - https://www.openstreetmap.org/user/daniel-j-h/diary/40555 
>  (en)
> - https://www.openstreetmap.org/user/daniel-j-h/diary/40554 
>  (de)
> 
> Cheers,
> Daniel J H
> 
> 
> On Fri, Mar 17, 2017 at 11:25 AM, Martin Koppenhoefer  > wrote:
> 
> 2017-03-16 5:13 GMT+01:00 Tod Fitch  >:
> The “direction” tag [1] has different uses that seem disjoint to me.
> To specify the orientation (compass point or degrees from north) of an object 
> (adit or cave entrance, etc.). 
> 
> "orientation" would have been a better descriptor IMHO, but the crowd uses 
> this tag differently (see taginfo, also subtags like roof:orientation, ...). 
> Direction is working for me nonetheless.
> 
> 
> 2. To specify direction (clockwise/counterclockwise) around a roundabout (not 
> sure why this is needed as it should be apparent from local laws or specified 
> with a “oneway=yes”).
> 
> 
> agree with you
> 
> 
> 3. To indicate the direction (forward/backward) a stop or yield (give way) 
> sign has effect along a way.
> 
> 
> broken. From time to time people are coming up with features to tag on nodes 
> that require (or seem to require) the information of a direction. Taking the 
> direction of a different object (e.g. here a way) doesn't seem a healthy way 
> to represent this. Ways might get split, might get reversed, nodes might be 
> (or become) part of several ways, etc. Either use a cardinal direction or a 
> short way stub or a relation, etc., but not "forward" or "backward" tag 
> values on a node, it simply doesn't make sense. Tags should refer to the 
> object they are tagged on.
> 
> 
>  
> Oddly, that third use seems only for stop and yield signs but not for traffic 
> signals where a “traffic_signals:direction=forward | backward” tag is to be 
> used. However that seems to be the most used form [2]. Apparently some have 
> figured that if we have “traffic_signals:direction” there should be 
> “stop:direction” [3] and “give_way:direction” [4] tags.
> 
> 
> similarly broken
> 
>  
> I would keep the variant 1 and discourage 2 and 3.
> 
> Cheers,
> Martin
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging 
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



smime.p7s
Description: S/MIME cryptographic signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The direction=* tag

[Daniel Hofmann]

Jumping in here to give a perspective from a routing engine (OSRM,
https://github.com/Project-OSRM/osrm-backend#open-source-routing-machine).
We do not handle direction tags on nodes which indicate a property for a
way or a turn at an intersection. The example with stop signs and give
yield signs is spot on. Even worse is the assumption that routing engines
can just infer the direction by checking the distance to the nearest
intersection. This is in conflict with how parsing and creating a graph
works.

There is a similar problem with exit_to node tags, indicating the exit way
destination - you can read about it here

- https://www.openstreetmap.org/user/daniel-j-h/diary/40555 (en)
- https://www.openstreetmap.org/user/daniel-j-h/diary/40554 (de)

Cheers,
Daniel J H


On Fri, Mar 17, 2017 at 11:25 AM, Martin Koppenhoefer <
dieterdre...@gmail.com> wrote:

>
> 2017-03-16 5:13 GMT+01:00 Tod Fitch :
>
>> The “direction” tag [1] has different uses that seem disjoint to me.
>>
>>1. To specify the orientation (compass point or degrees from north)
>>of an object (adit or cave entrance, etc.).
>>
>>
> "orientation" would have been a better descriptor IMHO, but the crowd uses
> this tag differently (see taginfo, also subtags like roof:orientation,
> ...). Direction is working for me nonetheless.
>
>
> 2. To specify direction (clockwise/counterclockwise) around a roundabout
>> (not sure why this is needed as it should be apparent from local laws or
>> specified with a “oneway=yes”).
>
>
>
> agree with you
>
>
> 3. To indicate the direction (forward/backward) a stop or yield (give way)
>> sign has effect along a way.
>
>
>
> broken. From time to time people are coming up with features to tag on
> nodes that require (or seem to require) the information of a direction.
> Taking the direction of a different object (e.g. here a way) doesn't seem a
> healthy way to represent this. Ways might get split, might get reversed,
> nodes might be (or become) part of several ways, etc. Either use a cardinal
> direction or a short way stub or a relation, etc., but not "forward" or
> "backward" tag values on a node, it simply doesn't make sense. Tags should
> refer to the object they are tagged on.
>
>
>
>
>> Oddly, that third use seems only for stop and yield signs but not for
>> traffic signals where a “traffic_signals:direction=forward | backward”
>> tag is to be used. However that seems to be the most used form [2].
>> Apparently some have figured that if we have “traffic_signals:direction”
>> there should be “stop:direction” [3] and “give_way:direction” [4] tags.
>>
>
>
> similarly broken
>
>
> I would keep the variant 1 and discourage 2 and 3.
>
> Cheers,
> Martin
>
>
>
> ___
> 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] The direction=* tag

[Craig Wallace]

On 2017-03-16 04:13, Tod Fitch wrote:

The “direction” tag [1] has different uses that seem disjoint to me.

 2. To specify direction (clockwise/counterclockwise) around a
roundabout (not sure why this is needed as it should be apparent
from local laws or specified with a “oneway=yes”).


This tag is used for mini-roundabouts, which are usually mapped as 
nodes. So you can't tag it with oneway.
Yes, maybe it is obvious from local laws, but is it practical for 
routing software and renderers to figure out what laws apply to a 
particular roundabout? And there may be a few exceptions, with 
mini-roundabouts which go in the opposite direction to the local defaults.

Though maybe it should be a more specific tag, eg roundabout:direction


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

Re: [Tagging] The direction=* tag

[Martin Koppenhoefer]

2017-03-16 5:13 GMT+01:00 Tod Fitch :

> The “direction” tag [1] has different uses that seem disjoint to me.
>
>1. To specify the orientation (compass point or degrees from north) of
>an object (adit or cave entrance, etc.).
>
>
"orientation" would have been a better descriptor IMHO, but the crowd uses
this tag differently (see taginfo, also subtags like roof:orientation,
...). Direction is working for me nonetheless.


2. To specify direction (clockwise/counterclockwise) around a roundabout
> (not sure why this is needed as it should be apparent from local laws or
> specified with a “oneway=yes”).



agree with you


3. To indicate the direction (forward/backward) a stop or yield (give way)
> sign has effect along a way.



broken. From time to time people are coming up with features to tag on
nodes that require (or seem to require) the information of a direction.
Taking the direction of a different object (e.g. here a way) doesn't seem a
healthy way to represent this. Ways might get split, might get reversed,
nodes might be (or become) part of several ways, etc. Either use a cardinal
direction or a short way stub or a relation, etc., but not "forward" or
"backward" tag values on a node, it simply doesn't make sense. Tags should
refer to the object they are tagged on.




> Oddly, that third use seems only for stop and yield signs but not for
> traffic signals where a “traffic_signals:direction=forward | backward”
> tag is to be used. However that seems to be the most used form [2].
> Apparently some have figured that if we have “traffic_signals:direction”
> there should be “stop:direction” [3] and “give_way:direction” [4] tags.
>


similarly broken


I would keep the variant 1 and discourage 2 and 3.

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

Re: [Tagging] The direction=* tag

[Michael Reichert]

Hi,

Am 2017-03-16 um 05:13 schrieb Tod Fitch:
> The “direction” tag [1] has different uses that seem disjoint to me.
> To specify the orientation (compass point or degrees from north) of an object 
> (adit or cave entrance, etc.). 
> To specify direction (clockwise/counterclockwise) around a roundabout (not 
> sure why this is needed as it should be apparent from local laws or specified 
> with a “oneway=yes”).
> To indicate the direction (forward/backward) a stop or yield (give way) sign 
> has effect along a way.
> Oddly, that third use seems only for stop and yield signs but not for traffic 
> signals where a “traffic_signals:direction=forward | backward” tag is to be 
> used. However that seems to be the most used form [2]. Apparently some have 
> figured that if we have “traffic_signals:direction” there should be 
> “stop:direction” [3] and “give_way:direction” [4] tags.

A direction tag is also used for railway signals, it's called
railway:signal=forward/backward/both. Both tags were used the first time
end of 2011 when the development of the current railway signal tagging
scheme started.

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] The direction=* tag

[Topographe Fou]

  Hi,The second use should not be encouraged IMHO as it is redundant with the direction of the way.Reguarding the third use, you can use either traffic_signals:direction or direction but the first form will explicitly apply to the traffic_signals while the second may apply to different tags of the node. Imagine a node which is tagged as a traffic light (or a stop) and a crossing or a camera. To which one the direction apply if you don't specify it? If the second form is used, then it applies to all tags which may be associated to a direction. This is how I understand and use it.From my understanding stops, give ways and traffic lights can be mapped the same way but editors (JOSM, iD) have implemented presets for those features at different point in time without feeling the need for consistency. I know that iD is currently doing the job of having a consistent behavior for those three features and that they might prefer (traffic_signals|stop|give_way):direction instead of direction (to be confirmed). They are also working to display the direction on the node on the map.LeTopographeFouDe: t...@fitchdesign.comEnvoyé: 16 mars 2017 5:15 AMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: [Tagging] The direction=* tag  The “direction” tag [1] has different uses that seem disjoint to me.To specify the orientation (compass point or degrees from north) of an object (adit or cave entrance, etc.). To specify direction (clockwise/counterclockwise) around a roundabout (not sure why this is needed as it should be apparent from local laws or specified with a “_oneway_=yes”).To indicate the direction (forward/backward) a stop or yield (give way) sign has effect along a way.Oddly, that third use seems only for stop and yield signs but not for traffic signals where a “traffic_signals:direction=forward | backward” tag is to be used. However that seems to be the most used form [2]. Apparently some have figured that if we have “traffic_signals:direction” there should be “stop:direction” [3] and “give_way:direction” [4] tags.And other things where a direction like tag might be used, like roof aspect have their own tags (“roof:direction=*”) [5] which follow the syntax and semantics of the first definition of the “direction=*” tag.It seems to me that the first and the third definitions should be split into separate tags with the second definition deprecated.From a data consumer point of view, there may not be a conflict as map rendering is likely to only use the bearing definition while routing would use the forward/backward definition. Though I suppose that a really detailed map may wish to show the actual angle of a stop or yield sign as they are not necessarily exactly aligned with the traveled way. From a mapper’s point of view having totally different  meanings for a tag based on context seems confusing.Since the “forward” and “backward” values are most used, it may be reasonable to keep the third definition of that tag even though it is inconsistent with “traffic_signals:direction”.Should we come up with a new tag to replace the angle/aspect meaning of the “direction=*” tag? If so, what tag name would make sense.“Bearing” (some uses which seem to follow the first definition of “direction”) [6]“Aspect” a couple of instances in use but not clear to me what was intended. [7][8]Thoughts?[1] https://wiki.openstreetmap.org/wiki/Key:direction[2] https://taginfo.openstreetmap.org/keys/direction#values[3] https://taginfo.openstreetmap.org/keys/stop%3Adirection[4] https://taginfo.openstreetmap.org/keys/give_way%3Adirection[5] https://wiki.openstreetmap.org/wiki/Key:roof:direction[6] https://taginfo.openstreetmap.org/keys/bearing#values[7] https://taginfo.openstreetmap.org/keys/Aspect#values[8] https://taginfo.openstreetmap.org/keys/aspect#values___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The direction=* tag

[Zecke]

Am 16.03.2017 05:13, schrieb Tod Fitch:
It seems to me that the first and the third definitions should be 
split into separate tags with the second definition deprecated.
I agree that this situation is suboptimal. The second meaning has 
nothing to do with a direction but with a sense of rotation. So, I agree 
it should be dropped first, if any.


Since the “forward” and “backward” values are most used, it may be 
reasonable to keep the third definition of that tag even though it is 
inconsistent with “traffic_signals:direction”.
I don't agree. The uses of direction for forward/backward are in the 
same magnitude of order as for compass directions. A factor of 2 is not 
relevant. Both uses have their tradition and they are not likely to be 
mixed. The compass thing has more of an absolute direction than the 
forward/backward one, as it only specifies a binary feature relative to 
another oriented feature.


Best regards,
Carsten
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] The direction=* tag

[Tod Fitch]

The “direction” tag [1] has different uses that seem disjoint to me.
To specify the orientation (compass point or degrees from north) of an object 
(adit or cave entrance, etc.). 
To specify direction (clockwise/counterclockwise) around a roundabout (not sure 
why this is needed as it should be apparent from local laws or specified with a 
“oneway=yes”).
To indicate the direction (forward/backward) a stop or yield (give way) sign 
has effect along a way.
Oddly, that third use seems only for stop and yield signs but not for traffic 
signals where a “traffic_signals:direction=forward | backward” tag is to be 
used. However that seems to be the most used form [2]. Apparently some have 
figured that if we have “traffic_signals:direction” there should be 
“stop:direction” [3] and “give_way:direction” [4] tags.

And other things where a direction like tag might be used, like roof aspect 
have their own tags (“roof:direction=*”) [5] which follow the syntax and 
semantics of the first definition of the “direction=*” tag.

It seems to me that the first and the third definitions should be split into 
separate tags with the second definition deprecated.

From a data consumer point of view, there may not be a conflict as map 
rendering is likely to only use the bearing definition while routing would use 
the forward/backward definition. Though I suppose that a really detailed map 
may wish to show the actual angle of a stop or yield sign as they are not 
necessarily exactly aligned with the traveled way. From a mapper’s point of 
view having totally different  meanings for a tag based on context seems 
confusing.

Since the “forward” and “backward” values are most used, it may be reasonable 
to keep the third definition of that tag even though it is inconsistent with 
“traffic_signals:direction”.

Should we come up with a new tag to replace the angle/aspect meaning of the 
“direction=*” tag? If so, what tag name would make sense.
“Bearing” (some uses which seem to follow the first definition of “direction”) 
[6]
“Aspect” a couple of instances in use but not clear to me what was intended. 
[7][8]
Thoughts?

[1] https://wiki.openstreetmap.org/wiki/Key:direction
[2] https://taginfo.openstreetmap.org/keys/direction#values
[3] https://taginfo.openstreetmap.org/keys/stop%3Adirection
[4] https://taginfo.openstreetmap.org/keys/give_way%3Adirection
[5] https://wiki.openstreetmap.org/wiki/Key:roof:direction
[6] https://taginfo.openstreetmap.org/keys/bearing#values
[7] https://taginfo.openstreetmap.org/keys/Aspect#values
[8] https://taginfo.openstreetmap.org/keys/aspect#values





smime.p7s
Description: S/MIME cryptographic signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging