Some rivers are long enough to cross several countries or used as international borders. Putting the local name into the tag "name:<lang>" is not a problem.
But what about the tag "name" itself which is used by many rendering engines when the river has multiple syntaxes in different languages ? Should this tag contain all local versions of the river name, separated by a semicolon ? Or just none of them (not use it) ? Or just the version of the biggest country crossed by the river ?

asked 07 Dec '11, 22:59

Pieren's gravatar image

Pieren
9.7k2075157
accept rate: 15%


I would say that all along the river should have the international name:<lang> and in each country the respective name in name. If the river makes the border, both names are equally valid, and since no name is bad I would use both separating them with a semicolon is probably the correct syntax, but (unlike separation with a slash or a dash) it will not look good on renderings (just a remark, tag correctly).

permanent link

answered 08 Dec '11, 00:10

LM_1's gravatar image

LM_1
3.2k334988
accept rate: 10%

1

After thinking about this for a while, maybe the best way for names would be to use only name:<lang> and never to use name. It would be the renderer's task to choose the name(s) to render. And one would always know the language. (After all each name is in a certain language)

(08 Dec '11, 13:24) LM_1

Can you enhance your reply for the relation assembling all sections of the river (I can imagine that setting the local name is easy when you can split the ways but not possible for the relation) ?

(08 Dec '11, 14:09) Pieren

In this situation it makes even more sense to have only language specific tags and to let the renderer decide. For legacy / compatibility the name tag of the relation should contain all the names.

(08 Dec '11, 14:43) LM_1

And I am the renderer, what to print out over the river which is a border also? My vote goes to: name=langA - langB. Since rivers are long objects it will looks well. Which will be the first, langA or langB depends on influence. Size matters.

(03 Jan '16, 17:00) lider

The river-as-border is the tricky case (for border-crossing rivers, just split the river into multiple parts and tag each accordingly). But multi-value tagging is both ugly and a cop-out.

You'll have to be subjective here. Does the river border one country for longer than the other ? Is the official administrative boundary shifted towards one of the riverbanks ? Is there more boat traffic from one country than the other ? Is one of the countries more internationaly influencial ?

Just choose one version and learn to be happy with it. It will not be perfect, but such is the fate of the "name" tag. Once that's done, put the other version in an "alt_name" tag.

permanent link

answered 08 Dec '11, 10:00

Vincent%20de%20Phily's gravatar image

Vincent de P... ♦
17.0k16147244
accept rate: 19%

1

As example, the Rhine is crossing 3 countries and "touching" 2 others. It is officially writen in at least 3 languages. So what would be the value entered in the relation "name" ?

(08 Dec '11, 14:07) Pieren

Different parts of the same river can have different names. If you have a top level relation with all the "name:< lang >=" tags and subrelations for each country with the name=.

The only problems are rivers that is used as a border where the locals on each side have different names for it. This is the same problem as where there are two equal languages spoken in a region. There have been a lot of debate about this. I think that puting name=< lang A >;< lang B > is the best option.

permanent link

answered 08 Dec '11, 13:12

Gnonthgol's gravatar image

Gnonthgol ♦
13.6k15101198
accept rate: 16%

River-as-border: since not all renderers support the "name:<lang>" tags, I think it's good practice to provide a default "name" tag as a fallback value. The Rhine river, bordering France and Germany, is probably a good example.

http://www.openstreetmap.org/browse/way/91320954

To remain neutral, names in the "name" tag could simply be in Unicode alphabetical order.

If the river borders many countries, using all the names on the "name" tag would be too verbose I think. You may consider a system of relations: one "master" relation for the entire river, using only "name:<lang>" and without a "name" tag; and one "minor" relation for each part of the river that borders a pair of countries, including "name:<lang>" for the languages of these two countries and a fallback "name" tag combining these two names.

This has several advantages: the "master" relation can be linked from the main Wikipedia article; the "master" and the "minor" relations would be returned by Nominatim and would fit different user's needs; there's no need to tag each way individually, minimizing maintenance; most maps (particularly Mapnik) would render an acceptable river name.

Note: some ways in the Rhine have a "note" tag saying that the "name" tag must include both names. This may indicate that naming only the relations is not enough for proper rendering.

permanent link

answered 02 Apr '13, 15:19

ftrebien's gravatar image

ftrebien
11
accept rate: 0%

edited 02 Apr '13, 15:36

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×178
×61
×16

question asked: 07 Dec '11, 22:59

question was seen: 5,519 times

last updated: 03 Jan '16, 17:01

powered by OSQA