Wat de afwijking in Ieper (8900) betreft, het enige wat in mij opkomt is dat er een dikke 2 jaar geleden een grootschalige hernoem actie was: http://nieuwsblad.be/cnt/DMF20120213_113
Dat de huisnummers daardoor foutief zijn lijkt me iets heel eigenaardigs. Buiten Ieper herken ik geen specifieke probleemgevallen. Groeten, Sander Op 27-okt.-2014 23:50 schreef "Sander Deryckere" <sander...@gmail.com>: > 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
