[OSM-talk-be] import AGIV CRAB-data

Tue Oct 28 09:19:26 UTC 2014

"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 <sanderd17 at gmail.com>:

> 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 <winfixit at 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 <sanderd17 at 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" <sanderd17 at gmail.com>:
>>>
>>> Bedankt voor de updates, lijkt veelbelovend. Die extra statistieken
>>>> kunnen idd handig zijn.
>>>>
>>>> Op 27-okt.-2014 22:27 schreef "Thomas" <osm at 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 <susvhv at 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 at openstreetmap.org
>>>> >>> https://lists.openstreetmap.org/listinfo/talk-be
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>> >> _______________________________________________
>>>> >> Talk-be mailing list
>>>> >> Talk-be at openstreetmap.org
>>>> >> https://lists.openstreetmap.org/listinfo/talk-be
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Talk-be mailing list
>>>> > Talk-be at openstreetmap.org
>>>> > https://lists.openstreetmap.org/listinfo/talk-be
>>>> >
>>>>
>>>
>>> _______________________________________________
>>> Talk-be mailing list
>>> Talk-be at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
>>>
>>
>> _______________________________________________
>> Talk-be mailing list
>> Talk-be at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>
> _______________________________________________
> Talk-be mailing list
> Talk-be at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20141028/c362b5d3/attachment.htm>