[OSM-talk-be] import AGIV CRAB-data

[Thomas]

Ik heb die adressenlijst even gedownload en voor een paar straten 
bekeken. Dat verheldert ook wel een paar zaken.

Weer kwam ik een geval tegen met als huisnummer 'ZN'. In deze lijst 
heeft hij echter wel een locatie meegekregen. Ik ken de betreffende 
plaats, en begrijp nu dat het een braakliggend perceel betreft waar in 
de nummering rekening is mee gehouden. Het huisnummer is dus nog niet 
toegekend, maar wel al gereserveerd, of zo iets.

Alle adressen hebben per huisnummer een locatie gekregen. Vervolgens is 
elk 'BUSNR' voor dat punt geregistreerd in een apart punt met dezelfde 
locatie. Zoals Sander zegt kunnen deze punten genegeerd worden, en 
volstaat het om de unieke 'HUISNR's in het script op te nemen.

Al ligt het misschien toch net wat ingewikkelder. Voor een bepaalde 
locatie (Kastanjelaan, Oostende, rond huisnummer 2) zie ik 24 (!) punten 
op elkaar liggen. Het betreft een klein appartementsgebouw. Het veld 
'APPTNR' is steeds leeg. Voor HUISNR zijn er de waarden 2, 2_107, 2_109, 
2_209, 2_309, 2A en 2D. Al deze 'HUISNR's met een underscore hebben als 
herkomst 'geinterpoleerdObvNevenliggendeHuisnummersGebouw'. In de 
dataset die ingeladen wordt met het script van Sander waren die 4 
huisnummers met een underscore inderdaad de 4 punten die als 'zonder 
locatie' geregistreerd waren. In deze dataset hebben ze dus wel een 
locatie, maar vallen ze samen met het kale huisnr.

Los daarvan heb je per 'HUISNR' in dit geval ook steeds een aantal 
'BUSNR's. Dat is in dit geval 107, 109, 209, 309, 409, etc. Frappant is 
dat voor de HUISNR's met underscore, niet het nummer na de underscore 
als BUSNR geregistreerd is. Alle adressen met een underscore hebben een 
variant met BUSNR leeg en een variant met BUSNR A. Wat het helemaal af 
maakt is het feit dat het HNRLABEL in alle 19 samenvallende gevallen 
gelijk is, namelijk '2-2_309'. Mogelijk heeft dat ermee te maken dat het 
punt met HUISNR '2_309' de hoogste ID heeft van die hele set.

Complex dus. Sander had het over het zinloos zijn van het registreren 
van meerdere busnummers per adrespunt, omdat dat toch allemaal 
samenvalt. Daar sluit ik mij bij aan. Echter, sommige van de nummers in 
de bovengenoemde casus zijn formeel bisnummers en geen subadres (wat dus 
op een busnummer of een appartementnummer zou slaan). Dat we de 
subadressen niet importeren lijkt me prima, maar mogelijk moeten we wel 
de bisnummers opnemen, ook als die toevallig samenvallen. Bij een 
opgesplitst rijhuis dat vroeger nr 5 was en nu nr 5 en nr 5A lijkt het 
me logisch om beide te importeren. Beide zou je ook prima kunnen 
intekenen met een eigen gebouw-polygoon. Bij een appartement heb je soms 
te maken met busnummers, maar soms ook met bisnummers (het was nog niet 
complex genoeg...). Wat dit betreft is het dus niet zo 'logisch' om al 
die 'HUISNR' met een underscore gewoon te negeren. Wat mij betreft mag 
dat wel gebeuren voor de APPTNR's en de BUSNR's.

Dat is in feite wat het huidige importscript ook doet met de 
adresposities-dataset die nu gebruikt wordt. Door de subadressen niet te 
gebruiken worden de diverse BUSNR's genegeerd. De adressen die nu in het 
script ingeladen worden zonder positie zijn naar mijn mening dus 
bisnummers (geen busnummers!). Als we deze dataset aanhouden, dan zouden 
deze punten de locatie van het overeenkomstige 'kale' nummer kunnen 
krijgen, met een kleine verschuiving dan.

In deze dataset (adressenlijst) is ook de 'HERKOMST' opgenomen. Die zegt 
wel wat over de nauwkeurigheid. Zoals ik in mijn vorige mail schreef, is 
het dus misschien handig om deze op te nemen als tag om bij de import 
die informatie beschikbaar te hebben.

Groeten,
Thomas

Sander Deryckere schreef op 24-10-2014 10:48:
>
>
> Op 24 oktober 2014 10:26 schreef Johan Van de Wauw 
> <johan.vandewauw at gmail.com <mailto:johan.vandewauw at gmail.com>>:
>
>     Sander,
>     je baseert je beter op de CRAB adressen*lijst* in plaats van de CRAB
>     adres*posities*
>
>     https://download.agiv.be/Producten/Detail?id=447
>
>     Dan krijg je per adres maar 1 positie (de beste) en er zijn zelfs een
>     aantal categorieën die niet in de adresposities zitten.
>
>     Verwarrend -> zeker wel.
>
>     Johan
>
>
> Dat is idd zeer verwarrend.
>
> Ben nu de andere database aan het downloaden, aangezien er geen 
> documentatie van is, wil ik die eerst wel eens bekijken.
>
> Groeten,
> Sander
>
>
>
> _______________________________________________
> 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/20141024/07043bbc/attachment.htm>