Op 24 oktober 2014 01:13 schreef Thomas <o...@aptum.nl>: > 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. > > 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. > > Ik begrijp niet goed of dat nu de subadressen zijn binnen CRAB of gewone > adressen, maar dan een bisnummers (zie ook > https://www.agiv.be/~/media/agiv/producten/crab/documenten/xgrabobjectcataloogv114.pdf > pagina 15 en 29). >
OPGELET: 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: https://download.agiv.be/Producten/Detail?id=102&title=CRAB_adresposities > 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. > > 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. > > 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. > > 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? > > Deze had ik nog niet gezien. > 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. > > 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. > > Groetjes, > Thomas > > > 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: https://github.com/sanderd17/sanderd17.github.io/blob/master/extract.py 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. Nu heb ik wel een mogelijke bug gevonden in mijn script. In https://download.agiv.be/Producten/GetDocument?id=90&title=Data_CRAB_pdf&x=Data_CRAB_pdf 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. 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)? Groeten, Sander.
_______________________________________________ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
