[Tagging] Draft Proposal: Default Langauge Format

Marc Gemis marc.gemis at gmail.com
Thu Sep 27 11:31:41 UTC 2018


We already have a map in of Belgium based on OSM without any
additional tag. A typical Flemish map does not show French names
high-level. So it it uses name:nl, if that's not there name. Since all
bi-langual object will be mapped with name, name:nl and name:fr, there
is no reason to use "name" if "name:nl"

Your assumption for streets is correct, also for administrative areas,
but not for POIs. And it might be hard for a mapper to find out what
the language is the name is for them (see mails from e.g. Frederik)
I tried to say that there are 2 types of objects,
administrative/government objects will have names in 2 or 3 languages
(federal government buildings in Brussels), and others that only have
1 name in a "random" language.

m.On Thu, Sep 27, 2018 at 1:18 PM Joseph Eisenberg
<joseph.eisenberg at gmail.com> wrote:
>
> Re: do “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 (?)
>
> There are no mandatory tags in OSM, nothing needs to be retagged. But there would be the option to add
> default:language=fr to a shop in Flanders which has a name in French. This would help database users know that this shop name is in French rather than Flemish. I believe this will be very useful, and I think mappers will enjoy the chance to add the extra tags where necessary. Mapping is a bit addictive, right?
>
> My understanding of Brussels was that the streets have all been tagged with 3 name tags: name=*, name:fr=, and name:nl=. Right? So with knowledge that the default languages for Brussels are nl and fr (recorded with a single tag on the administrative boundary) a database user will know that they can use both name:fr and name:nl in combination to render the Street names, and also that both names are likely on signs.
>
> This is important for a Flemish, Dutch or French-localized service, which might want to show the name:nl or name:fr on all features, along with the local name. Right now it you attempt to do this by showing name=* and name:fr= at the same time (when they are not identical), you’ll get the French name labeled twice on every street in Brussels! Not good
>
> Joseph
>
>
> On Thu, Sep 27, 2018 at 7:38 PM Marc Gemis <marc.gemis at gmail.com> wrote:
>>
>> 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
>>
>> m.
>> 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).
>> >
>> > -Joseph
>> >
>> >
>> >
>> > 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
>> >> problem.
>> >>
>> >> 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
>> >> http://www.imagico.de/
>> >>
>> >> _______________________________________________
>> >> Tagging mailing list
>> >> Tagging at openstreetmap.org
>> >> https://lists.openstreetmap.org/listinfo/tagging
>> >
>> > _______________________________________________
>> > Tagging mailing list
>> > Tagging at openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/tagging
>>
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



More information about the Tagging mailing list