[OSM-talk-be] import AGIV CRAB-data
Thomas
osm at aptum.nl
Wed Oct 29 18:45:04 UTC 2014
Wil je beide lijsten (busnrs en apptnrs) los in de JSON hebben, of
samengevoegd als “subadressenlijst”? Ik had het als dat laatste al
ingebouwd, maar ik kan het natuurlijk eenvoudig weer uit elkaar trekken.
De lijsten worden toch al los van elkaar opgebouwd.
Groeten,
Thomas
Sander Deryckere schreef op 29-10-2014 12:06:
> Hoi Thomas,
>
> Net het script wat verder aangepast voor de nieuwe data, en geuploaded
> naar jouw repo. Dus aan iedereen, gelieve vanaf nu vooral
> http://aptum.github.io/import.html te testen,
>
> Kan je de appartementsnummers en busnummers als aparte lijsten in de
> JSON zetten? Dan kan ik ook het script updaten om addr:flats te
> ondersteunen. Lijsten zijn het best aangezien ze gemakkelijker
> omgevormd kunnen worden naar de correcte formaat. Ook die best
> alfabetisch sorteren voor de diffs. En misschien enkel de lijsten aan
> de JSON toevoegen indien wel degelijk (dat zal bandbreedte sparen voor
> de vele adressen die geen busnummers of appartementsnummers hebben).
>
> Aangezien de overlappende en de niet overlappende nummers nu in
> verschillende kolommen staan, is daar geen verschillende CSS voor
> nodig. Een verschillende CSS voor de herkomst kan wel helpen.
> Momenteel staat die herkomst nog in CRAB:source om de waarden
> gemakkelijk te kunnen aflezen. Dus momenteel die tags nog niet gaan
> uploaden.
>
> Als het goed is voor iedereen, dan breng ik die tags naar de vorm
>
> * odbl:note=CRAB:manueleAanduidingVanGebouw
> * odbl:note=CRAB:geinterpoleerdObvNevenliggendeHuisnummersGebouw
> * ...
>
> odbl:note lijkt mij de meest neutrale van alle discardable tags, en
> het voorvoegsel CRAB: kan zorgen voor unieke CSS selectors.
>
> De grootste problemen momenteel zijn de huisnummers met een
> underscore. Ik kan moeilijk beslissen als ik die naar bis, ter, ... of
> naar /1, /2, /3, ... breng. Maar het overlaten aan de mapper kan er
> voor zorgen dat de huisnummers met een underscore rechtstreeks
> geuploaded worden.
>
> Het andere grote probleem is de spelling van de straatnaam. Dat is
> moeilijk om af te leiden met de beperkte OSM data die ik heb in de
> webpagina (vooral als er nog geen adressen in OSM zijn). Een
> spellingsverschil kan er voor zorgen dat huisnummers geuploaded worden
> waarbij addr:street verschilt van de straatnaam in OSM. Wat natuurlijk
> voor problemen zal zorgen. Maar hierbij kan Jo misschien helpen, of de
> JOSM validator.
>
>
> Als die problemen opgelost zijn, dan lijken de tools klaar, en wordt
> het tijd om enkele definitieve beslissingen te maken:
>
> * Huizen tekenen of niet
> * Aparte gebruikersnaam of niet
> * Welke tags moeten op de changeset
> * Hoe contacteren we het AGIV met opmerkingen?
> * ...
>
> Groeten,
> Sander
>
>
> Op 29 oktober 2014 08:39 schreef Sander Deryckere <sanderd17 at gmail.com
> <mailto:sanderd17 at gmail.com>>:
>
> 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
> <mailto: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
> <mailto: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
>> <mailto: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 <mailto: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 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 <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 <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/20141029/34ae8cef/attachment.htm>
More information about the Talk-be
mailing list