Wat die appartement en busnummers betreft, ik heb ook al gevallen gezien
waar het niet eenvoudig is om die te matchen. Zou het kunnen dat het
appartementnummer is, wat er op de bel staat en het busnummer wat je als
uitbreiding van het huisnummer op een enveloppe zou schrijven?
Dat zou dan betekenen dat iemand die dat wil nakijken met een survey,
gemakkelijker toegang zal hebben tot die appartementnummers. Misschien
kunnen we er de voorkeur aan geven om de appartementnummers in addr:flats
onder te brengen. Als beide er zijn de busnummers dan in een discardable
tag, ter referentie.
Als er geen appartementnummmers zijn, kunnen we natuurlijk gewoon de
gesorteerde busnummers in addr:flats onderbrengen.
Wat voor mij nog een twijfelgeval is, is wanneer er slechts 1 bus of
appartementnummer vermeld staat. Ik ben geneigd om dat dan niet mee over te
nemen.
Jo
Op 2 november 2014 09:41 schreef Sander Deryckere <sander...@gmail.com>:
> Net mijn laatste wijzigingen gepushed. Zal in de volgende uren geen push
> meer uitvoeren.
>
> Zou je ook de wijzigingen aan loadStreets.js in een aparte comit kunnen
> steken? Dan is het eenvoudiger om de diff te bekijken.
>
> Groeten,
> Sander
>
> Op 2 november 2014 09:33 schreef Thomas <o...@aptum.nl>:
>
> Sander,
>>
>> Ik heb de JSON-bestanden opnieuw aangemaakt met apptnrs en busnrs, deze
>> keer als echte arrays. Ik zie dat je precies nu bezig bent met wat
>> wijzigingen. Daarom even acties op elkaar afstemmen om geen conflicten te
>> veroorzaken. Laat je weten als je een uur geen push zult doen? Dan
>> pull-commit-push ik de nieuwe JSON bestanden op dat moment.
>>
>> Groeten,
>> Thomas
>>
>> Sander Deryckere schreef op 1-11-2014 21:45:
>>
>> Thomas,
>>
>> In je spec staat dat busnummers en appartementnummers arrays zijn, maar
>> in werkelijkheid lijken het comma-separated strings. Zou je het kunnen
>> wijzigen naar arrays? Arrays lijken veiliger voor het geval een busnummer
>> plots ook een komma bevat.
>>
>> Verder zijn er idd eigenaardige adressen. Dit zijn er twee in mijn dorp:
>> {
>> "apptnrs": "0/1,0/2,1/1,1/2,1/3,2/1,2/2,2/3,3/1,3/2",
>> "busnrs": "1,11,3",
>> "hnrlbls": [
>> "22-26"
>> ],
>> "housenumber": "22",
>> "lat": 50.94126031777649,
>> "lon": 3.061661179477891,
>> "municipality": "Staden",
>> "pcode": "8840",
>> "source": "afgeleidVanGebouw",
>> "street": "Roeselarestraat"
>> },
>>
>> Let op, nr 22 heeft hier veel bus- en appartementsnummers, nummer 26
>> blijkt er geen te hebben.
>>
>> {
>> "apptnrs": "0/1,1/3,2/1,2/2,2/3,3/3",
>> "busnrs": "1,2",
>> "hnrlbls": [
>> "7"
>> ],
>> "housenumber": "7",
>> "lat": 50.94025949900766,
>> "lon": 3.060482929425432,
>> "municipality": "Staden",
>> "pcode": "8840",
>> "source": "afgeleidVanGebouw",
>> "street": "Roeselarestraat"
>> },
>>
>> In beide gevallen lijkt er totaal geen verband tussen de busnummers en
>> appartementsnummers te bestaan. Ik zal morgen of overmorgen eens bekijken
>> wat er daar nu net zichtbaar is.
>>
>> Momenteel zal ik dus nog geen toevoegen aan de uitvoer. Iedereen die
>> meer info kan geven is zeker welkom.
>>
>> Groeten,
>> Sander
>>
>>
>> Op 1 november 2014 20:43 schreef Thomas <o...@aptum.nl>:
>>
>>> Het gebeurt in totaal 702 keer over alle adressen (inclusief
>>> subadressen) heen. Daarbij zijn 211 huisnummers betrokken. Op 27 oktober
>>> mailde ik dit daarover:
>>>
>>> "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 "
>>>
>>> In dat pdf-document krijg je een overzicht van huisnummer-labels die
>>> niet systematisch gelijk zijn voor alle subadressen voor dat huisnummer.
>>> Meestal lijkt het om vrij "logische" fouten te gaan. Hoe het kan dat dit
>>> niet consistent is in de CRAB-adressenlijst is mij niet duidelijk. Ik heb
>>> het gevoel dat het om een versie-probleempje gaat, dat niet alle
>>> huisnummers systematisch worden bijgewerkt wanneer een subadres wordt
>>> toegevoegd of wordt verwijderd. Omdat ik geen verder onderscheid kon maken
>>> tussen "goede" en "foute" huisnummers leek het mij het beste om ze gewoon
>>> "allemaal" mee te geven in de JSON.
>>>
>>> Groeten,
>>> Thomas
>>>
>>>
>>> Sander Deryckere schreef op 1-11-2014 20:15:
>>>
>>>
>>> Op 1 november 2014 13:12 schreef Thomas <o...@aptum.nl>:
>>>
>>> Zoals eerder gezegd is de voornaamste wijziging die invloed heeft op
>>>> de huidige werking het feit dat huisnummerlabels nu in een array meegegeven
>>>> worden, zodat bij meerdere huisnummer-labels per huisnummer, deze allemaal
>>>> doorgegeven kunnen worden. Dat kan Sander misschien helpen bij het matchen
>>>> met de gegevens uit OSM.
>>>>
>>>> Gebeurt dit vaak? Het lijkt me sowieso een fout in CRAB als dit
>>> gebeurt. Ik weet niet goed hoe ik foute data kan vergelijken, buiten melden
>>> dat er ergens een fout zit. Zal het verder onderzoeken.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Talk-be mailing list
>>> Talk-be@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
>>>
>>
>>
>> _______________________________________________
>> Talk-be mailing
>> listTalk-be@openstreetmap.orghttps://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
