[Tagging] Draft Proposal: Default Langauge Format
marc.gemis at gmail.com
Thu Sep 27 10:37:22 UTC 2018
Some practical information from Belgium:
We have three official languages nl,fr,de
Flanders is nl (*)
Brussels is nl;fr
Wallonia is Fr (*)
Eupen-Malmedy is de
This means that town names, street names and bus stops can be expected
in the above mentioned languages. Same goes for government buildings.
This does not mean that the names of shops, restaurants have to be in
any of the above languages (just as the examples given by others for
Germany and Italy). More over, the names in Brussels will typically be
in either Dutch or French, depending on the mother tongue of the
owner. Schools and universities (e.g. VUB is a Dutch-speaking
university and ULB a french-speaking university in Brussels) are also
typically named in 1 language. As far as I can see, the current
proposals would mean that any POI (not referring to a government
building) in Brussels needs to be retagged to name:XX or add
default:language:XX. Is this a correct assumption ?
Although I am not overly familiar with the Eupen-Malmedy area, I think
that a lot of POI names in that area are in French.
Furthermore, the destination signs in Belgium can be a mixture of
Dutch/French/German, even for towns in France/Germany. Those signs are
often mapped with the destination-tag in OSM and announced by
navigation software. None of the proposed solutions here helps the
software to read those aloud.
So I see a massive amount of work + a lot of work to maintain this. I
really do hope that the benefits are huge. And to be honest, I do not
have a lot of problems with the current navigation software based on
OSM without all those extra tags.
(*) exceptions exist, there are towns with facilities, which means
citizens can demand to get official letters in another language
On Thu, Sep 27, 2018 at 2:56 AM Joseph Eisenberg
<joseph.eisenberg at gmail.com> wrote:
> While it is a good idea to address the issues around name=* and name:<lg>=* tags, this proposal is a necessary first step before we can do anything else.
> Frederik's perferred solution and Christoph's idea both require there to be a default language format tag.
> I would recommend approving this proposal in some form first, then we can have a separate discussion about the name tags. So I have removed a couple of short comments from the proposal to avoid this confusion.
> Tags for official languages should also be a separate discussion (though I also think this idea has merit).
> On Thu, Sep 27, 2018 at 7:19 AM Christoph Hormann <osm at imagico.de> wrote:
>> On Wednesday 26 September 2018, Wolfgang Zenker wrote:
>> > > * allow mappers to accurately document information on names of
>> > > features in all situations that might exist world wide where there
>> > > are verifiable names with as little effort and in the least error
>> > > prone way as possible.
>> > > * allow data users to interpret this data without constraints due
>> > > to intransparent preprocessing performed by the mappers.
>> > I'm not sure that all the participants in this discussion and all the
>> > supporters of the draft proposal (and previous proposals) do really
>> > agree on the ultimate aim of that proposal.
>> Yes, of course i should have mentioned that this is just my personal
>> opinion. I did not mean to imply to speak for anyone else.
>> > Hence my suggestion to
>> > explore the problem space first and find out what problem(s)
>> > different people try to solve with that proposal, then identify the
>> > constraints that reduce the possible solutions space and the "nice to
>> > have" properties that we'ld like to see in the solution.
>> Yes, you can try to systematically develop a solution after defining
>> requirements and quantifying priorities. But you need to keep in mind
>> that in OSM you have no centralized decision making process as you
>> usually have in engineering disciplines. So you would already have
>> trouble finding agreement on what exactly the problem is. And
>> experience tells that the solution space is typically much smaller than
>> the problem space when it comes to tagging in OSM. Long story short:
>> Finding consensus on the solution is often much easier than on the
>> Still you are right, systematically collecting all the problems related
>> to name data recording in OSM would be quite useful - even if just from
>> a single person's perspective. But that is already quite a huge amount
>> of work.
>> Christoph Hormann
>> Tagging mailing list
>> Tagging at openstreetmap.org
> Tagging mailing list
> Tagging at openstreetmap.org
More information about the Tagging