"Op straat" kom je voor numerieke toevoegingen ook 10/1 tegen, dus een schuine streep is ook nog een mogelijkheid. Dit zou het script ook kunnen genereren. Onderstreepje heb ik nog nooit gezien.
mvg m. 2014-10-28 9:53 GMT+01:00 Sander Deryckere <[email protected]>: > 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 <[email protected]>: > > 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 <[email protected]>: >> >> 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" <[email protected]>: >>> >>> Bedankt voor de updates, lijkt veelbelovend. Die extra statistieken >>>> kunnen idd handig zijn. >>>> >>>> Op 27-okt.-2014 22:27 schreef "Thomas" <[email protected]>: >>>> > >>>> > 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 <[email protected]>: >>>> >>> >>>> >>> 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 >>>> >>> [email protected] >>>> >>> https://lists.openstreetmap.org/listinfo/talk-be >>>> >>> >>>> >> >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> Talk-be mailing list >>>> >> [email protected] >>>> >> https://lists.openstreetmap.org/listinfo/talk-be >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Talk-be mailing list >>>> > [email protected] >>>> > https://lists.openstreetmap.org/listinfo/talk-be >>>> > >>>> >>> >>> _______________________________________________ >>> Talk-be mailing list >>> [email protected] >>> https://lists.openstreetmap.org/listinfo/talk-be >>> >>> >> >> _______________________________________________ >> Talk-be mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/talk-be >> >> > > _______________________________________________ > Talk-be mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-be > >
_______________________________________________ Talk-be mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-be
