Bedankt voor de updates, lijkt veelbelovend. Die extra statistieken kunnen idd handig zijn.
Op 27-okt.-2014 22:27 schreef "Thomas" <o...@aptum.nl>: > > 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? > Mijn mening is dat we enerzijds enkel proberen informatie toe te voegen die op de server hoort, en als dat niet mogelijk is, dat die info dan op een gebruikelijke tag zoals fixme of note komt te staan. Misschien hoogstens de hack gebruiken om een betere mapCSS te kunnen maken, maar niet om directe info aan de mapper te geven. > 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. Deze tag is volgens mij niet nodig in het finale script. JOSM waarschuwt dat er overlappende nodes zijn, en ik denk nog altijd dat we zoveel mogelijk gebouwen moeten proberen te tekenen (en dus van de nodes enkel de tags overnemen). > 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. > 3) CRAB:source. Deze had ik eerder al toegevoegd en bevat de herkomst van de gegevens. > Deze is moeilijker. Het is vooral nuttig tijdens het mappen, en niet meer echt na het uploaden. Zeker niet als het punt verplaatst is, of op een gebouw staat. Behalve voor de voordeur positie kunnen we altijd minstens even goed doen in OSM. En ik vraag me dan nog af hoe goed die voordeur posities zijn. Misschien is het mappen van ingangen en taak apart, en moeten we er nu geen rekening mee houden. Misschien voor de heel slechte bronnen gewoon een fixme tag meegeven? > 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>: >>> >>> 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 >>> 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 >
_______________________________________________ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
