User talk:Mueschel/DestinationTagging

How is the "colour computing" done?

[Here] you say "[...] there is no need to tag this as it can be computed from the ref or symbol." When i watch the lane visualizer for w39609218 then the colour of the right lane is yellow insteed of blue . Any idea?--MalgiK (talk) 09:13, 3 November 2019 (UTC)

I suggest to have these software-specific questions in the issue tracker of GitHub.

The lane visualizer doesn't support Austrian signs (see the drop-down menu in the upper left), it tries to make sense of the sign using the German style and fails. There is a new tool available that is supposed to draw nicer signs: destinations. It has an Austrian style, but doesn't display destination:country yet.

Btw, I suggest to move A2 and Graz to destination:ref:to and destination:to - A2 can't be reached directly, but only after a longer drive. --Mueschel (talk) 09:39, 3 November 2019 (UTC)

Destinations (following tagging ML discussion)

Hello, Mueschel.

I'm following the discussion about destinations on the tagging ML — I contact you here because, for some reason, I'm not receiving your contributions on the ML. About the mess in the wiki pages about destinations, I'm thinking about creating a One-page-to-rule-them-all about destinations; something brand new, which would synthetize the current tagging practices about destinations. That would take a while to create it, and I'm not sure I can complete it, but I think I'll try, by creating a WIP user page with a rough draft, then asking opinions on the ML and synthetize them, then publishing the result in the general Wiki pages. What to do about the current pages — key/values pages excluded — is to be established, as some of them, but not all, will show outdated or incomplete. The rough draft would be based upon the current Wiki pages, what I know about tagging practices, the current discussion about this matter on the tagging ML and this page about current practices. What do you think of this project?

I noticed your lane visualizer tool; nice work. I may create a pull request to adapt it to FR rules, but that's unsure too.

Regards. --Penegal (talk) 16:48, 2 August 2020 (UTC)

Hi Penegal,

If you want to update the Wiki, I'm happy to support this. Let me know if you have anything to discuss / extent / proof read!

Please don't put too much effort into the Lane Visualizer, I don't want to support the current destination sign display there any more. It is planned to be replaced by the one I use on [1]. There is no French style either. If you can provide me with some rules how to draw signs, I'm happy to implement them.

Mueschel,

Tell me what you need for the French style and I'd be glad to give it to you. As a first guess, I think you need to know the colour code for ref signs; they are coloured according to the first letter of the ref=* tag (black font over white background being the default):

• A 12 (highway=motorway), N 12, E 12 (such values are supposed to be tagged as int_ref=E 12), D 12, C 12, R 12, F 12, M 12, T 12, P 12
  • Done.

By default :

• destination signs are written in black over white, but it is white over green for important destinations — rules are available, but are probably way too complicated for a program —, and white over blue when the destination is reachable by motorway — may be guessed by a program, I'm unsure about this one ;
  • Guessing might be too difficult and requires a database of cities or a query for 'population' on place nodes. I suggest to simply add destination:colour=green for these.
• the [destination:][int_]ref signs are usually placed over the destinations, not under it ; the letter at the beginning of the ref is never dropped, it is always displayed ;
  • Done.
• when there are turn:lanes=*, the through arrow is down, not up ;
  • Done.
• when there are destination:to:lanes=* and destination:ref:to:lanes=*, for instance destination:to:lanes=Lyon;Chalons ˢ/ S.;Beaune| and destination:ref:to:lanes=A 31|, they are usually indicated using this format ;
  • A 31 is blue A 311 is red - why?
    • Because, in case of destination:ref=*, the reference given is the one of the next road, and is supposed to be of the right colour. It is displayed on what is named in French a cartouche, a little sign over the destinations, which follows the colour convention. On the other hand, in the case of destination:ref:to=*, the ref is not the one of the next road and is not displayed in a cartouche, hence does not follow the colour convention to prevent confusion with the cartouche. For instance, compare this picture with your display; you may also look at this picture and your modelling of it. You can see, in this last case, that I forgot something: when there are both destination:to=* and destination:ref:to=*, they are supposed to be displayed side by side, apart from the other refs, but the precise location on the signs cannot be guessed. Good idea to keep a blue background for destination:ref:to=A *, I forgot to tell you that it was displayed this way.
• when there are destination:to=* and destination:ref:to=*, for instance destination:to=Genève and destination:ref:to=A 41|, this format is used.

There are exceptions, of course, but the rules are these and you can safely assume they are applied, as it will give you a good display for roughly 99% of cases. If you need more informations or just testing, tell me precisely what you need; if this additional informations, I'll give them to you as an issue in your OsmDestinationSigns Github repo. —Penegal (talk) 08:54, 3 August 2020 (UTC)

I added the first set of rules today. It would be nice if you can give some examples (Tagged OSM way + image of the actual sign) of what is still wrong.

http://osm.mueschelsoft.de/destinations/example/#wayid=477273282&direction=0&country=FR - I have to think about how to get the exit lane in white colour by default - it's a bit tricky because I don't have the information where this lane leads to. --Mueschel (talk) 15:07, 8 August 2020 (UTC)

Also, if you like to split hairs, you can use the French symbols listed here. —Penegal (talk) 13:18, 10 August 2020 (UTC)

If you like, you can prepare this easily: Edit this file and provide the matching images. They all must be in the public domain / CC0, because I don't want to add license statements somewhere. --Mueschel (talk) 16:26, 13 August 2020 (UTC)

Example 2 "B 8" marker place

On real traffic sign the marker "B 8" only applies for through destinations. On the generated traffic sign by tagging sand box as well as in given tagging schema marker "B 8" applies for all destinations.

On my suggestion the tagging should be "destination:ref=B 8;B 8;;;" for a result as most similar to the real traffic sign. --Vanagaudi (talk) 23:10, 23 May 2025 (UTC)

That's right - tagging with a list of ref's is more precise. --Mueschel (talk) 10:51, 24 May 2025 (UTC)

I've found another solution for Destination Signs Tagging Sandbox:

Destination Sign by Destination Signs Tagging Sandbox

destination=;Hannover;Düsseldorf;Messegelände;Recklinghausen;Dormagen

destination:ref=B 8;;;;;

destination:colour=;;;white;;

destination:arrow=through;through;through;through;left;right

destination:distance=;145;123;;36;42

However, the distance tags presently are not working on the Destination Signs Tagging Sandbox.

But on OSM Lane Visualizer this tagging results in an unwanted presentation:

Destination Sign by OSM Lane Visualizer

The rules implemented in Destination Signs Tagging Sandbox are more convenient for mappers as they allow some more option how to place the reference number. If there is no destination name tag in first row, the reference number might be place below the destination arrow. In case there is a name tag for this destination, reference number will be placed left of destination name.

The OSM Lane Visualizer fails in case the reference number for through lanes are different from the lanes to left and/or right.

--Vanagaudi (talk) 19:30, 11 July 2025 (UTC)

Why to differentiate between destination =* and destination: to =*?

I'm looking for a good reason why to differentiate between destination=* and destination:to=*

To show the problem on destination:to=* I would like you to check following combination of tags:

destination=Nordstadt;Weststadt;Industriegebiet;Südautobahn;Oststadt
destination:arrow=through;left;left;right;right
destination:arrow:to=right
destination:colour=#F0E060;#F0E060;white;blue;#F0E060
destination:colour:to=blue
destination:ref=;B 17;;A 35;B 17
destination:ref:to=A 34
destination:symbol=;;industrial;motorway;
destination:symbol:to=motorway
destination:to=Nordautobahn

The destination:*:to=* tags are always placed on the top of generated traffic sign. This isn't useful in some cases. On regular traffic signs like DE:348 or DE:349 the to: destinations are located on top of the direction chapter, so on top of all through destination, on top of all left destination, and so on. At location of DE:348 or DE:349 the road may consists of just a single lane in direction of all destinations. So the destination:*:to=* can't be used.

Even the destination:*:to=* is not required to be used in case destination tags are related to a single direction lane, in case of only left, only through or only right. My question is, why there is a need for destination:to=* tags?
--Vanagaudi (talk) 00:04, 24 May 2025 (UTC)

We have to distinguish between semantics of the sign and my rather crude rendering attempt. On the sign there is a difference between ```destination``` and ```destination:to```: In Germany, if the ```destination``` is a motorway, the sign is blue, but if it's a ```destination:to``` it's a blue box on a yellow or white sign. In my rendering I put them on top, because this is mostly right and easy to do. A slightly more elaborate way might be to change this behavior for split lanes and group the ```:to```s with the other destinations in the respective direction. --Mueschel (talk) 10:51, 24 May 2025 (UTC)

If the above traffic destination sign will be applied to a three lane road with individual directions for each lane everything on generated traffic sign looks fine.

I agree on "group the ```:to```s with the other destinations in the respective direction" and the issue should be addressed to GitHub. Thank you. --Vanagaudi (talk) 12:24, 24 May 2025 (UTC)