Inmiddels ben ik weer een heel stuk verder met het script. De memoryload
heb ik terug kunnen brengen tot 1,1GB. De looptijd zit nu net boven een
uur. Dat komt vooral omdat ik een aantal extra checks heb toegevoegd.
Daarmee kan de integriteit van de data wat beter vastgesteld worden, nu
en in de toekomstige updates van de lijst. Ook de sortering heb ik nu in
orde gebracht.
Concreet test ik nu of een straat-id inderdaad identificerend is voor
een straatnaam. Ook houd ik wat gedetailleerder bij hoeveel
appartementsnummers en busnummers het script negeert als adrespunt.
Daarnaast heb ik in mijn ogen mogelijk zinvolle informatie toegevoegd
aan de JSON-bestanden. Die informatie kan dan eenvoudig via het JS al
dan niet, met welke tag dan ook, in JOSM geladen worden. Het gaat met
name om een detailspecificatie van busnummers en appartementnummers die
ook op dat adres geregistreerd zijn.
Verder is er iets bijzonder aan de hand met de huisnummer-labels. Die
worden door het AGIV automatisch opgemaakt per huisnummer, althans, zo
hoort het. Toch heb ik met een check in mijn script 702 afwijkende
huisnummerlabels weten te vinden. Die zijn gekoppeld aan 211 adressen,
wat natuurlijk 'veel' is maar tegelijkertijd slechts 0,008% van het
totaal. Daarbij in acht genomen dat 67% van die afwijkende
huisnummerlabels zich voordoen in postcode 8900 lijkt het mij om een
fout in de database te gaan. Wat er precies fout gelopen is op die
punten weet ik niet. Ik heb de lijst op mijn server geplaatst:
http://downloader.aptum.nl/AfwijkendeHuisnummerLabelsCRAB.pdf
Wat daar aan de hand is moet dus even verder bekeken worden. Ik heb nu
de informatie van de huisnummerlabels opgenomen in de JSON bestanden.
Wanneer de huisnummerlabels voor alle sub-adressen bij 1 adrespunt (de
busnummers en appartementsnummers) niet onderling gelijk zijn, wordt
hier ook een melding van gemaakt en wordt de lijst met afwijkende
huisnummerlabels doorgegeven via de JSON-bestanden. Als jullie even
kunnen kijken of jullie punten op de lijst herkennen en weten wat
specifiek daar speelt, dan kan dat heel erg helpen bij het begrijpen wat
er precies fout loopt.
Even wat cijfers over de adressenlijst:
– 3.364.708 reccords
– daarvan bevatten er 142.010 een appartementnummer en 583.913 een
busnummer
– zonder de subadressen, blijven er 2.639.893 unieke adrespunten over.
– Er zijn 519 postcodes geregistreerd en 79185 straat-id's.
Over welke tags te gebruiken twijfel ik nog wat. Enerzijds vind ik het
een goed idee om discardable tags te gebruiken. Anderzijds (als ik de
lijst daarvan in de broncode van JOSM bekijk:
http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java?rev=7643
regel 687 ev) zijn de huidige allemaal op een heel specifiek project
gericht. Om zo'n bestaand label te 'verkrachten' met de informatie uit
het CRAB vind ik niet helemaal netjes (ook al komen ze niet in OSM);
maar misschien denken jullie daar anders over. Daarnaast is het
misschien ook vervelend dat die tags default niet weergegeven worden in
JOSM, terwijl het om informatie gaat die handig is / kan zijn voor de
mappers. Aan de andere kant: als een gebruiker het te moeilijk vindt /
te veel moeite om die tags aan te zetten in de configuratie, dan is het
misschien ook een te groot risico dat diezelfde gebruikers die tags
misschien wel zou opladen naar OSM. Hoe denken jullie hierover?
Nu voorlopig heb ik toch even het CRAB:key-patroon gebruikt zodat ze in
deze testfase voor iedereen helder zijn en netjes zichtbaar. Een andere
tag-naam is zo aangepast in het javascript. Let voor nu dus wel op dat
je deze tags niet naar OSM upload!
Ik heb nu volgende tags toegepast:
1) CRAB:huisnrlabel. Deze bevat het huisnummer-label zoals dat door het
CRAB aangeleverd wordt. Het is een samengestelde waarde uit de
huisnummers van (qua locatie) samenvallende adrespunten.
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.
3) CRAB:source. Deze had ik eerder al toegevoegd en bevat de herkomst
van de gegevens.
Ik heb de JSON-bestanden op mijn github-site bijgewerkt. Ik heb ook weer
de laatste versie van Sander zijn JS-bestand overgenomen en er de tags
aan toegevoegd. Alles staat nog steeds op
http://aptum.github.io/import.html
Groeten,
Thomas
Sander Deryckere schreef op 27-10-2014 11:55:
Ik heb een sorteermogelijkheid toegevoegd aan het JS script (door op
de headers te klikken, moet de UI nog wat aanpassen om het duidelijker
te maken), en ik heb ook nog een issue opgelost met de
huisnummervergelijking.
Zo werd in het vorige script nummer 241 niet gemarkeerd als "missing"
indien 24 of 41 van die straat in OSM bestond. Wat natuurlijk verkeerd
was.
Aangezien de meeste straten ofwel bijna volledig gemap zijn, ofwel
bijna niet, was deze fout moeilijk te vinden. Maar nu kan het dus zijn
dat je enkele extra "missing" adressen hebt.
Thomas, pas jij het ook aan in jouw kopie?
Groeten,
Sander
Op 26 oktober 2014 22:02 schreef Sus Verhoeven <sus...@gmail.com
<mailto:sus...@gmail.com>>:
Hooi
Met beide scripten heb ik hetzelfde probleem. Als ik de straat
gegevens van de script eerst oplaadt in JOSM kan ik geen OSM kaart
gegevens meer inladen in een apparte laag. Indien ik eerst de OSM
gegevens inlaad kan ik wel elke straatgegevens in apparte lagen
inladen.
In 3970 Leopoldsburg liggen met de nieuwe script de huisnummers
praktisch op dezelfde plaats dan in GRB, In Leopoldsbug lagen ze
meestal op de perceelcentroid, dat is dus veel beter
In de Koningsstraat krijg ik nu een nummer 40, maar die 40 wordt
niet gevalideerd door Bpost.
En volgens de foto en GRB is die moeilijk te verklaren
Aan de overkant liggen er nog enkele nummers, wel volgens de
foto's een terrein in aanbouw, Dat zou dus wel kunnen. Met de
eerste schript lagen er daar veel meer.
Zou het kunnen dat de mapccs van Jo niet meer werkt. ?
Toch wel handig.
Sus
_______________________________________________
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
