[OSM-talk-be] import AGIV CRAB-data
Thomas
osm at aptum.nl
Sat Oct 25 18:57:03 UTC 2014
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.
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.
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.
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?
Groeten,
Thomas
Sander Deryckere schreef op 25-10-2014 20:17:
>
>
> Op 25 oktober 2014 18:46 schreef Thomas <osm at aptum.nl
> <mailto:osm at aptum.nl>>:
>
> Ik ben inmiddels bijna klaar met het nieuwe script dat de
> adressenlijst (in plaats van de adresposities) moet beschikbaar
> stellen via de website die Sander gemaakt heeft.
>
> Geweldig nieuws ;)
>
> Het oude script kon ik maar voor kleine stukjes hergebruiken omdat
> het bestandsformaat en de datastructuur toch redelijk anders zijn.
> Ik ben uitgegaan van precies dezelfde JSON-uitwisselbestanden te
> genereren zodat de website wel volledig compatibel is (op
> misschien wat extra tags in javascript na dan). Het was niet
> eenvoudig om een goed werkend script op te zetten vanwege de door
> Sander genoemde coderingsproblemen en vanwege het feit dat deze
> adressenlijst in feite 1 grote tabel is tegenover de adresposities
> die in feite een 'database' zijn of een collectie van kleinere
> tabellen. Daardoor liep ik tegen nogal wat geheugenprobleempjes aan.
>
> De beschikbare modules om GML in te lezen in python bleken niet
> robuust genoeg om én met de vreemde codering om te gaan én met de
> enorme omvang van het bestand (ca. 3GB). Daarom heb ik ervoor
> gekozen om als bron het shp-bestand te gebruiken (dat 'slechts'
> 1GB in omvang is, door een efficiëntere datastructuur). Daarmee
> kreeg ik wel alles aan de praat.
>
>
> Ik had ook al wat zaken opgezocht om het GML bestand te splitsen en
> pas daarna te verwerken, om zo slechts XML kind per kind in het
> geheugen te laden en geen geheugen tekort te komen. Maar dat werd een
> serieus gepruts, en ik verwachtte ook dat het te traag zou zijn door
> de vele lees en schrijf operaties.
>
> Geheugenproblemen had ik sowieso verwacht, want zelft met het huidige
> script moet ik zorgen dat Firefox en JOSM alletwee gesloten zijn voor
> ik het script start. Anders loopt mijn computer onherroepelijk vast in
> het page-swapping.
>
>
> Ik ben nu een aantal extra checks in de code aan het inbouwen en
> te kijken wat handig is qua extra tags (evt. gekoppeld aan wat
> CSS). Het blijft ook wat worstelen met de omvang. Mijn eerste
> tests werken in elk geval bij mij. Als het een beetje wil komt dat
> dus dit weekend af. Ook alle gemelde 'problemen' met de huidige
> dataset ga ik bekijken in deze nieuwe dataset.
>
> Voor alle duidelijkheid: voor de gebruikers verandert er weinig
> tot niets tegenover de huidige versie. Belangrijkste wijzigingen
> zijn het feit dat er punten zonder positie zullen zijn en dat er
> misschien wat extra tags automatisch ingeladen worden in JOSM als
> je een straat importeert. Die extra tags moeten helpen om de
> informatie naar waarde te schatten. In elk geval in deze eerste
> test-fase kunnen ze zeer handig zijn om beter bepaalde zaken te
> begrijpen.
>
> Ik heb nu voor het patroon “CRAB:key” gekozen als key voor de tags
> die ik in JOSM inlaad maar die niet in OSM thuishoren. Zijn er
> alternatieve patronen voor dit soort “tijdelijke” werk-tags die
> OSM nooit mogen bereiken? In de link die Marc eerder doorstuurde
> lees ik vooral dat onze Nederlanders een aantal overbodige tags in
> OSM hebben zitten n.a.v. een aantal imports. Het lijkt me op zich
> een mooi streven om al dat soort tags buiten OSM te houden, wat
> onze 'import' betreft.
>
> Moet er overigens nog een “source=CRAB”-tag toegevoegd worden, of
> willen we dit juist vermijden omdat het toch al niet om een
> automatische import gaat?
>
>
> source=* tags zijn beter op hun plaats op het changeset object dan op
> objecten in de DB. Natuurlijk kan een specifieke bron (zoals afkomstig
> van de voordeur, gebouw or perceel) wel op het object zelf.
>
> Postcode en gemeente zijn sowieso niet nodig, die kunnen gerust uit de
> JSON gelaten worden. Welke andere keys twijfel je nog over?
>
>
> Groeten,
> Thomas
>
> Sander Deryckere schreef op 25-10-2014 17:52:
>> Hmm, blijkbaar hebben alle tabellen een mogelijkheid tot deleten
>> via "einddatum".
>>
>> En blijkbaar gaat dat niet altijd samen.
>>
>> Ik heb nu net eens het script laten lopen met alle records waar
>> "einddatum" bijstond genegeerd, en dat resulteert vooral in
>> terreinobjecten die genegeerd worden, waardoor er vooral extra
>> adressen zonder positie zijn :/
>>
>> Heb ook eens de Koningin Louisa-Marialaan bekeken met die nieuwe
>> data, en daar blijkt er nu geen verschil te zijn O_o
>>
>> Dus denk ik dat ik het script nog niet zal aanpassen.
>>
>> Groeten,
>> Sander
>>
>> Op 25 oktober 2014 16:11 schreef Sander Deryckere
>> <sanderd17 at gmail.com <mailto:sanderd17 at gmail.com>>:
>>
>>
>>
>> Op 25 oktober 2014 14:48 schreef Sus Verhoeven
>> <susvhv at gmail.com <mailto:susvhv at gmail.com>>:
>>
>> In Leopoldsburg 3970 op de Koningin-Louisalaan is er in
>> CRAB een hele reeks huizen met dubbele huisnummers niet
>> op dezelfde plaats, in GRB staat er maar een van deze
>> reeksen.
>> Eigenaardig.
>>
>> Sus
>>
>>
>> Dit lijkt een straat die onlangs hernummerd is, en waarvan de
>> oude nummers nog niet verwijderd zijn.
>>
>> Ook de GRB basiskaart is niet volledig duidelijk. Zo is er
>> daar een nummer 13-125 te zien, wat een veel te grote range
>> is om te kunnen kloppen. Ik zou voorstellen om eens ter
>> plaatse te gaan kijken wat er nu echt juist is.
>>
>> Volgens de documentatie van de databases zouden ze verouderde
>> nummers moeten deleten door er een "einddatum" aan te geven.
>> In het extract script test ik ook op die einddatum, dus als
>> ze correct verwijderd zijn, dan zouden ze niet meer in de
>> data mogen voorkomen.
>>
>> Het is natuurlijk niet eenvoudig om in dit geval te
>> controleren als het script of de data fout is, omdat het nu
>> eenmaal niet vaak gebeurt dat een straat hernummerd wordt.
>>
>> In Leuven werd onlangs een straat hernummerd (zie
>> http://www.nieuwsblad.be/article/detail.aspx?articleid=DMF20130218_00473793)
>> en ik denk dat de CRAB data overeenkomt met de huidige data,
>> dus dat de verwijderde nummers wel degelijk niet meer
>> zichtbaar zijn. Maar 1 voorbeeld is natuurlijk wat weinig om
>> op voort te gaan.
>>
>> Groeten,
>> Sander
>>
>>
>>
>>
>> _______________________________________________
>> Talk-be mailing list
>> Talk-be at openstreetmap.org <mailto:Talk-be at openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-be
>
>
> _______________________________________________
> Talk-be mailing list
> Talk-be at openstreetmap.org <mailto: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/20141025/bb2d7101/attachment.htm>
More information about the Talk-be
mailing list