<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Op 24 oktober 2014 01:13 schreef Thomas <span dir="ltr"><<a href="mailto:osm@aptum.nl" target="_blank">osm@aptum.nl</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>
      
      
      
      Ik heb nu de CRAB-data voor een hele verzameling straten in en
      rond Oostende bestudeerd. In het algemeen vind ik dat de data vrij
      nauwkeurig is. Een enkele keer merkte ik op dat twee naast elkaar
      gelegen huisnummers met elkaar omgewisseld lijken te zijn. In
      werkelijkheid nummert alles gewoon netjes door, maar in GRB en
      CadGIS lijken de nummers ook omgewisseld te staan. Ik veronderstel
      dat we in dat soort gevallen de nummerplaatjes bij het huis moeten
      aanhouden. Toch bijzonder dat al die “officiële” datasets die
      kennelijke fout bevatten.<br>
      <br>
      Verder zijn er wel vaak heel wat nummers zonder locatie. Het
      betreffen vrijwel altijd nummers met een toevoeging (meestal het
      huisnummer waar ze bijhoren, een underscore en dan de toevoeging;
      vb 22_03). Soms zijn het schijnbaar gewone nummers. De nummers
      komen nooit voor op het GRB, maar soms komt hetzelfde huisnummer
      zonder toevoeging wél voor op het GRB.<br>
      <br>
      Ik begrijp niet goed of dat nu de subadressen zijn binnen CRAB of
      gewone adressen, maar dan een bisnummers (zie ook
      <a href="https://www.agiv.be/~/media/agiv/producten/crab/documenten/xgrabobjectcataloogv114.pdf" target="_blank">https://www.agiv.be/~/media/agiv/producten/crab/documenten/xgrabobjectcataloogv114.pdf</a>
      pagina 15 en 29).</div></div></blockquote><div><br></div><div>OPGELET:<br>Merk op dat dit bestand over een andere database gaat. De xGrab database valt niet onder de open-data licentie, en deze mogen we dus ook niet gebruiken (de xGrab database bevat trouwens wel gebouwcontouren).Gelieve je tot de correcte documenten te richten: <a href="https://download.agiv.be/Producten/Detail?id=102&title=CRAB_adresposities">https://download.agiv.be/Producten/Detail?id=102&title=CRAB_adresposities</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div> Uit het feit dat er geen positie bekend is leid
      ik af dat het waarschijnlijk subadressen zijn die hun positie aan
      hun parent-adres horen te ontlenen. Misschien is het handig als
      deze punten vlak bij het bijbehorende parent-adres-punt geplaatst
      worden. In feite is dat ook waar ze gekarteerd zouden moeten
      worden. In Oostende alleen al gaat het om meer dan 1000 van dat
      soort nummers, met name in de winkelstraten en de
      appartementsblokken. Op de Zeedijk alleen al gaat het om 226
      adrespunten zonder locatie, die gewoon in de overeenkomstige
      adresblokken horen. Al die appartementsgebouwen hebben 1
      adrespunt, wat me verder doet vermoeden dat de meeste zo niet alle
      van die adrespunten zonder positie allen subadressen zijn die hun
      positie aan het parent adres zouden moeten ontlenen.<br>
      <br>
      Ik vind het niet aantrekkelijk om tientallen adressen voor 1
      appartementsblok handmatig op een netjes raster te plaatsen boven
      het appartementsblok. Als dat automatisch kan... Daarnaast is het
      misschien handig om deze punten alsnog een tag mee te geven zodat
      ze anders weergegeven kunnen worden binnen JOSM, maar misschien
      vinden de andere mappers dat enkel onhandig.<br>
      <br>
      In datzelfde kader is het misschien mogelijk om iets met het
      herkomstAdrespositie-veld te doen. Daaruit zou je moeten kunnen
      afleiden of het punt als perceel-centroid of gebouw-centroid is
      afgeleid. Daarnaast kan die informatie misschien licht werpen op
      bepaalde nauwkeurigheids-problemen. Maar wederom: ik kan ook goed
      begrijpen als andere mappers die extra tags enkel vervelend
      vinden. Ze zullen in elk geval verwijderd moeten worden voor het
      opladen van de gegevens, zoals Sander al aangeeft.<br>
      <br>
      Verder kwam ik nog een aantal keer een adrespunt tegen met als
      huisnummer 'ZN', zonder positie. Het lijkt er steeds hooguit 1 per
      straat te zijn. Heeft iemand enig idee waar dat voor staat?
      Misschien 'zonder nummer'? In dat geval kunnen we dus helemaal
      niets met zo'n punt zonder nummer of locatie. Misschien is het
      handig om die met het script eruit te filteren?<br>
      <br></div></div></blockquote><div>Deze had ik nog niet gezien. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
      Buiten een vergissing van een mapper in de Spechtstraat in
      Oostende, zijn alle andere foute huisnummers eigenlijk industriële
      of commerciële panden waar de afstand tussen het centroid in CRAB
      en het gemapte gebouw groter dan de door mij ingestelde 20m op de
      website van Sander is; geen echte fouten dus.<br>
      <br>
      In het algemeen zijn de gegevens voor Oostende dus zeer goed
      bruikbaar, zeker als die subadressen nog automatisch de positie
      van hun parent-adres kunnen krijgen.<br>
      <br>
      Groetjes,<br>
      Thomas<br>
      <br></div></div>
<br></blockquote><div><br></div><div>Bij mijn weten heb ik helemaal geen subadressen verwerkt, ik heb die tabel zelfs niet bekeken. Maar je kan het zelf controleren in het script: <a href="https://github.com/sanderd17/sanderd17.github.io/blob/master/extract.py">https://github.com/sanderd17/sanderd17.github.io/blob/master/extract.py</a><br><br></div><div> De subadressen zijn volgens mij bus-nummers. Een huisnummer kan een suffix hebben (zoals 29A), zonder dat het daarom een busnummer is. We zijn niet van plan om busnummers in OSM te importeren, omdat alle bussen die tot eenzelfde adres behoren toch meestal vlak naast elkaar te vinden zijn, en dat er maar 1 voordeur is. Als gevolg is er geen geografisch onderscheid, en is het dus niet nodig die in OSM te importeren.<br><br><br></div><div>Nu heb ik wel een mogelijke bug gevonden in mijn script. In <a href="https://download.agiv.be/Producten/GetDocument?id=90&title=Data_CRAB_pdf&x=Data_CRAB_pdf">https://download.agiv.be/Producten/GetDocument?id=90&title=Data_CRAB_pdf&x=Data_CRAB_pdf</a> staat vermeld dat een terrein object N huisnummers kan hebben. Maar volgens mij gebruik ik er maar 1 van (zie script lijn ~190). Nu weet ik niet hoe die N verschillende in een database zitten (die bestanden zijn niet echt eenvoudig te doorzoeken). Dus alle tips zijn welkom.<br><br></div><div>Misschien is het mogelijk om een hoop adressen zonder positie weg te krijgen (natuurlijk zal 1 terreinobject met verschillende huisnummers dan wel weer een voor verschillende adressen met dezelfde coordinaten zorgen)?<br><br></div><div>Groeten, Sander.<br></div></div></div></div>