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.vandew...@gmail.com <mailto:johan.vandew...@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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
