I am not saying these cases are impossible, only that they have to be
accommodated, preferably as uniformly as possible. It is not intended as
criticism, but as a critical test of fitness for purpose. If the tagging
scheme can't handle these real-world situations, it's not ready for
go-live yet.
On 2018-10-09 23:40, yo paseopor wrote:
> On Tue, Oct 9, 2018 at 8:16 PM Colin Smale <colin.sm...@xs4all.nl> wrote:
>
>> I can think of a couple of non-trivial cases which will need to be handled:
>>
>> 1) multiple signs on a single post
>
> As Finnish people do we can add subkey :2 :3 :4... (European regulations does
> nit recommend more than 3 traffic_signs together to make better their
> readibility.
This is of course a fairly easy one. What European regulations are you
referring to here by the way?
>> 2) signs with a dependent (qualifier) sign, such as "except for buses"
>
> Complementary signs are also traffic signs (in second, in third position)
> with its own code, so they need their information (the same osm tags we have
> for ways?) and position. A few weeks ago in this list I talk about the
> possible changes for "designation" value to make a key with this more
> specific information
How do you make the link between the qualifier and the main sign it
applies to? Does it only apply to the one sign immediately above? Or to
all signs above? Or the sign(s) below? How would these links work for
multiple qualifier signs, like "except for buses" / "except with
permit"?
>> 3) one or more signs on a larger panel - too large to represent as a node
>
> Sorry but I don't agree with you... because I test it...and it works. Example
> for a complete destination traffic sign
>
> COLOUR:ARROW
> black
>
> COLOUR:ARROW:LOWER_PANEL
> white
>
> COLOUR:BACK
> white
>
> COLOUR:BACK:LOWER_PANEL
> blue
>
> COLOUR:REF
> red
>
> COLOUR:REF:LOWER_PANEL
> blue
>
> COLOUR:TEXT
> white
>
> COLOUR:TEXT:LOWER_PANEL
> white
>
> DESTINATION:LOWER
> Coma-ruga
>
> DESTINATION:LOWER_PANEL
> Barcelona
>
> DESTINATION:LOWER_PANEL:LOWER
> Aeroport
>
> DESTINATION:LOWER_PANEL:UPPER
> Vilanova i la Geltrú
>
> DESTINATION:SYMBOL:LOWER_PANEL:LOWER
> airport
>
> DESTINATION:UPPER
> El Vendrell
>
> LENGTH [1]
> 500
>
> REF [2]
> N-340
>
> REF:LOWER_PANEL
> C-32
>
> SIDE
> up
>
> TIME:1
> 00:05
>
> TIME:3
> 00:05
>
> TIME:B
> 01:00
>
> TIME:B:1
> 00:20
>
> TIME:B:3
> 00:45
>
> TRAFFIC_SIGN:2:FORWARD
> ES:S235a
>
> TRAFFIC_SIGN:FORWARD
> ES:S235a
>
> TURN:DESTINATION
> under
>
> TURN:DESTINATION:LOWER_PANEL
> under
>
> TYPE [3]
> destination_sign
How does anyone or anything (a data consumer) connect the
"traffic_sign:forward=ES:S235a" to the way that it applies to? Not all
junctions are nice 4-way 90-degree junctions. What have you "tested"
exactly? Where do you place the node for this sign in relation to the
way? Maybe if you could give a link or an exact location of this sign,
then we could have a look and see what you intend.
>> 4) signs applying only to certain lanes
>
> you can specify the lanes and the exact information with all these tags
> (lanes scheme already exists)
Of course the lanes scheme exists, but it is currently applied to ways.
Should we indicate a bus lane by a node representing the sign, or as an
attribute of the way? Surely not as both. No trucks in the left hand
lane? Easy to tag on the way with lanes tagging, but what about the
sign, which might also say "buses only in the second lane except on
Tuesday" etc etc. I am not trying to be difficult here - these crazy
scenarios really do occur, and OSM needs to be able to deal with them.
You are suggesting encoding this information as tagging on a single
node; I think that's a challenge if you expect anyone/anything to be
able to interpret it properly.
>> 5) signs on a gantry above (half of) the road
>
> The example above is like the granty sign (with the same tags)
Is a gantry tagged as a single node, or a "way" crossing the highway?
The gantry may cross the entire highway, but the signs are only in one
direction. How to handle that?
>> I can understand the argument for mapping the signs as objects in their own
>> right. This would be limited to being a database of street furniture, unless
>> and until the effect of the signs can be linked to the effect they have on
>> traffic (in the broadest sense), which is the starting point for the present
>> discussion. This is of course a serious exercise to ensure the link from the
>> sign to the effect is represented unambiguously.
>
> Barrier nodes acts in routing, why not the prohibition in overtaking? or the
> city limit? or the warnings?
Indeed, but we are talking about traffic signs here. How would you
propose to
>> We already have turn restrictions, maxspeed, maxheight etc on the ways
>> themselves (without needing to have any link to a sign). This model works
>> reasonably well for routing applications, albeit not without some discussion
>> about the types of "weight" and so on.
>
> Signs are a next level for routing, for GPS software. Why Street View cars
> and software wants to recognize traffic signs? Why don't you have the
> possibility to have the traffic signs recreated in your own screen, with only
> OSM data in a node?
I have experienced traffic sign recognition (in a recent BMW) and I
wasn't very impressed. The signs are not used for real navigation, only
for information. The routing is done in the old-fashioned way. Traffic
sign recognition can only ever be an additional source of hints, and
cannot be relied upon as the only basis for routing decisions.
>> The point I am trying to make, is that there might not be much of a
>> "business case" for linking the signs/posts to their effects, and that
>> mapping them as "street furniture" might be going far enough...
>
> More than 30 countries, more than 24000 different traffic signs. In each
> country with their own traffic signs...why not? Are street lamps important?
> Are recycle bins important? Are Benchs important?
Important is not the right word here, that's too subjective. I am making
the assumption that you are thinking of being able to use the traffic
sign information for routing. Maybe that assumption is wrong, I am not
sure any more. But for the foreseeable future routing will be
graph-based, which means understanding the attributes that apply to way
segments and junctions. The current model is workable - there are many
examples of routing based on OSM data. I assume you want the routers to
be able to understand the traffic sign information, to reduce the
necessity for redundant information in OSM.
Links:
------
[1] https://wiki.openstreetmap.org/wiki/Key:length?uselang=en
[2] https://wiki.openstreetmap.org/wiki/Key:ref?uselang=en
[3] https://wiki.openstreetmap.org/wiki/Key:type?uselang=en
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
