<div dir="ltr">Fortunately all streets in Brussels are already mapped, based on official data from Urbis. So the person from Biel who would prefer to put / in those names doesn't need to to so anymore.<div><br></div><div>There are definitely street name signs which are wrong. It would be absurd to copy that wrong text into the name tags. It's not so wrong that is something completely different.</div><div><br></div><div>Besides many street name signs in Brussels are like this:</div><div><br></div><div>Avenue</div><div>  Simon Bolivar</div><div>                     laan</div><div>  </div><div>Even if that is a spelling error in itself.</div><div>name=Avenue Simon Bolivar - Simon Bolivarlaan</div><div>name:nl=Simon Bolivarlaan</div><div><br></div><div>words glue together in Dutch, like they do in German.</div><div><br></div><div>Anyway, we don't want to put exactly what is on the street name signs in our name tags. It's simply not practical and it would very quickly become nonsensical.</div><div><br></div><div>Jo</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">Op vr 10 aug. 2018 om 23:48 schreef Peter Elderson <<a href="mailto:pelderson@gmail.com">pelderson@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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. <br>
<br>
<br>
Mvg Peter Elderson<br>
<br>
> Op 10 aug. 2018 om 21:41 heeft marc marc <<a href="mailto:marc_marc_irc@hotmail.com" target="_blank">marc_marc_irc@hotmail.com</a>> het volgende geschreven:<br>
> <br>
>> Le 10. 08. 18 à 19:28, Peter Elderson a écrit :<br>
>> If the sign shows two strings one line each, you will need <br>
>> interpretation and/or a glue character or glue string.<br>
> <br>
> in fact, what's the better glue character IS the question<br>
> at the begging of this thread.<br>
> <br>
> Currently, a Brussels resident reading a sign with 2 lines in Biel is <br>
> unable to fill in the name field without making a mistake or without <br>
> first having to search the wiki to find the local convention, at least <br>
> if this mapper has guessed that he is in a bilingual area (which is not <br>
> always obvious when one is not able to recognize that the second line is <br>
> the same as the first line in another language).<br>
> On the other hand, an inhabitant of Biel is unable to map a street<br>
> in Brussels without making a mistake, for the same reason.<br>
> <br>
> In the same way as in osm we defined ";" as being the separator between <br>
> several values of the same key (with several exceptions), it would be <br>
> useful to define a separator between several lines of the same key.<br>
> Afterwards, it will be up to the different local communities to see<br>
> the interest or not, to use it.<br>
> but it would allow for example a contributor who adds a street to <br>
> Brussels in iD or Josm to have assistance from the application to tell <br>
> him how to encode this and make the possible link with the different <br>
> corresponding name:xx<br>
> <br>
> or to take a less personal example, what would be the ideal way to do <br>
> things in a bilingual city where nothing has yet been done ? does this <br>
> community need a 5th glue character different from the 4 others ?<br>
> or is there a way to discuss the advantages and disadvantages of the<br>
> 4 existing separators without falling into a sterile debate such as<br>
> "I don't live in a bilingual zone so bilingual zones must have to do <br>
> like me and have a one-only value in name"?<br>
> <br>
> Regards,<br>
> Marc<br>
> _______________________________________________<br>
> Tagging mailing list<br>
> <a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
<br>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>