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.ge...@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.eisenb...@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.ge...@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.eisenb...@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 <o...@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@openstreetmap.org > >> >> https://lists.openstreetmap.org/listinfo/tagging > >> > > >> > _______________________________________________ > >> > Tagging mailing list > >> > Tagging@openstreetmap.org > >> > https://lists.openstreetmap.org/listinfo/tagging > >> > >> _______________________________________________ > >> Tagging mailing list > >> Tagging@openstreetmap.org > >> https://lists.openstreetmap.org/listinfo/tagging > > > > _______________________________________________ > > Tagging mailing list > > Tagging@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
