Tagging of bilingual destinations and duplicating destination:ref in destination

[amakarevich_lyft]

Dear Canada community, I’m Artem, a policy lead on the OSM mapping team at Lyft. Due to the broadening of the Destination sign project to Canada, we would like to clarify some questions with the community before launching massive edits.

Tl;dr

• Suggested two approaches of tagging multilingual destinations. First - we put all destinations in both languages in the main tags and add additional tags wih lang code. Second approach - add in the main destination tags only destination in the language that is primary in this area and second language only in lang code
• Is it a good practice in Canada to duplicate values destination:ref in destination or destination:street tags or was it an undiscussed initiative of some mappers?

1. Bilingual destinations

In Canada, we met different types of provinces in terms of Destination Signs languages:

• Only French (i.e. Quebec)
• Only English (i.е. Toronto)
• Bilingual (i.e. Ottawa)

So we want to agree on a tagging schema for Destination Signs in order to support multiple languages and not lose data.

Bilingual signs

The vast majority of bilingual DSs are mapped without any systematic approach.

The English and the French value are mixed for the left direction. But it should be:

In French - Chemin Innes Ouest
In English - Innes Road West

---

The English and the French value are mixed for the left direction. But it should be:

In French - Promenade Moodie Nord
In English - Moodie Drive North

---

The French value is ignored

---

At the same time there are some examples where different languages are put into separate lang:en or lang:fr tags. It also duplicates in the main destination tags in both languages.

---

Only English/French signs

There is no issue. The values from the sign are added to the main destination tags that looks like a fine decision.

---

---

Suggested approach

Bilingual

There are several tags clarifying basic ingested tags in OSM (destination, destination:street and destination:ref)

destination:lang:en

destination:lang:fr

destination:street:lang:en

destination:street:lang:fr

destination:ref:lang:en

destination:ref:lang:fr

So in this case it looks like we have two approaches. Based on the first example from the Bilingual section, let’s look at how we can deal with it.

1st approach:

Firstly, we put all destinations for the right direction into the main destination tag

destination - Chemin Innes Road Est;Innes Road East;Orleans;Orléans;Rockland

Then we add additional language tags

destination:lang:en - Innes Road East;Orleans;Rockland

destination:lang:fr - Chemin Innes Road Est;Orléans;Rockland

As a result, destinations are displayed from lang:en tags for users with EN language in routers and from lang:fr for FR users. If the navigation system doesn’t support language setting, the drivers will see the main destinations in both languages without data loss.

---

2nd approach:

Firstly, we put all destinations in the language that is primary in this area for the right direction into the main destination tag.

destination - Innes Road East;Orleans;Rockland

And then we add the additional language tags

destination:lang:fr - Chemin Innes Road Est;Orléans;Rockland

As a result, drivers in any language should see the destination from the main tag in primary language in this area and drivers with FR language in routers will see destination with lang:fr with correct guidance and banners. But in this case, we lose data in the French language in the main destination tag. It’s not a good point, for the navigation system, that doesn’t support language settings.

Single language

Signs with English or French value only are applied to the main destination tags (destination, destination:street or destination:ref).

---

---

---

2. Duplicating destination:ref info in destination and destination:street

We came across several cases where destination:ref value was duplicated into the destination/street tag, without any indicators on the destination sign.

This info looks as duplicated and causes a duplicated guidance suggestion in the routers, and banners.

Toward 401/Highway 401

On the banner Highway 427 as a destination and as destination:ref

Is it a good practice in Canada to duplicate destination:ref in such ways, or was it an undiscussed initiative of some mappers, and can we clean up such duplicates?

---

Our goal is to reach a consensus and avoid any potential conflicts. Your thoughts and insights are invaluable in this process.
Thanks in advance for your cooperation and suggestions.

[jfd553]

I don’t remember any discussion about duplicating destination:ref in such a way on this forum (or talk-ca mailing list). Maybe others recall otherwise?

[SekeRob]

Triple those tags as there’s forward/backward as well not to speak of destination:lanes

[Johnwhelan]

In Ottawa specifically there is a bylaw that gives the English French translation for street names. Rue Street for example. This means it is technically possible to use a program to do the conversion subject to the normal automated edit rules.

Most highways are tagged with en: and fr: names, there might be one or two that have been added since I went through them all many years ago.

This means you can set OSMand etc. to English or French and it will just display the appropiate street name.

If the en: or fr: is missing it grabs whatever value is in the name field.

I personnally would favour the first approach you listed but be aware there are strong feelings on this subject.

Cheerio John

[Kevo]

I believe the reason for the duplication is this: the reference number of the highway is 401 and the highway’s name is “Highway 401”, so both the ref and names were filled out like this. As an aside for what an Ontarian would expect to hear from their guidance would be “Merge onto highway four-oh-one westbound”.

From what I recall when filling out many of them was that there were some destination tags already using that method and it seemed to make sense, so I followed what was already done. I’m indifferent as long as it all ends up working in the end.

[amakarevich_lyft]

@Kevo

I believe the reason for the duplication is this: the reference number of the highway is 401 and the highway’s name is “Highway 401”, so both the ref and names were filled out like this. As an aside for what an Ontarian would expect to hear from their guidance would be “Merge onto highway four-oh-one westbound”.

From what I recall when filling out many of them was that there were some destination tags already using that method and it seemed to make sense, so I followed what was already done. I’m indifferent as long as it all ends up working in the end.

Hi, thanks for feedback

Let’s take a look, for this exit

According to the current situation, for example in OsmAnd the guidance tell - “Take exit 139 onto four-two-seven, Pearson Airport”.

Due to OsmAnd don’t work with ‘destination:street’ and ‘:to’ values we got good guidance and duplication info didn’t cause any troubles.

But for example Valhalla guidance tell - ‘Keep right to take exit 139 onto four-two-seven, toward four-oh-one, highway four-oh-one, …’

Due to duplicated info in ‘destination:ref:to’ and ‘destination:street:to’ guidance and banner will be missing value of main destination tag ‘Pearson Airport’

So in both cases duplicated of ‘destination:ref’ in ‘destination:street’ and ‘:to’ has no sense, and we want to make some clean up