Voor zover ik zie, zijn er 2 mogelijke bisnummer formaten in CRAB. Deze met alfabetische en deze met numerieke toevoegingen.
Voor zover ik gezien heb, worden de alfabetische toevoegingen altijd als een hoofdletter geschreven, zonder scheidingssymbool (dus "7A" en niet "7a" of "7 A"). De numerieke toevoegsels worden in CRAB altijd gescheiden met een underscore ( _, "onderstreepje" in het Nederlands ). De toevoegsels "bis" en "ter" worden ook als numeriek beschouwd, zo zal een huisnummer "10 bis" vertaald worden naar "10_2" De schrijfwijze van numerieke toevoegingen vind ik ronduit lelijk voor elke toepassing. Er is ook niemand die zijn adres als "ik woon in de Koestraat 10 onderstreepje 2" zal vermelden. Mensen spreken over "10 bis" en "10 ter". Dus eender waar die "10_2" zal opduiken (Nomitatim, Mapnik, OsmAnd, ...) zal dit voor verwarring zorgen. Mijn gevoel is dus wat tegenstrijdig. Langs de ene kant wil ik de hoofdletters van CRAB altijd overnemen, langs de andere kant vind ik hun schrijfwijze van numerieke toevoegsels niet goed genoeg, en prefereer ik "bis", "ter" of wat er ook zichtbaar is op de gevel. Groeten, Sander Op 28 oktober 2014 08:46 schreef Jo <winfi...@gmail.com>: > Veel van de adressen die als wrong worden aangegeven, zijn gewoon 8a ipv > 8A. De vraag is nu standardiseren we op hoofdletters voor die letters, of > maken we het script hoofdletterongevoelig? > > Jo > > Op 28 oktober 2014 00:07 schreef Sander Deryckere <sander...@gmail.com>: > > 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 >> >> > > _______________________________________________ > 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
