[OSM-talk-be] UrbIS import

[Sander Deryckere]

I think a fix at the validator level will be slow. By default, the
validator only complains when you have edited the object. Though validator
fixes will of course be welcome to protect against future mistakes. I think
the following test is doable: When an address has addr:street:lg as a tag,
a nearby street should have name:lg with the same value. This check is
already done for the standard name, so the algorithms already exist.

About pronouncing names, I don't think we need to worry about that. You can
select in OsmAnd to have localised maps, and when you're using tts, the tts
should be aware of it too. The tts problem is even worse when you use the
GPS in France, but you want a Dutch route, those names don't have a Dutch
translation so the tts fails miserably.

The biggest problem here is just binding street segments to each other, and
binding houses to those streets, and for this, most tools fall back to name
comparison.

I honestly like the rule of "the first mapper decides the order", but now
it turns out to be hard to maintain. It's very hard to find the order that
was used the first time. Maybe it could be possible to create a tool to
easily find that first-used name (overpass has a date tool, and with the
right input and some date bisecting, it could be possible), so we can
rename all way segments and addresses to the same name.

Regards,
Sander

2015-01-12 21:30 GMT+01:00 Jo <winfixit at gmail.com>:

> I must admit I hadn't thought it through. It was easy to decide to
> standardise on FR - NL for the associatedStreet relations, but this
> percolates through to the street level.
>
> Of course, back then, JOSM's validator didn't have that test yet.
>
> Maybe we should try to fix it at the validator level.
>
> I've been succesful in amending the validator for 2 other issues already:
>
> now it takes into account noname=yes
>
> and it shouldn't complain anymore when 1 street participates in 2 aS
> relations, when those aS relations differ in postcode or city name. This
> occurs for streets which form the border between 2 municipalities.
>
> The problem is, one never knows what is likely to be fixed and when they
> declare me crazy instead...
>
> I tried to get the validator to heed:
>
> note=similarly_named_ways_
> boundary
>
> For the node which connects streets like
>
> Bruggesteenweg/Brugsesteenweg
> Oostdorp/Westdorp
>
> But maybe they'll implement taking borders into account (where this sort
> of thing is most likely to occur and cause a false positive). That's a lot
> harder to accomplish, if you ask me. But they don't want to 'pollute' the
> data with tags which only serve for the validator (like noexit=yes, after
> its usage was deflected from what it originally stood for)
>
>
>
> Jo
>
>
>
> 2015-01-12 20:55 GMT+01:00 eMerzh <merzhin at gmail.com>:
>
>> Yeah, i know .... we have already discuss about this here :
>> https://lists.openstreetmap.org/pipermail/talk-be/2014-January/005554.html
>>
>>
>> i don't see a lot of options here ...
>>
>> Change the name=* to smth more tool friendly
>> Remove the name=* (let only name:<code>=*)
>> Or "force" one order of name (FR-NL or NL-FR)... but i think this might
>> be hard to swallow for some...
>>
>> I know we always tell : "don't map for a tool" but it's really a mess in
>> ALL tools using osm...
>>
>>
>> the problem with scheme like Boulevard Lemonnier laan is when the name is
>> different 'Rue des Poissonniers - Visverkopersstraat' ....
>> or when tools like OsmAND have to pronounce the name ....
>>
>> --
>> Brice
>>
>
>
> _______________________________________________
> 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/20150112/71f3733d/attachment.htm>