<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Op 18 oktober 2014 10:18 schreef Marc Gemis <span dir="ltr"><<a href="mailto:marc.gemis@gmail.com" target="_blank">marc.gemis@gmail.com</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 dir="ltr">Tja, als ik dan nog eens naar de AGIV CRAB data op de eerste website kijk en vergelijk met wat ik al verzameld heb, dat weet ik weer waarom ik niet pro-imports ben.<div>Kijk maar eens naar de Vakbondstraat in Willebroek. Een gebouw met 2 verdiepingen en verschillende huisnummers op gelijkvloers en de eerste verdieping. Ofwel is de originele data niet juist ofwel is het conversie algoritme niet juist. Maar in de "geimporteerde" data ontbreekt meer dan de helft van de nummers tussen 9 en 41.</div><div><br></div></div></blockquote><div><br></div><div>Het is ook mogelijk dat sommige van die huisnummbers in CRAB geen positie hebben. Dit is opnieuw een bedrijf en een privé woning op één perceel (zelfs 1 gebouw, en dan nog boven elkaar). <br><br></div><div>In het oude script werden die gegevens totaal niet opgenomen. Zelf weet ik nog altijd niet goed wat ik er mee moet doen. Waarschijnlijk moet ik die apart classificeren, met een positie ergens centraal in de straat. Zodat mappers die na een survey op de correcte brievenbus of voordeur kunnen plaatsen.<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 dir="ltr"><div></div><div>Misschien een goede test voor Sander's algoritmes van punt 2 en 3. :-)</div><div><br></div><div>Een andere "test' voor die algoritmes: hoe gaan we om met POIs ? Die worden nu ofwel op het gehele gebouw getagged (bv. bij supermarkt) of als punt (indien slechts een deel van het gebouw is ingenomen). Nu ja, dit is de meest voorkoment guideline. Als het een punt is binnen een gebouw worden de adres gegevens dubbel gezet: op de POI en op het gebouw. Dus als je enkel adrespunten importeerd, waar zet je dan de POI informatie ? --- POI is bv. winkel met naam, type, openingsuren, website, enz.</div><div><br></div><div>Je kan nooit garanderen dat een import ID behouden blijft, dus daar mag/kan je je niet op baseren.</div><div><br></div><div>Tegen een volledig geautomatiseerde import zal ik me altijd verzetten omdat je zo teveel fouten introduceert. Liever minder snel en betere manuele controle. Bv. geen nummers importeren als het gebouw niet meer bestaat. Dus feitelijk liever minder data dan foutieve data.</div><div><br></div><div>Aan de andere kant besef ik ook wel dat je zonder import nooit op korte termijn alle adressen gaat hebben, maar het is niet omdat we aan een import zouden beginnen dat die "morgen" al af moet zijn. Daar mag ook best een aantal maanden, zo niet jaren over gaan. Zeker als de kwaliteit van de geïmporteerde data dan beter is.</div><div><br></div><div>mvg</div><span class=""><font color="#888888"><div><br></div><div>m</div></font></span></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2014-10-17 23:27 GMT+02:00 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>Bedankt voor alle informatie! Ik kom
nog maar net kijken bij OSM en had de import-list nog niet gezien.
Inmiddels heb ik alle relevante berichten van vorig jaar even
doorgenomen. Ik begrijp, samen met jullie informatie, nu een stuk
beter waar het geheel op hapert.<br>
<br>
Zoals ik het nu begrijp zijn er een viertal discussiepunten (los
van het meningsverschil over het al dan niet uitvoeren van de
“import” met een dedicated user-account):<br>
1) De conceptuele aanpak van de data: wat willen we op welke
manier in OSM hebben?<br>
2) De beoordeling van de kwaliteit van de data: hoe betrouwbaar
zijn de gegevens?<br>
3) De methode van de initiële import.<br>
4) De methode om de dataset up-to-date te houden<br>
<br>
Uit wat ik allemaal gelezen heb leid ik af dat er al heel veel
inspanningen geleverd zijn. Binnen de BE-community was er
enigszins overeenstemming, maar op de import-lijst was die er
niet. <br>
<br>
Het eerste discussiepunt lijkt altijd voor- en tegenstanders te
hebben van een bepaalde visie. Naar mijn mening is overeenstemming
lastig te bereiken omdat de achterliggende problematiek niet
uitgeklaard is dan wel kan worden. Het belangrijkste punt lijkt te
zijn of adresgegevens in een punt of als polygoon (de woning)
moeten worden geïmporteerd. Feit lijkt me dat gewoon niet helder
is wat een adres nu juist is. Verwijst een adres naar een
kadastraal perceel, een fysiek gebouw, een woon-eenheid binnen een
gebouw, een toegangspunt tot een privaat domein, een fysieke
voordeur, een brievenbus, etc. Eigenlijk enkel die eerste durf ik
echt te ontkennen (daar dienen kadastrale nummers immers voor).
Voor de rest is het begrip “adres” volgens mij gewoon niet nader
omschreven. Adressen werken omdat iedereen voor elk individueel
geval opnieuw beoordeelt waar in dat specifieke geval het adres
naar verwijst. Dat in een objectief, wereldwijd systeem te vatten
is zeer ambitieus.<br>
<br></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div>Dat is ook mijn mening. Ieder geval moet apart beoordeeld worden. Soms past een huisnummer beter bij een huis polygon. Soms is het slechts een brievenbus of een ingang. Soms zijn het ook meerdere gebouwen. Daarom is een lokale survey belangrijk. Niet om de outline van de gebouwen te bekijken, maar om te kijken waar het nummer hangt, en wat nu net met dat nummer bedoeld is. Vooral voor de eerste imports, en voor gebieden die moeilijker zijn dan wijken of rijhuizen.<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 class=""><div class="h5"><div class="gmail_extra"><div class="gmail_quote"><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>
Dat neemt natuurlijk niet weg dat de discussie wel gevoerd moet
worden (en dat is hij eigenlijk al, tot in den treure). Niemand
zal ontkennen dat beide systemen (nog los van de vele variaties op
deze systemen, verweven met meer of minder zaken koppelen in
relaties) voor- en nadelen hebben. Mijn gevoel zegt me dat een
pragmatische aanpak de enige manier is om vooruit te geraken. Ik
denk dat feitelijke omstandigheden (de wijze om de dataset
up-to-date te houden, de afwezigheid van gebouw-polygonen in een
groot deel van Vlaanderen) eigenlijk maken dat het héél lastig
wordt om enkel adresgegevens op polygonen te registreren. Ik denk
dat je niet ontsnapt om in sommige gevallen adresgegevens op een
punt te zetten. In het licht van consequent zaken op dezelfde
manier te doen lijken mij de punten dan het meest aangewezen. <br>
<br>
Een ander argument is meer uit de praktijk. Ik heb op een aantal
plaatsen gekeken waar gebouw-polygonen ingetekend zijn en waar de
adres-punten uit het CRAB niet op het overeenkomstige polygoon
vallen. Naar mijn idee staat het punt precies in het centroid van
het polygoon van het gebouw zoals dat bij AGIV gekend is. Daar
waar gebouw-polygonen beschikbaar zijn, zijn ze vaak ingetekend op
basis van een luchtfoto (die op die schaal toch een aanzienlijke
vertekening heeft). In vrijwel alle gevallen die ik bekeken heb is
het CRAB-adrespunt nauwkeuriger gepositioneerd dan de polygoon die
in OSM aanwezig is. Dat neemt natuurlijk niet weg dat er ook
fouten in het CRAB zitten.<br></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div>Er zijn gevallen waar het punt geplaatst is op de centroid van het gebouw, maar in de meeste gevallen zijn de punten centroids van de percelen (wat we dus net niet willen in OSM). Toch in de regio waar ik werk. Misschien zijn er verschillen per regio. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><div class="gmail_extra"><div class="gmail_quote"><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>
<br>
Ik wil hiermee geen oude koeien uit de gracht halen. Ik weet dat
het uitvoerig blijven discussiëren de community niet verder
richting consensus schuift en dat het zeer frustrerend is voor de
leden die hier heel veel moeite in stoppen om het te laten werken.
<br></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div>De consensus is die van een DoOcracy (<a href="http://www.communitywiki.org/cw/DoOcracy">http://www.communitywiki.org/cw/DoOcracy</a>). Automatische imports worden nooit erg geapprecieerd omdat er niet veel werk aan is, en het werk van anderen naar de knoppen kan helpen. Bij een import als deze (waar enkel wat tools ter beschikking gesteld worden, en waar individuele mappers nog veel werk hebben), zijn het de mappers die voor een groot deel beslissen. Als een mapper beslist dat een adres beter past als node, of als gebouw, dan is dat zo. <br><br></div><div>Ik wil er niet zozeer op hameren om het altijd als node of als gebouw te mappen. De combinatie tussen de twee is perfect bruikbaar (software kan heel eenvoudig centroids van gebouwen berekenen). Ik wil hoogstens wat inzichten geven zodat de mapper zelf kan beslissen als dat adres nu beter past op een node of gebouw.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><div class="gmail_extra"><div class="gmail_quote"><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>
<br>
Los van deze conceptuele keuze zijn de andere drie aspecten eerder
technisch/praktisch van aard. Wanneer de methodologie gekozen is,
zal een initiële test om de kwaliteit van de data te beoordelen
niet zo'n probleem zijn denk ik. Zoals ik het nu begrijp is het
belangrijkste struikelblok het “updateable” maken van de gegevens.
Sander legt met zijn bericht een hele hoop inhoudelijke zaken op
tafel. Hoewel ik nieuw ben bij OSM heb ik wel enige affiniteit met
GIS en ga ik me hier verder in verdiepen om misschien zelf ook bij
te kunnen dragen aan de technische aspecten. <br>
<br>
Volgens mij schetst Sander terecht dat de originele piste niet zo
handig is met zicht op het onderhouden van de gegevens. Ik heb
beide andere methoden even uitgeprobeerd. Via
<a href="http://sanderd17.github.io/8840.html" target="_blank">http://sanderd17.github.io/8840.html</a> lijken de punten steeds in
een perfecte verticale lijn te liggen. Volgens mij gaat daar nog
iets verkeerd in het script dat de OSM-bestanden opstelt. Maar
misschien doe ik ook wel iets verkeerd hoor... De wiki pagina
lijkt dan weer prima te functioneren.<br></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div>Oeps, komt er van als 3.2346396 geprogrammeerd is als longitude, i.p.v. de longitude van de adressen te nemen :D<br><br></div><div>Klein foutje. Zoals je ziet ben ik nog volop bezig met het ontwikkelen, en zit ik zelfs nog niet in de testfase.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><div class="gmail_extra"><div class="gmail_quote"><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>
<br>
Persoonlijk vind ik het om het even op welke manier de taken
beheerd worden. Naar mijn mening zullen de “imports” toch eerder
door ervaren leden gebeuren. Het hebben van een flashy interface
met mooie kaart die de status netjes weergeeft vind ik dan niet
belangrijk.<br>
<br>
Belangrijker is de opzet om het geheel te kunnen updaten in de
toekomst. Hoewel ik me nog in de technische aspecten moet
verdiepen, lijkt het me essentieel om een tool te hebben die een
soort van diff kan maken tussen een (geupdate) CRAB-dataset en de
OSM-situatie. Die gegevens moeten dus gematcht worden met elkaar.
In de situatie dat een adrespunt boven een niet-overeenkomstig
gebouw-polygoon (met eigen adres-gegevens) komt te liggen, lijkt
het me heel lastig die situatie goed op te lossen. Op het eerste
zicht is dat ook een probleem dat zich best vaak zal voordoen. Bij
de initiële import gebouw-polygonen verplaatsen naar waar ze horen
lijkt me lastig, omdat we geen dataset hebben waarmee we dat
nauwkeurig kunnen doen. Overtekenen van een luchtfoto is toch echt
behelpen. Daarentegen zal in veruit de meeste gevallen het
adres-punt vanuit het CRAB wel op een “juiste” locatie liggen (het
centroïd van het gebouw-polygoon). In zo'n situatie de locatie van
het punt weggooien en de adresgegevens mergen met het polygoon dat
kennelijk daarmee overeenstemt lijkt mij echt knoeien. Daarnaast
zal ter plaatse gaan kijken ook weinig oplossen. De precieze
vormen van een gebouw op enkele meters nauwkeurig bepalen zonder
professionele apparatuur lijkt mij zeer lastig.<br></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div>De positie van de CRAB data (toch waar ik werk) is heel vaak de centroid van het terrein (de database zelf spreekt ook van terreinobjecten, en geeft coordinaten aan terreinobjecten, de terreinobjecten zijn dan op hun beurt weer gelinkt aan adressen). Aangezien percelen een heel grillige vorm kunnen hebben, is het mogelijk dat de centroid dichter bij verschillende andere gebouwen ligt dan het gebouw waarvoor het bedoeld is. Maar meestal kan je a.d.h.v. hagen en muren wel uitmaken voor welk gebouw het bedoeld is.<br><br></div><div>In ieder geval zal een vergelijking op basis van afstanden genoeg marge moeten nemen. Gelukkig, als er adressen gewijzigd worden, dan is de wijziging normaal tamelijk groot (en geen kleine shift van 1 huis), zodat een ruime afstandsvergelijking die problemen ook zal ontdekken.<br><br></div><div>Het is ook zo, als er b.v. 10 huisnummers bij komen in een straat, en die huisnummers staan op posities die al een huisnummer hebben in OSM, dan bekijk je best eens de volledige straat, want dan is er een grote kans dat de hele straat hernummerd is. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><div class="gmail_extra"><div class="gmail_quote"><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>
<br>
Ik zeg dit niet om mijn eerdere standpunt over het al dan niet in
stand houden van de adressen als punten te herhalen. Ik wil enkel
aangeven dat het volgens mij heel lastig wordt als die adrespunten
niet gehandhaafd worden. Ik kan me geen algoritme voorstellen dat
in zo'n situatie de punten aan de polygonen weet te matchen,
wanneer zo'n polygoon niet precies onder zo'n punt ligt. Een soort
van afstand-algoritme zal niet helpen omdat er in veel gevallen
een naburig gebouw dichter bij het adrespunt ligt dan het
daadwerkelijk overeenkomstige gebouw-polygoon.<br>
<br>
Omgekeerd denk ik persoonlijk dat de adres-punten zouden kunnen
helpen bij het corrigeren van de locatie van gebouwen. De vorm van
een gebouw is doorgaans rechthoekig. De oriëntatie is doorgaans
loodrecht <br>
<br></div></div></blockquote></div></div></div></div></blockquote><div>Zie bovenstaande opmerkingen. De CRAB positie is net wat we niet in OSM willen, dus zullen we moeten werken met een afstandsmarge (die tamelijk groot is), en maakt het geen verschil als het nu getagd is op het gebouw of op een node.<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 class=""><div class="h5"><div class="gmail_extra"><div class="gmail_quote"><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>
Volgens mij komt het er eigenlijk op neer dat het veel eenvoudiger
zou zijn als we ook alle gebouw-contouren zouden hebben. Maar daar
zal iedereen het wel mee eens zijn. Mijn mening op dit moment is
dus dat het in deze realiteit heel erg lastig wordt om het te doen
met enkel adresgegevens op gebouwen. Daarnaast zie ik weinig grote
bezwaren tegen het in stand houden van de adrespunten. Naar mijn
mening is de meest pragmatische keuze dus het importeren van de
adresgegevens als punt en het updaten van die punten. Dat kan
volgens mij het eenvoudigst gedaan worden door een CRAB-id mee te
importeren (ik besef dat dit vloeken in de kerk is...). Echter,
ook met afstands-algoritmen moet er een en ander mogelijk zijn.<br>
<br></div></div></blockquote></div></div></div></div></blockquote><div>Een CRAB id zou een mogelijk zijn. Maar ik denk dat de algoritmes zo kunnen ontwikkelen dat ze nooit een vals-positieve mismatch aanduiden. Vals-positieve mismatches moeten absoluut vermeden worden, omdat dan sommige mappers de kaart gaan aanpassen om de statistieken te verbeteren. Echte fouten zijn sowieso zeldzaam, en beperken zich meestal tot spellingsfouten, of verkeerdelijke copy-pastes van andere nodes. Deze zullen in de meeste gevallen gemakkelijk ontdekt worden (bijvoorbeeld doordat een straat 1 huisnummer te kort heeft, een huisnummer dat verkeerdelijk met een andere straatnaam getagd is). Missen is menselijk, en iedere dataset zal altijd fouten bevatten (ook CRAB). Met de derde tool valt het zelfs zo te programmeren dat het afstandsverschil per gemeente of per straat apart aan te passen valt door gebruikers van de tool (zo kan je voor rijhuizen kleinere afstandsverschillen verwachten dan voor industriepercelen).<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 class=""><div class="h5"><div class="gmail_extra"><div class="gmail_quote"><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>
Daarnaast lijkt het mij belangrijk dat het hele proces goed
geautomatiseerd kan verlopen. Aan een initiële import die niet te
onderhouden valt heeft niemand wat. Integendeel; het eventueel
moeten mergen van zo'n hoop data in OSM met een geüpdatet CRAB
lijkt mij echt een nachtmerrie. In dit licht lijkt de derde optie
van Sander mij zondermeer de meest interessante.<br>
<br>
Ik kom nog terug op een aantal technische punten die Sander
aanhaalt. Complimenten voor iedereen die hier al zo hard aan
gewerkt heeft!<br>
<br>
Vriendelijke groeten,<br>
Thomas<br></div></div></blockquote></div></div></div></div>
<br></blockquote></div><br></div><div class="gmail_extra">Als je wat wil helpen, dan kan ik gerust de code die ik heb tot nu toe naar git uploaden. Ik zou enkel Ben nog eens moeten vragen onder welke licentie hij de code wil vrijgeven. Aangezien mijn extract-scripts volledig op die van Ben zijn gebaseerd.<br><br></div><div class="gmail_extra">Groeten,<br></div><div class="gmail_extra">Sander<br></div><div class="gmail_extra"><br></div></div>