Proposal talk:Destination details

Please add to the discussion using the Add Topic button above. Keep discussions succinct, try to stay on topic, and mark finished conversations with {{Resolved}} and related templates.

Associating destination to ref

Supposing a road junction where 2 road signs with destination:ref=Exx tags lead in different directions to different entrances of the Exx motorway, e.g. northbound and southbound. In addition to "Exx", the GPS software must obviously tell to the driver the "city" written next to Exx to determine which of the 2 roads to take. How can it know which city is written next to each Exx (each road may contain destination=city1;city2,...;cityn of which some not related to Exx)? --Papou (talk) 08:24, 26 September 2014 (UTC)

Syntax diagram needed

If they are sub-keys, must we write destination:ref:forward=* or destination:forward:ref=* ?
Not specifying this will lead to chaos.
More generally, the whole syntax must be defined with a full diagram, not just by examples.
Something like a completed destination[:ref|:country][:forward]=*
--Papou (talk) 22:31, 11 September 2014 (UTC)

I strongly support this. There are a lot of tags with a wrong order of parts in the key, e.g. destination:lanes:lang:XY instead of destination:lang:XY:lanes
--Mueschel (talk) 12:35, 14 March 2015 (UTC)

The suffixes :forward and :backward are always suffixes to the whole key, i.e. it is destination:ref:forward. This is the same as for all the other keys that might be suffixed with :forward and :backward. --Imagic (talk) 07:49, 17 March 2015 (UTC)

Just want to add the full list of subkey and suffix orders here. Almost all entries in the database right now follow this scheme.

 destination  [:subkey]  [:hgv|:bicycle|...]  [:lanes]  [:forward|:backward|:both_ways]  [:conditional]  [:start|:end] =*

--Mueschel (talk) 19:41, 21 December 2017 (UTC)

Lane-dependent destination tags on a node (on a one way)

Resolved

What about adding the lane-dependent tags on a node directly where the signpost is? Then we gain the information where the signpost is and e.g. navigational devices could present you with some graphical representation of it. For the photo in the Rationale section this would be:

 destination:lanes=Brno;Poysdorf;Mistelbach|Brno;Poysdorf;Mistelbach;Graz;Wien|Graz;Wien
 destination:ref:lanes=A5|A5;S1;A2|S1;A2
 destination:country:lanes=CZ|CZ;SK;HU;SI;IT|SK;HU;SI;IT
 destination:sign:lanes=none|airport|airport

Maybe we should also add another tag to indicate the presence of a signpost? --Imagic 09:45, 19 October 2012 (BST)

After some tagging and thinking I came to the conclusion that this is neither a good idea nor necessary. A node on a one-way might(!) work but as soon as someone connects another way to that node the tagging is ambiguous -> too fragile. And furthermore it is not necessary: the signpost has to be right at the beginning where the destination:lanes tagging starts, because that's the way it should be tagged. Therefore we already have the information where the signpost is. --Imagic 07:33, 22 October 2012 (BST)

Destination:ref versus Destination_ref and dest_ref

Resolved: Tagging has already moved to destination:ref --Imagic 15:36, 20 January 2013 (UTC)

Following the destination key type of tagging (fully written + a colon) I prefer destination:ref. Change management will be easy by applying a bot for destination_ref and dest_ref

I'm not a friend of bots, I prefer "manual bots" ;-) That's also what I'm doing right now: changing all my tagging (that I remember) to destination:ref . Takes some time but at the same time I have the opportunity to verify and in some cases fix/improve the tagging. --Imagic 07:36, 22 October 2012 (BST)

destination:sign=train_terminal

Resolved: Value changed to railroad_freight_terminal

I'm a little hesitant to use train_terminal. As I understand it, it is an end station, which excludes all other stations. I suggest changing it to train_station. --Magol 09:52, 25 October 2012 (BST)

A train terminal is a special train station where freight is unloaded from trucks and loaded onto a train or vice versa. It is not a train station for people. I will add a clarifying note. Thanks for pointing that out. --Imagic 10:02, 25 October 2012 (BST)

Then it was just me who misunderstood. The problem is that maybe more people will misunderstand. According to Wikipedia, a train terminal is just a train station located at the end of a railway. It says nothing that has to do with goods. I understand how you think, but I'm just worried that it will be used wrong. Maybe we can use train_freight_terminal? --Magol 12:06, 25 October 2012 (BST)

After some research I changed the value to railroad_freight_terminal. --Imagic 14:35, 25 October 2012 (BST)

AFAIK railroad is American English. British (what we use in OSM) is railway.--Geogast (talk) 11:29, 22 November 2014 (UTC)

destination:sign:name

Resolved: See section on photorealistic signpost view below for alternate solution

The destination:sign might have a name. How would any routing engine know the name of that destination sign? The tag destination:sign:name might solve this problem for the routing engine. It would look like this

destination:sign=ferry
destination:sign:name=Engeland

--It's so funny 22:42, 25 oktober 2012 (BST)

With this method you would need to tag England twice.

destination=England
destination:sign=ferry
destination:sign:name=England

But I do not know what to do instead. You have at least right that it in any way are needed. --Magol 16:32, 26 October 2012 (BST)

Good point. To avoid this redundancy I think destination=Engeland can be omitted in this case. Any routing engine will have enough information available with the two other tags (destination:sign and destination:sign:name)

Actually that was not the way I intented it. I thought this way:

All names of places/roads/etc. into destination resp. destination:lang
All countries into destination:country
All references into destination:ref
All signs/icons into destination:sign

I don't think that putting names into two separate tags is a good idea. It will take a while for apps to support at least some of the tags. If we create to much tags I'm afraid even less will be supported. --Imagic 16:45, 27 October 2012 (UTC)

After some thinking: I think it's good to split data and information based on that data. Data is stored in OSM. In the future users will have the flexibility to choose what they like: no viewing of signposts, little information of signposts or photorealistic information on signposts. All based on data in OSM. A routing engine can't guess the connection between a sign and the name of the sign (you need a photo of the signpost for that) , so the tagging should be good enough to connect the sign and the name. However, there are several solutions to achieve that, see the section on photorealistic signpost view. --It's so funny 21:22, 15 December 2012 (UTC)

destination:ref

Resolved

Current description: "The key destination:ref=* should be used to specify the reference of the road ahead. The value of this key should be equal to the value of the key ref=* of that road ".

In the example with the image A2 is included, but it is not directly the road ahead (this is only the S1).

If adding the A2 to destination:ref is intentional, then the text should be: "The key destination:ref=* should be used to specify the reference of the sign-posted roads ahead. The value of this key should be equal to the value of the key ref=* of these roads ".--Martinq 19:30, 26 October 2012 (BST)

Good point. I updated the defintion. Thanks for pointing out. --Imagic 16:48, 27 October 2012 (UTC)

Should international references like E-numbers be put into destination:int_ref?

Resolved: The key destination:int_ref is now part of the proposal. --Imagic 15:38, 20 January 2013 (UTC)

Please keep E-route numbers out of destination:ref - they don't belong in ref=* but in int_ref=*, so by extrapolation they should be in destination:int_ref. In most countries I know the E-route numbers are not used colloquially (although in Belgium they do often take precedence over the national A-numbers) and in some countries (such as UK) they are not signposted at all, although several E-routes pass through the country. By keeping them separate, data consumers (e.g. mkgmap) have the choice what to present. --Csmale 18:46, 11 December 2012 (UTC)

If the E-route numbers are not signposted at all, they should not be included in destination:ref (or any other destination-key), as only signposted information should be put into destination-keys.

Regarding destination:int_ref: I would like to hear some more opinions on this. You definitively have a point there, but I'm not sure if we should create so many subkeys. I will put a note pointing to this discussion on the proposals page and hope we get some more opinions. Thanks! --Imagic 13:54, 12 December 2012 (UTC)

After some thinking: I think it's good to split data and information based on that data. Data is stored in OSM. In the future users will have the flexibility to choose what they like: no viewing of signposts, little information of signposts or photorealistic information on signposts. All based on data in OSM. A routing engine does not have to guess the E-road numbering: it always starts with an E. So for data reasons it is not necessary to use destination:int_ref. However, I agree that separating data by different (sub)tags is easier for data consumers (like the mentioned example mkgmap), so it's fine for me to use destination:int_ref. Note that all other values (like N..., B...) will be included in destination:ref. --It's so funny 21:22, 15 December 2012 (UTC)

Do we need a destination:network?

If destination:ref is to "be equal to the value of the key ref", which in turn is meant to hold the number or code of the road, what identifies the network to which the number or code belongs? Do we need destination:network to express the network to which the number or code belongs?

According to the Australian Tagging Guidelines, the number or code shown on the sign is what is put into key ref, and a mnemonic for the road network is put into key network. For example, state route 13 is expressed as ref=13 and network=S, whereas national route 1 is expressed as ref=1 and network=NR. Even though the national highway system is being phased out (see here), there are apparently still plenty of network=NH and ref=* signs on the ground. Right now, I cannot reliably map the route number of destinations. --S2374 (talk) 22:37, 24 April 2016 (UTC)

destination:symbol instead of destination:sign

Resolved: destination:sign=* was changed to destination:symbol=*

There might be confusion about the word sign. A traffic sign (DE: wegweiser) is a complete sign which contains arrows, destinations and symbols. It might be better to use destination:symbol to avoid confusion. See also this UK page. --It's so funny 23:44, 19 december 2012 (BST)

+1 for destination:symbol . The word "sign" is used for the whole sign also at traffic_sign=* and Relation:destination_sign --Klumbumbus (talk) 17:54, 13 June 2014 (UTC)

+1 for destination:symbol. It will cause much less confusion StellanL (talk) 21:57, 7 July 2014 (UTC)

destination:sign=* was changed to destination:symbol=* --Imagic (talk) 07:15, 9 July 2014 (UTC)

Photorealistic signpost view

Imagine the situation, somewhere in the (hopefully not too far away) future, that users of navigation apps based on Openstreetmap have the chance to select for themselves:

a) if they want a signpost to be shown on their smartphone

b) at which distance from the junction it should be shown and

c) what data should be included from the signpost to provide the level of information they like for optimal navigating.

The maximum level for c) is (near) photorealistic. So, ideally the tagging should be designed on that. For (near) photorealistic view, some problems need to be solved:

How to connect the symbol to the name of the symbol

The destinations should be written from top to bottom of the signpost. So the position of the symbol relating to the name is enough to connect the symbol to the name of the symbol. That could be a tag like this: destination:symbol=none;none;commercial.

In Belgium it is quite common to have multiple names next to one another, so it should be top-bottom left-right. But in some countries (Japan ?) it might be better to have bottom-top, right-left An example from Belgium (couldn't find one on wikimedia, and don't have one myself): [[1]] --Escada (talk) 08:13, 9 July 2014 (UTC)

Here is a left/right bidirectional example from Belgium ;-) [[2]] --Papou (talk) 23:10, 11 September 2014 (UTC)

How to get colours in

For the colours of the background per destination the same method can be used, which would look like this: destination:colour=none;none;white The background colour of the signpost is country-specific, so a separate tag for that shouldn't be necessary. --It's so funny 21:22, 15 December 2012 (UTC)

I added a subsection for destination:colour. --Jojo4u (talk) 09:52, 28 January 2015 (UTC)

Tool

OsmLaneVisualizer renders photorealistic sign posts. From this proposal it supports destination, destination:ref, destination:symbol, destination:colour all with :lanes extension. (status january 2015)--Jojo4u (talk) 09:52, 28 January 2015 (UTC)

destination_sign relation

Is there any connection to the Relation:destination_sign? Both proposed tags and the relation mark the same thing basically. Can they be merged — by making the relation optional in most cases (on regular roads), or by using it to label exits? --Zverik (talk) 09:34, 9 July 2014 (UTC)

No, no connection at all. In my opinion the relation is another good example - as many can be found in OSM - of theoretical perfectness: tries to cover all but is just too complex for wide use. I used the relation for maybe five times and then switched to the destination tag. My brain tells me "this way leads to xyz" and that's just the way I want to tag this. Of course I fully agree with you, that the relation covers more information in a more processing-friendly manner. But that's just not the way OSM works, at least not in my perception. --Imagic (talk) 07:01, 10 July 2014 (UTC)

But joining different destinations with ";" created unobvious relations between tags, while the relation only needs a node and a way, and there can be many relations, one for each line. Also proposed tags won't work on two-way roads (or will, but with awful ":forward/:backward"). But I understand that I basically propose to deprecate already widely used tags — so maybe we should instead limit their usage: e.g. only on motorway junctions, which are oneway and span no longer than from one motorway to another or to another junction way. --Zverik (talk) 10:32, 10 July 2014 (UTC)

I'm not quite sure what you mean. If the way leads to A and to B, then we use destination=A;B. Where's the problem? If I want to express this with the relation, I have to create two relations. With the relation I could offer more detailed information, e.g. that the signpost for "A" has green background and that for "B" red, but the additional effort of using the relation just doesn't justify the additional information provided by it, at least not for me. And I'm sorry to say: I regularly use destination:forward/:backward.

Don't get me wrong: the relation is a good idea and well specified. I also try to support it in the JOSM style (which is near to impossible, by the way). But I doubt that I will ever use if for tagging again. --Imagic (talk) 14:04, 10 July 2014 (UTC)

Status

What is the status of this proposal? I like the destination:ref=* specifically, and it seems to be in wide use already. And there are no outstanding issues. Martijn van Exel (talk) 17:38, 9 July 2014 (UTC)

It is proposed. And it will stay this way. Simply use the keys and be happy. --Imagic (talk) 06:41, 10 July 2014 (UTC)

add camp_site symbol

Resolved

`destination:symbol=camp_site`		a camp_site.

--Klumbumbus (talk) 17:37, 14 July 2014 (UTC)

add ferry in the symbol table below harbour

Resolved

it is already used in one example

`destination:symbol=ferry`		a pier for ferries

--Klumbumbus (talk) 17:37, 14 July 2014 (UTC)

add soccer_stadium in the symbol table

Resolved

it is already used in one example

`destination:symbol=soccer_stadium`		a soccer stadium.

--Klumbumbus (talk) 18:07, 14 July 2014 (UTC)

add stadium in the symbol table

Resolved

`destination:symbol=stadium`		a stadium.

--Klumbumbus (talk) 19:16, 14 July 2014 (UTC)

add toilets in the symbol table

Resolved

`destination:symbol=toilets`		toilets.

--Klumbumbus (talk) 18:11, 14 July 2014 (UTC)

This recalls me my GPS in my bag in a shop: "please make a U-turn when possible".

Will it soon be a loud: "toilets are in second alley left"? --Papou (talk) 23:26, 11 September 2014 (UTC)

additions for the symbol table

museum, sports center (3 rings), Swimming pool, see http://xian.smugmug.com/OSM/OSM-2014/20140804-Duffel/i-56QTXZ4/A --Escada (talk) 11:06, 8 August 2014 (UTC)

a preformatted table with a symbol would help (like Klumbumbus).--Jojo4u (talk) 10:08, 28 January 2015 (UTC)

change "the next" to "a"

Resolved

In the table of destination symbols I think we should better write "a..." instead of "the next..." because it is not always the next one, but maybe an important one or a special one --Klumbumbus (talk) 19:26, 14 July 2014 (UTC)

destination:country

The proposal advises to use ISO country codes. Nevertheless, on all signs I'm aware of, license plate country codes are used as can be seen on the first picture in the proposal (SLO instead of SI, I instead of IT). I'd prefer to use these codes instead of the ISO ones. Most use cases of destination tagging relate to visual aid for the user and less as support for software applications (e.g. routing engines). To the user it's more helpful to know what is actually shown on the signpost. --Mueschel (talk) 14:33, 31 January 2015 (UTC)

Makes sense, these are called international licence plate country codes and are published by the UN as DISTINGUISHING SIGNS USED ON VEHICLES IN INTERNATIONAL TRAFFIC.--Jojo4u (talk) 15:52, 31 January 2015 (UTC)

Thanks. Updated accordingly. --Imagic (talk) 11:45, 1 February 2015 (UTC)

Different destinations = different subkeys and values

For a some systems, and clarify multiple values, for every different destination we wish a different subkey as destination:a,destination:b... or destination:1,destination:2... in order that shows real traffic sign or in order of distance, importance, whatever community decides. I propose destination:1 in order that shows real traffic sign.

Who is "we"? Variable keys in general are bad practice as they are hard to search for in the database - one needs to do an expensive search based on regular expressions as compared to simple, index-based queries. Also, there is nothing wrong with lists of values separated with semicolon, these can be interpreted without ambiguity. --Mueschel (talk) 13:53, 24 January 2016 (UTC)

We are some people in some projects we need exact information, not multiple information (i.e. try to build a style show two values in the same key.) Variable keys help to order correctly and "understand" exactly the values,because they are not variable really, they are unique: traffic_sign:1 and traffic_sign:2 are not the same key, [ES:p4];[ES:r1] are from the same value. Simple keys are easy using multivalues, with complex keys there's so much information for one node so it is important to make a good structure.Multivalues are more problematic than ordered keys in taht case, isn't? --yopaseopor (talk) 14:12, 24 January 2016 (UTC)

destination=* keys list destinations in the order they appear on a sign (or on writing on the pavement). If a sign has 'Munich' and 'Zurich' listed on the sign with 'Munich' listed first, the destination tag will contain 'destination=Munich;Zurich' . To put this another way, "the community already has determined the order in which semicolon-separated destinations appear, and it is: the order in which they appear on the sign or markings that indicate it." It does however assume one single sign - or at least, a sign that is identical in all inbound directions to the intersection.

That said, you may be pointing out 'But, two different signs at the same intersection may not be identical.' That is a flaw inherent to destination=* key implementation. The solution in that case is to parse destination_sign relations, which removes this ambiguity. Skybunny (talk) 02:13, 26 January 2016 (UTC)

Have you read Semi colon wiki's article ? In the article says : "When NOT to use. In general avoid ';' separated values whenever possible. Don't use them in your mapping, and don't propose them on the wiki if there are better ways of representing things. This is because use of semi-colons as value separators is contrary to the aim of keeping it simple both for data contributors (mappers) and data users. For the sake of new contributors and anyone trying to use the data (people building software for rendering, searching, "find my nearest cafe" mobile apps, etc) we should minimise use of values with special characters."

Split the element Separate things out into distinct features to allow them to be tagged separately with normal tags. Example: You're mapping a library which has a cafe inside it. Place a node for the cafe, and then either represent the library (a larger building) as an area instead, or just as a separate node. It is not a good idea to map it as amenity=library;cafe << I don't know why is a bad idea to use this but it is a good idea to put two destinations at the same key

Also in Good Practise you can read "Don't over-use semi-colon separated values.Semi-colon value separator characters can be introduced into values, where the same key needs to take multiple values. This can be useful for putting lists of values into certain type of minor attribute tags, however it should be avoided in more important top-level tags. In general these special characters should not be over-used, since they detract from the simplicity of the tagging system."

I don't understand why we are trying to do the opposite to what OSM wiki says.Variable keys for each destination (in order with numbers or with letters) can be the solution for this bad practise... --yopaseopor (talk) 17:51, 26 January 2016 (UTC)

The first page you mention does not reflect the opinion of all mappers, that's just very few. The second one: Please read carefully "in important top-level tags", e.g. it should not be used in things like building=* or highway=*. This is essentially because these tags can have only one value and not several in parallel. In tags like destination=* a list of values is perfectly fine as one destination doesn't forbid to have a second or third one. --Mueschel (talk) 18:30, 26 January 2016 (UTC)

If the first page does not reflect the "correct opinion" of the OSM community (why is here?) it should be erased from the wiki, because this can get the people like me to a big error...but the second page refrends the first page. For me destination is not a minor tag, because is so important, and the order and the correspondence are so important. Because little town is not more important than Capital City and the system should reflect that (as the reality does).with numbers or letters you can make an exact correspondence because destination:1(or a) is for 1 and destination:2 is for the second item. Some systems can say destination is "1and2". For simple tags is easy and it is good , for a list with two items, well, we can understand it, but in destination you can have up to three or four things it's very difficult.Also in some countries destinations are written in paralel. In which order do we have to put it? Vertically? Horizontally? With numbers, there's no problems.Also solutions with an easy way first discussion of this page because it establishes a direct correspondence between differents tags --yopaseopor (talk) 19:49, 26 January 2016 (UTC)

Semi-colon are only a problem when you want to further specify the value, e.g. amenity=hotel;restaurant causes problems when you want to specify e.g. opening hours. There is no problem for tags such as cuisine=chinese;japanese or for destination. As for your example with names written in parallel, how do numbers solve that ? Do I count first from top to bottom or left to right ?

Semi-colons are also used in e.g. the lane tagging without problems. Semi-colons are a problem when the name of your destination would contain a semi-colon, that's true. Keep in mind that there are already apps supporting the semi-colon approach for destinations. You will break them by changing the tagging scheme

add "aerialway" in the symbol table

Resolved

I have seen many "aerialway" symbols on the roads (also on exits of motorways) in Tirol and Vorarlberg (AT). This is an example I've found on the internet: https://commons.wikimedia.org/wiki/File:Pictogram_Cable_Car_small.svg

In Austria this sign has a green background.

Resolved and added symbols--Caboosey (talk) 01:56, 29 July 2016 (UTC)

destination:symbol with multiple symbol on one destination

Like the exemple destination:symbol=none;none;commercial;none;none we can have commercial and parking symbol at the same time. What to use? destination:symbol=none;none;(commercial;parking);none;none? -Yod4z (talk) 18:01, 3 November 2016 (UTC)