if I were a renderer I would not try to parse/interpret a free format string. I would parse only clearly defined sections, where the separator is very very unlikely to occur in text strings. Space slash space might be suitable, but not if any context is required, context such as that it’s about language. So even if mappers and taggers decide to use eg spaceslashspace as a language separator or whatever other category of separator, I would still just render the full string including the separator string.
As a mapper, I want to map whats visible on the ground. Street names are visible as strings on signs. I want to enter those without having to consult other sources. If I happen to have more detailed knowledge, I want to enter that in addition to the basics, not instead of. If the sign has one line which looks like it has variants within the one string, be it language varants, religious variants, or script variants, I still put the whole thing in the tag. I see no need for any kind of unification there, just copy the whole shebang. If (still as a mapper) I see multiple lines with equal font style/type/size, then I would probably summize that they are equal variants. In bilingual areas you can often be quite certain. Then I would concatenate using slash or space slash space. I would expect the renderer, any rendererer, not to break up the string but just render the whole thing as the name. Of course when name:xx tags are present, renderers may have rules for preference regarding name tags. If I were a data user, again I would not try to do anything with substrings of a free format string. Which is not the same as being against whatever people may wish to put in it, just you don’t build anything on free format strings. Mvg Peter Elderson > Op 10 aug. 2018 om 21:41 heeft marc marc <marc_marc_...@hotmail.com> het > volgende geschreven: > >> Le 10. 08. 18 à 19:28, Peter Elderson a écrit : >> If the sign shows two strings one line each, you will need >> interpretation and/or a glue character or glue string. > > in fact, what's the better glue character IS the question > at the begging of this thread. > > Currently, a Brussels resident reading a sign with 2 lines in Biel is > unable to fill in the name field without making a mistake or without > first having to search the wiki to find the local convention, at least > if this mapper has guessed that he is in a bilingual area (which is not > always obvious when one is not able to recognize that the second line is > the same as the first line in another language). > On the other hand, an inhabitant of Biel is unable to map a street > in Brussels without making a mistake, for the same reason. > > In the same way as in osm we defined ";" as being the separator between > several values of the same key (with several exceptions), it would be > useful to define a separator between several lines of the same key. > Afterwards, it will be up to the different local communities to see > the interest or not, to use it. > but it would allow for example a contributor who adds a street to > Brussels in iD or Josm to have assistance from the application to tell > him how to encode this and make the possible link with the different > corresponding name:xx > > or to take a less personal example, what would be the ideal way to do > things in a bilingual city where nothing has yet been done ? does this > community need a 5th glue character different from the 4 others ? > or is there a way to discuss the advantages and disadvantages of the > 4 existing separators without falling into a sterile debate such as > "I don't live in a bilingual zone so bilingual zones must have to do > like me and have a one-only value in name"? > > Regards, > Marc > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
