[Tagging] Draft Proposal: Default Langauge Format

Joseph Eisenberg joseph.eisenberg at gmail.com
Thu Sep 27 11:10:41 UTC 2018


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180927/93c8ff12/attachment.html>


More information about the Tagging mailing list