[Tagging] Draft Proposal: Default Langauge Format

Thu Sep 27 12:35:55 UTC 2018

I’m sorry I misunderstood your point about POIs (eg shops, amenities) in
Brussels, which as you say often have a name in only one language.

On this case, a map renderer or routing service that has adopted this new
tag should look first for name:nl=* and name:fr=*, and show whichever one
is found. If there is neither a name:fr or name:nl, then the label should
be based on name=*

It isn’t necessary to add the default language tag to any POIs in Brussels
as long as the name is in French, Flemish or both. Only places with foreign
names  (eg a Korean shop?) would need to be tagged directly.

I personally think it is a good idea to have a name:fr or a name:nl for
every POI in Brussels, but that’s not part of this proposal.

Joseph

On Thu, Sep 27, 2018 at 8:33 PM Marc Gemis <marc.gemis at gmail.com> wrote:

> 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
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180927/f5e72224/attachment-0001.html>