[Talk-it-southtyrol] Import numeri civici in OSM dal DB della Provincia di Bolzano

[Pietro d'Orio]

Hi Martin, i answer under your notes...

Il 08/11/2013 12:35, Martin Raifer ha scritto:
>> For the Ladin's towns the first problem is that the data that comes 
>> from the PA does not have the ladin names.
>
> Interesting. But I know that the Gemeindenverband has address data 
> also with Ladin street and place names.
I asked to PA the list of the address in ladin languages, their tell to 
me that it comes in short time..
>
>> So i want to append at first the ladin names following this rules:
>
> For what I know, the street names in Ladin towns are only in Ladin. 
> See here: http://goo.gl/NuzTe9
> That's also the way it is currently mapped in OSM: 
> http://osm.org/go/0IQl8TPN
> Names of towns are typically multilingual, I guess.
>
> Therefore, we should probably only use addr:street:lld for addr:street.
Ok. Also i am going to update only the addr:city with the rules LLD - DE 
- IT or LLD - IT -DE and insert the tag addr:street:de and 
addr:street:it when matches.
>
>>> * addr:country
>>> Can be omitted, but doesn't harm to include either.
>> A first analysis shows that there are a lot of data with tag 
>> incorrectly, for example addr: country = DE . I think it's good to 
>> correct this data
>
> I do only count 4 nodes with addr:country=DE 
> (http://overpass-turbo.eu/s/1qV), but this could be fixed very easily 
> outside of this import.
yes very very easy!
>
>>> If the house-number is already in OSM, I would keep the original 
>>> geometry for good practice. […]
>> A first analysis of Martell shows that there are a lot of problems [1]:
>> [1] http://freegis.r3-gis.com/download/aa2osm/3_martell_1.jpg
>> Two house number 219: one tagged on a building, one on a POI
>
> That's not an error from an OSM point-of-view. Both objects have this 
> address.
Ok. Also when i found duplicate in OSM is necessary to update the 
address information of all this points, not a problem.
>
>> The house number 220 does not exist anymore, there are 220/A, 220/B
>> Like above for hn 65 -> 65/A, 65/B, 65/C, 65/D
>
> Here, OSM is wrong, and the address information should be replaced by 
> new data.
Ok. For you is better to update 65 to 65/A and insert the new address 
65/B, 65/C, 65/D or delete 65 and insert new address 65/A, 65/B, 65/C, 
65/D? The second choice is easier than the first
>
>> My opinion is:
>> If the house number is a point, we keep the geometry of OSM
>> If the house number is related to a building, it's better to delete 
>> this information from the building and insert a new point
>
> But if you replace addresses on buildings with nodes, one can't easily 
> tell which building has which address. Take a look at your example and 
> search for 216/B. Which building is it? With the current OSM-tagging 
> it is perfectly clear, with address nodes, one would have to do some 
> pretty fancy address-matching.
You are right. But i'm sure that this problem is due to an approximative 
geometry of the building
>
> Another question: What does the address node from your data actually 
> represent? Is it the building's entrance? If yes: how accurate are the 
> coordinates? If it would be precise enough, we could in principle 
> import those as "entrance"[2] nodes if they are near to a building 
> (with address information if no address already exists, otherwise 
> without).
The nodes that comes from PA is the position of the access. The main 
priority for the Province of South Tyrol is have the most accurate 
position of the access to facilitate the civil protection in case of 
emergency.
>
> Martin
>
Today or tomorrow i am going to public the new wiki page for the import, 
and the first result of a preliminary anaysis on Martello

Pietro