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

Wed Oct 29 04:08:14 UTC 2014

Hoe zit het met het nodige papierwerk rond de import ? Zijn daar al
vorderingen gemaakt ?

groeten

m

2014-10-26 13:18 GMT+01:00 Thomas <osm at aptum.nl>:

>  De code staat op https://github.com/aptum/aptum.github.io. De code van
> het python-conversiescript staat er nog niet op omdat ik nog wat dingen aan
> het omschuiven ben. Ik probeer dat script zo snel mogelijk ook daarbij te
> zetten. De nieuwste variant van het javascript en de website (met
> uitzondering van die twee regels code om 'mijn' tag in JOSM in te laden;
> regels 358-359) kun je bij Sander vinden:
> https://github.com/sanderd17/sanderd17.github.io/
>
> Het inladen van gegevens uit de overpass is op zich wel mogelijk, maar we
> moeten denk ik wel heel erg opletten dat het geen allegaartje wordt. CRAB
> en OSM strikt gescheiden houden heeft misschien ook wel voordelen; tenzij
> je een specifiek doel voor ogen hebt?
>
> Groeten,
> Thomas
>
> Jo schreef op 26-10-2014 12:58:
>
>  Hallo Thomas,
>
>  Waar staat de broncode nu? Ik had het graag nog 's bekeken. Ook de JS die
> ik de vorige keer gemist heb... Is er een mogelijkheid om wat je afhaalt
> met Overpass ook mee te geven naar JOSM? Of is dat niet zo'n goed idee.
>
> Van zodra duidelijk is welke discardable tags je gebruikt, zal ik een
> MapCSS-stijl maken.
>
>  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 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20141029/0be11338/attachment.htm>