[OSM-talk-be] Some information about Nominatim for addresses in Brussels

[Jo]

This also came up when we were doing the Urbis import. Back then I said I
wouldn't care (even as a speaker of Flemish), if all streets in Brussels
would have French first in their name tags.

It's a coincidence of a difference between Dutch and French grammar that
French puts Rue Nom and Duthc uses Naamstraat. So on most street signs in
Brussels French will be first anyway, Either as

Rue
    Josaphat
               straat

or as

Rue du Miroir
    Spiegelstraat

The advantage of doing this in a consistent way across all streets, is when
you order them alphabetically. Since we have name:nl as well, people who
prefer to order them on Flemish name can also easily do this.

The initial rule was that whichever way/language it was mapped by the first
mapper should remain... I wouldn't be surprised if all streets are
consistently mapped French first and I don't see that as a very big
problem. There are worse things going on if you look at a somewhat larger
scale.

One thing I noticed, now that I've been cycling the streets of Brussels
more than I usually do, is an issue with OsmAnd.

If you set TTS to Dutch, it pronounces the French part of the name tag
wrongly (à l'anglaise). If you set it to French, it starts mumbling on the
Dutch part. The solution is, of course, for OsmAnd to use name:fr and
name:nl for the purpose for which we added them. I don't know if they are
present in the data extract though.

Polyglot


2016-09-28 11:08 GMT+02:00 Marc Gemis <marc.gemis at gmail.com>:

> The order on name can be random. But once you chose e.g. FR - NL, all
> the addr:street tags for the addresses in that street have to follow
> FR - NL. For another street you can take another order.
>
> This weird rule of FR - NL or NL - FR as name is something from the
> Belgium community. You cannot expect that all tools honour this. How
> can a tool know that in this small place on earth the name field is a
> concatenation of two names? By using FR - NL as name, you tell all the
> tools that the name of the street is "FR - NL". So you have to use
> that name everywhere you refer to the name of the street, which means
> the field addr:street has to be "FR - NL" as well.
> You do not use different names for addr:street and name for roads in
> Flanders, do you ?
>
> IMHO, this is not mapping for the tool, but is mapping in a consistent
> way. Once the order is determined for a street, we also agreed not to
> change it, so once cleaned up, there is no longer an issue.
>
> But if people don't care about the first impression people get when
> looking up an address in Brussels, fine for me.
> But it is already bad enough that when you look for Zutphen in a Dutch
> browser, you find "Zütphen".
> All those little things might turn people away from OSM... :-(
>
> m.
>
> p.s. alternatively, you could use an associatedStreet-relation to
> solve this problem. But this is not one of lonvia's preferred
> solutions.
>
>
>
>
>
>
> On Wed, Sep 28, 2016 at 10:18 AM, joost schouppe
> <joost.schouppe at gmail.com> wrote:
> > I'm not sure I understand correctly, but isn't the order of languages in
> the
> > general name tags supposed to be random (for political reasons)? If so,
> > shouldn't Nominatim be able to deal with this randomness?
> > It sounds a bit strange to expect the data to follow the same randomness
> in
> > the name and addr:street for different objects. Then upon every edit of a
> > new object, you would have to check which randomly selected order of
> names
> > is present on the street itself.
> >
> > To me, it looks a bit like "mapping for the tool" if we do clean this up.
> > But I might be missing the point.
> >
> >
> >
> > _______________________________________________
> > Talk-be mailing list
> > Talk-be at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> >
>
> _______________________________________________
> Talk-be mailing list
> Talk-be at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20160928/d08b4a69/attachment.htm>