Poll about tagging scheme for destination restrictions

General talk Tagging general discussion
, , , ,
1

Hello, there!

I’m currently drafting a proposal about destination restrictions, i.e. restrictions displayed on destination signs, which warn in advance the driver which restrictions (s)he will (likely) encounter if (s)he tries to reach a destination following a given highway, such as the second symbol on this image:

grafik
grafik300×220 16.5 KB

This second ideogram, for the record, warns the driver that turning right in order to reach Nancy or Lunéville will likely bring him/her to a hazmat:water=no restriction. Depending on local customs and regulations, the restriction itself may or may not exist; in the second case, displaying it on the destination sign may simply be a mean to discourage some vehicles to use the pointed highway.

As for any traffic sign, I see basically 2 possible ways to tag such ideograms:

  1. with human-readable values, or
  2. with traffic sign IDs.

What could it look like for this sign?

Design principles

In order to not reinvent the wheel by creating a third tagging scheme besides of the two already existing ones, I designed two possible tagging schemes for such ideograms, which as must as possible reuse the current restriction/traffic sign tagging schemes.

Human-readable values (concept option 1)

destination:ref=N 4
destination:colour=blue;blue;green;green
destination=Nancy;Lunéville;Blâmont;Sarrebourg
destination:symbol=motorway,hazmat:water;motorway,hazmat:water;;
destination:hazmat:water=no;no;;

Traffic sign IDs (concept option 2)

destination:ref=N 4
destination:colour=blue;blue;green;green
destination=Nancy;Lunéville;Blâmont;Sarrebourg
destination:symbol=motorway,FR:SI11,;motorway,FR:SI11;;

The details of each tagging scheme would be explained later, in time for the RFC; the proposal is currently not ready for RFC. These are only concept tagging; details may evolve later according to comments and arguments made here.

Given the exact details are worked out, explained and consistent, what tagging scheme option would you support, if any?

  • I would only support option 1.
  • I would support option 1, but could deal with option 2.
  • I would support any of the two options.
  • I would support option 2, but could deal with option 1.
  • I would only support option 2.
0 voters

This is only a poll. I can work out the detailed tagging scheme for any of the 2 options, and am not willing to counter the poll results, but I would prefer not to dedicate time drafting a proposal for one of these tagging schemes, and then figure out that the community could not deal with it or would prefer the other one.

I invite you to explain your preference below, in order to help me to work out the details of the preferred tagging scheme. Repeat: these tagging proposals are only tagging concepts; they are not final. The poll is on the concept itself, on the human-readable vs traffic sign ID question.

Edit: better explained the goal of the poll, improved concept 1 after some smart remarks.

2

I don’t like all the arbitrary destination:symbol= being invented, preferring such destination:*= corresponding to the usual *=
Mixing words and id is a whole debate that should be avoided cf traffic_sign:id= (forgot what’s the conclusion)
However, destination:*=symbol,hazmat:water;symbol,hazmat:water;; seems redundant, and detached. I’m fine with destination:symbol=motorway,hazmat:water;motorway,hazmat:water;; to be specified by destination:hazmat:water=no;no;; for the content.

1 Like
3

Hey, didn’t think about this; thanks! :star_struck:

4

I would suggest destination:hazmat:water=no (you are heading towards a hazmat:water=no) and/or destination:traffic_sign=FR:SI11 (you are heading towards a traffic_sign=FR:SI11).

1 Like
5

@JeroenvanderGun @Kovoschiz I’m unsure to understand your comments: do they imply you have a preference between the proposed options? If so, would you mind casting a vote in the poll? :face_holding_back_tears: :sweat_smile:

Sorry to ask, but I often have trouble with implicit things…

6

To clarify:

  • destination:hazmat:water from option 1 looks good to me.
  • For option 2, I suggest replacing destination:symbol with destination:traffic_sign for the traffic sign code (the motorway symbol can remain in destination:symbol).
  • destination:ideogram_order, which you included in option 1, seems overkill to me: complex tagging for little benefit for sign rendering.
  • Combining both options is also fine with me (notwithstanding the above). This may help data consumers that don’t know the traffic sign codes.
2 Likes
7

  1. Why ‘hazmat:water’? The traffic sign is not for hazmat but banning hazmat. There needs to be a negation somewhere.
    I know destinations signs both explicitly for and against hgv.

  2. Why does the option 2 only have ids and not human readable names? I don’t like the separate ‘ideogram_order’ from the first option, but also don’t want to be restricted to sign ids.
    destination:symbol=motorway,no:hazmat:water,;motorway,no:hazmat:water;;

I wouldn’t do that, because you lose the information about the order (if it’s not a national standard).
I don’t see a problem with having “strange” values in the symbol tag - if a user doesn’t understand them, nothing bad happens if they simply ignore it.

8

The hazmat:water value means: here goes the ideogram described with destination:hazmat:water. In France, there is a similar ideogram saying basically destination designated for hazmat:water vehicles, giving only hazmat:water as a destination:symbol is not enough to describe this.

Basicall, to not duplicate the ideogram by giving both traffic sign ID and its meaning: that would clutter object tagging, and would quickly go out of sync if people edit the human-readable meaning and not the traffic sign ID, or the other way.

And why no human-readable value in option 2? Well, I did not see any convenient way to do so for more complex restriction ideograms such as this one:

grafik
grafik120×121 2.14 KB

In France, this destination ideogram means highway designated for goods vehicles longer than 10m which want to reach this destination. Describing this in a separate tag, then call this ideogram in the right order allows more readable symbol values, and prevents hitting the 255 char limit for values.

Think that there can be multiple ideograms like this one on a single destination sign: you can easily crash on the 255 char limit if you try to describe all the ideograms in a single value while keeping it human-readable.

Edit: clarified a sentence which did not reflect my opinion.

9

Please note that I slightly improved the tagging concepts of the first message, following remarks made in comments. Notably, I removed the destination:ideogram_order and merged it with destination:symbol.

As these are only tagging concepts, tagging philosophies could one say, whose essence is left untouched by my edit, this edit does not invalidate the poll.

Please also note that I’m not necessarily able to adresse all comments yet: to me, the goal of this topic is to choose between competing tagging concepts, and then elaborate the chosen one. I’ll later adress whatever concerns made on the chosen concept, but for now, I cannot cope with all comments made on both concepts. For now. :wink:

10

I agree with @mueschel , rather than water it should be something like water_endagering

11

For consistency, I would prefer to replace symbol=motorway by
destination:traffic_sign=FR:C207
I mean .
No manual edit of course except by some specialists!

I could also live with the other option (only “normal” tags), but it would be harder to find the right symbol (and the right condition).

Comparison of traffic signs

We have seen that the following traffic signs have a sightly different meaning (more thant just hgv=no) depending on country and the visual representation would be straightforward.

Allemagne Autriche Belgique Danemark Espagne Estonie Finlande France Grèce Hongrie Irlande Islande Italie Lettonie Luxembourg Moldavie Norvège Pays-Bas Pologne Portugal Roumanie Royaume-Uni Russie Serbie Slovaquie Slovénie Suède Suisse Tchéquie Turquie Ukraine
Accès interdit aux véhicules lourds marchandises
12

I used hazmat:water because, in the first tagging concept, existing tagging is reused as much as possible, and because this ideogram, as standalone traffic sign, would be tagged as the restriction hazmat:water=no.Why reinventing the wheel and use a brand new restriction tagging for this ideogram when it is used on destination signs? Particularly in the first tagging concept, which is precisely about reusing existing human-readable restriction tagging?

If I push a proposal, I would better make I usable by other people than just specialists, isn’t it? :sweat_smile: By the way, that is one of the pros of the first tagging concept.

13

On second thoughts, destination:hazmat:water= would collide with per-mode destinations similar to turn:*= (eg destination=Nancy;Lunéville;Blâmont;Sarrebourg + destination:hazmat:water=;;Blâmont;Sarrebourg ). destination:access:hazmat:water= would be better.
My preference is “I would support option 1B, but could start with option 2B”
1B

destination:symbol=motorway,hazmat:water;motorway,hazmat:water;;
destination:hazmat:water=no;no;;

2B

destination:symbol=motorway,traffic_sign,;motorway,traffic_sign;;
destination:traffic_sign=FR:SC17,FR:SI11,;FR:SC17,FR:SI11;;

Is this correct? File:France road sign SC17.svg - Wikimedia Commons
destination:symbol=traffic_sign is to mean the content is relegated to destination:traffic_sign=

14
  1. It’s the same as traffic_sign= documented =city_limit + city_limit=end , =maxspeed + maxspeed=implicit , and =overtaking + overtaking=no Key:traffic_sign - OpenStreetMap Wiki
  2. I’m thinking destination:symbol= is the synonym for human-readable destination:traffic_sign*= , or can be a shortcut
15

Precisely what I suggested in my first message (although after correction following your suggestion :sweat_smile:).

Would be technically correct, but that’s repeating the motorway symbol with its meaning in destination:symbol and its ID in destination:traffic_sign; these two tags would risk to quickly go out of sync if a contributor understand destination:symbol and not destination:traffic_sign (likely with novice contributors, I would say; the other way round seems more unlikely, although possible).

1 Like
16

I can only repeat my statement I made in the traffic_sign:id discussion:
Don’t double tag any single feature, don’t duplicate data in the database. The duality between ids and names must be taken into account by optimizing editor software and not by adding additional tags.

17

Then I’m confused by your “2. Why does the option 2 only have ids and not human readable names? I don’t like the separate ‘ideogram_order’ from the first option, but also don’t want to be restricted to sign ids.”

18

My intention was only to point out that the first option used only names and the second only ids. I prefer having the option to have both of these as valid tagging options:

destination:symbol=motorway,hgv_excluded;  motorway,hgv_designated;

destination:symbol=motorway,XX:256;  motorway,XX:356;

(That’s pseudo-values, please don’t take them literally)

19

I forgot my further suggestion

destination:symbol=motorway,hazmat:water;motorway,hazmat:water;;
destination:access:hazmat:water=no;no;;

or

destination:symbol=motorway,access:hazmat:water;motorway,access:hazmat:water;;
destination:access:hazmat:water=no;no;;

Synchronization is not a problem unique to here. Eg maybe forgetting to update wikidata= after changing name= to new version or proper entity, does that prevent using both?

20

And what if someone wants to use FR:SC17 instead of motorway ? Would it be allowed? As I said from start, this should be discussed together with the traffic_sign= logic.

1 Like