subject:"Re\: \[OSM\-talk\-be\] import AGIV CRAB\-data"

Wat De Post betreft dus wel, ja. Weet jij waar 3018 Leuven is?

Jo

Op 4 november 2014 00:04 schreef Johan Van de Wauw <
johan.vandew...@gmail.com>:

> 3010 Leuven is de enige correcte schrijfwijze: Leuven is de gemeente,
> niet Kessel-Lo.
>
> http://www.bpost.be/adressering/#2
> "
> • Gebruik bij voorkeur de naam van de fusiegemeente (die van uw
> gemeentehuis)."
>
> 2014-11-03 23:48 GMT+01:00 Jo :
> > Ik heb 's een straat in 3010 Kessel-Lo afgehaald. Vreemd genoeg komt
> daar nu
> > addr:city=Leuven uit. Zitten de deelgemeentes ook in de data van CRAB? Ik
> > vind 3010 of 3012 Leuven ipv Kessel-Lo/Wilsele niet bepaald logisch. Al
> weet
> > ik wel dat je dat wat De Post betreft ook zo mag schrijven. Als het zo
> niet
> > in CRAB zit en wij geraken het erover eens dat we de deelgemeentes in de
> > adressen willen gebruiken, dan zorg ik wel voor een lookuptabel.
> >
> > Jo
> >
> > Op 3 november 2014 15:58 schreef Sander Deryckere :
> >
> >> Met gezipte antwoorden kan JS niet overweg.
> >>
> >> Ik denk dat er niets anders op zit dan te wachten tot de Duitse versie
> >> weer werkt, of de Russische versie hun software heeft geupdated.
> >>
> >> De code wijzigen voor de (hopelijk) enkele dagen dat dit ongemak zal
> duren
> >> heeft volgens mij geen zin.
> >>
> >> Groeten,
> >> Sander
> >>
> >> Op 3 november 2014 15:46 schreef Jo :
> >>
> >>> Dit is het volledige adres:
> >>>
> >>> http://oapi-fr.openstreetmap.fr/oapi/interpreter
> >>>
> >>> Die geeft wel steeds een gezipt antwoord, blijkbaar. En mijn query voor
> >>> alles wat met openbaar vervoer te maken heeft in België kan hij niet
> aan.
> >>>
> >>> jo
> >>>
> >>> Op 3 november 2014 12:46 schreef Jo :
> >>>
>  Misschien 's op de Franse server proberen:
> 
>  http://oapi-fr.openstreetmap.fr/oapi
> 
>  Jo
> 
>  Op 3 november 2014 10:24 schreef Sander Deryckere <
> sander...@gmail.com>:
> 
> > Wel, ik gebruik de "out center" abstractie van overpass (het bespaart
> > me de moeite om zelf de centra te berekenen, en het bespaart
> bandbreedte),
> > en die feature is nog maar enkele maanden uit.
> >
> > Dus misschien ontbreekt die nog op de Russische versie.
> >
> > Groeten,
> > Sander
> >
> > Op 3-nov.-2014 09:39 schreef "Thomas" :
> >
> >> Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig
> >> gehouden met de ontwikkeling van het javascript-gedeelte van de
> website. Op
> >> dit moment kan ik de Russische output ook moeilijk vergelijken met
> de
> >> Duitse, aangezien die Duitse het niet doet. Overigens; die doet het
> nog
> >> steeds niet. Dat soort emergency-ingrepen duren toch vaak langer
> dan men
> >> verwacht. Van zodra hij terug online is ga ik de verschillen even
> nader
> >> bestuderen.
> >>
> >> Groeten,
> >> Thomas
> >>
> >> Jo schreef op 3-11-2014 9:32:
> >>
> >> Op zich is het wel vreemd dat die 2 instances van Overpass niet
> >> dezelfde output teruggeven. Het gaat om dezelfde code. Al is de
> Duitse over
> >> het algemeen sneller met het aanbieden van nieuwe features.
> Misschien is het
> >> toch wel nodig om te melden dat de json-output afwijkt.
> >>
> >>
> >> mvg,
> >>
> >> Jo
> >>
> >> Op 3 november 2014 08:56 schreef Glenn Plas  >:
> >>>
> >>> Het zal wss zijn door de emergency rollback van overpass. Zie
> >>> subject:
> >>>
> >>>
> >>> [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback
> >>>
> >>> Glenn
> >>>
> >>>
> >>> On 03-11-14 01:32, Thomas wrote:
> >>> > De overpass-query wordt nu naar de Russische overpass-api
> gestuurd.
> >>> > Daarmee functioneert de import-pagina nu eerst weer. Uit de
> >>> > foutmeldingen in de javascript leid ik af dat het JSON-antwoord
> van
> >>> > die
> >>> > Russische api anders is dan die van de Duitse api. Ik heb een
> check
> >>> > toegevoegd die daarmee moet helpen. Uit de nu resulterende
> matches
> >>> > leid
> >>> > ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd
> >>> > worden. Blijkbaar zijn beide api's niet compatibel met elkaar.
> >>> >
> >>> > Op zich werkt het nu dus, zij het met beperkingen. Als over
> enkele
> >>> > uren
> >>> > de Duitse api het weer blijkt te doen, zal ik die weer koppelen.
> >>> > Als
> >>> > compatibiliteit zo'n lastige zaak is, dan moeten we misschien
> maar
> >>> > genoegen nemen met een afhankelijkheid van de Duitse api.
> >>> >
> >>> "Everything is going to be 200 OK."
> >>>
> >>> ___
> >>> Talk-be mailing list
> >>> Talk-be@openstreetmap.org
> >>> https://lists.openstreetmap.org/listinfo/talk-be
> >>
> >>
> >>
> >>
> >> ___
> >> Talk-be mailing list
> >> Talk-be@openstreetmap.org
> >> https://lis

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

2014-11-03 Thread Johan Van de Wauw

3010 Leuven is de enige correcte schrijfwijze: Leuven is de gemeente,
niet Kessel-Lo.

http://www.bpost.be/adressering/#2
"
• Gebruik bij voorkeur de naam van de fusiegemeente (die van uw gemeentehuis)."

2014-11-03 23:48 GMT+01:00 Jo :
> Ik heb 's een straat in 3010 Kessel-Lo afgehaald. Vreemd genoeg komt daar nu
> addr:city=Leuven uit. Zitten de deelgemeentes ook in de data van CRAB? Ik
> vind 3010 of 3012 Leuven ipv Kessel-Lo/Wilsele niet bepaald logisch. Al weet
> ik wel dat je dat wat De Post betreft ook zo mag schrijven. Als het zo niet
> in CRAB zit en wij geraken het erover eens dat we de deelgemeentes in de
> adressen willen gebruiken, dan zorg ik wel voor een lookuptabel.
>
> Jo
>
> Op 3 november 2014 15:58 schreef Sander Deryckere :
>
>> Met gezipte antwoorden kan JS niet overweg.
>>
>> Ik denk dat er niets anders op zit dan te wachten tot de Duitse versie
>> weer werkt, of de Russische versie hun software heeft geupdated.
>>
>> De code wijzigen voor de (hopelijk) enkele dagen dat dit ongemak zal duren
>> heeft volgens mij geen zin.
>>
>> Groeten,
>> Sander
>>
>> Op 3 november 2014 15:46 schreef Jo :
>>
>>> Dit is het volledige adres:
>>>
>>> http://oapi-fr.openstreetmap.fr/oapi/interpreter
>>>
>>> Die geeft wel steeds een gezipt antwoord, blijkbaar. En mijn query voor
>>> alles wat met openbaar vervoer te maken heeft in België kan hij niet aan.
>>>
>>> jo
>>>
>>> Op 3 november 2014 12:46 schreef Jo :
>>>
 Misschien 's op de Franse server proberen:

 http://oapi-fr.openstreetmap.fr/oapi

 Jo

 Op 3 november 2014 10:24 schreef Sander Deryckere :

> Wel, ik gebruik de "out center" abstractie van overpass (het bespaart
> me de moeite om zelf de centra te berekenen, en het bespaart bandbreedte),
> en die feature is nog maar enkele maanden uit.
>
> Dus misschien ontbreekt die nog op de Russische versie.
>
> Groeten,
> Sander
>
> Op 3-nov.-2014 09:39 schreef "Thomas" :
>
>> Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig
>> gehouden met de ontwikkeling van het javascript-gedeelte van de website. 
>> Op
>> dit moment kan ik de Russische output ook moeilijk vergelijken met de
>> Duitse, aangezien die Duitse het niet doet. Overigens; die doet het nog
>> steeds niet. Dat soort emergency-ingrepen duren toch vaak langer dan men
>> verwacht. Van zodra hij terug online is ga ik de verschillen even nader
>> bestuderen.
>>
>> Groeten,
>> Thomas
>>
>> Jo schreef op 3-11-2014 9:32:
>>
>> Op zich is het wel vreemd dat die 2 instances van Overpass niet
>> dezelfde output teruggeven. Het gaat om dezelfde code. Al is de Duitse 
>> over
>> het algemeen sneller met het aanbieden van nieuwe features. Misschien is 
>> het
>> toch wel nodig om te melden dat de json-output afwijkt.
>>
>>
>> mvg,
>>
>> Jo
>>
>> Op 3 november 2014 08:56 schreef Glenn Plas :
>>>
>>> Het zal wss zijn door de emergency rollback van overpass. Zie
>>> subject:
>>>
>>>
>>> [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback
>>>
>>> Glenn
>>>
>>>
>>> On 03-11-14 01:32, Thomas wrote:
>>> > De overpass-query wordt nu naar de Russische overpass-api gestuurd.
>>> > Daarmee functioneert de import-pagina nu eerst weer. Uit de
>>> > foutmeldingen in de javascript leid ik af dat het JSON-antwoord van
>>> > die
>>> > Russische api anders is dan die van de Duitse api. Ik heb een check
>>> > toegevoegd die daarmee moet helpen. Uit de nu resulterende matches
>>> > leid
>>> > ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd
>>> > worden. Blijkbaar zijn beide api's niet compatibel met elkaar.
>>> >
>>> > Op zich werkt het nu dus, zij het met beperkingen. Als over enkele
>>> > uren
>>> > de Duitse api het weer blijkt te doen, zal ik die weer koppelen.
>>> > Als
>>> > compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar
>>> > genoegen nemen met een afhankelijkheid van de Duitse api.
>>> >
>>> "Everything is going to be 200 OK."
>>>
>>> ___
>>> 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
>

>>>
>>>
>>> ___

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

Die gemeentenaam komt uit de CRAB-data. Ik denk dat dat losstaat van de
Overpass Query.

Jo

Op 3 november 2014 23:59 schreef Glenn Plas :

> Ik zou het nu niet gebruiken, de Russische data komt niet goed.  Als de
> duitse overpass api terug goed werkt zal het beter gaan.  Ik had alles
> in 1982 goed gezet, en ik krijg andere resultaten nu.
>
> Glenn
>
>
> On 03-11-14 23:48, Jo wrote:
> > Ik heb 's een straat in 3010 Kessel-Lo afgehaald. Vreemd genoeg komt
> > daar nu addr:city=Leuven uit. Zitten de deelgemeentes ook in de data van
> > CRAB? Ik vind 3010 of 3012 Leuven ipv Kessel-Lo/Wilsele niet bepaald
> > logisch. Al weet ik wel dat je dat wat De Post betreft ook zo mag
> > schrijven. Als het zo niet in CRAB zit en wij geraken het erover eens
> > dat we de deelgemeentes in de adressen willen gebruiken, dan zorg ik wel
> > voor een lookuptabel.
> >
> > Jo
> >
> > Op 3 november 2014 15:58 schreef Sander Deryckere  > >:
> >
> > Met gezipte antwoorden kan JS niet overweg.
> >
> > Ik denk dat er niets anders op zit dan te wachten tot de Duitse
> > versie weer werkt, of de Russische versie hun software heeft
> geupdated.
> >
> > De code wijzigen voor de (hopelijk) enkele dagen dat dit ongemak zal
> > duren heeft volgens mij geen zin.
> >
> > Groeten,
> > Sander
> >
> > Op 3 november 2014 15:46 schreef Jo  > >:
> >
> > Dit is het volledige adres:
> >
> > http://oapi-fr.openstreetmap.fr/oapi/interpreter
> >
> > Die geeft wel steeds een gezipt antwoord, blijkbaar. En mijn
> > query voor alles wat met openbaar vervoer te maken heeft in
> > België kan hij niet aan.
> >
> > jo
> >
> > Op 3 november 2014 12:46 schreef Jo  > >:
> >
> > Misschien 's op de Franse server proberen:
> >
> > http://oapi-fr.openstreetmap.fr/oapi
> >
> > Jo
> >
> > Op 3 november 2014 10:24 schreef Sander Deryckere
> > mailto:sander...@gmail.com>>:
> >
> > Wel, ik gebruik de "out center" abstractie van overpass
> > (het bespaart me de moeite om zelf de centra te
> > berekenen, en het bespaart bandbreedte), en die feature
> > is nog maar enkele maanden uit.
> >
> > Dus misschien ontbreekt die nog op de Russische versie.
> >
> > Groeten,
> > Sander
> >
> > Op 3-nov.-2014 09:39 schreef "Thomas"  > >:
> >
> > Dat vind ik ook zeer opvallend. Ik heb me alleen
> > helemaal niet bezig gehouden met de ontwikkeling van
> > het javascript-gedeelte van de website. Op dit
> > moment kan ik de Russische output ook moeilijk
> > vergelijken met de Duitse, aangezien die Duitse het
> > niet doet. Overigens; die doet het nog steeds niet.
> > Dat soort emergency-ingrepen duren toch vaak langer
> > dan men verwacht. Van zodra hij terug online is ga
> > ik de verschillen even nader bestuderen.
> >
> > Groeten,
> > Thomas
> >
> > Jo schreef op 3-11-2014 9:32:
> >> Op zich is het wel vreemd dat die 2 instances van
> >> Overpass niet dezelfde output teruggeven. Het gaat
> >> om dezelfde code. Al is de Duitse over het
> >> algemeen sneller met het aanbieden van nieuwe
> >> features. Misschien is het toch wel nodig om te
> >> melden dat de json-output afwijkt.
> >>
> >>
> >> mvg,
> >>
> >> Jo
> >>
> >> Op 3 november 2014 08:56 schreef Glenn Plas
> >>  >> >:
> >>
> >> Het zal wss zijn door de emergency rollback
> >> van overpass. Zie subject:
> >>
> >>
> >> [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de
> >> : Emergency rollback
> >>
> >> Glenn
> >>
> >>
> >> On 03-11-14 01:32, Thomas wrote:
> >> > De overpass-query wordt nu naar de Russische
> >> overpass-api gestuurd.
> >> > Daarmee functioneert de import-pagina nu
> >> eerst weer. Uit de
> >> > foutmeldingen in de javascript leid ik af
> >> dat het JSON-antwoord van die
> >> > Russische api anders is dan die van de
> >> Duitse api. Ik heb een check
> >> > toegev

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

2014-11-03 Thread Glenn Plas

Ik zou het nu niet gebruiken, de Russische data komt niet goed.  Als de
duitse overpass api terug goed werkt zal het beter gaan.  Ik had alles
in 1982 goed gezet, en ik krijg andere resultaten nu.

Glenn


On 03-11-14 23:48, Jo wrote:
> Ik heb 's een straat in 3010 Kessel-Lo afgehaald. Vreemd genoeg komt
> daar nu addr:city=Leuven uit. Zitten de deelgemeentes ook in de data van
> CRAB? Ik vind 3010 of 3012 Leuven ipv Kessel-Lo/Wilsele niet bepaald
> logisch. Al weet ik wel dat je dat wat De Post betreft ook zo mag
> schrijven. Als het zo niet in CRAB zit en wij geraken het erover eens
> dat we de deelgemeentes in de adressen willen gebruiken, dan zorg ik wel
> voor een lookuptabel.
> 
> Jo
> 
> Op 3 november 2014 15:58 schreef Sander Deryckere  >:
> 
> Met gezipte antwoorden kan JS niet overweg.
> 
> Ik denk dat er niets anders op zit dan te wachten tot de Duitse
> versie weer werkt, of de Russische versie hun software heeft geupdated.
> 
> De code wijzigen voor de (hopelijk) enkele dagen dat dit ongemak zal
> duren heeft volgens mij geen zin.
> 
> Groeten,
> Sander
> 
> Op 3 november 2014 15:46 schreef Jo  >:
> 
> Dit is het volledige adres:
> 
> http://oapi-fr.openstreetmap.fr/oapi/interpreter
> 
> Die geeft wel steeds een gezipt antwoord, blijkbaar. En mijn
> query voor alles wat met openbaar vervoer te maken heeft in
> België kan hij niet aan.
> 
> jo
> 
> Op 3 november 2014 12:46 schreef Jo  >:
> 
> Misschien 's op de Franse server proberen:
> 
> http://oapi-fr.openstreetmap.fr/oapi
> 
> Jo
> 
> Op 3 november 2014 10:24 schreef Sander Deryckere
> mailto:sander...@gmail.com>>:
> 
> Wel, ik gebruik de "out center" abstractie van overpass
> (het bespaart me de moeite om zelf de centra te
> berekenen, en het bespaart bandbreedte), en die feature
> is nog maar enkele maanden uit.
> 
> Dus misschien ontbreekt die nog op de Russische versie.
> 
> Groeten,
> Sander
> 
> Op 3-nov.-2014 09:39 schreef "Thomas"  >:
> 
> Dat vind ik ook zeer opvallend. Ik heb me alleen
> helemaal niet bezig gehouden met de ontwikkeling van
> het javascript-gedeelte van de website. Op dit
> moment kan ik de Russische output ook moeilijk
> vergelijken met de Duitse, aangezien die Duitse het
> niet doet. Overigens; die doet het nog steeds niet.
> Dat soort emergency-ingrepen duren toch vaak langer
> dan men verwacht. Van zodra hij terug online is ga
> ik de verschillen even nader bestuderen.
> 
> Groeten,
> Thomas
> 
> Jo schreef op 3-11-2014 9:32:
>> Op zich is het wel vreemd dat die 2 instances van
>> Overpass niet dezelfde output teruggeven. Het gaat
>> om dezelfde code. Al is de Duitse over het
>> algemeen sneller met het aanbieden van nieuwe
>> features. Misschien is het toch wel nodig om te
>> melden dat de json-output afwijkt.
>>
>>
>> mvg,
>>
>> Jo
>>
>> Op 3 november 2014 08:56 schreef Glenn Plas
>> > >:
>>
>> Het zal wss zijn door de emergency rollback
>> van overpass. Zie subject:
>>
>>
>> [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de
>> : Emergency rollback
>>
>> Glenn
>>
>>
>> On 03-11-14 01:32, Thomas wrote:
>> > De overpass-query wordt nu naar de Russische
>> overpass-api gestuurd.
>> > Daarmee functioneert de import-pagina nu
>> eerst weer. Uit de
>> > foutmeldingen in de javascript leid ik af
>> dat het JSON-antwoord van die
>> > Russische api anders is dan die van de
>> Duitse api. Ik heb een check
>> > toegevoegd die daarmee moet helpen. Uit de
>> nu resulterende matches leid
>> > ik dan weer af dat toch niet alle
>> huisnummers in OSM gedetecteerd
>> > worden. Blijkbaar zijn beide api's niet
>> compatibel met elkaar.
>>

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

Ik heb 's een straat in 3010 Kessel-Lo afgehaald. Vreemd genoeg komt daar
nu addr:city=Leuven uit. Zitten de deelgemeentes ook in de data van CRAB?
Ik vind 3010 of 3012 Leuven ipv Kessel-Lo/Wilsele niet bepaald logisch. Al
weet ik wel dat je dat wat De Post betreft ook zo mag schrijven. Als het zo
niet in CRAB zit en wij geraken het erover eens dat we de deelgemeentes in
de adressen willen gebruiken, dan zorg ik wel voor een lookuptabel.

Jo

Op 3 november 2014 15:58 schreef Sander Deryckere :

> Met gezipte antwoorden kan JS niet overweg.
>
> Ik denk dat er niets anders op zit dan te wachten tot de Duitse versie
> weer werkt, of de Russische versie hun software heeft geupdated.
>
> De code wijzigen voor de (hopelijk) enkele dagen dat dit ongemak zal duren
> heeft volgens mij geen zin.
>
> Groeten,
> Sander
>
> Op 3 november 2014 15:46 schreef Jo :
>
> Dit is het volledige adres:
>>
>> http://oapi-fr.openstreetmap.fr/oapi/interpreter
>>
>> Die geeft wel steeds een gezipt antwoord, blijkbaar. En mijn query voor
>> alles wat met openbaar vervoer te maken heeft in België kan hij niet aan.
>>
>> jo
>>
>> Op 3 november 2014 12:46 schreef Jo :
>>
>> Misschien 's op de Franse server proberen:
>>>
>>> http://oapi-fr.openstreetmap.fr/oapi
>>>
>>> Jo
>>>
>>> Op 3 november 2014 10:24 schreef Sander Deryckere :
>>>
>>> Wel, ik gebruik de "out center" abstractie van overpass (het bespaart me
 de moeite om zelf de centra te berekenen, en het bespaart bandbreedte), en
 die feature is nog maar enkele maanden uit.

 Dus misschien ontbreekt die nog op de Russische versie.

 Groeten,
 Sander
 Op 3-nov.-2014 09:39 schreef "Thomas" :

  Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig
> gehouden met de ontwikkeling van het javascript-gedeelte van de website. 
> Op
> dit moment kan ik de Russische output ook moeilijk vergelijken met de
> Duitse, aangezien die Duitse het niet doet. Overigens; die doet het nog
> steeds niet. Dat soort emergency-ingrepen duren toch vaak langer dan men
> verwacht. Van zodra hij terug online is ga ik de verschillen even nader
> bestuderen.
>
> Groeten,
> Thomas
>
> Jo schreef op 3-11-2014 9:32:
>
>  Op zich is het wel vreemd dat die 2 instances van Overpass niet
> dezelfde output teruggeven. Het gaat om dezelfde code. Al is de Duitse 
> over
> het algemeen sneller met het aanbieden van nieuwe features. Misschien is
> het toch wel nodig om te melden dat de json-output afwijkt.
>
>
>  mvg,
>
>  Jo
>
> Op 3 november 2014 08:56 schreef Glenn Plas :
>
>> Het zal wss zijn door de emergency rollback van overpass. Zie subject:
>>
>>
>> [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback
>>
>> Glenn
>>
>>
>> On 03-11-14 01:32, Thomas wrote:
>> > De overpass-query wordt nu naar de Russische overpass-api gestuurd.
>> > Daarmee functioneert de import-pagina nu eerst weer. Uit de
>> > foutmeldingen in de javascript leid ik af dat het JSON-antwoord van
>> die
>> > Russische api anders is dan die van de Duitse api. Ik heb een check
>> > toegevoegd die daarmee moet helpen. Uit de nu resulterende matches
>> leid
>> > ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd
>> > worden. Blijkbaar zijn beide api's niet compatibel met elkaar.
>> >
>> > Op zich werkt het nu dus, zij het met beperkingen. Als over enkele
>> uren
>> > de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als
>> > compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar
>> > genoegen nemen met een afhankelijkheid van de Duitse api.
>> >
>> "Everything is going to be 200 OK."
>>
>>  ___
>> 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
>>
>>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

2014-11-03 Thread Sander Deryckere

Met gezipte antwoorden kan JS niet overweg.

Ik denk dat er niets anders op zit dan te wachten tot de Duitse versie weer
werkt, of de Russische versie hun software heeft geupdated.

De code wijzigen voor de (hopelijk) enkele dagen dat dit ongemak zal duren
heeft volgens mij geen zin.

Groeten,
Sander

Op 3 november 2014 15:46 schreef Jo :

> Dit is het volledige adres:
>
> http://oapi-fr.openstreetmap.fr/oapi/interpreter
>
> Die geeft wel steeds een gezipt antwoord, blijkbaar. En mijn query voor
> alles wat met openbaar vervoer te maken heeft in België kan hij niet aan.
>
> jo
>
> Op 3 november 2014 12:46 schreef Jo :
>
> Misschien 's op de Franse server proberen:
>>
>> http://oapi-fr.openstreetmap.fr/oapi
>>
>> Jo
>>
>> Op 3 november 2014 10:24 schreef Sander Deryckere :
>>
>> Wel, ik gebruik de "out center" abstractie van overpass (het bespaart me
>>> de moeite om zelf de centra te berekenen, en het bespaart bandbreedte), en
>>> die feature is nog maar enkele maanden uit.
>>>
>>> Dus misschien ontbreekt die nog op de Russische versie.
>>>
>>> Groeten,
>>> Sander
>>> Op 3-nov.-2014 09:39 schreef "Thomas" :
>>>
>>>  Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig
 gehouden met de ontwikkeling van het javascript-gedeelte van de website. Op
 dit moment kan ik de Russische output ook moeilijk vergelijken met de
 Duitse, aangezien die Duitse het niet doet. Overigens; die doet het nog
 steeds niet. Dat soort emergency-ingrepen duren toch vaak langer dan men
 verwacht. Van zodra hij terug online is ga ik de verschillen even nader
 bestuderen.

 Groeten,
 Thomas

 Jo schreef op 3-11-2014 9:32:

  Op zich is het wel vreemd dat die 2 instances van Overpass niet
 dezelfde output teruggeven. Het gaat om dezelfde code. Al is de Duitse over
 het algemeen sneller met het aanbieden van nieuwe features. Misschien is
 het toch wel nodig om te melden dat de json-output afwijkt.


  mvg,

  Jo

 Op 3 november 2014 08:56 schreef Glenn Plas :

> Het zal wss zijn door de emergency rollback van overpass. Zie subject:
>
>
> [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback
>
> Glenn
>
>
> On 03-11-14 01:32, Thomas wrote:
> > De overpass-query wordt nu naar de Russische overpass-api gestuurd.
> > Daarmee functioneert de import-pagina nu eerst weer. Uit de
> > foutmeldingen in de javascript leid ik af dat het JSON-antwoord van
> die
> > Russische api anders is dan die van de Duitse api. Ik heb een check
> > toegevoegd die daarmee moet helpen. Uit de nu resulterende matches
> leid
> > ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd
> > worden. Blijkbaar zijn beide api's niet compatibel met elkaar.
> >
> > Op zich werkt het nu dus, zij het met beperkingen. Als over enkele
> uren
> > de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als
> > compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar
> > genoegen nemen met een afhankelijkheid van de Duitse api.
> >
> "Everything is going to be 200 OK."
>
>  ___
> 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
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

Dit is het volledige adres:

http://oapi-fr.openstreetmap.fr/oapi/interpreter

Die geeft wel steeds een gezipt antwoord, blijkbaar. En mijn query voor
alles wat met openbaar vervoer te maken heeft in België kan hij niet aan.

jo

Op 3 november 2014 12:46 schreef Jo :

> Misschien 's op de Franse server proberen:
>
> http://oapi-fr.openstreetmap.fr/oapi
>
> Jo
>
> Op 3 november 2014 10:24 schreef Sander Deryckere :
>
> Wel, ik gebruik de "out center" abstractie van overpass (het bespaart me
>> de moeite om zelf de centra te berekenen, en het bespaart bandbreedte), en
>> die feature is nog maar enkele maanden uit.
>>
>> Dus misschien ontbreekt die nog op de Russische versie.
>>
>> Groeten,
>> Sander
>> Op 3-nov.-2014 09:39 schreef "Thomas" :
>>
>>  Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig
>>> gehouden met de ontwikkeling van het javascript-gedeelte van de website. Op
>>> dit moment kan ik de Russische output ook moeilijk vergelijken met de
>>> Duitse, aangezien die Duitse het niet doet. Overigens; die doet het nog
>>> steeds niet. Dat soort emergency-ingrepen duren toch vaak langer dan men
>>> verwacht. Van zodra hij terug online is ga ik de verschillen even nader
>>> bestuderen.
>>>
>>> Groeten,
>>> Thomas
>>>
>>> Jo schreef op 3-11-2014 9:32:
>>>
>>>  Op zich is het wel vreemd dat die 2 instances van Overpass niet
>>> dezelfde output teruggeven. Het gaat om dezelfde code. Al is de Duitse over
>>> het algemeen sneller met het aanbieden van nieuwe features. Misschien is
>>> het toch wel nodig om te melden dat de json-output afwijkt.
>>>
>>>
>>>  mvg,
>>>
>>>  Jo
>>>
>>> Op 3 november 2014 08:56 schreef Glenn Plas :
>>>
 Het zal wss zijn door de emergency rollback van overpass. Zie subject:


 [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback

 Glenn


 On 03-11-14 01:32, Thomas wrote:
 > De overpass-query wordt nu naar de Russische overpass-api gestuurd.
 > Daarmee functioneert de import-pagina nu eerst weer. Uit de
 > foutmeldingen in de javascript leid ik af dat het JSON-antwoord van
 die
 > Russische api anders is dan die van de Duitse api. Ik heb een check
 > toegevoegd die daarmee moet helpen. Uit de nu resulterende matches
 leid
 > ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd
 > worden. Blijkbaar zijn beide api's niet compatibel met elkaar.
 >
 > Op zich werkt het nu dus, zij het met beperkingen. Als over enkele
 uren
 > de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als
 > compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar
 > genoegen nemen met een afhankelijkheid van de Duitse api.
 >
 "Everything is going to be 200 OK."

  ___
 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

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

Misschien 's op de Franse server proberen:

http://oapi-fr.openstreetmap.fr/oapi

Jo

Op 3 november 2014 10:24 schreef Sander Deryckere :

> Wel, ik gebruik de "out center" abstractie van overpass (het bespaart me
> de moeite om zelf de centra te berekenen, en het bespaart bandbreedte), en
> die feature is nog maar enkele maanden uit.
>
> Dus misschien ontbreekt die nog op de Russische versie.
>
> Groeten,
> Sander
> Op 3-nov.-2014 09:39 schreef "Thomas" :
>
>  Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig
>> gehouden met de ontwikkeling van het javascript-gedeelte van de website. Op
>> dit moment kan ik de Russische output ook moeilijk vergelijken met de
>> Duitse, aangezien die Duitse het niet doet. Overigens; die doet het nog
>> steeds niet. Dat soort emergency-ingrepen duren toch vaak langer dan men
>> verwacht. Van zodra hij terug online is ga ik de verschillen even nader
>> bestuderen.
>>
>> Groeten,
>> Thomas
>>
>> Jo schreef op 3-11-2014 9:32:
>>
>>  Op zich is het wel vreemd dat die 2 instances van Overpass niet
>> dezelfde output teruggeven. Het gaat om dezelfde code. Al is de Duitse over
>> het algemeen sneller met het aanbieden van nieuwe features. Misschien is
>> het toch wel nodig om te melden dat de json-output afwijkt.
>>
>>
>>  mvg,
>>
>>  Jo
>>
>> Op 3 november 2014 08:56 schreef Glenn Plas :
>>
>>> Het zal wss zijn door de emergency rollback van overpass. Zie subject:
>>>
>>>
>>> [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback
>>>
>>> Glenn
>>>
>>>
>>> On 03-11-14 01:32, Thomas wrote:
>>> > De overpass-query wordt nu naar de Russische overpass-api gestuurd.
>>> > Daarmee functioneert de import-pagina nu eerst weer. Uit de
>>> > foutmeldingen in de javascript leid ik af dat het JSON-antwoord van die
>>> > Russische api anders is dan die van de Duitse api. Ik heb een check
>>> > toegevoegd die daarmee moet helpen. Uit de nu resulterende matches leid
>>> > ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd
>>> > worden. Blijkbaar zijn beide api's niet compatibel met elkaar.
>>> >
>>> > Op zich werkt het nu dus, zij het met beperkingen. Als over enkele uren
>>> > de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als
>>> > compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar
>>> > genoegen nemen met een afhankelijkheid van de Duitse api.
>>> >
>>> "Everything is going to be 200 OK."
>>>
>>>  ___
>>> 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

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

2014-11-03 Thread Sander Deryckere

Wel, ik gebruik de "out center" abstractie van overpass (het bespaart me de
moeite om zelf de centra te berekenen, en het bespaart bandbreedte), en die
feature is nog maar enkele maanden uit.

Dus misschien ontbreekt die nog op de Russische versie.

Groeten,
Sander
Op 3-nov.-2014 09:39 schreef "Thomas" :

>  Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig
> gehouden met de ontwikkeling van het javascript-gedeelte van de website. Op
> dit moment kan ik de Russische output ook moeilijk vergelijken met de
> Duitse, aangezien die Duitse het niet doet. Overigens; die doet het nog
> steeds niet. Dat soort emergency-ingrepen duren toch vaak langer dan men
> verwacht. Van zodra hij terug online is ga ik de verschillen even nader
> bestuderen.
>
> Groeten,
> Thomas
>
> Jo schreef op 3-11-2014 9:32:
>
>  Op zich is het wel vreemd dat die 2 instances van Overpass niet dezelfde
> output teruggeven. Het gaat om dezelfde code. Al is de Duitse over het
> algemeen sneller met het aanbieden van nieuwe features. Misschien is het
> toch wel nodig om te melden dat de json-output afwijkt.
>
>
>  mvg,
>
>  Jo
>
> Op 3 november 2014 08:56 schreef Glenn Plas :
>
>> Het zal wss zijn door de emergency rollback van overpass. Zie subject:
>>
>>
>> [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback
>>
>> Glenn
>>
>>
>> On 03-11-14 01:32, Thomas wrote:
>> > De overpass-query wordt nu naar de Russische overpass-api gestuurd.
>> > Daarmee functioneert de import-pagina nu eerst weer. Uit de
>> > foutmeldingen in de javascript leid ik af dat het JSON-antwoord van die
>> > Russische api anders is dan die van de Duitse api. Ik heb een check
>> > toegevoegd die daarmee moet helpen. Uit de nu resulterende matches leid
>> > ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd
>> > worden. Blijkbaar zijn beide api's niet compatibel met elkaar.
>> >
>> > Op zich werkt het nu dus, zij het met beperkingen. Als over enkele uren
>> > de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als
>> > compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar
>> > genoegen nemen met een afhankelijkheid van de Duitse api.
>> >
>> "Everything is going to be 200 OK."
>>
>>  ___
>> 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

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

2014-11-03 Thread Thomas

Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig 
gehouden met de ontwikkeling van het javascript-gedeelte van de website. 
Op dit moment kan ik de Russische output ook moeilijk vergelijken met de 
Duitse, aangezien die Duitse het niet doet. Overigens; die doet het nog 
steeds niet. Dat soort emergency-ingrepen duren toch vaak langer dan men 
verwacht. Van zodra hij terug online is ga ik de verschillen even nader 
bestuderen.

Groeten,
Thomas

Jo schreef op 3-11-2014 9:32:
Op zich is het wel vreemd dat die 2 instances van Overpass niet 
dezelfde output teruggeven. Het gaat om dezelfde code. Al is de Duitse 
over het algemeen sneller met het aanbieden van nieuwe features. 
Misschien is het toch wel nodig om te melden dat de json-output afwijkt.

mvg,

Jo

Op 3 november 2014 08:56 schreef Glenn Plas >:

Het zal wss zijn door de emergency rollback van overpass. Zie subject:

[OSM-talk-be] Fwd: [OSM-talk] overpass-api.de
: Emergency rollback

Glenn

On 03-11-14 01:32, Thomas wrote:
> De overpass-query wordt nu naar de Russische overpass-api gestuurd.
> Daarmee functioneert de import-pagina nu eerst weer. Uit de
> foutmeldingen in de javascript leid ik af dat het JSON-antwoord
van die
> Russische api anders is dan die van de Duitse api. Ik heb een check
> toegevoegd die daarmee moet helpen. Uit de nu resulterende
matches leid
> ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd
> worden. Blijkbaar zijn beide api's niet compatibel met elkaar.
>
> Op zich werkt het nu dus, zij het met beperkingen. Als over
enkele uren
> de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als
> compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar
> genoegen nemen met een afhankelijkheid van de Duitse api.
>
"Everything is going to be 200 OK."

___
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

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

Op zich is het wel vreemd dat die 2 instances van Overpass niet dezelfde
output teruggeven. Het gaat om dezelfde code. Al is de Duitse over het
algemeen sneller met het aanbieden van nieuwe features. Misschien is het
toch wel nodig om te melden dat de json-output afwijkt.


mvg,

Jo

Op 3 november 2014 08:56 schreef Glenn Plas :

> Het zal wss zijn door de emergency rollback van overpass. Zie subject:
>
>
> [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback
>
> Glenn
>
>
> On 03-11-14 01:32, Thomas wrote:
> > De overpass-query wordt nu naar de Russische overpass-api gestuurd.
> > Daarmee functioneert de import-pagina nu eerst weer. Uit de
> > foutmeldingen in de javascript leid ik af dat het JSON-antwoord van die
> > Russische api anders is dan die van de Duitse api. Ik heb een check
> > toegevoegd die daarmee moet helpen. Uit de nu resulterende matches leid
> > ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd
> > worden. Blijkbaar zijn beide api's niet compatibel met elkaar.
> >
> > Op zich werkt het nu dus, zij het met beperkingen. Als over enkele uren
> > de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als
> > compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar
> > genoegen nemen met een afhankelijkheid van de Duitse api.
> >
> "Everything is going to be 200 OK."
>
> ___
> 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

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

2014-11-02 Thread Glenn Plas

Het zal wss zijn door de emergency rollback van overpass. Zie subject:


[OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback

Glenn


On 03-11-14 01:32, Thomas wrote:
> De overpass-query wordt nu naar de Russische overpass-api gestuurd.
> Daarmee functioneert de import-pagina nu eerst weer. Uit de
> foutmeldingen in de javascript leid ik af dat het JSON-antwoord van die
> Russische api anders is dan die van de Duitse api. Ik heb een check
> toegevoegd die daarmee moet helpen. Uit de nu resulterende matches leid
> ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd
> worden. Blijkbaar zijn beide api's niet compatibel met elkaar.
> 
> Op zich werkt het nu dus, zij het met beperkingen. Als over enkele uren
> de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als
> compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar
> genoegen nemen met een afhankelijkheid van de Duitse api.
> 
"Everything is going to be 200 OK."

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

De overpass-query wordt nu naar de Russische overpass-api gestuurd.
Daarmee functioneert de import-pagina nu eerst weer. Uit de
foutmeldingen in de javascript leid ik af dat het JSON-antwoord van die
Russische api anders is dan die van de Duitse api. Ik heb een check
toegevoegd die daarmee moet helpen. Uit de nu resulterende matches leid
ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd
worden. Blijkbaar zijn beide api's niet compatibel met elkaar.

Op zich werkt het nu dus, zij het met beperkingen. Als over enkele uren
de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als
compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar
genoegen nemen met een afhankelijkheid van de Duitse api.

Groeten,
Thomas

Thomas schreef op 2-11-2014 23:43:
Bedankt voor beide meldingen! Het probleem ligt in dit geval bij de
overpass-api. De JSON-response bestaat niet uit JSON maar uit xhtml.
Wanneer de javascript dat probeert te verwerken als een JSON-response
treedt er een fout op. Dat heeft vast te maken met de emergency
rollback waar je eerder over mailde.

Ik heb even het request naar overpass.osm.rambler.ru doorgestuurd
waardoor het request op zich nu weer werkt. Verderop in het script
loopt nu wat verkeerd omdat het antwoord van deze Russische variant
blijkbaar inhoudelijk verschillend is van de originele Duitse website.
Ik kijk even of ik dat op kan lossen, anders draai ik het geheel terug
naar de originele Duitse variant en moeten we maar even wachten tot de
emergency rollback voorbij is.

Groeten,
Thomas

Glenn Plas schreef op 2-11-2014 23:19:

There's an error at the moment with the importer.

loadStreets.js:276
Uncaught SyntaxError: Unexpected token <
import.html?pcode=1982&filterStreets=*&maxDistance=&loadOsm=true&includePcode=false&crabInfo=false&…:1

This is on chrome.

Glenn

On 02-11-14 10:57, Thomas wrote:

De nieuwe JSON-bestanden staan online. Nu zijn de busnrs en apptnrs wel
netjes als array opgenomen en niet meer als comma-separated-string.

Ik zag gisteren inderdaad dat het niet zo handig is om die mega-commit
van die data-bestanden samen uit te voeren met wat losse wijzigingen in
de code. Ik ga ze voortaan braaf in losse commits pushen ;-)

Verder heb ik ook een doc-directory toegevoegd om de documentatie in te
verzamelen. Daarin staan de documenten die ik eerder al op mijn server
plaatste en ook een CSV-bestand met daarin de postcode-gemeentenaam
probleemgevallen.

Groeten,
Thomas

Sander Deryckere schreef op 2-11-2014 9:41:

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

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

Bedankt voor beide meldingen! Het probleem ligt in dit geval bij de
overpass-api. De JSON-response bestaat niet uit JSON maar uit xhtml.
Wanneer de javascript dat probeert te verwerken als een JSON-response
treedt er een fout op. Dat heeft vast te maken met de emergency rollback
waar je eerder over mailde.

Ik heb even het request naar overpass.osm.rambler.ru doorgestuurd
waardoor het request op zich nu weer werkt. Verderop in het script loopt
nu wat verkeerd omdat het antwoord van deze Russische variant blijkbaar
inhoudelijk verschillend is van de originele Duitse website. Ik kijk
even of ik dat op kan lossen, anders draai ik het geheel terug naar de
originele Duitse variant en moeten we maar even wachten tot de emergency
rollback voorbij is.

Groeten,
Thomas

Glenn Plas schreef op 2-11-2014 23:19:

There's an error at the moment with the importer.

loadStreets.js:276
Uncaught SyntaxError: Unexpected token <
import.html?pcode=1982&filterStreets=*&maxDistance=&loadOsm=true&includePcode=false&crabInfo=false&…:1

This is on chrome.

Glenn

On 02-11-14 10:57, Thomas wrote:

De nieuwe JSON-bestanden staan online. Nu zijn de busnrs en apptnrs wel
netjes als array opgenomen en niet meer als comma-separated-string.

Groeten,
Thomas

Sander Deryckere schreef op 2-11-2014 9:41:

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

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

2014-11-02 Thread Glenn Plas

There's an error at the moment with the importer.

loadStreets.js:276
Uncaught SyntaxError: Unexpected token <
import.html?pcode=1982&filterStreets=*&maxDistance=&loadOsm=true&includePcode=false&crabInfo=false&…:1

..




This is on chrome.

Glenn


On 02-11-14 10:57, Thomas wrote:
> De nieuwe JSON-bestanden staan online. Nu zijn de busnrs en apptnrs wel
> netjes als array opgenomen en niet meer als comma-separated-string.
> 
> Ik zag gisteren inderdaad dat het niet zo handig is om die mega-commit
> van die data-bestanden samen uit te voeren met wat losse wijzigingen in
> de code. Ik ga ze voortaan braaf in losse commits pushen ;-)
> 
> Verder heb ik ook een doc-directory toegevoegd om de documentatie in te
> verzamelen. Daarin staan de documenten die ik eerder al op mijn server
> plaatste en ook een CSV-bestand met daarin de postcode-gemeentenaam
> probleemgevallen.
> 
> Groeten,
> Thomas
> 
> Sander Deryckere schreef op 2-11-2014 9:41:
>> 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
>>
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be


-- 
"Everything is going to be 200 OK."

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

2014-11-02 Thread Sander Deryckere

De appartementnummers en busnummers zijn nu toegevoegd aan de tools. Er
wordt ook gewaarschuwd indien zowel bus- als appartementsnummers aanwezig
zijn. Wees nog voorzichtig met deze tag. Ik heb nog geen tijd gehad om uit
te zoeken welke CRAB onderverdeling nu gebruikt wordt in welk geval.

Ik heb ook een test toegevoegd die moet helpen om de huisnummers te
standardiseren. Voor alles wat nu buiten het standaardformaat valt zal je
een waarschuwing voor krijgen (bijvoorbeeld 10_2, wat 10 bis of 10/2 zou
moeten zijn). Ik hoop dat er zo niet teveel vals-positieven gegenereerd
worden. We kunnen altijd nog die test terug verwijderen of versoepelen.

Groeten,
Sander

Op 2 november 2014 14:35 schreef Glenn Plas :

> Heb nu postcode 1982 gedaan tot en met straten met een "T*".  Heel veel
> werkt, mijn RSI-pols is terug maar we zijn er bijna erdoor.
>
> Er vallen mij wel aantal dingen op.
>
> -1A vs 1a wordt door de tool als fout gemerkt, niet echt een probleem,
> ik zet ze allemaal naar de hoofdletter versie, mss wel goed dat het
> uniform is.
>
> - CRab data voor 1982 is niet slecht meestal.  Ik vind niet veel fouten
> eigenlijk tot hiertoe, meeste zijn twijfelaars ivm subaddressen
>
> - Indien CRAB enkel officiele nummer vermeld (ik weet hier een 3-woonst
> die enkel onder nummer 1 gekend is hier).  Maar ik heb er persoonlijk
> een survey gedaan, dus 1/1,2,3 bestaan.  Dat zet ik onder addr:flats
> indien gemeenschappelijke ingang.
>
> Gaat prima tot hiertoe.  Geen noemenswaardige issues.
>
> Glenn
>
>
> On 02-11-14 10:56, Jo wrote:
> > 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.
>
> ___
> 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

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

2014-11-02 Thread Glenn Plas

Heb nu postcode 1982 gedaan tot en met straten met een "T*".  Heel veel
werkt, mijn RSI-pols is terug maar we zijn er bijna erdoor.

Er vallen mij wel aantal dingen op.

-1A vs 1a wordt door de tool als fout gemerkt, niet echt een probleem,
ik zet ze allemaal naar de hoofdletter versie, mss wel goed dat het
uniform is.

- CRab data voor 1982 is niet slecht meestal.  Ik vind niet veel fouten
eigenlijk tot hiertoe, meeste zijn twijfelaars ivm subaddressen

- Indien CRAB enkel officiele nummer vermeld (ik weet hier een 3-woonst
die enkel onder nummer 1 gekend is hier).  Maar ik heb er persoonlijk
een survey gedaan, dus 1/1,2,3 bestaan.  Dat zet ik onder addr:flats
indien gemeenschappelijke ingang.

Gaat prima tot hiertoe.  Geen noemenswaardige issues.

Glenn


On 02-11-14 10:56, Jo wrote:
> 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.

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

De nieuwe JSON-bestanden staan online. Nu zijn de busnrs en apptnrs wel 
netjes als array opgenomen en niet meer als comma-separated-string.


Ik zag gisteren inderdaad dat het niet zo handig is om die mega-commit 
van die data-bestanden samen uit te voeren met wat losse wijzigingen in 
de code. Ik ga ze voortaan braaf in losse commits pushen ;-)


Verder heb ik ook een doc-directory toegevoegd om de documentatie in te 
verzamelen. Daarin staan de documenten die ik eerder al op mijn server 
plaatste en ook een CSV-bestand met daarin de postcode-gemeentenaam 
probleemgevallen.


Groeten,
Thomas

Sander Deryckere schreef op 2-11-2014 9:41:
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



___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

2014-11-02 Thread Jo

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 :

> 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 :
>
>  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 :
>>
>>>  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 :
>>>
>>>  Zoals eerder gezegd

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

2014-11-02 Thread Sander Deryckere

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 :

>  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 :
>
>>  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 :
>>
>>  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
>
>
__

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


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 >:


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 mailto: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 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

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

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 :

>  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 :
>
>  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 list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

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 >:


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

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

2014-11-01 Thread Marc Gemis

2014-10-31 16:22 GMT+01:00 Sander Deryckere :

> Verder heb ik er ook nog een optie aan toegevoegd om te exporteren naar
> GPX. Onderaan de tabel vind je drie knoppen om die drie kolommen te
> exporteren naar GPX, en zo alle probleemgevallen in je gemeente naar je GPS
> of smartphone te downloaden (door de simpele html werkt de site ook
> tamelijk goed op een smartphone, waardoor je niet met kabeltjes moet
> klungelen, maar het rechtstreeks daar kan downloaden).
>

Net de eerste field-test achter de rug met die bestanden.
Alle 3 de bestanden voor 2840 gedownload en op mijn Garmin Dakota 10 gezet.

Eerste probleem: de Dakota heeft niet genoeg geheugen. Ik kon geen
waypoints meer bijmaken.
Als iemand een programma kent (OSX) dat waypoints kan beperken binnen een
bounding box, laat het maar weten. Ik zal eens met Basecamp proberen.

2de probleem, de namen van de waypoints zijn te lang. Ze worden afgekapt,
zodat je de huisnummers niet meer ziet. Sander, zou je de fout kunnen
korter maken en de nummer naar voor kunnen brengen ? (ipv van vb.
missing_overlapping_Kardinaal_Cardijnstraat xx
misov_xx_Kardidaal_Cardijnstraat.
Aan de korte naam van de fout wennen we wel en de straatnaam is zelfs
onvolledige nog wel te herkennen. Zeker omdat het punt toch juist staat.

met vriendelijke groeten

m
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

Op 1 november 2014 13:15 schreef Gilbert Hersschens :

> Ik heb even een poging gedaan. Ziet er wel handig uit, maar bij
> appartementen geeft hij een hoop "missing" nummers op omdat hij geen
> rekening houdt met get gebruik van een bereik van nummers. Ik ben eerlijk
> gezegd niet van zin om ieder individueel huisnummer van elk apt dat in een
> appartementsblok zit in te tikken. Ik weet wel dat er discussie is hierover
> (zie de desbetreffende wiki
> https://wiki.openstreetmap.org/wiki/Addresses#Buildings_with_multiple_house_numbers)
> maar zowel de AGIV/Geopunt kaart alsook in sommige gevallen de plaatjes op
> de appartementen zelf tonen alle mogelijke varianten van nummering.
> Ter illustratie een paar foto's op
> https://drive.google.com/folderview?id=0B_mcNCW4oRVOSE13OGZEM040UzQ&usp=sharing
> .
> Overigens zitten er ook nog andere fouten in, maar dat ligt misschien aan
> de data in CRAB? Zo geeft hij bv. voor Elsum 191-191C in Geel (2440)  op
> dat hier de nummers 191A, B, C en D zouden moeten staan terwijl nummer 191
> (zonder suffix) er ook bij hoort. Zie fofo op de link hierboven.
>
> Gilbert
>
De tool houdt wel rekening met het bereik. Het zal bijvoorbeeld nummers 5
en 7 als "missing" opgeven, maar als die nummers in de werkelijkheid
overlappen (ze zijn beiden huisnummer van hetzelfde gebouw), en je voegt
een gebouw toe met nummer "5-7", dan zouden er twee "missing" nummers
minder moeten zijn.

Daarnaast moet je ook goed het verschil tussen bus/appartementnummers en
bisnummers weten. Bisnummers zijn deel van het huisnummer. bus- en
apartementnummers zijn verschillende brievenbussen met dezelfde voordeur.

Bij de bisnummers kan het gebeuren dat er verschillende gebouwen bedoeld
zijn, en dat ze dus apart gemapt moeten worden. Maar het kan ook gebeuren
dat hetzelfde gebouw (Eventueel met een andere ingang) bedoeld is, en in
dat geval zal bijvoorbeeld het huisnummer "7-7A" aanvaard worden. Bus- en
appartementsnummers zijn echter nooit deel van het huisnummer, en zullen
altijd op hetzelfde gebouw getagd zijn. Bijvoorbeeld een gebouw met de tags

addr:street = Dorpsstraat
addr:housenumber = 5
addr:flats = 1,2,3,4,5,6

heeft 6 appartementnummers op dat ene adres.

De meeste foto's die jij toont zijn waarschijnlijk bus- of
appartementnummers. Die zullen normaal gezien zelfs nooit apart verschijnen
in CRAB.

Zou je met de bovenstaande info je probleemgevallen nog eens kunnen
controleren?

Groeten,
Sander


>
> 2014-11-01 12:31 GMT+01:00 Glenn Plas :
>
>> Heb nog niks concreet eigenlijk, maar wel paar ideetjes alvast.  De
>> problemen die ik zag zijn zo te zien allemaal ondertussen opgelost.
>>
>>
>> De wiki handleiding is handig ook.  Tijdens het gebruiken heb ik
>> eigenlijk vooral problemen bij nr notaties van dit type:
>>
>> vb1:
>>
>> nr is 100 , bus 4
>>
>> varianten die je ziet:
>>
>> - 100b4
>> - 100/4
>>
>>
>> vb2:
>>
>> nr is 26 / A
>>
>> - 26A
>> - 26/a
>> - 26a
>>
>> vb3 (moeilijker)
>>
>> - 46 / 0001 en 46 / 0101 (2-woonst... op het gebouw zo op de plaatjes),
>> vind ik maar rare nummering.  Ik ben al even op zoek in de wiki over wat
>> de consensus nu is over dit soort adressen.
>>
>> Die vind je ook niet terug in CRAB.  Maar zo'n nodes zie ik de meeste
>> 'missing in crab' terugkomen.
>>
>> Ik hou me nog wel wat in tot ik iets echt nuttig kan toevoegen.
>>
>>
>> Glenn
>>
>>
>> On 01-11-14 11:36, Thomas wrote:
>> > Vooraleer iemand in het komende uur of zo een pull of push wil gaan
>> > uitvoeren: ik sta op het punt de nieuwe JSON bestanden te pushen. Het
>> > enige punt waarop ze niet backwards-compatible zijn is het feit dat het
>> > huisnummerlabel nu in een lijst zit. Ik heb de loadStreets.js al
>> > aangepast naar een vorm waarin voor de 5x dat een huisnummerlabel
>> > gelezen wordt in het script gewoon het eerste element uit de array
>> > genomen wordt. Die nieuwe variant van de javascript zit als het goed is
>> > mee in die push.
>> >
>> > Gelieve dus nog even een uurtje te wachten met andere acties, anders
>> > komen er mogelijk een hele hoop conflicten.
>> >
>> > Van zodra de push klaar is, stuur ik nog een mailtje met wat meer
>> > informatie over die postcode-gemeente problematiek en wat inhoudelijke
>> > informatie over de extra gegevens in de JSON. Het kan even duren; de
>> > diff maken voor die hele berg JSON-bestanden duurt vaak wel echt even...
>> >
>> > Groeten,
>> > Thomas
>> >
>> > Sander Deryckere schreef op 1-11-2014 11:25:
>> >>
>> >> Op 1 november 2014 10:30 schreef Glenn Plas > >> >:
>> >>
>> >>
>> >> @Sander Accepteer je de occasionele commits of pull requests?
>> >>
>> >> Zeker, waarover gaat het?
>> >>
>> >
>> >
>> >
>> > ___
>> > Talk-be mailing list
>> > Talk-be@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-be
>> >
>>
>>
>> --
>> "Everything is going to be 200 OK."
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.

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

Op 1 november 2014 13:12 schreef Thomas :

> De nieuwe reeks JSON-bestanden staat inmiddels online.
>
> Bedankt, zal eens kijken als alles nog werkt, en wat er toegevoegd is ;)


> 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.


> Verder wordt er per adres nu ook, indien aanwezig, een lijst met
> busnummers en appartementnummers op dat huisnummer meegegeven (allen
> gesorteerd en gefilterd zodat de lijsten geen dubbele waarden bevatten).
> Hoe beide lijsten zich tot elkaar verhouden kan nu in de praktijk bekeken
> worden. Mogelijk is er soms overlap. Daarnaast zijn er 4 keer zoveel
> busnummers als appartementnummers. Wanneer voor welke gekozen wordt, is mij
> niet duidelijk.
>
> De “message” (die in tekstvorm informatie gaf over busnrs en apptnrs) die
> in de laatste varianten van de javascript niet meer ingeladen werd heb ik
> uit de JSON weggehaald.
>
> Ik heb een element “municipality” toegevoegd die de gemeentenaam
> weergeeft. De postcode was eerder al ontsloten via het element “postc”. Er
> kan nu gekeken worden of en onder welke tags deze gegevens in JOSM
> ingeladen moeten worden. Daarnaast kunnen de gegevens gebruikt worden voor
> een verificatie van bestaande gemeente- en postcodegrenzen in OSM, hoewel
> dat natuurlijk los staat van deze import.
>
> Tot slot heb ik een lijst “otherPCs” toegevoegd aan de
> postcode-JSON-bestanden, die (indien aanwezig) een lijst geeft met de
> andere postcodes waar de betreffende straat in doorloopt. Hoewel dat in het
> huidige systeem niet nodig is, kan het interessante informatie zijn om
> bepaalde vreemde zaken te analyseren.
>
> Ook heb ik een overzicht gemaakt van de gebruikte JSON-elementen zodat
> voor iedereen duidelijk is welke informatie beschikbaar wordt gesteld via
> de JSON-bestanden en op welke manier dat gebeurt. Daarnaast heb ik ook de
> data-specificatie van de adressenlijst zelf opgenomen. Het bestand staat nu
> op http://downloader.aptum.nl/data_format.pdf maar ga ik netjes
> integreren met de rest van de documentatie en vervolgens als verzamelde
> documentatie op github plaatsen.
>
> Dan over die vreemde postcode-gemeente overlap. Ben gaf eerder aan dat er
> situaties zijn waarin postcode-straatnaam-huisnummer niet uniek zijn en dat
> de gemeentenaam daarbij noodzakelijk is om het adres te identificeren.
> Uiteraard heb je per postcode-straatnaam-huisnummer een hele verzameling
> subadressen (met elk een eigen busnummer / appartementnummer) maar dat was
> uiteraard niet wat er bedoeld werd. Ik heb de volledige dataset expliciet
> doorzocht naar een situatie waarbij er voor een combinatie van
> postcode-straatnaam-huisnummer meerdere gemeenten geregistreerd waren, maar
> die heb ik niet kunnen aantreffen.
>
> Als deze situatie zich zou voordoen, dan kan dit enkel voor de gevallen
> waar een postcode zich over meerdere gemeenten uitstrekt. We weten al dat
> deze situatie zich slechts voor 253 adressen binnen de volledige dataset
> (2.639.893 echte adressen) voordoet. Van die 253 adressen die een
> gemeentenaam hebben die je niet bij die postcode verwacht, lijkt het
> meestal om vergissingen te gaan. Ik heb het idee dat wat Sander aanhaalt
> wel eens de systematisch fout kan zijn: iets met gemeentelijke
> herindelingen. Dat is de enige logica die in de collectie fouten lijkt te
> zitten.
>
> Om dat verder uit te zoeken heb ik volgend document opgesteld:
> http://downloader.aptum.nl/multiple_NIS_per_PC.pdf . Daarin heb ik de
> betreffende 253 adressen per straat gegroepeerd en het aantal adressen per
> straat aangegeven. De postcode en gemeente zijn de gegevens zoals die voor
> dat adres in de CRAB-adressenlijst zijn opgegeven. De Gemeente_verwacht is
> de gemeente zoals mijn script die zou verwachten voor de opgegeven
> postcode. De vraag is dus hoe beide gemeenten gerelateerd zijn. Zoals
> Sander al schreef is de kans zeer aanwezig dat de opgegeven postcodes nog
> “oude” postcodes zijn van voor de gemeentelijke herindeling, en dat de
> opgegeven gemeente dus wel klopt, maar dat de postcode verouderd is. Ik ga
> dat proberen systematisch na te zoeken. In elk geval betreft het hier
> fouten in de CRAB-adressenlijst.
>
> In de adressenlijst zitten geen gegevens over de status van het adres (zie
> ook de data-specificatie hierboven). Mogelijk is dat wel een achterliggende
> reden: dat de adressen in de praktijk geschrapt zijn en daarmee niet
> bijgewerkt worden, maar dat ze niet formeel een statuswijziging gekregen
> hebben in de database. Dat zal het Agiv echter moeten uitzoe

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

Op 1-nov.-2014 17:30 schreef "Stijn Rombauts" :
>
> Hoi,
>
> Misschien een kleine bijdrage ivm adressering (busnummers, cijfers in
straatnamen e.d.). De post zegt op http://www.bpost.be/adressering/ hoe het
allemaal zou moeten. Kan een reden zijn om in osm dezelfde regels te volgen.
>
> Groetje,
>
> Stijn
>
Dit is hoe we het al doen in OSM. Enkel de schrijfwijze van numeriek
uitgebreide huisnummers (zoals 16/2) is hier expliciet vermeld, terwijl het
in crab 16_2 is. Dat es ook iets wat ik al eerder vermeld had.

Dus niets nieuws.

Groeten,
Sander.

> 
> From: Glenn Plas 
> To: OpenStreetMap Belgium 
> Sent: Saturday, November 1, 2014 12:31 PM
> Subject: Re: [OSM-talk-be] import AGIV CRAB-data
>
> Heb nog niks concreet eigenlijk, maar wel paar ideetjes alvast.  De
> problemen die ik zag zijn zo te zien allemaal ondertussen opgelost.
>
>
> De wiki handleiding is handig ook.  Tijdens het gebruiken heb ik
> eigenlijk vooral problemen bij nr notaties van dit type:
>
> vb1:
>
> nr is 100 , bus 4
>
> varianten die je ziet:
>
> - 100b4
> - 100/4
>
>
> vb2:
>
> nr is 26 / A
>
> - 26A
> - 26/a
> - 26a
>
> vb3 (moeilijker)
>
> - 46 / 0001 en 46 / 0101 (2-woonst... op het gebouw zo op de plaatjes),
> vind ik maar rare nummering.  Ik ben al even op zoek in de wiki over wat
> de consensus nu is over dit soort adressen.
>
> Die vind je ook niet terug in CRAB.  Maar zo'n nodes zie ik de meeste
> 'missing in crab' terugkomen.
>
> Ik hou me nog wel wat in tot ik iets echt nuttig kan toevoegen.
>
>
> Glenn
>
>
> On 01-11-14 11:36, Thomas wrote:
> > Vooraleer iemand in het komende uur of zo een pull of push wil gaan
> > uitvoeren: ik sta op het punt de nieuwe JSON bestanden te pushen. Het
> > enige punt waarop ze niet backwards-compatible zijn is het feit dat het
> > huisnummerlabel nu in een lijst zit. Ik heb de loadStreets.js al
> > aangepast naar een vorm waarin voor de 5x dat een huisnummerlabel
> > gelezen wordt in het script gewoon het eerste element uit de array
> > genomen wordt. Die nieuwe variant van de javascript zit als het goed is
> > mee in die push.
> >
> > Gelieve dus nog even een uurtje te wachten met andere acties, anders
> > komen er mogelijk een hele hoop conflicten.
> >
> > Van zodra de push klaar is, stuur ik nog een mailtje met wat meer
> > informatie over die postcode-gemeente problematiek en wat inhoudelijke
> > informatie over de extra gegevens in de JSON. Het kan even duren; de
> > diff maken voor die hele berg JSON-bestanden duurt vaak wel echt even...
> >
> > Groeten,
> > Thomas
> >
> > Sander Deryckere schreef op 1-11-2014 11:25:
> >>
> >> Op 1 november 2014 10:30 schreef Glenn Plas  >> <mailto:gl...@byte-consult.be>>:
> >>
> >>
> >>@Sander Accepteer je de occasionele commits of pull requests?
> >>
> >> Zeker, waarover gaat het?
> >>
> >
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> >
>
>
> --
> "Everything is going to be 200 OK."
>
>
> ___
> 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

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

2014-11-01 Thread Sus Verhoeven

Hooi,
Leopoldsburg heeft 2 zonenummers, 3970 en 3971 (vroeger Heppen).
De Vaartstraat loopt door de 2 zones. Nummers 120 en 134 liggen in 3971,
maar 122,126, 128, 130 en 132 die er tussen liggen vindt men in 3970, wat
fout is, ook volgens Bpost.
Fout dus in CRAB.

Sus
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

2014-11-01 Thread Stijn Rombauts

Hoi,

Misschien een kleine bijdrage ivm adressering (busnummers, cijfers in 
straatnamen e.d.). De post zegt op http://www.bpost.be/adressering/ hoe het 
allemaal zou moeten. Kan een reden zijn om in osm dezelfde regels te volgen.


Groetje,

Stijn




 From: Glenn Plas 
To: OpenStreetMap Belgium  
Sent: Saturday, November 1, 2014 12:31 PM
Subject: Re: [OSM-talk-be] import AGIV CRAB-data
 

Heb nog niks concreet eigenlijk, maar wel paar ideetjes alvast.  De
problemen die ik zag zijn zo te zien allemaal ondertussen opgelost.


De wiki handleiding is handig ook.  Tijdens het gebruiken heb ik
eigenlijk vooral problemen bij nr notaties van dit type:

vb1:

nr is 100 , bus 4

varianten die je ziet:

- 100b4
- 100/4


vb2:

nr is 26 / A

- 26A
- 26/a
- 26a

vb3 (moeilijker)

- 46 / 0001 en 46 / 0101 (2-woonst... op het gebouw zo op de plaatjes),
vind ik maar rare nummering.  Ik ben al even op zoek in de wiki over wat
de consensus nu is over dit soort adressen.

Die vind je ook niet terug in CRAB.  Maar zo'n nodes zie ik de meeste
'missing in crab' terugkomen.

Ik hou me nog wel wat in tot ik iets echt nuttig kan toevoegen.


Glenn


On 01-11-14 11:36, Thomas wrote:
> Vooraleer iemand in het komende uur of zo een pull of push wil gaan
> uitvoeren: ik sta op het punt de nieuwe JSON bestanden te pushen. Het
> enige punt waarop ze niet backwards-compatible zijn is het feit dat het
> huisnummerlabel nu in een lijst zit. Ik heb de loadStreets.js al
> aangepast naar een vorm waarin voor de 5x dat een huisnummerlabel
> gelezen wordt in het script gewoon het eerste element uit de array
> genomen wordt. Die nieuwe variant van de javascript zit als het goed is
> mee in die push.
> 
> Gelieve dus nog even een uurtje te wachten met andere acties, anders
> komen er mogelijk een hele hoop conflicten.
> 
> Van zodra de push klaar is, stuur ik nog een mailtje met wat meer
> informatie over die postcode-gemeente problematiek en wat inhoudelijke
> informatie over de extra gegevens in de JSON. Het kan even duren; de
> diff maken voor die hele berg JSON-bestanden duurt vaak wel echt even...
> 
> Groeten,
> Thomas
> 
> Sander Deryckere schreef op 1-11-2014 11:25:
>>
>> Op 1 november 2014 10:30 schreef Glenn Plas > <mailto:gl...@byte-consult.be>>:
>>  
>>
>> @Sander Accepteer je de occasionele commits of pull requests?
>>
>> Zeker, waarover gaat het?
>>  
> 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


-- 
"Everything is going to be 200 OK."


___
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

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

On 01-11-14 15:46, Thomas wrote:
> Oeps! Mijn fout. Door het omzetten van huisnummerlabel naar een lijst
> van huisnummerlabels ging het verkeerd als die lijst niet aanwezig was
> in de JSON. Ik heb twee checks toegevoegd rond regel 360. Als het goed
> is is het probleem nu verholpen.

"All engines at 100%, Captain!"

Glenn

-- 
"Everything is going to be 200 OK."

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

Oeps! Mijn fout. Door het omzetten van huisnummerlabel naar een lijst 
van huisnummerlabels ging het verkeerd als die lijst niet aanwezig was 
in de JSON. Ik heb twee checks toegevoegd rond regel 360. Als het goed 
is is het probleem nu verholpen.


Glenn Plas schreef op 1-11-2014 15:07:

Der zit een probleem in de js:


sourceHnr = uniformise(sourceAddr.housenumber);
sourceHnrLabel = uniformise(sourceAddr.hnrlbls[0]);
compHnr = uniformise(compAddr.housenumber);
compHnrLabel = uniformise(compAddr.hnrlbls[0]);


compAddr is not defined, dus ook geen array.  De map laad niet meer.

Glenn

On 01-11-14 13:12, Thomas wrote:

De nieuwe reeks JSON-bestanden staat inmiddels online.

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.

Verder wordt er per adres nu ook, indien aanwezig, een lijst met
busnummers en appartementnummers op dat huisnummer meegegeven (allen
gesorteerd en gefilterd zodat de lijsten geen dubbele waarden bevatten).
Hoe beide lijsten zich tot elkaar verhouden kan nu in de praktijk
bekeken worden. Mogelijk is er soms overlap. Daarnaast zijn er 4 keer
zoveel busnummers als appartementnummers. Wanneer voor welke gekozen
wordt, is mij niet duidelijk.

De “message” (die in tekstvorm informatie gaf over busnrs en apptnrs)
die in de laatste varianten van de javascript niet meer ingeladen werd
heb ik uit de JSON weggehaald.

Ik heb een element “municipality” toegevoegd die de gemeentenaam
weergeeft. De postcode was eerder al ontsloten via het element “postc”.
Er kan nu gekeken worden of en onder welke tags deze gegevens in JOSM
ingeladen moeten worden. Daarnaast kunnen de gegevens gebruikt worden
voor een verificatie van bestaande gemeente- en postcodegrenzen in OSM,
hoewel dat natuurlijk los staat van deze import.

Tot slot heb ik een lijst “otherPCs” toegevoegd aan de
postcode-JSON-bestanden, die (indien aanwezig) een lijst geeft met de
andere postcodes waar de betreffende straat in doorloopt. Hoewel dat in
het huidige systeem niet nodig is, kan het interessante informatie zijn
om bepaalde vreemde zaken te analyseren.

Ook heb ik een overzicht gemaakt van de gebruikte JSON-elementen zodat
voor iedereen duidelijk is welke informatie beschikbaar wordt gesteld
via de JSON-bestanden en op welke manier dat gebeurt. Daarnaast heb ik
ook de data-specificatie van de adressenlijst zelf opgenomen. Het
bestand staat nu op http://downloader.aptum.nl/data_format.pdf maar ga
ik netjes integreren met de rest van de documentatie en vervolgens als
verzamelde documentatie op github plaatsen.

Dan over die vreemde postcode-gemeente overlap. Ben gaf eerder aan dat
er situaties zijn waarin postcode-straatnaam-huisnummer niet uniek zijn
en dat de gemeentenaam daarbij noodzakelijk is om het adres te
identificeren. Uiteraard heb je per postcode-straatnaam-huisnummer een
hele verzameling subadressen (met elk een eigen busnummer /
appartementnummer) maar dat was uiteraard niet wat er bedoeld werd. Ik
heb de volledige dataset expliciet doorzocht naar een situatie waarbij
er voor een combinatie van postcode-straatnaam-huisnummer meerdere
gemeenten geregistreerd waren, maar die heb ik niet kunnen aantreffen.

Als deze situatie zich zou voordoen, dan kan dit enkel voor de gevallen
waar een postcode zich over meerdere gemeenten uitstrekt. We weten al
dat deze situatie zich slechts voor 253 adressen binnen de volledige
dataset (2.639.893 echte adressen) voordoet. Van die 253 adressen die
een gemeentenaam hebben die je niet bij die postcode verwacht, lijkt het
meestal om vergissingen te gaan. Ik heb het idee dat wat Sander aanhaalt
wel eens de systematisch fout kan zijn: iets met gemeentelijke
herindelingen. Dat is de enige logica die in de collectie fouten lijkt
te zitten.

Om dat verder uit te zoeken heb ik volgend document opgesteld:
http://downloader.aptum.nl/multiple_NIS_per_PC.pdf . Daarin heb ik de
betreffende 253 adressen per straat gegroepeerd en het aantal adressen
per straat aangegeven. De postcode en gemeente zijn de gegevens zoals
die voor dat adres in de CRAB-adressenlijst zijn opgegeven. De
Gemeente_verwacht is de gemeente zoals mijn script die zou verwachten
voor de opgegeven postcode. De vraag is dus hoe beide gemeenten
gerelateerd zijn. Zoals Sander al schreef is de kans zeer aanwezig dat
de opgegeven postcodes nog “oude” postcodes zijn van voor de
gemeentelijke herindeling, en dat de opgegeven gemeente dus wel klopt,
maar dat de postcode verouderd is. Ik ga dat proberen systematisch na te
zoeken. In elk geval betreft het hier fouten in de CRAB-adressenlijst.

In de adressenlijst zitten geen gegevens over de status van het adres
(zie ook de data-specificatie hierboven). Mogelijk is dat wel een
achterliggende re

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

Der zit een probleem in de js:


sourceHnr = uniformise(sourceAddr.housenumber);
sourceHnrLabel = uniformise(sourceAddr.hnrlbls[0]);
compHnr = uniformise(compAddr.housenumber);
compHnrLabel = uniformise(compAddr.hnrlbls[0]);


compAddr is not defined, dus ook geen array.  De map laad niet meer.

Glenn

On 01-11-14 13:12, Thomas wrote:
> De nieuwe reeks JSON-bestanden staat inmiddels online.
> 
> 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.
> 
> Verder wordt er per adres nu ook, indien aanwezig, een lijst met
> busnummers en appartementnummers op dat huisnummer meegegeven (allen
> gesorteerd en gefilterd zodat de lijsten geen dubbele waarden bevatten).
> Hoe beide lijsten zich tot elkaar verhouden kan nu in de praktijk
> bekeken worden. Mogelijk is er soms overlap. Daarnaast zijn er 4 keer
> zoveel busnummers als appartementnummers. Wanneer voor welke gekozen
> wordt, is mij niet duidelijk.
> 
> De “message” (die in tekstvorm informatie gaf over busnrs en apptnrs)
> die in de laatste varianten van de javascript niet meer ingeladen werd
> heb ik uit de JSON weggehaald.
> 
> Ik heb een element “municipality” toegevoegd die de gemeentenaam
> weergeeft. De postcode was eerder al ontsloten via het element “postc”.
> Er kan nu gekeken worden of en onder welke tags deze gegevens in JOSM
> ingeladen moeten worden. Daarnaast kunnen de gegevens gebruikt worden
> voor een verificatie van bestaande gemeente- en postcodegrenzen in OSM,
> hoewel dat natuurlijk los staat van deze import.
> 
> Tot slot heb ik een lijst “otherPCs” toegevoegd aan de
> postcode-JSON-bestanden, die (indien aanwezig) een lijst geeft met de
> andere postcodes waar de betreffende straat in doorloopt. Hoewel dat in
> het huidige systeem niet nodig is, kan het interessante informatie zijn
> om bepaalde vreemde zaken te analyseren.
> 
> Ook heb ik een overzicht gemaakt van de gebruikte JSON-elementen zodat
> voor iedereen duidelijk is welke informatie beschikbaar wordt gesteld
> via de JSON-bestanden en op welke manier dat gebeurt. Daarnaast heb ik
> ook de data-specificatie van de adressenlijst zelf opgenomen. Het
> bestand staat nu op http://downloader.aptum.nl/data_format.pdf maar ga
> ik netjes integreren met de rest van de documentatie en vervolgens als
> verzamelde documentatie op github plaatsen.
> 
> Dan over die vreemde postcode-gemeente overlap. Ben gaf eerder aan dat
> er situaties zijn waarin postcode-straatnaam-huisnummer niet uniek zijn
> en dat de gemeentenaam daarbij noodzakelijk is om het adres te
> identificeren. Uiteraard heb je per postcode-straatnaam-huisnummer een
> hele verzameling subadressen (met elk een eigen busnummer /
> appartementnummer) maar dat was uiteraard niet wat er bedoeld werd. Ik
> heb de volledige dataset expliciet doorzocht naar een situatie waarbij
> er voor een combinatie van postcode-straatnaam-huisnummer meerdere
> gemeenten geregistreerd waren, maar die heb ik niet kunnen aantreffen.
> 
> Als deze situatie zich zou voordoen, dan kan dit enkel voor de gevallen
> waar een postcode zich over meerdere gemeenten uitstrekt. We weten al
> dat deze situatie zich slechts voor 253 adressen binnen de volledige
> dataset (2.639.893 echte adressen) voordoet. Van die 253 adressen die
> een gemeentenaam hebben die je niet bij die postcode verwacht, lijkt het
> meestal om vergissingen te gaan. Ik heb het idee dat wat Sander aanhaalt
> wel eens de systematisch fout kan zijn: iets met gemeentelijke
> herindelingen. Dat is de enige logica die in de collectie fouten lijkt
> te zitten.
> 
> Om dat verder uit te zoeken heb ik volgend document opgesteld:
> http://downloader.aptum.nl/multiple_NIS_per_PC.pdf . Daarin heb ik de
> betreffende 253 adressen per straat gegroepeerd en het aantal adressen
> per straat aangegeven. De postcode en gemeente zijn de gegevens zoals
> die voor dat adres in de CRAB-adressenlijst zijn opgegeven. De
> Gemeente_verwacht is de gemeente zoals mijn script die zou verwachten
> voor de opgegeven postcode. De vraag is dus hoe beide gemeenten
> gerelateerd zijn. Zoals Sander al schreef is de kans zeer aanwezig dat
> de opgegeven postcodes nog “oude” postcodes zijn van voor de
> gemeentelijke herindeling, en dat de opgegeven gemeente dus wel klopt,
> maar dat de postcode verouderd is. Ik ga dat proberen systematisch na te
> zoeken. In elk geval betreft het hier fouten in de CRAB-adressenlijst.
> 
> In de adressenlijst zitten geen gegevens over de status van het adres
> (zie ook de data-specificatie hierboven). Mogelijk is dat wel een
> achterliggende reden: dat de adressen in de praktijk geschrapt zijn en
> daarmee niet bijgewerkt worden, maar dat ze niet formeel een
> statuswijziging ge

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

2014-11-01 Thread Gilbert Hersschens

Ik heb even een poging gedaan. Ziet er wel handig uit, maar bij
appartementen geeft hij een hoop "missing" nummers op omdat hij geen
rekening houdt met get gebruik van een bereik van nummers. Ik ben eerlijk
gezegd niet van zin om ieder individueel huisnummer van elk apt dat in een
appartementsblok zit in te tikken. Ik weet wel dat er discussie is hierover
(zie de desbetreffende wiki
https://wiki.openstreetmap.org/wiki/Addresses#Buildings_with_multiple_house_numbers)
maar zowel de AGIV/Geopunt kaart alsook in sommige gevallen de plaatjes op
de appartementen zelf tonen alle mogelijke varianten van nummering.
Ter illustratie een paar foto's op
https://drive.google.com/folderview?id=0B_mcNCW4oRVOSE13OGZEM040UzQ&usp=sharing
.
Overigens zitten er ook nog andere fouten in, maar dat ligt misschien aan
de data in CRAB? Zo geeft hij bv. voor Elsum 191-191C in Geel (2440)  op
dat hier de nummers 191A, B, C en D zouden moeten staan terwijl nummer 191
(zonder suffix) er ook bij hoort. Zie fofo op de link hierboven.

Gilbert

2014-11-01 12:31 GMT+01:00 Glenn Plas :

> Heb nog niks concreet eigenlijk, maar wel paar ideetjes alvast.  De
> problemen die ik zag zijn zo te zien allemaal ondertussen opgelost.
>
>
> De wiki handleiding is handig ook.  Tijdens het gebruiken heb ik
> eigenlijk vooral problemen bij nr notaties van dit type:
>
> vb1:
>
> nr is 100 , bus 4
>
> varianten die je ziet:
>
> - 100b4
> - 100/4
>
>
> vb2:
>
> nr is 26 / A
>
> - 26A
> - 26/a
> - 26a
>
> vb3 (moeilijker)
>
> - 46 / 0001 en 46 / 0101 (2-woonst... op het gebouw zo op de plaatjes),
> vind ik maar rare nummering.  Ik ben al even op zoek in de wiki over wat
> de consensus nu is over dit soort adressen.
>
> Die vind je ook niet terug in CRAB.  Maar zo'n nodes zie ik de meeste
> 'missing in crab' terugkomen.
>
> Ik hou me nog wel wat in tot ik iets echt nuttig kan toevoegen.
>
>
> Glenn
>
>
> On 01-11-14 11:36, Thomas wrote:
> > Vooraleer iemand in het komende uur of zo een pull of push wil gaan
> > uitvoeren: ik sta op het punt de nieuwe JSON bestanden te pushen. Het
> > enige punt waarop ze niet backwards-compatible zijn is het feit dat het
> > huisnummerlabel nu in een lijst zit. Ik heb de loadStreets.js al
> > aangepast naar een vorm waarin voor de 5x dat een huisnummerlabel
> > gelezen wordt in het script gewoon het eerste element uit de array
> > genomen wordt. Die nieuwe variant van de javascript zit als het goed is
> > mee in die push.
> >
> > Gelieve dus nog even een uurtje te wachten met andere acties, anders
> > komen er mogelijk een hele hoop conflicten.
> >
> > Van zodra de push klaar is, stuur ik nog een mailtje met wat meer
> > informatie over die postcode-gemeente problematiek en wat inhoudelijke
> > informatie over de extra gegevens in de JSON. Het kan even duren; de
> > diff maken voor die hele berg JSON-bestanden duurt vaak wel echt even...
> >
> > Groeten,
> > Thomas
> >
> > Sander Deryckere schreef op 1-11-2014 11:25:
> >>
> >> Op 1 november 2014 10:30 schreef Glenn Plas  >> >:
> >>
> >>
> >> @Sander Accepteer je de occasionele commits of pull requests?
> >>
> >> Zeker, waarover gaat het?
> >>
> >
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> >
>
>
> --
> "Everything is going to be 200 OK."
>
> ___
> 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

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


De nieuwe reeks JSON-bestanden staat inmiddels online.

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.


Verder wordt er per adres nu ook, indien aanwezig, een lijst met 
busnummers en appartementnummers op dat huisnummer meegegeven (allen 
gesorteerd en gefilterd zodat de lijsten geen dubbele waarden bevatten). 
Hoe beide lijsten zich tot elkaar verhouden kan nu in de praktijk 
bekeken worden. Mogelijk is er soms overlap. Daarnaast zijn er 4 keer 
zoveel busnummers als appartementnummers. Wanneer voor welke gekozen 
wordt, is mij niet duidelijk.


De “message” (die in tekstvorm informatie gaf over busnrs en apptnrs) 
die in de laatste varianten van de javascript niet meer ingeladen werd 
heb ik uit de JSON weggehaald.


Ik heb een element “municipality” toegevoegd die de gemeentenaam 
weergeeft. De postcode was eerder al ontsloten via het element “postc”. 
Er kan nu gekeken worden of en onder welke tags deze gegevens in JOSM 
ingeladen moeten worden. Daarnaast kunnen de gegevens gebruikt worden 
voor een verificatie van bestaande gemeente- en postcodegrenzen in OSM, 
hoewel dat natuurlijk los staat van deze import.


Tot slot heb ik een lijst “otherPCs” toegevoegd aan de 
postcode-JSON-bestanden, die (indien aanwezig) een lijst geeft met de 
andere postcodes waar de betreffende straat in doorloopt. Hoewel dat in 
het huidige systeem niet nodig is, kan het interessante informatie zijn 
om bepaalde vreemde zaken te analyseren.


Ook heb ik een overzicht gemaakt van de gebruikte JSON-elementen zodat 
voor iedereen duidelijk is welke informatie beschikbaar wordt gesteld 
via de JSON-bestanden en op welke manier dat gebeurt. Daarnaast heb ik 
ook de data-specificatie van de adressenlijst zelf opgenomen. Het 
bestand staat nu op http://downloader.aptum.nl/data_format.pdf maar ga 
ik netjes integreren met de rest van de documentatie en vervolgens als 
verzamelde documentatie op github plaatsen.


Dan over die vreemde postcode-gemeente overlap. Ben gaf eerder aan dat 
er situaties zijn waarin postcode-straatnaam-huisnummer niet uniek zijn 
en dat de gemeentenaam daarbij noodzakelijk is om het adres te 
identificeren. Uiteraard heb je per postcode-straatnaam-huisnummer een 
hele verzameling subadressen (met elk een eigen busnummer / 
appartementnummer) maar dat was uiteraard niet wat er bedoeld werd. Ik 
heb de volledige dataset expliciet doorzocht naar een situatie waarbij 
er voor een combinatie van postcode-straatnaam-huisnummer meerdere 
gemeenten geregistreerd waren, maar die heb ik niet kunnen aantreffen.


Als deze situatie zich zou voordoen, dan kan dit enkel voor de gevallen 
waar een postcode zich over meerdere gemeenten uitstrekt. We weten al 
dat deze situatie zich slechts voor 253 adressen binnen de volledige 
dataset (2.639.893 echte adressen) voordoet. Van die 253 adressen die 
een gemeentenaam hebben die je niet bij die postcode verwacht, lijkt het 
meestal om vergissingen te gaan. Ik heb het idee dat wat Sander aanhaalt 
wel eens de systematisch fout kan zijn: iets met gemeentelijke 
herindelingen. Dat is de enige logica die in de collectie fouten lijkt 
te zitten.


Om dat verder uit te zoeken heb ik volgend document opgesteld: 
http://downloader.aptum.nl/multiple_NIS_per_PC.pdf . Daarin heb ik de 
betreffende 253 adressen per straat gegroepeerd en het aantal adressen 
per straat aangegeven. De postcode en gemeente zijn de gegevens zoals 
die voor dat adres in de CRAB-adressenlijst zijn opgegeven. De 
Gemeente_verwacht is de gemeente zoals mijn script die zou verwachten 
voor de opgegeven postcode. De vraag is dus hoe beide gemeenten 
gerelateerd zijn. Zoals Sander al schreef is de kans zeer aanwezig dat 
de opgegeven postcodes nog “oude” postcodes zijn van voor de 
gemeentelijke herindeling, en dat de opgegeven gemeente dus wel klopt, 
maar dat de postcode verouderd is. Ik ga dat proberen systematisch na te 
zoeken. In elk geval betreft het hier fouten in de CRAB-adressenlijst.


In de adressenlijst zitten geen gegevens over de status van het adres 
(zie ook de data-specificatie hierboven). Mogelijk is dat wel een 
achterliggende reden: dat de adressen in de praktijk geschrapt zijn en 
daarmee niet bijgewerkt worden, maar dat ze niet formeel een 
statuswijziging gekregen hebben in de database. Dat zal het Agiv echter 
moeten uitzoeken.


Verdere analyse moet uitwijzen of er ook “correcte” gegevens in de lijst 
staan. Dat zal aangeven of de situatie van een postcode die over 
meerdere gemeenten loopt ook daadwerkelijk voorkomt. Ik ben geneigd te 
denken van niet. In totaal hebben we nu maximaal 253 adressen waarvan 
toch zeker een aanzienlijk deel gewoon fouten zijn. Stel dat er 50 
plausibele gevallen overblijven in de tot

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

Heb nog niks concreet eigenlijk, maar wel paar ideetjes alvast.  De
problemen die ik zag zijn zo te zien allemaal ondertussen opgelost.


De wiki handleiding is handig ook.  Tijdens het gebruiken heb ik
eigenlijk vooral problemen bij nr notaties van dit type:

vb1:

nr is 100 , bus 4

varianten die je ziet:

- 100b4
- 100/4


vb2:

nr is 26 / A

- 26A
- 26/a
- 26a

vb3 (moeilijker)

- 46 / 0001 en 46 / 0101 (2-woonst... op het gebouw zo op de plaatjes),
vind ik maar rare nummering.  Ik ben al even op zoek in de wiki over wat
de consensus nu is over dit soort adressen.

Die vind je ook niet terug in CRAB.  Maar zo'n nodes zie ik de meeste
'missing in crab' terugkomen.

Ik hou me nog wel wat in tot ik iets echt nuttig kan toevoegen.


Glenn


On 01-11-14 11:36, Thomas wrote:
> Vooraleer iemand in het komende uur of zo een pull of push wil gaan
> uitvoeren: ik sta op het punt de nieuwe JSON bestanden te pushen. Het
> enige punt waarop ze niet backwards-compatible zijn is het feit dat het
> huisnummerlabel nu in een lijst zit. Ik heb de loadStreets.js al
> aangepast naar een vorm waarin voor de 5x dat een huisnummerlabel
> gelezen wordt in het script gewoon het eerste element uit de array
> genomen wordt. Die nieuwe variant van de javascript zit als het goed is
> mee in die push.
> 
> Gelieve dus nog even een uurtje te wachten met andere acties, anders
> komen er mogelijk een hele hoop conflicten.
> 
> Van zodra de push klaar is, stuur ik nog een mailtje met wat meer
> informatie over die postcode-gemeente problematiek en wat inhoudelijke
> informatie over de extra gegevens in de JSON. Het kan even duren; de
> diff maken voor die hele berg JSON-bestanden duurt vaak wel echt even...
> 
> Groeten,
> Thomas
> 
> Sander Deryckere schreef op 1-11-2014 11:25:
>>
>> Op 1 november 2014 10:30 schreef Glenn Plas > >:
>>  
>>
>> @Sander Accepteer je de occasionele commits of pull requests?
>>
>> Zeker, waarover gaat het?
>>  
> 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


-- 
"Everything is going to be 200 OK."

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

Vooraleer iemand in het komende uur of zo een pull of push wil gaan 
uitvoeren: ik sta op het punt de nieuwe JSON bestanden te pushen. Het 
enige punt waarop ze niet backwards-compatible zijn is het feit dat het 
huisnummerlabel nu in een lijst zit. Ik heb de loadStreets.js al 
aangepast naar een vorm waarin voor de 5x dat een huisnummerlabel 
gelezen wordt in het script gewoon het eerste element uit de array 
genomen wordt. Die nieuwe variant van de javascript zit als het goed is 
mee in die push.


Gelieve dus nog even een uurtje te wachten met andere acties, anders 
komen er mogelijk een hele hoop conflicten.


Van zodra de push klaar is, stuur ik nog een mailtje met wat meer 
informatie over die postcode-gemeente problematiek en wat inhoudelijke 
informatie over de extra gegevens in de JSON. Het kan even duren; de 
diff maken voor die hele berg JSON-bestanden duurt vaak wel echt even...


Groeten,
Thomas

Sander Deryckere schreef op 1-11-2014 11:25:


Op 1 november 2014 10:30 schreef Glenn Plas >:


@Sander Accepteer je de occasionele commits of pull requests?

Zeker, waarover gaat het?



___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

Op 1 november 2014 10:30 schreef Glenn Plas :

> Dat is goed bezig een vette tool te worden 
>
> Ik zie veel fouten in de buurt, maar allemaal op nummers die ik zelf heb
> gemapt, en waarvan ik zeker ben (3 liggen binnen de 100meter).  Het
> lijkt wel alsof crab vol fouten zit.
>
>
> In veel straten (uitgezonderd nieuwe wijken met tamelijk logische
nummering) zit wel een fout. Toch zeker in de gemeenten die CRAB nog niet
gevalideerd hebben.

Dus ja, er zitten wel veel fouten in CRAB, maar meestal is het duidelijk
dat iets fout is (door overlappende adressen, niet-logische volgordes, ...).


> @Sander Accepteer je de occasionele commits of pull requests?
>
> Zeker, waarover gaat het?


> Glenn
>
>
>
> On 01-11-14 09:56, Sander Deryckere wrote:
> >
> >
> > Op 1 november 2014 01:43 schreef Thomas  > >:
> >
> > Je verbeteringen vind ik zeer goed Sander! Bij mij laadt de pagina
> > nu echter niet, met een foutmelding “'section' is null” op
> > loadstreets.js ~664. Het lijkt fout te gaan wanneer in de URL de
> > GET-parameter collapsedSections geset wordt, maar zonder waarde
> > blijft. Als ik die parameter handmatig uit de URL verwijder doet hij
> > het perfect! (tot ik op update druk...).
> >
> >
> > Hmm, dat was dezelfde bug als die van Marc. Ik had die opgelost, maar
> > mijn push naar de online repo was niet doorgekomen. Zou nu ECHT opgelost
> > moeten zijn.
>
> ___
> 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

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

Dat is goed bezig een vette tool te worden 

Ik zie veel fouten in de buurt, maar allemaal op nummers die ik zelf heb
gemapt, en waarvan ik zeker ben (3 liggen binnen de 100meter).  Het
lijkt wel alsof crab vol fouten zit.


@Sander Accepteer je de occasionele commits of pull requests?

Glenn



On 01-11-14 09:56, Sander Deryckere wrote:
> 
> 
> Op 1 november 2014 01:43 schreef Thomas  >:
> 
> Je verbeteringen vind ik zeer goed Sander! Bij mij laadt de pagina
> nu echter niet, met een foutmelding “'section' is null” op
> loadstreets.js ~664. Het lijkt fout te gaan wanneer in de URL de
> GET-parameter collapsedSections geset wordt, maar zonder waarde
> blijft. Als ik die parameter handmatig uit de URL verwijder doet hij
> het perfect! (tot ik op update druk...).
> 
> 
> Hmm, dat was dezelfde bug als die van Marc. Ik had die opgelost, maar
> mijn push naar de online repo was niet doorgekomen. Zou nu ECHT opgelost
> moeten zijn.

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

Op 1 november 2014 01:43 schreef Thomas :

>  Je verbeteringen vind ik zeer goed Sander! Bij mij laadt de pagina nu
> echter niet, met een foutmelding “'section' is null” op loadstreets.js
> ~664. Het lijkt fout te gaan wanneer in de URL de GET-parameter
> collapsedSections geset wordt, maar zonder waarde blijft. Als ik die
> parameter handmatig uit de URL verwijder doet hij het perfect! (tot ik op
> update druk...).
>

Hmm, dat was dezelfde bug als die van Marc. Ik had die opgelost, maar mijn
push naar de online repo was niet doorgekomen. Zou nu ECHT opgelost moeten
zijn.

>
> Ik ben (helaas) nog steeds bezig met het script. In mijn vorige mail
> schreef ik dat de postcodes en de gemeenten schijnbaar niet helemaal
> overlappen. Hoewel dat zeker klopt, ben ik er nu van overtuigd dat ik met
> die check toch wel meer dan 100 fouten in het CRAB gevonden heb. In de 250+
> adrespunten die ik zo geïdentificeerd heb, blijkt het in héél wat gevallen
> om een postcode en een gemeente te gaan die helemaal niet aan elkaar
> grenzen, en soms meer dan 50km uit elkaar liggen. Het moet dus wel om
> fouten gaan. Daarmee heb ik dus een forse set fouten geïdentificeerd...
> Heeft iemand hier een goede ingang bij het AGIV om dit door te geven? Ik
> werk nu aan een nette lijst met alle gegevens.
>
> Ha, net het volgende ontdekt. Voor de fusie in de jaren '70 had
Oostnieuwkerke de postcode 8820. Sinds de fusie hebben we echter de
postcode van Staden (8840). Raar genoeg is 8820 nu wel de postcode van
Torhout (ik weet niet wat hun postcode voor de fusie was).

Als je nu dus de adressen van 8820 bekijkt (
http://aptum.github.io/import.html?pcode=8820&loadOsm=true&collapsedSections=comparison,export,data#data),
dan zie je dat er 2 adressen nog altijd in Oostnieuwkerke liggen (2 dorpen
ten zuiden van Torhout).

Kan je nog eens controleren als die adressen in de adressenlijst niet
aangegeven zijn als "verwijderd" op een of andere manier? Als dat niet
gebeurd is, dan zij dat duidelijk 2 fouten in de CRAB adressenlijst. En
waarschijnlijk dezelfde fout als die andere 100 fouten.


> Dit is eigenlijk (naast dan de afwijkende adres-labels) de enige
> inconsistentie die ik op basis van de data zelf kan vaststellen in de
> adressenlijst. Alle adressen vallen netjes onder een postcode en zo. Dus
> voor onze huidige opzet is er helemaal geen probleem, zoals Sander al
> aangaf. Ik neem de vraag naar postcodes en gemeenten wel mee; ik zorg dat
> deze in de JSON aanwezig zijn. Een verdere verwerking via de javascript is
> dan triviaal. Het importeren van die gegevens in de vorm van discardable
> tags lijkt mij ook helemaal geen probleem. Als dat kan bijdragen aan het
> controleren van die gegevens in OSM lijkt me dat enkel een toevoeging.
>
> De uitspraak van Ben dat er situaties zijn waar postcode, straat en
> huisnummer niet identificerend zijn (naast de busnrs/apptnrs dan) vind ik
> intrigerend. Ik ben wat checks aan het doen op de dataset om te kijken of
> ik dit soort situaties kan vinden. Ik kom hier nog op terug, want onze
> huidige classificatie is wel gebaseerd op het feit dat die drie elementen
> identificerend zouden moeten zijn.
>
> Voor wat betreft de relaties tussen de huisnummers en straten sluit ik mij
> deels aan bij Ben: vanuit mijn informatica-achtergrond ben ik een groot fan
> van dit soort relaties. Vanuit mijn ervaringen met niet-informatici weet ik
> echter dat dat soort abstracte koppelingen die geen zichtbare weerslag
> hebben en puur een ordening op meta-niveau zijn vaak voor ellende zorgen.
> Ik vind dat soort relaties een zeer elegante oplossing, maar tegelijkertijd
> te abstract voor een brede toepassing.
>
> Het toevoegen van postcode en gemeente tags op een adres vind ik dan weer
> lastig; waar houdt het op? Ik denk dat iedereen het absurd vindt om op elke
> tag het land te mappen, maar waarom wel de gemeente? Wat mij betreft vormen
> die gemeentegrenzen toch een basisonderdeel van de kaart. Als we al niet op
> gemeentegrenzen kunnen vertrouwen dan wordt het wel heel lastig. Voor de
> postcodes ligt dat weer iets anders. Postcodes hebben volgens mij puur een
> functie voor postadressen. Wat mij betreft mag dat op de adressen getagd
> worden. Een postcode is naar mijn gevoel ook echt iets wat een eigenschap
> is van een adres, in tegenstelling tot een gemeente dat echt voor een
> grondgebied staat. Het argument van Jo over de data-omvang lijkt mij de
> belangrijkste om het aantal tags toch proberen te beperken, en daarom toch
> de gemeente aan de gemeente-contour over te laten in plaats van deze als
> tag te registreren.
>
> Dat deze ingevoerde gegevens nu misschien niet altijd overeenkomen met wat
> uit een gerenderde kaart komt lijkt mij niet het belangrijkste. Deze
> gegevens kunnen in elk geval gebruikt worden om de contouren (met name dan
> de postcodes) te controleren op afwijkingen ten opzichte van de ingevoerde
> nodes. Op die manier kan eenvoudig de data op de nodes getagd worden en
> kunnen de contouren v

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

2014-10-31 Thread Marc Gemis

2014-11-01 1:43 GMT+01:00 Thomas :

>
> Voor wat betreft de relaties tussen de huisnummers en straten sluit ik mij
> deels aan bij Ben: vanuit mijn informatica-achtergrond ben ik een groot fan
> van dit soort relaties. Vanuit mijn ervaringen met niet-informatici weet ik
> echter dat dat soort abstracte koppelingen die geen zichtbare weerslag
> hebben en puur een ordening op meta-niveau zijn vaak voor ellende zorgen.
> Ik vind dat soort relaties een zeer elegante oplossing, maar tegelijkertijd
> te abstract voor een brede toepassing.
>
>
vergeet niet dat het hier om een geografische databank gaat. Relaties
tussen objecten worden ook (in de eerste plaats zelfs) afgeleid uit hun
onderlinge positie. Er is geen reden om deze expliciet te maken in een
ander object (relatie), zoals bij een relationele databank. Ik dacht tot
voor een jaar ook in termen van relaties, maar doordat op de verschillende
fora en mailing lists zo dikwijls over dat geografische aspect gehamerd
wordt, heb ik mijn mening herzien


> Het toevoegen van postcode en gemeente tags op een adres vind ik dan weer
> lastig; waar houdt het op?
>

Je het die enkel nodig voor de paar uitzonderingsgevallen zoals bv die
langestraat 14 & 15 die Jo aanhaalt, omdat dat "enclaves" zijn binnen een
andere postcode grens. De Engelsen doen het bijna uitsluitend met alles op
de node omdat hun postcodes geen zones zijn.

Ik heb vorig jaar al eens een berekening gemaakt hoeveel ruimte een
associatedStreet relatie inneemt versus een expliciete straatnaam tag. Je
moest al een lange naam hebben wou de relatie minder getransfereerde bytes
inhouden voor JOSM.

Geocoders en navigatie programma's herstructuren de data toch nog volledig,
dus je weet niet wat daarvoor de interessantse structuur is. Ze kappen
bijvoorbeeld toch alle straten verder in stukken op de kruispunten. Dus
plaats besparen door een straat niet in stukken te kappen maakt voor hen
ook niet uit.

Dus voor mij:

- alle gemeente grenzen en postcodes in boundary relaties (en ja daar
moeten we dan maar werk van maken)
- enkel straat en nummer op node
- bij uitzonderingsgevallen city & postcode op node

eenvoudiger kan het niet :-)

mvg

m
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

2014-10-31 Thread Thomas

Je verbeteringen vind ik zeer goed Sander! Bij mij laadt de pagina nu 
echter niet, met een foutmelding “'section' is null” op loadstreets.js 
~664. Het lijkt fout te gaan wanneer in de URL de GET-parameter 
collapsedSections geset wordt, maar zonder waarde blijft. Als ik die 
parameter handmatig uit de URL verwijder doet hij het perfect! (tot ik 
op update druk...).


Ik ben (helaas) nog steeds bezig met het script. In mijn vorige mail 
schreef ik dat de postcodes en de gemeenten schijnbaar niet helemaal 
overlappen. Hoewel dat zeker klopt, ben ik er nu van overtuigd dat ik 
met die check toch wel meer dan 100 fouten in het CRAB gevonden heb. In 
de 250+ adrespunten die ik zo geïdentificeerd heb, blijkt het in héél 
wat gevallen om een postcode en een gemeente te gaan die helemaal niet 
aan elkaar grenzen, en soms meer dan 50km uit elkaar liggen. Het moet 
dus wel om fouten gaan. Daarmee heb ik dus een forse set fouten 
geïdentificeerd... Heeft iemand hier een goede ingang bij het AGIV om 
dit door te geven? Ik werk nu aan een nette lijst met alle gegevens.


Dit is eigenlijk (naast dan de afwijkende adres-labels) de enige 
inconsistentie die ik op basis van de data zelf kan vaststellen in de 
adressenlijst. Alle adressen vallen netjes onder een postcode en zo. Dus 
voor onze huidige opzet is er helemaal geen probleem, zoals Sander al 
aangaf. Ik neem de vraag naar postcodes en gemeenten wel mee; ik zorg 
dat deze in de JSON aanwezig zijn. Een verdere verwerking via de 
javascript is dan triviaal. Het importeren van die gegevens in de vorm 
van discardable tags lijkt mij ook helemaal geen probleem. Als dat kan 
bijdragen aan het controleren van die gegevens in OSM lijkt me dat enkel 
een toevoeging.


De uitspraak van Ben dat er situaties zijn waar postcode, straat en 
huisnummer niet identificerend zijn (naast de busnrs/apptnrs dan) vind 
ik intrigerend. Ik ben wat checks aan het doen op de dataset om te 
kijken of ik dit soort situaties kan vinden. Ik kom hier nog op terug, 
want onze huidige classificatie is wel gebaseerd op het feit dat die 
drie elementen identificerend zouden moeten zijn.


Voor wat betreft de relaties tussen de huisnummers en straten sluit ik 
mij deels aan bij Ben: vanuit mijn informatica-achtergrond ben ik een 
groot fan van dit soort relaties. Vanuit mijn ervaringen met 
niet-informatici weet ik echter dat dat soort abstracte koppelingen die 
geen zichtbare weerslag hebben en puur een ordening op meta-niveau zijn 
vaak voor ellende zorgen. Ik vind dat soort relaties een zeer elegante 
oplossing, maar tegelijkertijd te abstract voor een brede toepassing.


Het toevoegen van postcode en gemeente tags op een adres vind ik dan 
weer lastig; waar houdt het op? Ik denk dat iedereen het absurd vindt om 
op elke tag het land te mappen, maar waarom wel de gemeente? Wat mij 
betreft vormen die gemeentegrenzen toch een basisonderdeel van de kaart. 
Als we al niet op gemeentegrenzen kunnen vertrouwen dan wordt het wel 
heel lastig. Voor de postcodes ligt dat weer iets anders. Postcodes 
hebben volgens mij puur een functie voor postadressen. Wat mij betreft 
mag dat op de adressen getagd worden. Een postcode is naar mijn gevoel 
ook echt iets wat een eigenschap is van een adres, in tegenstelling tot 
een gemeente dat echt voor een grondgebied staat. Het argument van Jo 
over de data-omvang lijkt mij de belangrijkste om het aantal tags toch 
proberen te beperken, en daarom toch de gemeente aan de gemeente-contour 
over te laten in plaats van deze als tag te registreren.


Dat deze ingevoerde gegevens nu misschien niet altijd overeenkomen met 
wat uit een gerenderde kaart komt lijkt mij niet het belangrijkste. Deze 
gegevens kunnen in elk geval gebruikt worden om de contouren (met name 
dan de postcodes) te controleren op afwijkingen ten opzichte van de 
ingevoerde nodes. Op die manier kan eenvoudig de data op de nodes getagd 
worden en kunnen de contouren verbeterd worden, tot die tijd dat andere 
systemen wel met de informatie op de nodes gaan werken. Het beheer van 
de contouren lijkt me in elk geval eenvoudiger te worden met de data op 
de nodes.


Nuja; ik zorg dat alle gegevens via JSON beschikbaar zijn en bijgewerkt 
worden. Met veranderende inzichten kan dan alsnog eenvoudig beslist 
worden deze informatie al dan niet in JOSM in te laden, al dan niet via 
discardable tags.


Groeten,
Thomas

Sander Deryckere schreef op 31-10-2014 19:42:

Marc, die bug moet ondertussen opgelost zijn.

Jo, dat is idd een optie. Maar ik vraag me af als het wel in deze tool 
past. De fixme gaat in veel gevallen niet over het adres, maar ook 
over de naam van de winkel, de openingsuren, ... Daarnaast zijn er ook 
veel fixmes die wel moeten opgelost zijn, maar die niet op een gebouw 
staan. Ik denk dat dit werk is voor een andere tool (het is sowieso al 
mogelijk met overpass turbo, maar het is iets moeilijker overpass 
queries te schrijven op een telefoon).


Bedankt voor de CSS, kan je het meteen al docume

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

2014-10-31 Thread Sander Deryckere

Marc, die bug moet ondertussen opgelost zijn.

Jo, dat is idd een optie. Maar ik vraag me af als het wel in deze tool
past. De fixme gaat in veel gevallen niet over het adres, maar ook over de
naam van de winkel, de openingsuren, ... Daarnaast zijn er ook veel fixmes
die wel moeten opgelost zijn, maar die niet op een gebouw staan. Ik denk
dat dit werk is voor een andere tool (het is sowieso al mogelijk met
overpass turbo, maar het is iets moeilijker overpass queries te schrijven
op een telefoon).

Bedankt voor de CSS, kan je het meteen al documenteren op de wiki? Ik ben
momenteel bezig met sommige van die wiki pagina's te vertalen.

Groeten,
Sander

Op 31 oktober 2014 18:54 schreef Jo :

> Zou het een idee zijn om ook de gebouwen voorzien van een fixme aan zo'n
> GPX-bestand toe te voegen?
>
> Dan kunnen we ook via die weg terugkoppelen dat extra survey nodig is, in
> geval van twijfel.
>
> ook de adressen waar wij zeker van zijn, maar die anders in crab zitten
> zouden we van een tag kunnen voorzien om de terugkoppeling upstream te
> vergemakkelijken.
>
> De MapCSS zal waarschijnlijk morgen beschikbaar zijn.
>
> Jo
> On Oct 31, 2014 4:23 PM, "Sander Deryckere"  wrote:
>
>> Nog wat verder gewerkt aan de tools.
>>
>>
>> De straten worden nu altijd op een kaartje weergegeven, met een
>> kleurencode om aan te duiden hoe compleet die zijn. De links in die popup
>> werken zoals de links in de tabel.
>>
>> Verder heb ik er ook nog een optie aan toegevoegd om te exporteren naar
>> GPX. Onderaan de tabel vind je drie knoppen om die drie kolommen te
>> exporteren naar GPX, en zo alle probleemgevallen in je gemeente naar je GPS
>> of smartphone te downloaden (door de simpele html werkt de site ook
>> tamelijk goed op een smartphone, waardoor je niet met kabeltjes moet
>> klungelen, maar het rechtstreeks daar kan downloaden).
>>
>> Als je de GPX maar voor 1 straat wil hebben, dan vul je best de
>> straat-filter bovenaan de pagina in.
>>
>> Om die GPX bijvoorbeeld met OsmAnd te gebruiken, sla je hem op onder
>> /sdcard/osmand/tracks, en dan kan je die gemakkelijk weergeven en op de
>> markers drukken om te zien over welk adres het gaat.
>>
>> Ik hoop dat dit een goede manier is om gemakkelijk alle probleemgevallen
>> te bezoeken.
>>
>> Groeten,
>> Sander
>>
>> ___
>> 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

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

2014-10-31 Thread Jo

Zou het een idee zijn om ook de gebouwen voorzien van een fixme aan zo'n
GPX-bestand toe te voegen?

Dan kunnen we ook via die weg terugkoppelen dat extra survey nodig is, in
geval van twijfel.

ook de adressen waar wij zeker van zijn, maar die anders in crab zitten
zouden we van een tag kunnen voorzien om de terugkoppeling upstream te
vergemakkelijken.

De MapCSS zal waarschijnlijk morgen beschikbaar zijn.

Jo
On Oct 31, 2014 4:23 PM, "Sander Deryckere"  wrote:

> Nog wat verder gewerkt aan de tools.
>
>
> De straten worden nu altijd op een kaartje weergegeven, met een
> kleurencode om aan te duiden hoe compleet die zijn. De links in die popup
> werken zoals de links in de tabel.
>
> Verder heb ik er ook nog een optie aan toegevoegd om te exporteren naar
> GPX. Onderaan de tabel vind je drie knoppen om die drie kolommen te
> exporteren naar GPX, en zo alle probleemgevallen in je gemeente naar je GPS
> of smartphone te downloaden (door de simpele html werkt de site ook
> tamelijk goed op een smartphone, waardoor je niet met kabeltjes moet
> klungelen, maar het rechtstreeks daar kan downloaden).
>
> Als je de GPX maar voor 1 straat wil hebben, dan vul je best de
> straat-filter bovenaan de pagina in.
>
> Om die GPX bijvoorbeeld met OsmAnd te gebruiken, sla je hem op onder
> /sdcard/osmand/tracks, en dan kan je die gemakkelijk weergeven en op de
> markers drukken om te zien over welk adres het gaat.
>
> Ik hoop dat dit een goede manier is om gemakkelijk alle probleemgevallen
> te bezoeken.
>
> Groeten,
> Sander
>
> ___
> 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

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

2014-10-31 Thread Marc Gemis

Sander, Thomas,

op http://aptum.github.io/import.html moet ik nadat ik op 'update' heb
gedrukt, nu een "back" doen om de data te zien.

platform Chrome op OSX.

veel debug plezier (niet zonder leedvermaak, na een dag van bug hunting op
het werk :-)  )

2014-10-31 17:54 GMT+01:00 Marc Gemis :

> die GPX bestanden gaan zeker van pas komen. hartelijk dank !
>
> m
>
> 2014-10-31 16:22 GMT+01:00 Sander Deryckere :
>
>> Nog wat verder gewerkt aan de tools.
>>
>>
>> De straten worden nu altijd op een kaartje weergegeven, met een
>> kleurencode om aan te duiden hoe compleet die zijn. De links in die popup
>> werken zoals de links in de tabel.
>>
>> Verder heb ik er ook nog een optie aan toegevoegd om te exporteren naar
>> GPX. Onderaan de tabel vind je drie knoppen om die drie kolommen te
>> exporteren naar GPX, en zo alle probleemgevallen in je gemeente naar je GPS
>> of smartphone te downloaden (door de simpele html werkt de site ook
>> tamelijk goed op een smartphone, waardoor je niet met kabeltjes moet
>> klungelen, maar het rechtstreeks daar kan downloaden).
>>
>> Als je de GPX maar voor 1 straat wil hebben, dan vul je best de
>> straat-filter bovenaan de pagina in.
>>
>> Om die GPX bijvoorbeeld met OsmAnd te gebruiken, sla je hem op onder
>> /sdcard/osmand/tracks, en dan kan je die gemakkelijk weergeven en op de
>> markers drukken om te zien over welk adres het gaat.
>>
>> Ik hoop dat dit een goede manier is om gemakkelijk alle probleemgevallen
>> te bezoeken.
>>
>> Groeten,
>> Sander
>>
>> ___
>> 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

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

2014-10-31 Thread Marc Gemis

die GPX bestanden gaan zeker van pas komen. hartelijk dank !

m

2014-10-31 16:22 GMT+01:00 Sander Deryckere :

> Nog wat verder gewerkt aan de tools.
>
>
> De straten worden nu altijd op een kaartje weergegeven, met een
> kleurencode om aan te duiden hoe compleet die zijn. De links in die popup
> werken zoals de links in de tabel.
>
> Verder heb ik er ook nog een optie aan toegevoegd om te exporteren naar
> GPX. Onderaan de tabel vind je drie knoppen om die drie kolommen te
> exporteren naar GPX, en zo alle probleemgevallen in je gemeente naar je GPS
> of smartphone te downloaden (door de simpele html werkt de site ook
> tamelijk goed op een smartphone, waardoor je niet met kabeltjes moet
> klungelen, maar het rechtstreeks daar kan downloaden).
>
> Als je de GPX maar voor 1 straat wil hebben, dan vul je best de
> straat-filter bovenaan de pagina in.
>
> Om die GPX bijvoorbeeld met OsmAnd te gebruiken, sla je hem op onder
> /sdcard/osmand/tracks, en dan kan je die gemakkelijk weergeven en op de
> markers drukken om te zien over welk adres het gaat.
>
> Ik hoop dat dit een goede manier is om gemakkelijk alle probleemgevallen
> te bezoeken.
>
> Groeten,
> Sander
>
> ___
> 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

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

2014-10-31 Thread Sander Deryckere

Nog wat verder gewerkt aan de tools.


De straten worden nu altijd op een kaartje weergegeven, met een kleurencode
om aan te duiden hoe compleet die zijn. De links in die popup werken zoals
de links in de tabel.

Verder heb ik er ook nog een optie aan toegevoegd om te exporteren naar
GPX. Onderaan de tabel vind je drie knoppen om die drie kolommen te
exporteren naar GPX, en zo alle probleemgevallen in je gemeente naar je GPS
of smartphone te downloaden (door de simpele html werkt de site ook
tamelijk goed op een smartphone, waardoor je niet met kabeltjes moet
klungelen, maar het rechtstreeks daar kan downloaden).

Als je de GPX maar voor 1 straat wil hebben, dan vul je best de
straat-filter bovenaan de pagina in.

Om die GPX bijvoorbeeld met OsmAnd te gebruiken, sla je hem op onder
/sdcard/osmand/tracks, en dan kan je die gemakkelijk weergeven en op de
markers drukken om te zien over welk adres het gaat.

Ik hoop dat dit een goede manier is om gemakkelijk alle probleemgevallen te
bezoeken.

Groeten,
Sander
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

klopt volgens mij, maar er moet een reden zijn dat Nominatim niet naar de
tags op de node kijkt. (disk space ?)

m.

2014-10-30 15:10 GMT+01:00 Ben Abelshausen :

> Geen enkele geocoder is correct, heb er toch wel een 5-6 tal getest. Toch
> zeker niet als je dit opgeeft: Langestraat 14, Tremelo. Het grote nadeel
> is dat ze allemaal nominatim gebruiken als is alleen als pre-processing
> stap. Een duidelijke monocultuur als het geocoding aankomt.
>
> Ik begrijp het niet goed, wat we nu ook overeenkomen, en of Jo nu
> associatedStreets toevoegd of niet, die adressen zijn toch over het
> algemeen eenduidig af te leiden:
>
> - 1: Neem tags op node/gebouw eerst.
> - 2: Gebruik associated street tags als stap 1 niet werkt.
> - 3: Gebruik boundaries voor de vermiste informatie.
>
> Of zie ik het nu zo verkeerd?
>
> Ik heb zeker interesse in wat jullie hiervan denken omdat het ook op mijn
> agenda staat om een poging te doen begin volgend jaar.
>
> Met vriendelijke groeten,
> Best regards,
>
> Ben Abelshausen
>
> ___
> 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

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

2014-10-30 Thread Sander Deryckere

Bon,

De CRAB herkomst staat nu altijd als "odbl:note=CRAB:xxx", en kan dus
gebruikt worden in de CSS.

De webpagina is ook aangepast met twee extra opties. Zo kan je nu de CRAB
herkomst ook zichtbaar meekrijgen (voor degene die het willen bekijken), en
kan je ook de postcode als tag toevoegen. Let er op dat die postcode
behandeling nog maar tijdelijk is, en mogelijks buggy. De echte code voor
die optie kan er maar komen als de CRAB data vernieuwd is.

Groeten,
Sander

2014-10-30 15:13 GMT+01:00 Ben Abelshausen :

> Deze ookal:
>
>
> http://maps.skobbler.com/?country=Belgium&city=tremelo&street=Langestraat&number=14&lat=51.0244385&lon=4.7465014&z=16
>
> Met vriendelijke groeten,
> Best regards,
>
> Ben Abelshausen
>
> ___
> 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

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

2014-10-30 Thread Glenn Plas

Ik speel al lang met het idee om een light weight straightforward
geocoder te maken omdat nominatim te zwaar is, de hele PHP code is
vergeven van uitzonderingen , afhankelijk van welke diepte level je zit.

5 jaar geleden moest ik de postcodes er nog bijhacken omdat die voor
belgie niet meekwam als je zelf nominatim opzette (terwijl de indertijd
gazetteer/nominatim het wel kon).

Mijn interesse is vooral voor reverse geocoding (professioneel dan),
maar het moet gewoon simpeler kunnen dan hoe het is nu.

Uw 3 punten zijn wat mij betreft al de functionele analyse ervan.

Glenn

On 30-10-14 15:10, Ben Abelshausen wrote:
> Geen enkele geocoder is correct, heb er toch wel een 5-6 tal
> getest. Toch zeker niet als je dit opgeeft: Langestraat 14, Tremelo. Het
> grote nadeel is dat ze allemaal nominatim gebruiken als is alleen als
> pre-processing stap. Een duidelijke monocultuur als het geocoding aankomt.
> 
> Ik begrijp het niet goed, wat we nu ook overeenkomen, en of Jo nu
> associatedStreets toevoegd of niet, die adressen zijn toch over het
> algemeen eenduidig af te leiden:
> 
> - 1: Neem tags op node/gebouw eerst.
> - 2: Gebruik associated street tags als stap 1 niet werkt.
> - 3: Gebruik boundaries voor de vermiste informatie.
> 
> Of zie ik het nu zo verkeerd?
> 
> Ik heb zeker interesse in wat jullie hiervan denken omdat het ook op
> mijn agenda staat om een poging te doen begin volgend jaar.
> 
> Met vriendelijke groeten,
> Best regards,
> 
> Ben Abelshausen
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 

-- 
"Everything is going to be 200 OK."

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

Deze ookal:

http://maps.skobbler.com/?country=Belgium&city=tremelo&street=Langestraat&number=14&lat=51.0244385&lon=4.7465014&z=16

Met vriendelijke groeten,
Best regards,

Ben Abelshausen
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

Geen enkele geocoder is correct, heb er toch wel een 5-6 tal getest. Toch
zeker niet als je dit opgeeft: Langestraat 14, Tremelo. Het grote nadeel is
dat ze allemaal nominatim gebruiken als is alleen als pre-processing stap.
Een duidelijke monocultuur als het geocoding aankomt.

Ik begrijp het niet goed, wat we nu ook overeenkomen, en of Jo nu
associatedStreets toevoegd of niet, die adressen zijn toch over het
algemeen eenduidig af te leiden:

- 1: Neem tags op node/gebouw eerst.
- 2: Gebruik associated street tags als stap 1 niet werkt.
- 3: Gebruik boundaries voor de vermiste informatie.

Of zie ik het nu zo verkeerd?

Ik heb zeker interesse in wat jullie hiervan denken omdat het ook op mijn
agenda staat om een poging te doen begin volgend jaar.

Met vriendelijke groeten,
Best regards,

Ben Abelshausen
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

geeft "Schrieksesteenweg;Langestraat" vermoedelijk weer een ander segment
van de straat ...

De oplossing is om in de associatedStreet relatie slechts 1 straat segment
te steken, met de juiste naam en volledig geleden in de juiste gemeente.
Maar dat lukt ook niet overal.


m.

2014-10-30 14:51 GMT+01:00 Glenn Plas :

> Probeer eens op deze:
>
> http://nm1.bitless.be/
>
> Is een oudere export met eigen customizations van mezelf.
>
> Glenn
>
>
>
> On 30-10-14 14:46, Marc Gemis wrote:
> >
> > 2014-10-30 14:31 GMT+01:00 Ben Abelshausen  > >:
> >
> > Langestraat 14, Tremelo
> >
> >
> > Nominatim gebruikt de associatedStreet enkel en alleen om een
> > straatsegment te zoeken. Het neemt gewoon de eerste "street" in de
> > relatie (verklaart misschien de afwijkende resultaten op de 2 sites, als
> > die 2 databanken hebben).
> > Verder kijkt het waar die straat ligt, binnen welke grenzen. Het kijkt
> > niet naar de attributen op de relatie (zoals Jo wil).
> > Misschien is associatedStreet een goed instrument voor dit, maar kijk
> > maar eens op het Duitse forum, de Engelse mailing list. Niemand wil dat
> > ding. Dus is het IMHO twijfelachtig dat de opvolger daar wel naar gaat
> > kijken.
> >
> > Omdat Nominatim nu ook niet kijkt naar de attributen op het adrespunt
> > zelf (buiten huisnr), is er voor de Langestraat 14 (en vele andere
> > gevallen) geen goede tagging methode. Maar misschien dat een andere
> > geocoder wel iets zinnig doet met die attributen op de node/gebouw.
> >
> > mvg
> >
> >
> > m
> >
> >
> >
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> >
>
>
> --
> "Everything is going to be 200 OK."
>
> ___
> 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

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

2014-10-30 Thread Glenn Plas

Probeer eens op deze:

http://nm1.bitless.be/

Is een oudere export met eigen customizations van mezelf.

Glenn



On 30-10-14 14:46, Marc Gemis wrote:
> 
> 2014-10-30 14:31 GMT+01:00 Ben Abelshausen  >:
> 
> Langestraat 14, Tremelo
> 
> 
> Nominatim gebruikt de associatedStreet enkel en alleen om een
> straatsegment te zoeken. Het neemt gewoon de eerste "street" in de
> relatie (verklaart misschien de afwijkende resultaten op de 2 sites, als
> die 2 databanken hebben). 
> Verder kijkt het waar die straat ligt, binnen welke grenzen. Het kijkt
> niet naar de attributen op de relatie (zoals Jo wil).
> Misschien is associatedStreet een goed instrument voor dit, maar kijk
> maar eens op het Duitse forum, de Engelse mailing list. Niemand wil dat
> ding. Dus is het IMHO twijfelachtig dat de opvolger daar wel naar gaat
> kijken. 
> 
> Omdat Nominatim nu ook niet kijkt naar de attributen op het adrespunt
> zelf (buiten huisnr), is er voor de Langestraat 14 (en vele andere
> gevallen) geen goede tagging methode. Maar misschien dat een andere
> geocoder wel iets zinnig doet met die attributen op de node/gebouw.
> 
> mvg
> 
> 
> m
> 
> 
> 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


-- 
"Everything is going to be 200 OK."

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

2014-10-30 14:31 GMT+01:00 Ben Abelshausen :

> Langestraat 14, Tremelo


Nominatim gebruikt de associatedStreet enkel en alleen om een straatsegment
te zoeken. Het neemt gewoon de eerste "street" in de relatie (verklaart
misschien de afwijkende resultaten op de 2 sites, als die 2 databanken
hebben).
Verder kijkt het waar die straat ligt, binnen welke grenzen. Het kijkt niet
naar de attributen op de relatie (zoals Jo wil).
Misschien is associatedStreet een goed instrument voor dit, maar kijk maar
eens op het Duitse forum, de Engelse mailing list. Niemand wil dat ding.
Dus is het IMHO twijfelachtig dat de opvolger daar wel naar gaat kijken.

Omdat Nominatim nu ook niet kijkt naar de attributen op het adrespunt zelf
(buiten huisnr), is er voor de Langestraat 14 (en vele andere gevallen)
geen goede tagging methode. Maar misschien dat een andere geocoder wel iets
zinnig doet met die attributen op de node/gebouw.

mvg


m
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

2014-10-30 14:02 GMT+01:00 Marc Gemis :

> Langestraat 14, Baal


Vreemd toch die nominatim: Langestraat 14, Tremelo werkt dan weer wel! (op
osm.org op de nominatim-website dan weer niet)

Ik heb nominatim altijd een vreemd beest gevonden. Het is volgens mij of
een kwestie van tijd voor verdere verbeteringen of anders gaat die volledig
vervangen worden door iets nieuw. Dat kan zo niet blijven duren.

Met vriendelijke groeten,
Best regards,

Ben Abelshausen
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

2014-10-30 Thread Sander Deryckere

Natuurlijk zijn er problemen met adressen. Iedereen kent probleemadressen.

Maar werken met relaties zorgt ongetwijfeld voor fouten (iedereen maakt
fouten). Het wordt enkel maar erger als je 200 relaties moet onderhouden
voor 1 gemeente. Terwijl je hier ook, voor alle gevallen de gegevens
perfect kan afleiden van de grenzen.

Natuurlijk kan het met een grens fout lopen, als iemand die onderbreekt of
verschuift. Maar het onderhouden van een grens is maar 1 relatie per
postcode, gemeente of deelgemeente.

Ook met het taggen van objecten loopt het soms fout. Gelukkig doet JOSM
altijd suggesties, maar soms kan je met een verkeerde Tab-Enter actie ook
wel de verkeerde tag toevoegen. Hoe meer tags, hoe meer er verkeerd kunnen
zijn.

Ik kan begrijpen dat je die relaties of extra tags wil toevoegen voor de
moeilijke gevallen (om zo een beter overzicht te krijgen), als je echter
voor alles relaties en/of extra tags toevoegt, dan verlies je opnieuw het
overzicht door de vele relaties die niet nodig zijn.

Zelf heb ik ook ooit alles met A-S relaties gedaan. Maar daar ben ik van
afgestapt. Mijn dorp was gewoon niet meer te onderhouden omdat er veel te
veel A-S relaties waren in de selectielijst. Het is al een eindje dat ik
geen nieuwe A-S relaties meer maak, en sinds kort verwijder ik ook de A-S
relaties in de straten die ik update. Met taggen heb ik dezelfde fouten
gemaakt. Een hoop is_in tags zijn nog altijd te vinden. Ook deze verwijder
ik nu als ik ze tegenkom.

Groeten,
Sander

Op 30 oktober 2014 13:13 schreef Jo :

> Ziehier een prachtvoorbeeld van hoe scheef het kan lopen:
>
> https://www.openstreetmap.org/relation/1523419/history
> https://www.openstreetmap.org/relation/1523417/history
> https://www.openstreetmap.org/relation/1524225/history
>
> Maar wat wil je dan op een grens tussen de provincies...
>
> Vooral deze huizen (14 en 15) lijken mij bijzonder lastig om te vinden:
>
> https://www.openstreetmap.org/node/1495908473/history
>
> Die straat is dus op een bepaald gedeelte aan de ene kant doorlopend
> genummerd en aan de andere kant even/oneven met een andere reeks nummers en
> ze heet tegelijk Langstraat en Langestraat op die gedeeltes.
>
> Dankzij die relaties is het meteen duidelijk hoe de vork aan de steel zit.
>
> Jo
>
> Op 30 oktober 2014 12:20 schreef Glenn Plas :
>
> Ik deel die mening ook over die relaties.   En zeker over interpolation
>> van adressen in Belgie springt het van tijd wel heel hard, ik weet een
>> straat waar huizen naast elkaar opeenvolgende nummers krijgen, bv
>> 1,2,3,4,5 8  Dus geen even/oneven verdeling zoals we gewoon zijn.
>>
>> Geocoding werkt ook gewoon beter met de klassieke adress tagging, dit is
>> vooral vanuit mijn eigen ervaring met nominatim servers te bouwen.
>>
>> Glenn
>>
>>
>> On 30-10-14 11:57, Sander Deryckere wrote:
>> >
>> > Ik heb gewoon conceptuele problemen met associatedStreet relaties.
>> > Wanneer stopt een straat? Stop een straat aan iedere postcode of
>> > gemeentegrens? Wat doe je als de nummering verder loopt, is dat dan niet
>> > dezelfde straat? Krijg je geen problemen als je ziet dat onze grenzen
>> > verkeerd waren, en er bepaalde huizen blijken in andere gemeentes te
>> liggen?
>> >
>> > Dus ga ik akkoord met Ben: Keep it simple, maar net iets anders.
>> >
>> > Gewoon straatnaam en huisnummer op het gebouw, de rest kan afgeleid
>> > worden uit de grenzen. Als die grenzen verkeerd blijken, dan moeten we
>> > slechts die grenzen aanpassen, en niet alles wat er binnen ligt.
>> >
>> > We kunnen de data van CRAB ook gebruiken om de grenzen te verbeteren,
>> > maar dat is niet het primaire doel van deze import. Grenzen verbeteren
>> > is trouwens een piece of cake vergeleken met het importeren van alle
>> > adressen.
>> >
>> > Het onderhouden van boundaries is ook veel eenvoudiger dan het
>> > onderhouden van de adressen.
>> >
>> > Iedere mapper is natuurlijk vrij te doen wat hij wil.
>> >
>> > Groeten,
>> > Sander
>> >
>> > Op 30 oktober 2014 09:10 schreef Ben Abelshausen
>> > mailto:ben.abelshau...@gmail.com>>:
>> >
>> > Hey,
>> >
>> > 2014-10-30 8:41 GMT+01:00 Jo > > >:
>> >
>> > Wat mij betreft is een adres niet compleet, zonder postcode en
>> > gemeente.
>> >
>> >
>> > Ik ben het hiermee eens.
>> >
>> > Ge moet ook bedenken dat we in OSM niet persé het meest efficiënte
>> > data-model moeten hebben. Een deel van de prioriteit zou ook moeten
>> > zijn dat de dingen gemakkelijk onderhoudbaar zijn daarom ben ik
>> > voorstander van de meest eenvoudige oplossing in de vorm van
>> > adressen met straat, nummer, postcode, gemeente.
>> >
>> > Associated street klinkt logisch en best vertrekkende vanuit kennis
>> > van IT, GIS, JOSM, database normalisatie en dergelijke maar ik wil
>> > niet diegene zijn die dat moet gaan uitleggen aan nieuwelingen. En
>> > als er nu één ding is dat we nodig hebben is meer mappers. Werken
>> > met boundaries voor postc

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

Vul nu Langestraat 14, Baal  (daar moet ze toch inliggen niet ?) in op
osm.org of nominatim.openstreetmap.org

Ik geloof niet dat daar het gewenste resultaat uitkomt. Of wel ? (het
resultaat is: House 14, Schrieksesteenweg, Baal, Flanders, 3128, Belgium)

Leg dat maar eens uit een een beginnende mapper. Maak maar al deze
"complexe" relaties aan dan komt het wel goed

zolang er geen support is van Nominatim is het volgens mij gewoon zinloos.

mvg

m.


2014-10-30 13:13 GMT+01:00 Jo :

> Ziehier een prachtvoorbeeld van hoe scheef het kan lopen:
>
> https://www.openstreetmap.org/relation/1523419/history
> https://www.openstreetmap.org/relation/1523417/history
> https://www.openstreetmap.org/relation/1524225/history
>
> Maar wat wil je dan op een grens tussen de provincies...
>
> Vooral deze huizen (14 en 15) lijken mij bijzonder lastig om te vinden:
>
> https://www.openstreetmap.org/node/1495908473/history
>
> Die straat is dus op een bepaald gedeelte aan de ene kant doorlopend
> genummerd en aan de andere kant even/oneven met een andere reeks nummers en
> ze heet tegelijk Langstraat en Langestraat op die gedeeltes.
>
> Dankzij die relaties is het meteen duidelijk hoe de vork aan de steel zit.
>
> Jo
>
> Op 30 oktober 2014 12:20 schreef Glenn Plas :
>
> Ik deel die mening ook over die relaties.   En zeker over interpolation
>> van adressen in Belgie springt het van tijd wel heel hard, ik weet een
>> straat waar huizen naast elkaar opeenvolgende nummers krijgen, bv
>> 1,2,3,4,5 8  Dus geen even/oneven verdeling zoals we gewoon zijn.
>>
>> Geocoding werkt ook gewoon beter met de klassieke adress tagging, dit is
>> vooral vanuit mijn eigen ervaring met nominatim servers te bouwen.
>>
>> Glenn
>>
>>
>> On 30-10-14 11:57, Sander Deryckere wrote:
>> >
>> > Ik heb gewoon conceptuele problemen met associatedStreet relaties.
>> > Wanneer stopt een straat? Stop een straat aan iedere postcode of
>> > gemeentegrens? Wat doe je als de nummering verder loopt, is dat dan niet
>> > dezelfde straat? Krijg je geen problemen als je ziet dat onze grenzen
>> > verkeerd waren, en er bepaalde huizen blijken in andere gemeentes te
>> liggen?
>> >
>> > Dus ga ik akkoord met Ben: Keep it simple, maar net iets anders.
>> >
>> > Gewoon straatnaam en huisnummer op het gebouw, de rest kan afgeleid
>> > worden uit de grenzen. Als die grenzen verkeerd blijken, dan moeten we
>> > slechts die grenzen aanpassen, en niet alles wat er binnen ligt.
>> >
>> > We kunnen de data van CRAB ook gebruiken om de grenzen te verbeteren,
>> > maar dat is niet het primaire doel van deze import. Grenzen verbeteren
>> > is trouwens een piece of cake vergeleken met het importeren van alle
>> > adressen.
>> >
>> > Het onderhouden van boundaries is ook veel eenvoudiger dan het
>> > onderhouden van de adressen.
>> >
>> > Iedere mapper is natuurlijk vrij te doen wat hij wil.
>> >
>> > Groeten,
>> > Sander
>> >
>> > Op 30 oktober 2014 09:10 schreef Ben Abelshausen
>> > mailto:ben.abelshau...@gmail.com>>:
>> >
>> > Hey,
>> >
>> > 2014-10-30 8:41 GMT+01:00 Jo > > >:
>> >
>> > Wat mij betreft is een adres niet compleet, zonder postcode en
>> > gemeente.
>> >
>> >
>> > Ik ben het hiermee eens.
>> >
>> > Ge moet ook bedenken dat we in OSM niet persé het meest efficiënte
>> > data-model moeten hebben. Een deel van de prioriteit zou ook moeten
>> > zijn dat de dingen gemakkelijk onderhoudbaar zijn daarom ben ik
>> > voorstander van de meest eenvoudige oplossing in de vorm van
>> > adressen met straat, nummer, postcode, gemeente.
>> >
>> > Associated street klinkt logisch en best vertrekkende vanuit kennis
>> > van IT, GIS, JOSM, database normalisatie en dergelijke maar ik wil
>> > niet diegene zijn die dat moet gaan uitleggen aan nieuwelingen. En
>> > als er nu één ding is dat we nodig hebben is meer mappers. Werken
>> > met boundaries voor postcode/gemeente klinkt ook goed maar dat stopt
>> > met werken als er een boundary kapot gaat (en dan zijn ineens alle
>> > adressen daar waardeloos), als een gebouw adres op/dichtbij de grens
>> > ligt (denk aan een perceel dat grotendeels in één gemeente ligt maar
>> > het gebouw in een andere?!).
>> >
>> > Ik heb heel veel ervaring met adressen vanuit mijn werk bij de post
>> > en AGIV en boundaries kloppen niet altijd, adressen kloppen niet
>> > altijd, locaties van adressen zijn niet altijd logisch tov
>> > straatnaam/postcode en/of gemeente! Er zijn zelfs adressen die enkel
>> > te onderscheiden zijn op gemeente naam (dus postcode,straat, nummer
>> > is NIET overal uniek).
>> >
>> > Als dat zo gebeurt, dan moeten we zorgen dat we die nodes niet mergen in
>> > de tools. Maar op zich is het geen probleem dat die ene straat 2 keer
>> > hetzelfde huisnummer heeft. De vergelijkingstools zullen ook niet zo
>> > werken als het moet tenzij een max afstand ingegeven is. Maar ik denk
>> > niet

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

2014-10-30 13:13 GMT+01:00 Jo :

> Vooral deze huizen (14 en 15) lijken mij bijzonder lastig om te vinden:
>

Mooi voorbeeld, 14 en 15 op googlemaps:

https://www.google.be/maps/place/Langestraat+15,+3128+Tremelo
https://www.google.be/maps/place/Langestraat+14,+3128+Tremelo

Haha! Allebei fout en dan op op een andere manier verkeerd ook! ;-)

Met vriendelijke groeten,
Best regards,

Ben Abelshausen
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

Ziehier een prachtvoorbeeld van hoe scheef het kan lopen:

https://www.openstreetmap.org/relation/1523419/history
https://www.openstreetmap.org/relation/1523417/history
https://www.openstreetmap.org/relation/1524225/history

Maar wat wil je dan op een grens tussen de provincies...

Vooral deze huizen (14 en 15) lijken mij bijzonder lastig om te vinden:

https://www.openstreetmap.org/node/1495908473/history

Die straat is dus op een bepaald gedeelte aan de ene kant doorlopend
genummerd en aan de andere kant even/oneven met een andere reeks nummers en
ze heet tegelijk Langstraat en Langestraat op die gedeeltes.

Dankzij die relaties is het meteen duidelijk hoe de vork aan de steel zit.

Jo

Op 30 oktober 2014 12:20 schreef Glenn Plas :

> Ik deel die mening ook over die relaties.   En zeker over interpolation
> van adressen in Belgie springt het van tijd wel heel hard, ik weet een
> straat waar huizen naast elkaar opeenvolgende nummers krijgen, bv
> 1,2,3,4,5 8  Dus geen even/oneven verdeling zoals we gewoon zijn.
>
> Geocoding werkt ook gewoon beter met de klassieke adress tagging, dit is
> vooral vanuit mijn eigen ervaring met nominatim servers te bouwen.
>
> Glenn
>
>
> On 30-10-14 11:57, Sander Deryckere wrote:
> >
> > Ik heb gewoon conceptuele problemen met associatedStreet relaties.
> > Wanneer stopt een straat? Stop een straat aan iedere postcode of
> > gemeentegrens? Wat doe je als de nummering verder loopt, is dat dan niet
> > dezelfde straat? Krijg je geen problemen als je ziet dat onze grenzen
> > verkeerd waren, en er bepaalde huizen blijken in andere gemeentes te
> liggen?
> >
> > Dus ga ik akkoord met Ben: Keep it simple, maar net iets anders.
> >
> > Gewoon straatnaam en huisnummer op het gebouw, de rest kan afgeleid
> > worden uit de grenzen. Als die grenzen verkeerd blijken, dan moeten we
> > slechts die grenzen aanpassen, en niet alles wat er binnen ligt.
> >
> > We kunnen de data van CRAB ook gebruiken om de grenzen te verbeteren,
> > maar dat is niet het primaire doel van deze import. Grenzen verbeteren
> > is trouwens een piece of cake vergeleken met het importeren van alle
> > adressen.
> >
> > Het onderhouden van boundaries is ook veel eenvoudiger dan het
> > onderhouden van de adressen.
> >
> > Iedere mapper is natuurlijk vrij te doen wat hij wil.
> >
> > Groeten,
> > Sander
> >
> > Op 30 oktober 2014 09:10 schreef Ben Abelshausen
> > mailto:ben.abelshau...@gmail.com>>:
> >
> > Hey,
> >
> > 2014-10-30 8:41 GMT+01:00 Jo  > >:
> >
> > Wat mij betreft is een adres niet compleet, zonder postcode en
> > gemeente.
> >
> >
> > Ik ben het hiermee eens.
> >
> > Ge moet ook bedenken dat we in OSM niet persé het meest efficiënte
> > data-model moeten hebben. Een deel van de prioriteit zou ook moeten
> > zijn dat de dingen gemakkelijk onderhoudbaar zijn daarom ben ik
> > voorstander van de meest eenvoudige oplossing in de vorm van
> > adressen met straat, nummer, postcode, gemeente.
> >
> > Associated street klinkt logisch en best vertrekkende vanuit kennis
> > van IT, GIS, JOSM, database normalisatie en dergelijke maar ik wil
> > niet diegene zijn die dat moet gaan uitleggen aan nieuwelingen. En
> > als er nu één ding is dat we nodig hebben is meer mappers. Werken
> > met boundaries voor postcode/gemeente klinkt ook goed maar dat stopt
> > met werken als er een boundary kapot gaat (en dan zijn ineens alle
> > adressen daar waardeloos), als een gebouw adres op/dichtbij de grens
> > ligt (denk aan een perceel dat grotendeels in één gemeente ligt maar
> > het gebouw in een andere?!).
> >
> > Ik heb heel veel ervaring met adressen vanuit mijn werk bij de post
> > en AGIV en boundaries kloppen niet altijd, adressen kloppen niet
> > altijd, locaties van adressen zijn niet altijd logisch tov
> > straatnaam/postcode en/of gemeente! Er zijn zelfs adressen die enkel
> > te onderscheiden zijn op gemeente naam (dus postcode,straat, nummer
> > is NIET overal uniek).
> >
> > Als dat zo gebeurt, dan moeten we zorgen dat we die nodes niet mergen in
> > de tools. Maar op zich is het geen probleem dat die ene straat 2 keer
> > hetzelfde huisnummer heeft. De vergelijkingstools zullen ook niet zo
> > werken als het moet tenzij een max afstand ingegeven is. Maar ik denk
> > niet dat er veel dergelijke straten zijn.
> >
> >
> > De boodschap is: keep it simple!
> >
> > Iets relatiefs eenvoudig als een adres moet in OSM ook eenvoudig
> > blijven om toe te voegen en te wijzigen. Dat wil zeggen: inloggen op
> > website, klikken op gebouw of node en een paar veldjes invullen.
> >
> > Met vriendelijke groeten,
> > Best regards,
> >
> > Ben Abelshausen
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/

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

Wat mij betreft stopt een straat inderdaad aan gemeente- en
postcodegrenzen. (Of tenminste een groep adressen). Kijk maar eens naar de
Tiensesteenweg in Heverlee/Kessel-Lo/Korbeek-Lo(3000 zoals Leuven) en dan
Bierbeek. 't Is niet omdat die straat dezelfde naam houdt, dat het dezelfde
straat is. Of anders gezegd. De mensen die aan de ene kant van het begin
van die steenweg wonen, hebben een adres in Heverlee, die aan de andere
kant in Kessel-Lo en wat verderop wonen ze in Korbeek-Lo, maar dat is sinds
de fusie een 'exclave' van Leuven geworden.

associatedStreet zegt niet echt iets over de straat, dan wel over hoe de
huizen gerelateerd zijn met die straat.

Nu goed, ik voeg die relaties toe. Ze zitten niet in de weg. Ben wil
blijkbaar complete adressen toevoegen voor elk gebouw en de consensus was
om er overal toch minstens de straatnaam aan toe te voegen, zodat de
geocoders ermee uit de voeten kunnen (als de grenzen correct zijn
tenminste) en te zorgen dat de validatietools er niet over vallen.

Het lijkt me nuttige informatie om door te geven naar degene die de data
gaat verwerken. Vandaar mijn vraag. Je zegt zelf dat er geen garantie is
dat de huisnummers uniek zijn, als zo'n grens wordt overschreden.

Wel in discardable tags, zoniet zal iedereen ze overal laten staan. Als Ben
alles wil toevoegen, dan kan hij die tags gemakkelijk hernoemen voor de
straten die hij afwerkt.

In Brussel zijn ook alle adressen toegevoegd. Allemaal met aS-relaties.
Geen enkele van de mensen die daarbij geholpen heeft, had daar problemen
mee. Natuurlijk was het daar wat eenvoudiger, aangezien de gebouwcontouren
er ook bijzaten.

Jo

Op 30 oktober 2014 11:57 schreef Sander Deryckere :

>
> Ik heb gewoon conceptuele problemen met associatedStreet relaties. Wanneer
> stopt een straat? Stop een straat aan iedere postcode of gemeentegrens? Wat
> doe je als de nummering verder loopt, is dat dan niet dezelfde straat?
> Krijg je geen problemen als je ziet dat onze grenzen verkeerd waren, en er
> bepaalde huizen blijken in andere gemeentes te liggen?
>
> Dus ga ik akkoord met Ben: Keep it simple, maar net iets anders.
>
> Gewoon straatnaam en huisnummer op het gebouw, de rest kan afgeleid worden
> uit de grenzen. Als die grenzen verkeerd blijken, dan moeten we slechts die
> grenzen aanpassen, en niet alles wat er binnen ligt.
>
> We kunnen de data van CRAB ook gebruiken om de grenzen te verbeteren, maar
> dat is niet het primaire doel van deze import. Grenzen verbeteren is
> trouwens een piece of cake vergeleken met het importeren van alle adressen.
>
> Het onderhouden van boundaries is ook veel eenvoudiger dan het onderhouden
> van de adressen.
>
> Iedere mapper is natuurlijk vrij te doen wat hij wil.
>
> Groeten,
> Sander
>
> Op 30 oktober 2014 09:10 schreef Ben Abelshausen <
> ben.abelshau...@gmail.com>:
>
>> Hey,
>>
>> 2014-10-30 8:41 GMT+01:00 Jo :
>>
>>> Wat mij betreft is een adres niet compleet, zonder postcode en gemeente.
>>>
>>
>> Ik ben het hiermee eens.
>>
>> Ge moet ook bedenken dat we in OSM niet persé het meest efficiënte
>> data-model moeten hebben. Een deel van de prioriteit zou ook moeten zijn
>> dat de dingen gemakkelijk onderhoudbaar zijn daarom ben ik voorstander van
>> de meest eenvoudige oplossing in de vorm van adressen met straat, nummer,
>> postcode, gemeente.
>>
>> Associated street klinkt logisch en best vertrekkende vanuit kennis van
>> IT, GIS, JOSM, database normalisatie en dergelijke maar ik wil niet diegene
>> zijn die dat moet gaan uitleggen aan nieuwelingen. En als er nu één ding is
>> dat we nodig hebben is meer mappers. Werken met boundaries voor
>> postcode/gemeente klinkt ook goed maar dat stopt met werken als er een
>> boundary kapot gaat (en dan zijn ineens alle adressen daar waardeloos), als
>> een gebouw adres op/dichtbij de grens ligt (denk aan een perceel dat
>> grotendeels in één gemeente ligt maar het gebouw in een andere?!).
>>
>> Ik heb heel veel ervaring met adressen vanuit mijn werk bij de post en
>> AGIV en boundaries kloppen niet altijd, adressen kloppen niet altijd,
>> locaties van adressen zijn niet altijd logisch tov straatnaam/postcode
>> en/of gemeente! Er zijn zelfs adressen die enkel te onderscheiden zijn op
>> gemeente naam (dus postcode,straat, nummer is NIET overal uniek).
>>
>> Als dat zo gebeurt, dan moeten we zorgen dat we die nodes niet mergen in
> de tools. Maar op zich is het geen probleem dat die ene straat 2 keer
> hetzelfde huisnummer heeft. De vergelijkingstools zullen ook niet zo werken
> als het moet tenzij een max afstand ingegeven is. Maar ik denk niet dat er
> veel dergelijke straten zijn.
>
>
>> De boodschap is: keep it simple!
>>
>> Iets relatiefs eenvoudig als een adres moet in OSM ook eenvoudig blijven
>> om toe te voegen en te wijzigen. Dat wil zeggen: inloggen op website,
>> klikken op gebouw of node en een paar veldjes invullen.
>>
>> Met vriendelijke groeten,
>> Best regards,
>>
>> Ben Abelshausen
>>
>> ___

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

2014-10-30 Thread Glenn Plas

Ik deel die mening ook over die relaties.   En zeker over interpolation
van adressen in Belgie springt het van tijd wel heel hard, ik weet een
straat waar huizen naast elkaar opeenvolgende nummers krijgen, bv
1,2,3,4,5 8  Dus geen even/oneven verdeling zoals we gewoon zijn.

Geocoding werkt ook gewoon beter met de klassieke adress tagging, dit is
vooral vanuit mijn eigen ervaring met nominatim servers te bouwen.

Glenn


On 30-10-14 11:57, Sander Deryckere wrote:
> 
> Ik heb gewoon conceptuele problemen met associatedStreet relaties.
> Wanneer stopt een straat? Stop een straat aan iedere postcode of
> gemeentegrens? Wat doe je als de nummering verder loopt, is dat dan niet
> dezelfde straat? Krijg je geen problemen als je ziet dat onze grenzen
> verkeerd waren, en er bepaalde huizen blijken in andere gemeentes te liggen?
> 
> Dus ga ik akkoord met Ben: Keep it simple, maar net iets anders.
> 
> Gewoon straatnaam en huisnummer op het gebouw, de rest kan afgeleid
> worden uit de grenzen. Als die grenzen verkeerd blijken, dan moeten we
> slechts die grenzen aanpassen, en niet alles wat er binnen ligt.
> 
> We kunnen de data van CRAB ook gebruiken om de grenzen te verbeteren,
> maar dat is niet het primaire doel van deze import. Grenzen verbeteren
> is trouwens een piece of cake vergeleken met het importeren van alle
> adressen.
> 
> Het onderhouden van boundaries is ook veel eenvoudiger dan het
> onderhouden van de adressen.
> 
> Iedere mapper is natuurlijk vrij te doen wat hij wil.
> 
> Groeten,
> Sander
> 
> Op 30 oktober 2014 09:10 schreef Ben Abelshausen
> mailto:ben.abelshau...@gmail.com>>:
> 
> Hey,
> 
> 2014-10-30 8:41 GMT+01:00 Jo  >:
> 
> Wat mij betreft is een adres niet compleet, zonder postcode en
> gemeente.
> 
> 
> Ik ben het hiermee eens.
> 
> Ge moet ook bedenken dat we in OSM niet persé het meest efficiënte
> data-model moeten hebben. Een deel van de prioriteit zou ook moeten
> zijn dat de dingen gemakkelijk onderhoudbaar zijn daarom ben ik
> voorstander van de meest eenvoudige oplossing in de vorm van
> adressen met straat, nummer, postcode, gemeente.
> 
> Associated street klinkt logisch en best vertrekkende vanuit kennis
> van IT, GIS, JOSM, database normalisatie en dergelijke maar ik wil
> niet diegene zijn die dat moet gaan uitleggen aan nieuwelingen. En
> als er nu één ding is dat we nodig hebben is meer mappers. Werken
> met boundaries voor postcode/gemeente klinkt ook goed maar dat stopt
> met werken als er een boundary kapot gaat (en dan zijn ineens alle
> adressen daar waardeloos), als een gebouw adres op/dichtbij de grens
> ligt (denk aan een perceel dat grotendeels in één gemeente ligt maar
> het gebouw in een andere?!). 
> 
> Ik heb heel veel ervaring met adressen vanuit mijn werk bij de post
> en AGIV en boundaries kloppen niet altijd, adressen kloppen niet
> altijd, locaties van adressen zijn niet altijd logisch tov
> straatnaam/postcode en/of gemeente! Er zijn zelfs adressen die enkel
> te onderscheiden zijn op gemeente naam (dus postcode,straat, nummer
> is NIET overal uniek). 
> 
> Als dat zo gebeurt, dan moeten we zorgen dat we die nodes niet mergen in
> de tools. Maar op zich is het geen probleem dat die ene straat 2 keer
> hetzelfde huisnummer heeft. De vergelijkingstools zullen ook niet zo
> werken als het moet tenzij een max afstand ingegeven is. Maar ik denk
> niet dat er veel dergelijke straten zijn.
>  
> 
> De boodschap is: keep it simple!
> 
> Iets relatiefs eenvoudig als een adres moet in OSM ook eenvoudig
> blijven om toe te voegen en te wijzigen. Dat wil zeggen: inloggen op
> website, klikken op gebouw of node en een paar veldjes invullen.
> 
> Met vriendelijke groeten,
> Best regards,
> 
> Ben Abelshausen
> 
> ___
> 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
> 


-- 
"Everything is going to be 200 OK."

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

Hallo Guy,

De discussie is op dit moment nogal technisch. Dit is met de bedoeling om
de data 'klaar te stomen', zodat iedereen er vlot gebruik van kan maken.
Dat je die discussie niet altijd kan volgen, maak je daar geen zorgen over.

We zullen nog wat meetings en hangouts moeten organiseren om te zorgen dat
iedereen weet hoe deze dat in OSM te integreren. Want helemaal automatisch
zal dat zeker niet gebeuren. Ik ben er bij wijze van test een aantal aan
het invoeren en ik kan je verzekeren, dat het nog heel wat werk kost, als
je het goed wilt doen.

Het enige verschil is dat de huisnummers op nodes worden aangeleverd. Dan
moeten ze nog op de gebouwen worden overgezet. Als deze gebouwen er nog
niet zijn, kan je met de building tools er met 3 klikken een rechthoek
overheen tekenen en wordt de info van de node naar het gebouw overgedragen.

Als dat gebouw parallel staat met het gebouw ernaast, kan het ook met 2
klikken.

Als het gebouw al in OSM zit, dan zijn er een aantal mogelijkheden. Het
komt er echter bijna altijd wel op neer dat je de geometrie van het gebouw
ook nog wat moet aanpassen. Opnieuw tekenen zou soms zelfs sneller gaan.
(Maar we willen wel de historiek intact houden).

Gebouwen zijn natuurlijk niet altijd rechthoekig, maar de extrude tool (x)
kan hierbij enorm behulpzaam zijn. (als je in extrude mode zit, kan je met
dubbelklik ook nodes op de contour van het gebouw toevoegen).

Als je een gebouw wilt tekenen dat parallel is, houd je het vorige
geselecteerd.

Als je echter een gebouw wilt tekenen dat aanligt bij het vorige, dan kan
je beginnen op 1 van de nodes ervan, dan een 2e aanklikken en dan beginnen
'uitrekken'. Dan zijn de nodes vanzelf deel van beide gebouwen.

Gebouwen met curves kunnen tegenwoordig ook mooi afgewerkt worden met 'o'.

Voor bestaande gebouwen kan je de conflation tool gebruiken.

Je kan echter ook in het menu selection,* 'Select all inside'* kiezen. Als
dat 1 node en 1 gebouw oplevert, kan je daarna *'Replace Geometry'*
gebruiken om beide samen te voegen. Je krijgt dan nog een dialoogvenster
als er conflicten zijn. Ik heb die respectievelijk op 't' en 'v' gemapt.
(Je kan de sneltoetsen voor je tools aanpassen aan je eigen voorkeuren)

Jo

Op 30 oktober 2014 11:45 schreef Guy Vanvuchelen 
:

> Reeds enkele weken volg ik de discutie over de adressen. Eigenlijk snap ik
> er weinig van.  Ik wil me niet bij de echte mappers rekenen maar echt
> beginnend ben ik toch ook niet.  Maanden geleden ben ik begonnen met in de
> streek rond Tienen huisnummers in te brengen.  Maar toen ik op het forum
> meende te begrijpen dat het automatisch zou kunnen ben ik natuurlijk
> gestopt. En nu, weet ik het niet meer. Moet ik terug beginnen of moet ik
> nog wachten.  Er zijn misschien efficiëntere manieren om adressen te mappen
> dan de manier waarop ik het doe maar anderzijds… als ik er 1000 doe zijn er
> 1000 gedaan.  Of worden die bij een eventuele automatisering toch
> overschreven?
>
> Mijn manier is gewoon met AGIV luchtfoto’s de huizen van een straat
> tekenen en dan met RGB-AGIV er de nummers proberen op te zetten.  Bij
> problemen ga ik dan gewoon eens kijken of ik ter plaatse de zaak kan
> oplossen.
>
> Een kleine anekdote: In het Medekersveld in KUmtich (Tienen) staan vooraan
> 3 huizen aan de linkerkant: 1, 3 en 5. Enkele honderden meters verder dat
> er nog één huis. Volgens AGIV is dat nr 7. Nochtans had ik in OSM nr 100
> ingebracht. Op het huis of op de brievenbus staat geen nummer, maar in de
> (geopende) brievenbus vond ik een brief met nr 100. Wie heeft nu gelijk?
>
> O ja, als de huizen getekend zijn gebruik ik het ‘adres tool’ en daar
> blijven de gegevens voor straat, gemeente, enz. gewoon staan en moet je
> alleen het nummer wijzigen. Bij het gereedschap ‘Rijtjeshuis maken’ komen
> de straten  enz;  automatisch in een associatedStreet relatie.
>
>
>
> Ik bewonder diegenen die, dank zij een of ander script, bergen werk kunnen
> herleiden tot een niemendalletje maar ik vrees dat er niet zoveel mappers
> zijn die nog kunnen volgen. Het moet eenvoudig blijven zodat ‘niet
> programmeurs’ ook nog mee kunnen want dat zijn de mensen die meestal het
> meest tijd hebben om ‘veldwerk’ te doen.
>
>
>
> GuyVV
>
>
>
> *Van:* Marc Gemis [mailto:marc.ge...@gmail.com]
> *Verzonden:* donderdag 30 oktober 2014 11:11
> *Aan:* Jo Simoens; OpenStreetMap Belgium
> *Onderwerp:* Re: [OSM-talk-be] import AGIV CRAB-data
>
>
>
> Jo, jammer genoeg ben je nog zo wat de enige die nog met associatedStreet
> relaties wil werken. Als ik in de landen om ons heen kijk, breken ze
> associatedStreet allemaal af. (in de figuurlijke zin)
>
> Dus waar ga je support krijgen voor data in die relatie ? Op het minieme
> gebruik van Nominatim na, dat dan nog niet hetzelfde doet als

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

Hallo Guy,

Waar Sander en Thomas nu bezig zijn is het volgende:

- een website waarop je eenvoudig per postcode kan zien waar AGIV Crab
huisnummers heeft en OSM niet. Je kan er ook op zien waar een andere
nummers staan in de 2 databanken
- Vanuit die website kan je dan de gegevens downloaden in JOSM. En dan
begint het manuele werk. Sander heeft een beschrijving gedaan van hoe je
die gegevens dan "verwerkt" en oplaadt. Maar, dit kan net zo goed gebeuren
op de manier die jij beschrijft. Ik moet zelf ook nog Sander's manier
uitproberen om nu te weten of die zoveel efficiënter is als wat jij nu
doet. Het is natuurlijk wel de bedoeling dat we deze methode zo duidelijk
mogelijk uitleggen aan een zo'n groot mogelijk publiek. Dit kan via de wiki
met screenshots, hangouts, video's of gewoon op "cafe".

- Ik denk wel dat er wat verschillen zitten in de data die je via hun werk
gaat krijgen, vs. wat je op RGB-AGIV ziet. Dit heeft o.a. te maken met
verschillende databanken die AGIV CRAB zelf heeft met huisnummers.

Nergens in deze procedure zal het harde werk dat tot nu toe al gebeurd is,
weggegooid worden (in tegenstelling tot bv. de Nederlandse BAG import).
Je gaat bv. wel via de website kunnen zien of je in een straat ergens een
nummertje vergeten bent.

Hopelijk maakt dit een en ander wat begrijpelijk. Mocht dat nog niet het
geval zijn, aarzel dan niet om bijkomende vragen te stellen.

met vriendelijke groeten

m

2014-10-30 11:45 GMT+01:00 Guy Vanvuchelen :

> Reeds enkele weken volg ik de discutie over de adressen. Eigenlijk snap ik
> er weinig van.  Ik wil me niet bij de echte mappers rekenen maar echt
> beginnend ben ik toch ook niet.  Maanden geleden ben ik begonnen met in de
> streek rond Tienen huisnummers in te brengen.  Maar toen ik op het forum
> meende te begrijpen dat het automatisch zou kunnen ben ik natuurlijk
> gestopt. En nu, weet ik het niet meer. Moet ik terug beginnen of moet ik
> nog wachten.  Er zijn misschien efficiëntere manieren om adressen te mappen
> dan de manier waarop ik het doe maar anderzijds… als ik er 1000 doe zijn er
> 1000 gedaan.  Of worden die bij een eventuele automatisering toch
> overschreven?
>
> Mijn manier is gewoon met AGIV luchtfoto’s de huizen van een straat
> tekenen en dan met RGB-AGIV er de nummers proberen op te zetten.  Bij
> problemen ga ik dan gewoon eens kijken of ik ter plaatse de zaak kan
> oplossen.
>
> Een kleine anekdote: In het Medekersveld in KUmtich (Tienen) staan vooraan
> 3 huizen aan de linkerkant: 1, 3 en 5. Enkele honderden meters verder dat
> er nog één huis. Volgens AGIV is dat nr 7. Nochtans had ik in OSM nr 100
> ingebracht. Op het huis of op de brievenbus staat geen nummer, maar in de
> (geopende) brievenbus vond ik een brief met nr 100. Wie heeft nu gelijk?
>
> O ja, als de huizen getekend zijn gebruik ik het ‘adres tool’ en daar
> blijven de gegevens voor straat, gemeente, enz. gewoon staan en moet je
> alleen het nummer wijzigen. Bij het gereedschap ‘Rijtjeshuis maken’ komen
> de straten  enz;  automatisch in een associatedStreet relatie.
>
>
>
> Ik bewonder diegenen die, dank zij een of ander script, bergen werk kunnen
> herleiden tot een niemendalletje maar ik vrees dat er niet zoveel mappers
> zijn die nog kunnen volgen. Het moet eenvoudig blijven zodat ‘niet
> programmeurs’ ook nog mee kunnen want dat zijn de mensen die meestal het
> meest tijd hebben om ‘veldwerk’ te doen.
>
>
>
> GuyVV
>
>
>
> *Van:* Marc Gemis [mailto:marc.ge...@gmail.com]
> *Verzonden:* donderdag 30 oktober 2014 11:11
> *Aan:* Jo Simoens; OpenStreetMap Belgium
> *Onderwerp:* Re: [OSM-talk-be] import AGIV CRAB-data
>
>
>
> Jo, jammer genoeg ben je nog zo wat de enige die nog met associatedStreet
> relaties wil werken. Als ik in de landen om ons heen kijk, breken ze
> associatedStreet allemaal af. (in de figuurlijke zin)
>
> Dus waar ga je support krijgen voor data in die relatie ? Op het minieme
> gebruik van Nominatim na, dat dan nog niet hetzelfde doet als jij zou
> willen ?
>
>
>
> Ben, als je jouw approach volgt (alles op node), zou ik dat toch ook eerst
> testen op osm.org. Leg anders maar eens uit aan een beginnende mapper dat
> hoewel hij een postcode op een node plaatst er toch een andere uitrolt.
>
>
> Ik weet dat je niet met bepaalde software in je achterhoofd mag mappen,
> maar als er nu iemand naar osm.org gaat en het verkeerde adres rolt
> eruit, dan stopt het voor velen (dat is mijn mening, niet wetenschappelijk
> getest).
>
> Het is weeral een tijdje geleden dat ik op dat gebied nog testen gedaan
> heb, dus nominatim is misschien gewijzigd ondertussen, maar data van een
> node werd genegeerd.
>
>
>
> Het is voor mij gemakkelijker uit te leggen dat een boundary is gebroken
> dan om ieman

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

2014-10-30 Thread Sander Deryckere

Ik heb gewoon conceptuele problemen met associatedStreet relaties. Wanneer
stopt een straat? Stop een straat aan iedere postcode of gemeentegrens? Wat
doe je als de nummering verder loopt, is dat dan niet dezelfde straat?
Krijg je geen problemen als je ziet dat onze grenzen verkeerd waren, en er
bepaalde huizen blijken in andere gemeentes te liggen?

Dus ga ik akkoord met Ben: Keep it simple, maar net iets anders.

Gewoon straatnaam en huisnummer op het gebouw, de rest kan afgeleid worden
uit de grenzen. Als die grenzen verkeerd blijken, dan moeten we slechts die
grenzen aanpassen, en niet alles wat er binnen ligt.

We kunnen de data van CRAB ook gebruiken om de grenzen te verbeteren, maar
dat is niet het primaire doel van deze import. Grenzen verbeteren is
trouwens een piece of cake vergeleken met het importeren van alle adressen.

Het onderhouden van boundaries is ook veel eenvoudiger dan het onderhouden
van de adressen.

Iedere mapper is natuurlijk vrij te doen wat hij wil.

Groeten,
Sander

Op 30 oktober 2014 09:10 schreef Ben Abelshausen 
:

> Hey,
>
> 2014-10-30 8:41 GMT+01:00 Jo :
>
>> Wat mij betreft is een adres niet compleet, zonder postcode en gemeente.
>>
>
> Ik ben het hiermee eens.
>
> Ge moet ook bedenken dat we in OSM niet persé het meest efficiënte
> data-model moeten hebben. Een deel van de prioriteit zou ook moeten zijn
> dat de dingen gemakkelijk onderhoudbaar zijn daarom ben ik voorstander van
> de meest eenvoudige oplossing in de vorm van adressen met straat, nummer,
> postcode, gemeente.
>
> Associated street klinkt logisch en best vertrekkende vanuit kennis van
> IT, GIS, JOSM, database normalisatie en dergelijke maar ik wil niet diegene
> zijn die dat moet gaan uitleggen aan nieuwelingen. En als er nu één ding is
> dat we nodig hebben is meer mappers. Werken met boundaries voor
> postcode/gemeente klinkt ook goed maar dat stopt met werken als er een
> boundary kapot gaat (en dan zijn ineens alle adressen daar waardeloos), als
> een gebouw adres op/dichtbij de grens ligt (denk aan een perceel dat
> grotendeels in één gemeente ligt maar het gebouw in een andere?!).
>
> Ik heb heel veel ervaring met adressen vanuit mijn werk bij de post en
> AGIV en boundaries kloppen niet altijd, adressen kloppen niet altijd,
> locaties van adressen zijn niet altijd logisch tov straatnaam/postcode
> en/of gemeente! Er zijn zelfs adressen die enkel te onderscheiden zijn op
> gemeente naam (dus postcode,straat, nummer is NIET overal uniek).
>
> Als dat zo gebeurt, dan moeten we zorgen dat we die nodes niet mergen in
de tools. Maar op zich is het geen probleem dat die ene straat 2 keer
hetzelfde huisnummer heeft. De vergelijkingstools zullen ook niet zo werken
als het moet tenzij een max afstand ingegeven is. Maar ik denk niet dat er
veel dergelijke straten zijn.


> De boodschap is: keep it simple!
>
> Iets relatiefs eenvoudig als een adres moet in OSM ook eenvoudig blijven
> om toe te voegen en te wijzigen. Dat wil zeggen: inloggen op website,
> klikken op gebouw of node en een paar veldjes invullen.
>
> Met vriendelijke groeten,
> Best regards,
>
> Ben Abelshausen
>
> ___
> 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

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

2014-10-30 Thread Guy Vanvuchelen

Reeds enkele weken volg ik de discutie over de adressen. Eigenlijk snap ik er 
weinig van.  Ik wil me niet bij de echte mappers rekenen maar echt beginnend 
ben ik toch ook niet.  Maanden geleden ben ik begonnen met in de streek rond 
Tienen huisnummers in te brengen.  Maar toen ik op het forum meende te 
begrijpen dat het automatisch zou kunnen ben ik natuurlijk gestopt. En nu, weet 
ik het niet meer. Moet ik terug beginnen of moet ik nog wachten.  Er zijn 
misschien efficiëntere manieren om adressen te mappen dan de manier waarop ik 
het doe maar anderzijds… als ik er 1000 doe zijn er 1000 gedaan.  Of worden die 
bij een eventuele automatisering toch overschreven?

Mijn manier is gewoon met AGIV luchtfoto’s de huizen van een straat tekenen en 
dan met RGB-AGIV er de nummers proberen op te zetten.  Bij problemen ga ik dan 
gewoon eens kijken of ik ter plaatse de zaak kan oplossen. 

Een kleine anekdote: In het Medekersveld in KUmtich (Tienen) staan vooraan 3 
huizen aan de linkerkant: 1, 3 en 5. Enkele honderden meters verder dat er nog 
één huis. Volgens AGIV is dat nr 7. Nochtans had ik in OSM nr 100 ingebracht. 
Op het huis of op de brievenbus staat geen nummer, maar in de (geopende) 
brievenbus vond ik een brief met nr 100. Wie heeft nu gelijk?

O ja, als de huizen getekend zijn gebruik ik het ‘adres tool’ en daar blijven 
de gegevens voor straat, gemeente, enz. gewoon staan en moet je alleen het 
nummer wijzigen. Bij het gereedschap ‘Rijtjeshuis maken’ komen de straten  enz; 
 automatisch in een associatedStreet relatie.

 

Ik bewonder diegenen die, dank zij een of ander script, bergen werk kunnen 
herleiden tot een niemendalletje maar ik vrees dat er niet zoveel mappers zijn 
die nog kunnen volgen. Het moet eenvoudig blijven zodat ‘niet programmeurs’ ook 
nog mee kunnen want dat zijn de mensen die meestal het meest tijd hebben om 
‘veldwerk’ te doen.

 

GuyVV

 

Van: Marc Gemis [mailto:marc.ge...@gmail.com] 
Verzonden: donderdag 30 oktober 2014 11:11
Aan: Jo Simoens; OpenStreetMap Belgium
Onderwerp: Re: [OSM-talk-be] import AGIV CRAB-data

 

Jo, jammer genoeg ben je nog zo wat de enige die nog met associatedStreet 
relaties wil werken. Als ik in de landen om ons heen kijk, breken ze 
associatedStreet allemaal af. (in de figuurlijke zin)

Dus waar ga je support krijgen voor data in die relatie ? Op het minieme 
gebruik van Nominatim na, dat dan nog niet hetzelfde doet als jij zou willen ?

 

Ben, als je jouw approach volgt (alles op node), zou ik dat toch ook eerst 
testen op osm.org. Leg anders maar eens uit aan een beginnende mapper dat 
hoewel hij een postcode op een node plaatst er toch een andere uitrolt.


Ik weet dat je niet met bepaalde software in je achterhoofd mag mappen, maar 
als er nu iemand naar osm.org gaat en het verkeerde adres rolt eruit, dan stopt 
het voor velen (dat is mijn mening, niet wetenschappelijk getest).

Het is weeral een tijdje geleden dat ik op dat gebied nog testen gedaan heb, 
dus nominatim is misschien gewijzigd ondertussen, maar data van een node werd 
genegeerd.

 

Het is voor mij gemakkelijker uit te leggen dat een boundary is gebroken dan om 
iemand wijs te maken dat de data wel juist is, maar dat de "gekendste" website  
(osm.org) er geen gebruik van maakt.

 

just my .5 cent

 

m

 

2014-10-30 9:37 GMT+01:00 Jo :

Als je de data aangeleverd krijgt, inclusief de associatedStreet-relatie, dan 
is het niet zo'n grote uitdaging om uit te leggen, waar dat voor staat. Zelfs 
kinderen, vanaf een jaar of 10 kunnen dat begrijpen. We moeten de mensen die 
bijdragen aan OSM nu weer niet al te veel gaan onderschatten.

Laten we niet vergeten dat het om miljoenen adressen gaat voor Vlaanderen 
alleen. Als al die adressen er eenmaal inzitten, moet je al die rompslomp elke 
keer weer over de draad trekken als je dat inlaadt en verwerkt. Ik heb nog 
steeds een datalimiet op 3G.

We hoeven niet superefficiënt te zijn, maar om nu in het andere uiterste te 
vervallen, gewoon omdat we willen dat een kind van 7 het ook zou kunnen 
snappen...

Ik gebruik die aS-relaties trouwens ook om snel een (grafisch) overzicht te 
krijgen van een straat. Waar zijn er nog adressen als node gemapt, e.d. De 
validatietools geven ook wat meldingen, maar die staan nog niet helemaal op 
punt, voor onze situaties waar straten soms in meerdere aS-relaties thuishoren.

 

Jo

 

Op 30 oktober 2014 09:10 schreef Ben Abelshausen :

 

Hey,

 

2014-10-30 8:41 GMT+01:00 Jo :

Wat mij betreft is een adres niet compleet, zonder postcode en gemeente.


Ik ben het hiermee eens.

 

Ge moet ook bedenken dat we in OSM niet persé het meest efficiënte data-model 
moeten hebben. Een deel van de prioriteit zou ook moeten zijn dat de dingen 
gemakkelijk onderhoudbaar zijn daarom ben ik voorstander van de meest 
eenvoudige oplossing in de vorm van adressen met straat, nummer, postcode, 
gemeente.

 

Associated street klinkt logisch en best vertrekkende vanuit kennis van IT, 
GIS,

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

Jo, jammer genoeg ben je nog zo wat de enige die nog met associatedStreet
relaties wil werken. Als ik in de landen om ons heen kijk, breken ze
associatedStreet allemaal af. (in de figuurlijke zin)
Dus waar ga je support krijgen voor data in die relatie ? Op het minieme
gebruik van Nominatim na, dat dan nog niet hetzelfde doet als jij zou
willen ?

Ben, als je jouw approach volgt (alles op node), zou ik dat toch ook eerst
testen op osm.org. Leg anders maar eens uit aan een beginnende mapper dat
hoewel hij een postcode op een node plaatst er toch een andere uitrolt.

Ik weet dat je niet met bepaalde software in je achterhoofd mag mappen,
maar als er nu iemand naar osm.org gaat en het verkeerde adres rolt eruit,
dan stopt het voor velen (dat is mijn mening, niet wetenschappelijk getest).
Het is weeral een tijdje geleden dat ik op dat gebied nog testen gedaan
heb, dus nominatim is misschien gewijzigd ondertussen, maar data van een
node werd genegeerd.

Het is voor mij gemakkelijker uit te leggen dat een boundary is gebroken
dan om iemand wijs te maken dat de data wel juist is, maar dat de
"gekendste" website  (osm.org) er geen gebruik van maakt.

just my .5 cent

m

2014-10-30 9:37 GMT+01:00 Jo :

> Als je de data aangeleverd krijgt, inclusief de associatedStreet-relatie,
> dan is het niet zo'n grote uitdaging om uit te leggen, waar dat voor staat.
> Zelfs kinderen, vanaf een jaar of 10 kunnen dat begrijpen. We moeten de
> mensen die bijdragen aan OSM nu weer niet al te veel gaan onderschatten.
>
> Laten we niet vergeten dat het om miljoenen adressen gaat voor Vlaanderen
> alleen. Als al die adressen er eenmaal inzitten, moet je al die rompslomp
> elke keer weer over de draad trekken als je dat inlaadt en verwerkt. Ik heb
> nog steeds een datalimiet op 3G.
>
> We hoeven niet superefficiënt te zijn, maar om nu in het andere uiterste
> te vervallen, gewoon omdat we willen dat een kind van 7 het ook zou kunnen
> snappen...
>
> Ik gebruik die aS-relaties trouwens ook om snel een (grafisch) overzicht
> te krijgen van een straat. Waar zijn er nog adressen als node gemapt, e.d.
> De validatietools geven ook wat meldingen, maar die staan nog niet helemaal
> op punt, voor onze situaties waar straten soms in meerdere aS-relaties
> thuishoren.
>
> Jo
>
> Op 30 oktober 2014 09:10 schreef Ben Abelshausen <
> ben.abelshau...@gmail.com>:
>
> Hey,
>>
>> 2014-10-30 8:41 GMT+01:00 Jo :
>>
>>> Wat mij betreft is een adres niet compleet, zonder postcode en gemeente.
>>>
>>
>> Ik ben het hiermee eens.
>>
>> Ge moet ook bedenken dat we in OSM niet persé het meest efficiënte
>> data-model moeten hebben. Een deel van de prioriteit zou ook moeten zijn
>> dat de dingen gemakkelijk onderhoudbaar zijn daarom ben ik voorstander van
>> de meest eenvoudige oplossing in de vorm van adressen met straat, nummer,
>> postcode, gemeente.
>>
>> Associated street klinkt logisch en best vertrekkende vanuit kennis van
>> IT, GIS, JOSM, database normalisatie en dergelijke maar ik wil niet diegene
>> zijn die dat moet gaan uitleggen aan nieuwelingen. En als er nu één ding is
>> dat we nodig hebben is meer mappers. Werken met boundaries voor
>> postcode/gemeente klinkt ook goed maar dat stopt met werken als er een
>> boundary kapot gaat (en dan zijn ineens alle adressen daar waardeloos), als
>> een gebouw adres op/dichtbij de grens ligt (denk aan een perceel dat
>> grotendeels in één gemeente ligt maar het gebouw in een andere?!).
>>
>> Ik heb heel veel ervaring met adressen vanuit mijn werk bij de post en
>> AGIV en boundaries kloppen niet altijd, adressen kloppen niet altijd,
>> locaties van adressen zijn niet altijd logisch tov straatnaam/postcode
>> en/of gemeente! Er zijn zelfs adressen die enkel te onderscheiden zijn op
>> gemeente naam (dus postcode,straat, nummer is NIET overal uniek).
>>
>> De boodschap is: keep it simple!
>>
>> Iets relatiefs eenvoudig als een adres moet in OSM ook eenvoudig blijven
>> om toe te voegen en te wijzigen. Dat wil zeggen: inloggen op website,
>> klikken op gebouw of node en een paar veldjes invullen.
>>
>> Met vriendelijke groeten,
>> Best regards,
>>
>> Ben Abelshausen
>>
>
>
> ___
> 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

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

Als je de data aangeleverd krijgt, inclusief de associatedStreet-relatie,
dan is het niet zo'n grote uitdaging om uit te leggen, waar dat voor staat.
Zelfs kinderen, vanaf een jaar of 10 kunnen dat begrijpen. We moeten de
mensen die bijdragen aan OSM nu weer niet al te veel gaan onderschatten.

Laten we niet vergeten dat het om miljoenen adressen gaat voor Vlaanderen
alleen. Als al die adressen er eenmaal inzitten, moet je al die rompslomp
elke keer weer over de draad trekken als je dat inlaadt en verwerkt. Ik heb
nog steeds een datalimiet op 3G.

We hoeven niet superefficiënt te zijn, maar om nu in het andere uiterste te
vervallen, gewoon omdat we willen dat een kind van 7 het ook zou kunnen
snappen...

Ik gebruik die aS-relaties trouwens ook om snel een (grafisch) overzicht te
krijgen van een straat. Waar zijn er nog adressen als node gemapt, e.d. De
validatietools geven ook wat meldingen, maar die staan nog niet helemaal op
punt, voor onze situaties waar straten soms in meerdere aS-relaties
thuishoren.

Jo

Op 30 oktober 2014 09:10 schreef Ben Abelshausen 
:

> Hey,
>
> 2014-10-30 8:41 GMT+01:00 Jo :
>
>> Wat mij betreft is een adres niet compleet, zonder postcode en gemeente.
>>
>
> Ik ben het hiermee eens.
>
> Ge moet ook bedenken dat we in OSM niet persé het meest efficiënte
> data-model moeten hebben. Een deel van de prioriteit zou ook moeten zijn
> dat de dingen gemakkelijk onderhoudbaar zijn daarom ben ik voorstander van
> de meest eenvoudige oplossing in de vorm van adressen met straat, nummer,
> postcode, gemeente.
>
> Associated street klinkt logisch en best vertrekkende vanuit kennis van
> IT, GIS, JOSM, database normalisatie en dergelijke maar ik wil niet diegene
> zijn die dat moet gaan uitleggen aan nieuwelingen. En als er nu één ding is
> dat we nodig hebben is meer mappers. Werken met boundaries voor
> postcode/gemeente klinkt ook goed maar dat stopt met werken als er een
> boundary kapot gaat (en dan zijn ineens alle adressen daar waardeloos), als
> een gebouw adres op/dichtbij de grens ligt (denk aan een perceel dat
> grotendeels in één gemeente ligt maar het gebouw in een andere?!).
>
> Ik heb heel veel ervaring met adressen vanuit mijn werk bij de post en
> AGIV en boundaries kloppen niet altijd, adressen kloppen niet altijd,
> locaties van adressen zijn niet altijd logisch tov straatnaam/postcode
> en/of gemeente! Er zijn zelfs adressen die enkel te onderscheiden zijn op
> gemeente naam (dus postcode,straat, nummer is NIET overal uniek).
>
> De boodschap is: keep it simple!
>
> Iets relatiefs eenvoudig als een adres moet in OSM ook eenvoudig blijven
> om toe te voegen en te wijzigen. Dat wil zeggen: inloggen op website,
> klikken op gebouw of node en een paar veldjes invullen.
>
> Met vriendelijke groeten,
> Best regards,
>
> Ben Abelshausen
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

Hey,

2014-10-30 8:41 GMT+01:00 Jo :

> Wat mij betreft is een adres niet compleet, zonder postcode en gemeente.
>

Ik ben het hiermee eens.

Ge moet ook bedenken dat we in OSM niet persé het meest efficiënte
data-model moeten hebben. Een deel van de prioriteit zou ook moeten zijn
dat de dingen gemakkelijk onderhoudbaar zijn daarom ben ik voorstander van
de meest eenvoudige oplossing in de vorm van adressen met straat, nummer,
postcode, gemeente.

Associated street klinkt logisch en best vertrekkende vanuit kennis van IT,
GIS, JOSM, database normalisatie en dergelijke maar ik wil niet diegene
zijn die dat moet gaan uitleggen aan nieuwelingen. En als er nu één ding is
dat we nodig hebben is meer mappers. Werken met boundaries voor
postcode/gemeente klinkt ook goed maar dat stopt met werken als er een
boundary kapot gaat (en dan zijn ineens alle adressen daar waardeloos), als
een gebouw adres op/dichtbij de grens ligt (denk aan een perceel dat
grotendeels in één gemeente ligt maar het gebouw in een andere?!).

Ik heb heel veel ervaring met adressen vanuit mijn werk bij de post en AGIV
en boundaries kloppen niet altijd, adressen kloppen niet altijd, locaties
van adressen zijn niet altijd logisch tov straatnaam/postcode en/of
gemeente! Er zijn zelfs adressen die enkel te onderscheiden zijn op
gemeente naam (dus postcode,straat, nummer is NIET overal uniek).

De boodschap is: keep it simple!

Iets relatiefs eenvoudig als een adres moet in OSM ook eenvoudig blijven om
toe te voegen en te wijzigen. Dat wil zeggen: inloggen op website, klikken
op gebouw of node en een paar veldjes invullen.

Met vriendelijke groeten,
Best regards,

Ben Abelshausen
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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