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

Sat Nov 1 08:56:09 UTC 2014

Op 1 november 2014 01:43 schreef Thomas <osm at aptum.nl>:

>  Je verbeteringen vind ik zeer goed Sander! Bij mij laadt de pagina nu
> echter niet, met een foutmelding “'section' is null” op loadstreets.js
> ~664. Het lijkt fout te gaan wanneer in de URL de GET-parameter
> collapsedSections geset wordt, maar zonder waarde blijft. Als ik die
> parameter handmatig uit de URL verwijder doet hij het perfect! (tot ik op
> update druk...).
>

Hmm, dat was dezelfde bug als die van Marc. Ik had die opgelost, maar mijn
push naar de online repo was niet doorgekomen. Zou nu ECHT opgelost moeten
zijn.

>
> Ik ben (helaas) nog steeds bezig met het script. In mijn vorige mail
> schreef ik dat de postcodes en de gemeenten schijnbaar niet helemaal
> overlappen. Hoewel dat zeker klopt, ben ik er nu van overtuigd dat ik met
> die check toch wel meer dan 100 fouten in het CRAB gevonden heb. In de 250+
> adrespunten die ik zo geïdentificeerd heb, blijkt het in héél wat gevallen
> om een postcode en een gemeente te gaan die helemaal niet aan elkaar
> grenzen, en soms meer dan 50km uit elkaar liggen. Het moet dus wel om
> fouten gaan. Daarmee heb ik dus een forse set fouten geïdentificeerd...
> Heeft iemand hier een goede ingang bij het AGIV om dit door te geven? Ik
> werk nu aan een nette lijst met alle gegevens.
>
> Ha, net het volgende ontdekt. Voor de fusie in de jaren '70 had
Oostnieuwkerke de postcode 8820. Sinds de fusie hebben we echter de
postcode van Staden (8840). Raar genoeg is 8820 nu wel de postcode van
Torhout (ik weet niet wat hun postcode voor de fusie was).

Als je nu dus de adressen van 8820 bekijkt (
http://aptum.github.io/import.html?pcode=8820&loadOsm=true&collapsedSections=comparison,export,data#data),
dan zie je dat er 2 adressen nog altijd in Oostnieuwkerke liggen (2 dorpen
ten zuiden van Torhout).

Kan je nog eens controleren als die adressen in de adressenlijst niet
aangegeven zijn als "verwijderd" op een of andere manier? Als dat niet
gebeurd is, dan zij dat duidelijk 2 fouten in de CRAB adressenlijst. En
waarschijnlijk dezelfde fout als die andere 100 fouten.

> Dit is eigenlijk (naast dan de afwijkende adres-labels) de enige
> inconsistentie die ik op basis van de data zelf kan vaststellen in de
> adressenlijst. Alle adressen vallen netjes onder een postcode en zo. Dus
> voor onze huidige opzet is er helemaal geen probleem, zoals Sander al
> aangaf. Ik neem de vraag naar postcodes en gemeenten wel mee; ik zorg dat
> deze in de JSON aanwezig zijn. Een verdere verwerking via de javascript is
> dan triviaal. Het importeren van die gegevens in de vorm van discardable
> tags lijkt mij ook helemaal geen probleem. Als dat kan bijdragen aan het
> controleren van die gegevens in OSM lijkt me dat enkel een toevoeging.
>
> De uitspraak van Ben dat er situaties zijn waar postcode, straat en
> huisnummer niet identificerend zijn (naast de busnrs/apptnrs dan) vind ik
> intrigerend. Ik ben wat checks aan het doen op de dataset om te kijken of
> ik dit soort situaties kan vinden. Ik kom hier nog op terug, want onze
> huidige classificatie is wel gebaseerd op het feit dat die drie elementen
> identificerend zouden moeten zijn.
>
> Voor wat betreft de relaties tussen de huisnummers en straten sluit ik mij
> deels aan bij Ben: vanuit mijn informatica-achtergrond ben ik een groot fan
> van dit soort relaties. Vanuit mijn ervaringen met niet-informatici weet ik
> echter dat dat soort abstracte koppelingen die geen zichtbare weerslag
> hebben en puur een ordening op meta-niveau zijn vaak voor ellende zorgen.
> Ik vind dat soort relaties een zeer elegante oplossing, maar tegelijkertijd
> te abstract voor een brede toepassing.
>
> Het toevoegen van postcode en gemeente tags op een adres vind ik dan weer
> lastig; waar houdt het op? Ik denk dat iedereen het absurd vindt om op elke
> tag het land te mappen, maar waarom wel de gemeente? Wat mij betreft vormen
> die gemeentegrenzen toch een basisonderdeel van de kaart. Als we al niet op
> gemeentegrenzen kunnen vertrouwen dan wordt het wel heel lastig. Voor de
> postcodes ligt dat weer iets anders. Postcodes hebben volgens mij puur een
> functie voor postadressen. Wat mij betreft mag dat op de adressen getagd
> worden. Een postcode is naar mijn gevoel ook echt iets wat een eigenschap
> is van een adres, in tegenstelling tot een gemeente dat echt voor een
> grondgebied staat. Het argument van Jo over de data-omvang lijkt mij de
> belangrijkste om het aantal tags toch proberen te beperken, en daarom toch
> de gemeente aan de gemeente-contour over te laten in plaats van deze als
> tag te registreren.
>
> Dat deze ingevoerde gegevens nu misschien niet altijd overeenkomen met wat
> uit een gerenderde kaart komt lijkt mij niet het belangrijkste. Deze
> gegevens kunnen in elk geval gebruikt worden om de contouren (met name dan
> de postcodes) te controleren op afwijkingen ten opzichte van de ingevoerde
> nodes. Op die manier kan eenvoudig de data op de nodes getagd worden en
> kunnen de contouren verbeterd worden, tot die tijd dat andere systemen wel
> met de informatie op de nodes gaan werken. Het beheer van de contouren
> lijkt me in elk geval eenvoudiger te worden met de data op de nodes.
>
> Nuja; ik zorg dat alle gegevens via JSON beschikbaar zijn en bijgewerkt
> worden. Met veranderende inzichten kan dan alsnog eenvoudig beslist worden
> deze informatie al dan niet in JOSM in te laden, al dan niet via
> discardable tags.
>
> Groeten,
> Thomas
>
> Sander Deryckere schreef op 31-10-2014 19:42:
>
>   Marc, die bug moet ondertussen opgelost zijn.
>
>  Jo, dat is idd een optie. Maar ik vraag me af als het wel in deze tool
> past. De fixme gaat in veel gevallen niet over het adres, maar ook over de
> naam van de winkel, de openingsuren, ... Daarnaast zijn er ook veel fixmes
> die wel moeten opgelost zijn, maar die niet op een gebouw staan. Ik denk
> dat dit werk is voor een andere tool (het is sowieso al mogelijk met
> overpass turbo, maar het is iets moeilijker overpass queries te schrijven
> op een telefoon).
>
>  Bedankt voor de CSS, kan je het meteen al documenteren op de wiki? Ik ben
> momenteel bezig met sommige van die wiki pagina's te vertalen.
>
> Groeten,
>  Sander
>
> Op 31 oktober 2014 18:54 schreef Jo <winfixit at gmail.com>:
>
>> Zou het een idee zijn om ook de gebouwen voorzien van een fixme aan zo'n
>> GPX-bestand toe te voegen?
>>
>> Dan kunnen we ook via die weg terugkoppelen dat extra survey nodig is, in
>> geval van twijfel.
>>
>> ook de adressen waar wij zeker van zijn, maar die anders in crab zitten
>> zouden we van een tag kunnen voorzien om de terugkoppeling upstream te
>> vergemakkelijken.
>>
>> De MapCSS zal waarschijnlijk morgen beschikbaar zijn.
>>
>> Jo
>>   On Oct 31, 2014 4:23 PM, "Sander Deryckere" <sanderd17 at gmail.com>
>> wrote:
>>
>>>   Nog wat verder gewerkt aan de tools.
>>>
>>>
>>>  De straten worden nu altijd op een kaartje weergegeven, met een
>>> kleurencode om aan te duiden hoe compleet die zijn. De links in die popup
>>> werken zoals de links in de tabel.
>>>
>>>  Verder heb ik er ook nog een optie aan toegevoegd om te exporteren
>>> naar GPX. Onderaan de tabel vind je drie knoppen om die drie kolommen te
>>> exporteren naar GPX, en zo alle probleemgevallen in je gemeente naar je GPS
>>> of smartphone te downloaden (door de simpele html werkt de site ook
>>> tamelijk goed op een smartphone, waardoor je niet met kabeltjes moet
>>> klungelen, maar het rechtstreeks daar kan downloaden).
>>>
>>>  Als je de GPX maar voor 1 straat wil hebben, dan vul je best de
>>> straat-filter bovenaan de pagina in.
>>>
>>>  Om die GPX bijvoorbeeld met OsmAnd te gebruiken, sla je hem op onder
>>> /sdcard/osmand/tracks, en dan kan je die gemakkelijk weergeven en op de
>>> markers drukken om te zien over welk adres het gaat.
>>>
>>>  Ik hoop dat dit een goede manier is om gemakkelijk alle
>>> probleemgevallen te bezoeken.
>>>
>>>  Groeten,
>>> Sander
>>>
>>>  _______________________________________________
>>> 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
>>
>>
>
>
> _______________________________________________
> 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/20141101/7a0c262f/attachment.htm>