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

[Marc Gemis]

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

[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

[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

[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

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

[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

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

[Marc Gemis]

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

[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

[Marc Gemis]

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

[Ben Abelshausen]

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

[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

[Marc Gemis]

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

[Ben Abelshausen]

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

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

[Jo]

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

[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

[Jo]

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

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

[Marc Gemis]

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

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

[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

[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, JOSM, database normalisati

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

[Marc Gemis]

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

[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, 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

[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

[Jo]

Dus enerzijds zeggen we: we voegen postcode en gemeente niet toe; je kan
dat uit de boundaries halen

Anderzijds zeggen we: je kan het niet uit de boundaries halen, want die
zijn er niet allemaal.

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

En nu weet ik weer waarom ik zo'n voorstander van die
associatedStreet-relaties ben. Die laten toe om deze cruciale informatie
mee te geven, zonder dat deze miljoenen malen onnodig herhaald hoeft te
worden EN zonder de noodzaak om ingewikkelde operaties op boundaries, die
al dan niet aanwezig/stuk zijn mbv een geodatabase.

Neen, je haalt gewoon de parent relations op, filtert op associatedStreet
en daar zit dan de rest van je adresinformatie.

Eigenlijk zit de straatnaam daar ook, maar goed ik kan me verzoenen met het
compromis om deze toch maar te vermiljoenigvuldigen.

Wat er nu toch zo ingewikkeld is aan die relaties, dat ontgaat me compleet.

Persoonlijk zal ik ze dus steeds toevoegen en zonodig zelf aanmaken.

Ik zou het op prijs stellen als deze info ook mee wordt doorgegeven (liefst
in discardable tags), zodat we tenminste kunnen zien dat een straat
postcode- of gemeentegrenzen overschrijdt.

We kunnen ook zeggen, dat we via CRAB over voldoende informatie beschikken
om de postcodegrenzen zelf te creëren, mits wat gegeoochel met
PostGIS-functies. Dat klopt wel, maar zelfs dan is de informatie veel
directer beschikbaar voor de gebruiker van de data via aS-relaties.

Johan

Op 29 oktober 2014 20:37 schreef Sander Deryckere :

>
> Misschien beter om de lijsten van appartementsnummers en busnummers te
> splitsen. Zelf begrijp ik het verschil nog niet goed, maar als we het
> eenmaal begrijpen, dan moet de data tenminste niet opnieuw gegenereerd
> worden.
>
>
> Op 29 oktober 2014 19:52 schreef Thomas :
>
>>  Ik heb het script nu verder uitgerust met een aantal
>> data-integriteits-checks rond postcode / gemeente. Daaruit blijken toch nog
>> wat bijzondere dingen waar ik het script op moet aanpassen. Zo blijkt dat
>> een straat (zoals geïdentificeerd door zijn ID in de adressenlijst) in
>> meerdere postcodes kan voorkomen, maar nooit in meerdere gemeenten. Een
>> gemeente bestaat uiteraard uit meerdere postcodes. Daarnaast kan 1 postcode
>> zich in meerdere gemeenten bevinden. Halleluja; lees deze alinea nog maar 3
>> keer opnieuw...
>>
>> Op dit moment identificeren we op basis van postcode → straat. Dat houdt
>> in dat we nu een aantal straten splitsen over de postcode, terwijl we op
>> basis van de data die straten zouden kunnen samenhouden. Mogelijk (nouja;
>> dat ben ik wel zeker) zijn straten ook gesplitst op gemeentegrenzen, maar
>> deze dataset biedt daar geen mogelijkheden voor.
>>
>> Mijn script pikt nu deze over-postcodes-heen-gesplitste-straten op; het
>> gaat om 1920 unieke straten die meestal over 2 maar soms over 3 postcodes
>> heen gesplitst zijn. Mijn script biedt al heel wat mogelijkheden om hier
>> mee om te gaan, maar we moeten het natuurlijk wel eens zijn over wat
>> wenselijk is.
>>
>> Concreet betekent het in feite dat als we onderscheid maken op basis van
>> een postcode, we onherroepelijk straten zullen splitsen. We kunnen ervoor
>> kiezen om de data per gemeente te ordenen, maar dan wordt de hoeveelheid
>> data per gemeente bijna 2 keer zo groot als de data nu per postcode (er
>> zijn in totaal 308 gemeenten en 519 postcodes). Gezien de nu vaak al grote
>> hoeveelheid straten per postcode is dit misschien onwenselijk. Zeker omdat
>> het volgens mij vaak al de stedelijke gemeenten zijn die meerdere postcodes
>> hebben. Die gemeenten gaan dan van zeer grote stratenlijsten naar enorme
>> stratenlijsten. Een alternatief is die straten in beide postcodegebieden op
>> te nemen. Dat vind ik ook geen nette uitwerking omdat je dan redundancy
>> krijgt in de de JSON-bestanden.
>>
>> Volgens mij is dan de beste optie om per straat in de
>> postcode-JSON-bestanden een extra JSON-attribuut mee te geven die aangeeft
>> of de straat doorloopt in een andere gemeente. Dat zie ik in de vorm van
>> een lijst van postcodes per straat waar de straat in doorloopt. Dat kan met
>> wat javascript uitgelezen worden. Die specifieke straat kan in datzelfde
>> stuk javascript opgehaald worden en aan de betrokken straat toegevoegd
>> worden. Als je het meer handmatig wil houden kun je vrij eenvoudig een knop
>> toevoegen voor de gebruiker om die straat in de andere gemeenten mee in te
>> laden. Op deze manier kan de opdeling per postcode gehandhaafd worden, maar
>> is toch duidelijk op straat-niveau waar mappers mee rekening dienen te
>> houden. Daarnaast is deze informatie mogelijk ook zeer belangrijk voor de
>> scripts van Jo rond het koppelen van adressen/gebouwen aan een straat. Wat
>> denken jullie hiervan?
>>
>> Ik zie hier geen probleem in. Normaal moet een adres uniek zijn met
> postcode, straatnaam en huisnummer (het is toch op deze manier dat de Post
> - of bPost - brieven sorteert). Dus, hoewel een straat kan doorlopen in een
> ande