<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=UTF-8">
<title></title>
<meta name="GENERATOR" content="LibreOffice 4.0.3.3 (Windows)">
<style type="text/css">
<!--
@page { margin: 2cm }
P { margin-bottom: 0.21cm }
-->
</style>Ik heb die adressenlijst even gedownload en voor een paar
straten bekeken. Dat verheldert ook wel een paar zaken.<br>
<br>
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.<br>
<br>
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. <br>
<br>
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. <br>
<br>
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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
Groeten,<br>
Thomas<br>
<br>
Sander Deryckere schreef op 24-10-2014 10:48:<br>
</div>
<blockquote
cite="mid:CABUOUO-mEzm1fX3GfHqxO2RQh-iXsQO-B0FLJMhOyEvciK5jNQ@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">Op 24 oktober 2014 10:26 schreef
Johan Van de Wauw <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:johan.vandewauw@gmail.com" target="_blank">johan.vandewauw@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Sander,<br>
je baseert je beter op de CRAB adressen*lijst* in plaats
van de CRAB<br>
adres*posities*<br>
<br>
<a moz-do-not-send="true"
href="https://download.agiv.be/Producten/Detail?id=447"
target="_blank">https://download.agiv.be/Producten/Detail?id=447</a><br>
<br>
Dan krijg je per adres maar 1 positie (de beste) en er
zijn zelfs een<br>
aantal categorieën die niet in de adresposities zitten.<br>
<br>
Verwarrend -> zeker wel.<br>
<span><font color="#888888"><br>
Johan<br>
</font></span>
<div>
<div><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Dat is idd zeer verwarrend.<br>
<br>
</div>
<div>Ben nu de andere database aan het downloaden, aangezien
er geen documentatie van is, wil ik die eerst wel eens
bekijken.<br>
<br>
</div>
<div>Groeten,<br>
</div>
<div>Sander<br>
</div>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Talk-be mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-be">https://lists.openstreetmap.org/listinfo/talk-be</a>
</pre>
</blockquote>
<br>
</body>
</html>