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

Wed Nov 6 16:47:56 UTC 2013

Il 06/11/2013 14:09, Martin Raifer ha scritto:
> I'm answering in English, if you don't mind.
>
> I guess you already know it, but just in case: Please make sure to 
> read and respect OSM's Import Guidelines [1].
>
> As you have already done some work, it would now make sense to create 
> a wiki-page for the import. I made one for the previous 
> opengisdata.eu/TOL house-numbers import attempt here: [2]. You can 
> either extend that page or (probably better) create a new one to make 
> it clear that this is a new attempt.
Ok. In the next days i am going to create a new wiki-page
>
> -- Import Schedule --
>
> I like the idea of a „pilot town“. It doesn't really matter which one 
> exactly, but it probably should cover all the corner cases we have to 
> consider, which probably don't exist all in one single place. So, I'd 
> propose to have a few pilot towns, for example one larger town with 
> pre-existing house-numbers, one smallish municipality which doesn't 
> use street names for addressing (like Martell or Rodeneck, but those 
> are already well mapped) and one Ladin town.
Ok we can start with Martell (see below)

For the Ladin's towns the first problem is that the data that comes from 
the PA does not have the ladin names.
So i want to append at first the ladin names following this rules:
La Valle (97,6%) LLD – DE –IT,
S.Martino in Badia (97%) LLD-DE-IT,
Badia (94%) LLD – IT –DE,
Marebbe (92%) LLD –IT –DE,
S. Cristina Val Gardena (91%) LLD – IT –DE,
Selva di Val Gardena (90%) LLD – IT–DE,
Corvara in Badia (84%) LLD – DE – IT
>
> Can you explain what your flow-chart[3] actually means? I don't get 
> it. What does the „Community sais YES/NO“ mean? Is this comparable to 
> how OSMLY[4] does imports?
We need still to choose a control process with you
>
> -- Tagging --
>
> Addressing in OSM isn't always very straight-forward (especially not 
> in a multilingual region), so here are my ideas:
>
> Relation-based addresses are preferred by some mappers (even I mapped 
> my first few house-numbers that way), but it has also it's downsides 
> (harder to comprehend by new mappers, less support in OSM software, …) 
> and it would certainly complicate the import. Other address imports 
> (like the one in Denmark [5]) also only used simple nodes.
>
> * 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
> * addr:city
> Could in principle also be omitted, but again, it doesn't harm to have 
> it and in some corner cases it could even be necessary to have it 
> (like a house very close to an administrative border).
Like above, i think that is good to correct the data
> * addr:postcode
> I would include it, because postcodes actually can be different within 
> Municipalities in South Tyrol (e.g. Eppan has 39057 and 39050) and the 
> borders of postcode areas may not be the very same as administrative 
> boundaries.
Ok. We can leave this update
> * addr:place
> I think you are misinterpreting this tag. It is not used to set the 
> "frazione" of an address like "St.Pauls" in "Schulweg 1, St. Pauls, 
> Eppan, 39050". For this there is addr:hamlet (see below). addr:place 
> is used in the following case: A small village has only a few unnamed 
> roads and all addresses are based on the locality: "Gand 45, Martell, 
> 39020". Here "Gand" is not a street-name, but a hamlet. In such cases, 
> we use addr:place _instead_ of addr:street. See an example [6].
Ok
> * addr:hamlet
> If an address is street-based, one can also provide the "frazione" of 
> the respective house by using this tag. As far as I know it is not 
> required for physical mailing, but it would be nice to have this 
> information, if available, to make searching more accurate (e.g. a 
> user may only search for "Schulweg 1, St. Pauls" instead of "Schulweg 
> 1, Eppan").
Ok
> * addr:street
> See above
> * addr:housenumber
> Surely needed
> * addr:full
> I would not import this field, as this is only intended to be used 
> _instead_ of all the fields mentioned above. As described in the wiki: 
> “Use this for a full-text, often multi-line, address if you find the 
> structured address fields unsuitable for denoting the address of this 
> particular location. Examples: "Fifth house on the left after the 
> village oak, Smalltown, Smallcountry"”
>
> -- Multilingual Tagging --
>
> When it comes to multilingualism it gets a little bit complicated:
>
> In order to get OSM's search tool to work, the name of the street (or 
> locality) must exactly match the value in addr:street (or addr:place). 
> While we have a naming convention in OSM (namely multiple names in the 
> name-tag separated by a dash with the locally dominant language 
> first), it is not (yet?) used everywhere.
So is correct for example "Brixen | Bressanone" ?
>
> As far as I know, it is possible to provide additional addr:street:de 
> and addr:street:it fields. With such tags the search could even work 
> if the street is not yet properly tagged. Same applies for 
> addr:place:*, addr:hamlet:* and addr:city:*. And also for Ladin names 
> with the postfix ":lld".
Ok
>
> So, I'd propose to simply use OSM's naming conventions and 
> additionally provide the individual language versions for further 
> clarity and a fall-back mechanism to get proper search also with 
> incomplete OSM data.
>
> When it comes to Meran, not even the city itself seems to know whether 
> to prefer German or Italian, see this street [8] with exactly opposite 
> language order on opposite sides of the street :D . In this case I 
> would stick to the order most streets are already mapped, that is 
> "German - Italian". I'd say that the decisive factor would be the 
> mostly German speaking population in the vicinity (“metropolitan 
> area”) of Meran.
Ok, also we take DE-IT
>
> -- Conflation --
>
> This probably also needs a little extra attention.
>
> If the house-number is already in OSM, I would keep the original 
> geometry for good practice. Except of course, when OSM is incorrect 
> (e.g. if the position is far off, or a house with multiple numbers has 
> only one in OSM like in your example, etc.). In that case it would be 
> OK to delete the data and insert more precise addresses instead.
A first analysis of Martell shows that there are a lot of problems [1]:
Two house number 219: one tagged on a building, one on a POI
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

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

>
> And maybe with the following additional exception: If an address is 
> already in OSM, but only as an additional datum of a POI (like a bar, 
> shop, etc.) it would probably make sense to import an additional 
> address. This is because the POI can relocate or disappear quite 
> quickly, while the actual address usually doesn't.
OK
>
>
> That's it from me – for now ;)
> Martin
Thank you very much for your notes

Pietro

[1] http://freegis.r3-gis.com/download/aa2osm/3_martell_1.jpg