Over het beschikbaar maken van postcode en gemeentenaam: de postcode
wordt reeds meegegeven in de JSON bestanden en de gemeentenaam kan
daaraan worden toegevoegd. Met twee regels code heb ik dat voor elkaar.
Echter, daarbij moet ik wel de nodige extra checks inbouwen voor de
gemeente-id en de naam en de mate waarin deze 1 op 1 matchen om ook
hierin eenduidigheid te garanderen. Daarnaast biedt dit ook de
mogelijkheid om een extra verwantschap tussen gemeente en postcode te
bestuderen. Zoals ik uit de voorgaande mails begrepen heb matchen die
niet overal. Dat zorgt voor gesplitste straten met potentieel andere
schrijfwijzen. In de suggestie van Jo om iets met straat-relaties te
doen kan dit punt ook voor problemen zorgen. Mijn import-script kan deze
gevallen signaleren. Daarmee kan weer een aanvullend stuk zekerheid over
de kwaliteit van de brondata worden ingebouwd.
In de discussie over discardable keys denk ik dat de sleutel ligt in het
gebruik van de addr:flats tag die de lijst met
busnummers/appartementnummers weergeeft. Het is namelijk die informatie
die door de gebruikers echt gezien moet worden. Voor die functie is een
discardable tag ook niet echt inzetbaar, juist omdat de informatie erin
verborgen wordt voor de gebruiker. Met de lijst van busnr/apptnr is dat
afgedekt. De rest kan dan inderdaad met een discardable key en wat
mapCSS worden weergegeven.
De CRAB:huisnrlabel kan als als tag weggehaald worden uit de javascript.
Voorlopig kan dit in de JSON blijven staan. Op die manier kan de
informatie gebruikt worden door het script van Sander om verder gegevens
aan elkaar te matchen. CRAB:message verdwijnt dus met het toevoegen van
de addr:flats. CRAB-source heeft weinig inhoudelijke betekenis en kan
met een discardable-tag worden vormgegeven met mapCSS ter ondersteuning
bij het mappen. De fixme-tag inzetten bij specifieke herkomsten is ook
een goed idee, denk ik.
Die afwijkende huisnummerlabels zijn toch iets bijzonders. Dat wijst
toch op een vage integratie van verschillende databronnen. Mogelijk dat
dat probleem verholpen wordt als alle gemeenten eenmaal hun
adressenbestand gevalideerd hebben.
Het standaardiseren van de letters is een lastige kwestie. Die functie
inbouwen in het importeer-script is misschien niet heel handig, omdat
het matchen met OSM sowieso in de javascript gebeurt. Dit
standaardiseren op 2 plaatsen regelen lijkt me zeer onhandig. Daarom ben
ik voorstander van de gegevens uit het CRAB niet te standaardiseren naar
al dan niet met hoofdletter bij het omzetten naar de JSON bestanden. Ik
weet niet hoe consistent de gegevens in OSM zijn op dit punt. Als nu al
in OSM beide varianten voor komen, dan zal dat ook in de toekomst
mogelijk heel lastig te vermijden zijn, denk ik. Maar dat hangt dus af
van de huidige status van OSM en die ken ik niet. Verder deel ik de
visie van Sander op de schrijfwijze.
Het script dat Jo beschrijft om gemakkelijker de CRAB-gegevens te mergen
met OSM lijkt mij ook zeer handig. Daarbij zou ik wel heel erg opletten
met het inladen van informatie uit OSM in de laag die geïmporteerd
wordt. Ook de tegenovergestelde handeling van het automatisch doorvoeren
van informatie uit de import in de OSM-data-laag lijkt me 'gevaarlijk'
omdat eventuele fouten dan weer lastig te spotten zijn. Een wizard die
voor elk punt de match weergeeft en slechts een druk op de knop vereist
om de tags over te laden lijkt me dan weer prima. Op welke manier zie
jij die koppeling tussen de CRAB-adrespunten en de OSM-gebouwcontouren
voor je?
Het tweede script vind ik lastiger. Het omzetten van de tags vind ik
risicovol omdat op die manier een derde parse plaatsvindt. Er zijn nu al
twee omzettingen: CRAB → JSON → JOSM. Ik denk dat die alternatieve tags
beter in de javascript gerealiseerd kunnen worden. De
associatedStreet-relatie is voor zover ik begrijp toch wat
controversieel vanwege de toegevoegde complexiteit en de problemen van
beginnende mappers met relaties. Hoewel ik de meerwaarde van een
dergelijke relatie zeker zie, is dit ook een extra verwevenheid tussen
de brondata en OSM die met de hoogste voorzichtigheid moet worden
toegepast. Ook de opmerking van Sander over de potentieel verkeerde
relaties lijkt me een aandachtspunt. Wanneer het script hiermee rekening
houdt lijkt het me potentieel een zeer waardevolle toevoeging!
Ik ga nu mijn conversie-script aanpassen met de bovengenoemde
wijzigingen mbt de tags en de extra informatie. Ik ga een stuk
documentatie opstellen over de inhoud en de structuur van de
JSON-bestanden zodat mensen die aan andere scripts werken die hierop
aansluiten een duidelijke referentie hebben over het hoe en wat van de
beschikbare data. Ik ga de extra controle inbouwen voor
gemeente-postcode. Daarmee staat het conversie-script dan zo ongeveer op
punt. Als dat eenmaal getest is plaats ik mijn conversiescript ook op
github. Alle command-line interactie heb ik nu ook bijna op orde,
waarmee het script ook geschikt wordt om het daglicht te zien...
Sander: de aanpassingen die je al maakte aan de website vind ik zeer
geslaagd. De herbestemming van de Missing w/o pos lijkt mij ook
positief. Een punt zonder locatie wordt al afgevangen door mijn
conversiescript. Wat voorwaardelijke opmaak van de tabel kan er ook voor
zorgen dat de “Wrong” kolom leeg blijft, tenzij er 1 of meer punten
gevonden worden. Zo wordt het geheel wat rustiger en wordt
tegelijkertijd de aandacht meer gevestigd op specifieke potentiële
fouten in OSM. Het proces van de foute adrespunten inladen en OSM
verbeteren staat immers wat los van de werkwijze van het toevoegen van
nieuwe adrespunten. Door de opmaak echt te laten contrasteren kan daar
alsnog de aandacht voor gevestigd worden. Lijkt het je wat om in elk
geval die conditional rond die <a> toe te voegen? Het stylen is dan van
ondergeschikt belang.
Ik regel ook de toegang voor je tot de repo.
Groeten,
Thomas
Sander Deryckere schreef op 28-10-2014 17:39:
Ik heb mij bezig gehouden met het maken van unit tests. De vele
regexen zorgden vaak voor bugs die al eens vroeger opgelost waren.
Er is ondertussen ook ondersteuning voor "bis", "ter" en "/1", "/2",
... Ook straatnamen met een streepje verschil ("Sint-Jansstraat" en
"Sint Jansstraat") worden nu vergeleken.
De dubbele huisnummers worden nu ook vergeleken op basis van het
huisnrlabel (wat enkel zal werken met de data van Thomas). Een adres
wordt dus als "matching" beschouwd indien het huisnummer van OSM
overeenkomt met het huisnummer van CRAB, of met het huisnummerlabel
van CRAB. Afhankelijk van de lokale situatie kan een mapper dan kiezen
om meerdere samenvallende huisnummers te splitsen, of samen te laten.
Beiden moeten herkend worden.
Thomas, aangezien het duidelijk is dat we met de adressenlijst gaan
verder werken, zou ik commit access kunnen krijgen voor jouw repo? Dan
kan ik verder werken met jouw data, en kan mijn adres gesloten worden.
Ik denk om de no-position lijst te vervangen door een lijst van
samenvallende adressen (a.d.h.v het huisnummerlabel eenvoudig te
bepalen). Dat is net zoals vroeger, een simpele splitsing tussen de
gemakkelijke gevallen en de moeilijke gevallen, wat de productiviteit
enkel maar ten goede kan komen. Daarvoor is natuurlijk jouw data nodig.
Jo, een script dat straten met dezelfde naam zoekt is idd handig.
Vooral met straten zonder adres valt dit moeilijk te controleren op de
webpagina (tenzij ik een nieuwe overpass query maak, en de gebruikers
nog wat langer moeten wachten). Dus is het maar al te gemakkelijk om
bij een straat als "Guido Gezellestraat" de adressen met "G.
Gezellestraat" te importeren. Dat is zeker iets wat we moeten
voorkomen. Ik denk echter niet dat die associatedStreet relaties nodig
zijn (en dan heb je ook de postcode niet nodig).
Groeten,
Sander
Op 28 oktober 2014 14:44 schreef Jo <winfi...@gmail.com
<mailto:winfi...@gmail.com>>:
> 2) CRAB:message. Deze bevat informatie over het al dan niet aanwezig zijn
van
busnummers en appartementnummers op dat specifieke adrespunt. Deze
gegevens hoeven niet in OSM opgenomen te worden maar kunnen (zeker
nu in de testfase) verhelderend werken.
Er is een addr:flats tag die kan gebruikt worden (
http://wiki.openstreetmap.org/wiki/Key:addr:housenumber#Detailed_subkeys).
Ik weet niet wat nu net het verschil is tussen een busnummer
en een appartementsnummer, maar het is volgens mij objectieve,
verifieerbare een geografische info, dus als die beschikbaar
is, dan moeten we ze niet persé uit OSM weren.
Het lijkt mij ook het beste om deze info te parsen en onder te
brengen onder addr:flats, waarbij we geen onderscheid hoeven te
maken tussen apartmentnrs of busnrs.
Wellicht best wel sorteren en dan gescheiden door komma's zonder
verdere spaties.
Mijn eerste CRAB: crap is ondertussen (per ongeluk) doorgestuurd
naar de server. Daar gaan zeker en vast nog meer ongelukken mee
gebeuren.
Verder werk ik aan een Pythonscript dat binnen JOSM werkt om te
helpen bij het integreren van de CRAB-data met wat er reeds in OSM
zit. Om zoveel mogelijk adressen automatisch te koppelen aan
gebouwcontouren. Zo blijft er meer tijd over om de gebouwcontouren
zelf dan nauwkeuriger in te tekenen.
De MapCSS is bijna klaar.
Ik heb ook een pythonscriptje gemaakt (eigenlijk Jython) dat
jullie output omzet naar data met discardable tags en dat een
associatedStreetrelatie aanmaakt. Waarbij hij ook meteen op zoek
gaat naar straten met dezelfde naam.
Het zou daarbij helpen om postcode en gemeente ook aangeleverd te
krijgen in discardable tags.
Jo
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org <mailto:Talk-be@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
