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

Wed Oct 29 07:39:43 UTC 2014

Nog niet,

eerst onze tools maken, dan kunnen we het opnieuw presenteren.

Groeten,
Sander

Op 29 oktober 2014 05:08 schreef Marc Gemis <marc.gemis at gmail.com>:

> 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
>>
>>
>
> _______________________________________________
> 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/0f29eb07/attachment.htm>