[OSM-talk-be] import AGIV CRAB-data

Sun Oct 26 19:10:16 UTC 2014

Zo, even wat kwalitatief onderzoek gedaan:

* De kwaliteit van de adressenlijst is over het algemeen beter, maar voor
enkele huizen is het ook slechter. Zo heb ik de Ieperstraat in Staden
(8840) bekeken, daar werd voor bepaalde huizen de positie in de
adressenlijst net verder van de straat gezet (in de tuin), terwijl het net
bij rijhuizen moeilijk is om de tuin te volgen en het juiste huis te
vinden. Voor de meeste huizen ging het dan net omgekeerd en werd de positie
dichter bij de straat gezet in de adressenlijst
* Het probleem in de Mastbos straat is opgelost in de adressenlijst. Bij de
Louisa-Marialaan blijft het probleem van dubbele huisnummers echter bestaan
(hoe worden verwijderde huisnummers behandeld in de adressenlijst?)
* Hoewel de herkomst soms aangeeft dat het afgeleid is van een gebouw, kan
dit ook betekenen dat het afgeleid is van meerdere gebouwen. Zo kan een
adres positie in het midden van een boerderij liggen, en niet op het
hoofdgebouw. Als die boerderij dan nog eens 2 huisnummers heeft, dan wordt
het helemaal onduidelijk.

Dus is de adressenlijst meestal wel beter, maar ook soms minder goed.
Bepalen welke de beste is, dat is programmatisch zo goed als onmogelijk.
Aangezien 2 databases ondersteunen voor heel wat extra werk zal zorgen,
stel ik momenteel voor om toch bij de adressenlijst te blijven, en de
adresposities DB weg te negeren.

De code zelf lijkt behoorlijk te werken. Enkel de sortering mankeert nog.
De nummers van "missing" en "wrong" kolommen komen perfect overeen, en ook
de accenten werken zonder probleem.

Groeten,
Sander

Op 26 oktober 2014 11:41 schreef Jo <winfixit at gmail.com>:

> Het lijkt mij ook aangewezen om voor de nummers die in de wronglaag worden
> geladen geen addr:housenumber/addr:street te gebruiken. Daar zou ik enkel
> discardable keys gebruiken, die we dan zichtbaar maken mbv MapCSS. (Wel
> Expert modus gebruiken, anders worden ze niet getoond)
>
> Zo ontstaat er geen verwarring bij het samenvoegen van die lagen. Als die
> nodes enkel discardable keys bevatten, zoals:
>
> "tiger:upload_uuid", "tiger:tlid", "tiger:source", "tiger:separated",
> "geobase:datasetName", "geobase:uuid", "sub_sea:type", "odbl",
> "odbl:note",  "yh:LINE_NAME", "yh:LINE_NUM", "yh:STRUCTURE",
> "yh:TOTYUMONO",     "yh:TYPE", "yh:WIDTH_RANK"));
>
> dan worden die allemaal weggehaald en dan zal de validator daarover
> klagen. Even testen. Ai, de tags en hun waardes worden pas weggehaald na de
> validatie. Dat moet nog beter kunnen.
>
>
> Wat me ook belangrijk lijkt, is om voor die wrong-laag, upload=no aan te
> zetten in het XML-bestand:
>
> <osm version="0.6" upload="no" generator="Python/JS script">
>   <changeset>
>    <tag k="source" v="CRAB"/>
>   </changeset>
>
> Dan zal JOSM tenminste toch al klagen, als je die laag zonder meer zou
> proberen door te sturen.
>
> Met die changeset/source tags wordt spijtig genoeg geen rekening gehouden,
> voor zover ik kan zien. Maar toch lijkt het me wel goed om die toe te
> voegen.
>
> Jo
>
>
>
>
>
> Op 26 oktober 2014 11:09 schreef Jo <winfixit at gmail.com>:
>
>> Voor tags waarvan je niet wilt dat ze naar OSM worden opgeladen is het
>> het beste om tags te gebruiken die automatisch zullen worden verwijderd,
>> voorbeelden zijn created_by en odbl. Laat me weten als er meer nodig zijn.
>> Ze zitten ergens in de broncode van JOSM.
>>
>> Ik zou dus die tags gebruiken ipv CRAB:source.
>>
>> Jo
>>
>> Op 26 oktober 2014 10:20 schreef Thomas <osm at aptum.nl>:
>>
>>  De validator geeft inderdaad netjes melding van de meerdere punten op
>>> elkaar. Ik vraag me af of we daar nog iets mee moeten. Veel (alle?) van de
>>> adressen zonder positie uit jouw script vallen nu samen met een ander punt.
>>> Voor wat ik zo snel even kon bekijken zijn dat toch best veel punten. Daar
>>> moet dus sowieso handmatig op ingegrepen worden (zoals eigenlijk op heel
>>> veel punten).
>>>
>>> Moeten we nog iets doen met een hulptag over appartementsnummer,
>>> busnummers of huisnummerlabels? Over dat laatste zegt het AGIV in de
>>> documentatie: “Opgelet: Komen er op de coördinaat van het CRAB adres
>>> meerdere huisnummers voor die in dezelfde straat liggen, dan bevat het
>>> label het laagste en het hoogste huisnummer (bv. label 10-14 voor het
>>> perceel met de huisnummers 10, 12 en 14 in de Molenstraat).”. Het zou ook
>>> mogelijk moeten zijn om voor deze punten automatisch een samengestelde
>>> addr:housenumber-value te maken die een samenstelling is van de
>>> verschillende punten die samenvallen. Dat valt nog wel te coderen.
>>>
>>> Los van de technische vraag is de inhoudelijke vraag dus eigenlijk: wat
>>> doen we met die samenvallende punten? Schuiven we de punten handmatig uit
>>> elkaar, of voegen we ze samen met een samengesteld label als 15A-B voor de
>>> adressen “15A” en “15B”. Dat laatste kan automatisch, maar het is dan weer
>>> de vraag of dat wenselijk is. Er zullen vast situaties zijn waarin je die
>>> punten niet wil mergen maar juist individueel houden. Het hele idee is ook
>>> dat we puur adressen (en eventuele bisnummers) in OSM stoppen en geen
>>> subadressen (busnummers en appartementnummers). Dus: indien de adrespositie
>>> voor twee adrespunten gelijk is, moeten deze dan automatisch worden
>>> samengevoegd tot 1 punt met een samengesteld label, of laten we dat ter
>>> beoordeling van de mapper?
>>>
>>> Ik ga nog even kijken naar wat checks op die straatnamen met een
>>> gelijkaardige naam en een verschillende id. Het zou interessant zijn als
>>> die gevallen opgepikt worden. Ik ben het ermee eens dat veel van de
>>> foutopsporing in het algemeen best aan de JS-kant gebeurt. Daar heb je ook
>>> je overpass-query beschikbaar. Aan de andere kant vind ik dat een aantal
>>> basis-integriteits-dingen toch al door het python-gedeelte mogen worden
>>> opgepikt. De loopduur van het script moet aan de andere kant ook weer zo
>>> kort mogelijk gehouden worden. Ik denk dat het een beetje zichzelf wijst.
>>> Een aantal checks (zoals zelfde straatnaamid, verschillende straatnaam)
>>> hebben geen of een zeer lage kost, terwijl deze toch een zekere
>>> basiskwaliteit van de dataset opleveren.
>>>
>>> De scripts eerst vergelijken en evalueren lijkt me prima. Ik heb een
>>> eigen github aangemaakt zodat het onderscheid tussen beide scripts nu eerst
>>> helder is. Ik heb de data van de laatste conversie alvast opgeladen samen
>>> met de webpagina en het JS. Aan de webpagina heb ik helemaal niets
>>> gewijzigd. Aan het JS heb ik enkel de extra tag toegevoegd, binnen een
>>> conditional.
>>>
>>> Ik ga nog wat kleine puntjes aanpakken en het python-script wat
>>> robuuster opbouwen. Misschien dat ik met een parallelle architectuur nog
>>> wat snelheidswinst kan boeken. Vanaf nu kan er in elk geval weer getest
>>> gaan worden. Ook alle problemen met de dataset die in de laatste mails
>>> gemeld werden ga ik nader bekijken.
>>>
>>> Bij deze dus het verzoek aan al diegenen die mee willen testen: jullie
>>> kunnen op http://aptum.github.io/import.html mijn script testen. Het
>>> verschil met de pagina van Sander is dat mijn pagina gebruik maakt van de
>>> adressenlijst in plaats van de adresposities. Uiterlijk is er niets
>>> veranderd, maar het conversiescript is vrijwel compleet nieuw. Daarnaast
>>> heb ik een extra tag toegevoegd (CRAB:source) die weergeeft waar de
>>> informatie uit het CRAB vandaan komt. Deze geeft aan hoe het adrespunt
>>> bepaald is, en zegt daarmee iets over de nauwkeurigheid van de plaats van
>>> het label. Deze tag mag niet naar OSM opgeladen worden! Graag hoor ik het
>>> als er nog problemen gesignaleerd worden. Bij deze ook credits voor het
>>> vele en goede werk van Sander en voor het ter beschikking stellen van alle
>>> code!
>>>
>>> Groeten,
>>> Thomas
>>>
>>> Sander Deryckere schreef op 25-10-2014 21:17:
>>>
>>>
>>>
>>> Op 25 oktober 2014 20:57 schreef Thomas <osm at aptum.nl>:
>>>
>>>>
>>>> Inmiddels ook de codering in gehoorzaamheid gedwongen. Blijkt dat de
>>>> codering van de shapefile gewoon Latin-1 is en niet die vage CP-720. Dat
>>>> scheelt ook maar weer.
>>>>
>>>> De snelheid van mijn script valt me al bij al wel mee. Op dit moment
>>>> gebruikt hij maar 1 thread. Het inlezen van het bestand in de dictionaries
>>>> duurt zo'n 50 minuten. Het schrijven naar de JSON-bestanden een kleine 10
>>>> minuten (op een SSD'tje). Het schrijven gaat volgens mij wat trager omdat
>>>> ik de adres-dictionary vervangen heb door een tuple. Dat scheelt toch een
>>>> kleine 500MB in geheugengebruik. In totaal gebruikt het script maar iets
>>>> van 2GB ram dacht ik, maar dat moet ik nog even nakijken. Sinds die
>>>> wijziging heb ik in elk geval geen geheugenproblemen meer gehad.
>>>>
>>>> Qua tags hoeven we inderdaad enkel de addr:housenumber en addr:street
>>>> over te nemen. Daarnaast wil ik graag het herkomst-veld als tag invoeren,
>>>> zodat de punten gestyled kunnen worden op basis daarvan. Naar mijn idee is
>>>> die herkomst zeer bepalend voor de “nauwkeurigheid” van de punten. Ik heb
>>>> dat nu geïmplementeerd als een “CRAB:herkomst”-tag. De Engelse variant
>>>> “CRAB:source” vond ik een beetje misleidend. Aan de andere kant gaat het
>>>> natuurlijk wel over hoe ze de locatie van het punt bepaald hebben. Dat kun
>>>> je dus wel als “source” zien.
>>>>
>>>
>>>  CRAB:source=* lijkt me goed. Als de waarden enigszins duidelijk zijn,
>>> dan is alles ok.
>>>
>>>>
>>>> Daarnaast misschien nog iets van een tag om waarschuwingen mee te
>>>> communiceren, bijvoorbeeld over de schrijfwijze van de straatnaam. Aan de
>>>> andere kant heb ik geen enkel geval kunnen vinden waar twee adressen een
>>>> zelfde straatnaam-id hebben maar een verschillende straatnaam (bijvoorbeeld
>>>> een andere spelling). Dat soort fouten lijken me maar beperkt aanwezig en
>>>> kunnen dus waarschijnlijk allemaal opgevangen worden met de FIXME-tag. Het
>>>> huidige gebruik (om punten zonder locatie mee aan te geven) is in feite
>>>> overbodig, omdat alle punten een locatie hebben.
>>>>
>>>>   De JOSM validator kan hier ook nuttig zijn. Als de coordinaten
>>> volledig overeenkomen, dan zal de validator sowieso klagen denk ik. Dus is
>>> een fixme tag misschien niet volledig noodzakelijk
>>>
>>> De straatnaam id is in de posities database de enige manier om de
>>> straatnaam te vinden. Dus als er enige overeenkomst tussen de databases is,
>>> dan is het normaal dat je geen straatnaam-id vindt met twee verschillende
>>> namen. De andere kant kan wel voor komen: dezelfde straatnaam (of bijna
>>> dezelfde) met een verschillende straat id.
>>>
>>>
>>>>  Ik ben nu nog wat aan het kijken welke fouten ik met het
>>>> python-script moet opsporen en welke best in de javascript naar boven
>>>> gehaald kunnen worden in combinatie met de overpass-query. Het
>>>> belangrijkste zijn de punten die samenvallen. Dat is een situatie die niet
>>>> ingevoerd mag worden in OSM, dus ook hier lijkt een FIXME-tag mij het meest
>>>> geschikt. Dat ga ik in elk geval nog even netjes documenteren.
>>>>
>>>>   Ik zou het foutopsporen vooral voor de JS kant houden. Dan kunnen we
>>> dat gemakkelijker aanpassen (zonder een script van een uur te draaien om
>>> dan een klein tikfoutje te ontdekken).
>>>
>>>
>>>>  Nog een praktisch punt: hoe willen we deze tweede variant beschikbaar
>>>> stellen? Moet dat naast de huidige komen te staan zodat we kunnen
>>>> vergelijken, of moeten we juist vermijden dat er twee varianten in gebruik
>>>> zijn en dat er verwarring ontstaat? Voor de gewone gebruiker is er
>>>> eigenlijk geen verschil tussen beide systemen, dus dat is potentieel
>>>> verwarrend. Anderzijds is het in de huidige beperkte opzet niet zo'n punt
>>>> en misschien juist handig. Wat zijn jullie ideeën hierover?
>>>>
>>>>   Ik zou het nog even naast elkaar houden, kwestie van vergelijking.
>>> Na het evalueren van de tools kunnen die dan onder een beter adres
>>> beschikbaar gesteld worden.
>>>
>>>  Host je het onder je eigen server (desnoods je eigen github account)
>>> of wil je toegang tot de repo die ik nu heb?
>>>
>>>  Groeten,
>>>  Sander
>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Talk-be mailing listTalk-be at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-be
>>>
>>>
>>>
>>> _______________________________________________
>>> Talk-be mailing list
>>> Talk-be at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
>>>
>>
>
> _______________________________________________
> Talk-be mailing list
> Talk-be at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20141026/4db166bf/attachment.htm>