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

Sun Oct 26 10:09:16 UTC 2014

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20141026/b2a73887/attachment.htm>