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 <[email protected]> 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 <[email protected]> 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 >> <[email protected]> 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 <[email protected]> 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 >> >> [email protected] >> >> https://lists.openstreetmap.org/listinfo/tagging >> > >> > _______________________________________________ >> > Tagging mailing list >> > [email protected] >> > https://lists.openstreetmap.org/listinfo/tagging >> >> _______________________________________________ >> Tagging mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/tagging > > _______________________________________________ > Tagging mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/tagging _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
