Re: [OSM-talk-nl] BAG data en de Import Guidelines

[Gertjan Idema]

On Sun, 2012-10-21 at 17:33 +0200, Cartinus wrote:

> On 10/21/2012 04:04 PM, Sebastiaan Couwenberg wrote:
> > Nu de discussies over het importeren van BAG data goed op gang komen heb
> > ik eens gekeken hoe hiervoor rekening te houden met de Import Guidelines
> 
> 
> 
> 
> > We hebben nu toegang tot de meest authoratieve bron voor deze grenzen,
> > waardoor ik geen bezwaar verwacht tegen het gebruik hiervan. Maar
> > natuurlijk onder voorwaarde dat dit zorgvuldig gebeurt. Het is erg
> > makkelijk om aangrenzende boundaries incompleet te maken bij het
> > splitsen van gemeente grenzen ten behoeve van de woonplaats grenzen daarin.
> 
> De gebouwen kunnen goed in kleine hapjes worden geïmporteerd. Voor de
> woonplaatsgrenzen is dat denk ik echter vragen om problemen, die zijn
> veel te veel verweven met elkaar.
> > Voor het opnemen van de grenzen moeten we denk ik ook een "officiele"
> > procedure ontwikkelen al dan niet geautomatiseerd. Ik meen dat de Deense
> > community een bot heeft draaien die de grenzen daar automatisch
> > corrigeert met de meest recente overheids data, zoiets wil ik voor
> > Nederland ook. Maar tools die het makkelijk maken om de grenzen in OSM
> > op te nemen zonder andere boundaries te slopen vind ik ook wel een goed
> > idee. Ik denk dat de woonplaats export de ways vast moet splitsen op de
> > punten waar grenzen bij elkaar komen om het eenvoudiger in OSM op te
> > nemen. Dit kan in de osmosis plugin, of ik kan daar een script voor
> > schrijven om mee te beginnen.
> 
> Waarom het wiel opnieuw uitvinden? ogr2osm is voor zover ik weet
> speciaal ontwikkeld voor het importeren (als multipolygonen) van
> aansluitende vlakken.

Helaas sluiten de vlakken van de woonplaats multipolygonen in de BAG
vaak niet op elkaar aan. Ik betwijfel of ogr2osm daarmee om kan gaan,
maar ga het zeker proberen.

Gertjan

> 
> - - - - - - - -
> 
> De rest van het verhaal klinkt goed.
> 
> 


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] BAG data en de Import Guidelines

[Cartinus]

On 10/21/2012 04:04 PM, Sebastiaan Couwenberg wrote:
> Nu de discussies over het importeren van BAG data goed op gang komen heb
> ik eens gekeken hoe hiervoor rekening te houden met de Import Guidelines




> We hebben nu toegang tot de meest authoratieve bron voor deze grenzen,
> waardoor ik geen bezwaar verwacht tegen het gebruik hiervan. Maar
> natuurlijk onder voorwaarde dat dit zorgvuldig gebeurt. Het is erg
> makkelijk om aangrenzende boundaries incompleet te maken bij het
> splitsen van gemeente grenzen ten behoeve van de woonplaats grenzen daarin.

De gebouwen kunnen goed in kleine hapjes worden geïmporteerd. Voor de
woonplaatsgrenzen is dat denk ik echter vragen om problemen, die zijn
veel te veel verweven met elkaar.

> Voor het opnemen van de grenzen moeten we denk ik ook een "officiele"
> procedure ontwikkelen al dan niet geautomatiseerd. Ik meen dat de Deense
> community een bot heeft draaien die de grenzen daar automatisch
> corrigeert met de meest recente overheids data, zoiets wil ik voor
> Nederland ook. Maar tools die het makkelijk maken om de grenzen in OSM
> op te nemen zonder andere boundaries te slopen vind ik ook wel een goed
> idee. Ik denk dat de woonplaats export de ways vast moet splitsen op de
> punten waar grenzen bij elkaar komen om het eenvoudiger in OSM op te
> nemen. Dit kan in de osmosis plugin, of ik kan daar een script voor
> schrijven om mee te beginnen.

Waarom het wiel opnieuw uitvinden? ogr2osm is voor zover ik weet
speciaal ontwikkeld voor het importeren (als multipolygonen) van
aansluitende vlakken.

- - - - - - - -

De rest van het verhaal klinkt goed.


-- 
---
m.v.g.,
Cartinus

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] BAG data en de Import Guidelines

[Pander]

On 2012-10-21 16:50, Frank Steggink wrote:
> On 21-10-2012 16:04, Sebastiaan Couwenberg wrote:
>> Nu de discussies over het importeren van BAG data goed op gang komen
>> heb ik eens gekeken hoe hiervoor rekening te houden met de Import
>> Guidelines [1]. We zijn al een heel eind op weg wat dat betreft, maar
>> nog niet aan alle details is al invulling gegeven.
>>
>> [1] http://wiki.openstreetmap.org/wiki/Import/Guidelines
>>
>> De checklist noemt acht punten om rekening mee te houden.
>>
>> "1.  Gain familiarity with the basics of OpenStreetMap, including
>> editing, such as adding details of your neighbourhood. Consider
>> following the beginners' guide."
>>
>> Ieder van ons voldoet aan dit criterium. Het is inderdaad niet
>> verstandig als nieuwe mappers direct aan de slag gaan met BAG data
>> voordat we hier een beginners vriendelijke handleiding voor hebben
>> opgesteld.
>>
>> "2.  Contact the relevant local OSM community to make sure you're not
>> heading down a path someone else has tried and to get a sense of how
>> receptive the community is to imports. Check for local user groups,
>> local chapters, and country-specific mailing lists."
>>
>> De discussies met de lokale community zijn gestart op de mailinglist
>> [2] en forum [3], en de reacties tot nu zijn nog niet echt negatief.
>> Ik verwacht geen bezwaar van de NL community tegen de BAG imports
>> zolang de uitvoering hiervan geen problemen gaat verzorgen. Zolang de
>> BAG panden maar geen custom edits verwijderen, en BAG woonplaats
>> grenzen de bestaanden kunnen aanpassen ipv vervangen lijkt mij de weg
>> vrij. Maar het is ook nog wat vroeg om over duidelijke consensus te
>> spreken. Nog niet veel verschillende mensen hebben zich in de
>> discussies gemengd. Veel meer mensen verwacht eerlijk gezegd ook niet
>> echt, er zijn niet erg veel NL mappers die zich ook nog eens met de
>> community communicatie bezig houden lijkt het.
>>
>> [2]
>> http://lists.openstreetmap.org/pipermail/talk-nl/2012-October/014215.html
>> [3] http://forum.openstreetmap.org/viewtopic.php?id=18311
>>
>> "3.  Check the license of the data. If the license of the data is not
>> compatible with the OpenStreetMap license, you can not use the data."
>>
>> De open data portal van de Nederlandse overheid [4] is heel expliet in
>> de vrije licensering van de BAG data. Licentie: Publiek Domein.
>>
>> [4]
>> https://data.overheid.nl/data/dataset/basisregistratie-adressen-en-gebouwen-bag-
>>
>>
>> Op de home page van de open data portal staat dit wat uitgebreider:
>> http://lists.openstreetmap.org/pipermail/talk/2012-October/064868.html
>> "Wat is open data?
>>
>>  *  De data is openbaar;
>>  *  Er berust geen auteursrecht of andere rechten van derden op;
>>  *  De data zijn bekostigd uit publieke middelen, beschikbaar gesteld
>> voor de uitvoering van die taak;
>>  *  De data voldoen bij voorkeur aan ‘open standaarden’ (geen barrières
>> voor het gebruik door ICT-gebruikers of door ICT-aanbieders);
>>  *  Open Data is bij voorkeur computer-leesbaar, zodat zoekmachines
>> informatie in documenten kunnen vinden."
>>
>> De situatie rond de postcode is mogelijk nog wel een struikelblok.
>> Ondank dat de overheid de data vrij geeft, procederen PostNL en
>> Cendris nog steeds tegen het vrij geven van de postcode database. Zie
>> de dreigbrief tegen postcodeatlas.nl:
>>
>> http://www.postcodeatlas.nl/pages/postcodebestand.html
>>
>> In het vonnis van 21 december 2011 [5] word gesteld dat de postcodes
>> die de overheid van PostNL krijgt niet uit het postcodebestand van
>> PostNL noch de postcodetabel van Cendris komen, en de databaserechten
>> die beide partijen hebben niet van toepassing zijn op de postcodes in
>> de BAG. Dat na de privatisering van de PTT het toewijzen van postcodes
>> niet meer door een overheidsinstantie gedaan word maakt het tot een
>> vreemde situatie. Alle drie partijen stellen nu hun eigen database op
>> met de gegevens die zijn gezamenlijk vast stellen zoals ze dat vroeger
>> als staatsbedrijf onder een dak deden. De BAG database van de overheid
>> word duidelijk als losstaand werk gezien, wat geen afgeleide is van de
>> postcode databases van PostNL en Cendris.
>>
>> Het vonnis word nader toegelicht in Jurispundentie Nr 1 [6].
>>
>> [5] http://zoeken.rechtspraak.nl/detailpage.aspx?ljn=BU9147
>> [6] http://www.ivir.nl/publicaties/eechoud/Annotatie_Mf_2012_4.pdf
>>
>> Mocht in het beroep dat PostNL heeft aangetekend tegen dit vonnis
>> geoordeeld worden dat PostNL toch rechten heeft op de postcodes in de
>> BAG, dan verwacht ik dat de overheid licentiegelden aan PostNL zal
>> gaan betalen voor het gebruik van de postcodes. Wat OSM betreft zullen
>> we de postcodes dan mogelijk achterwege moeten laten bij het
>> importeren indien de postcodes uit de BAG niet vrijelijk gebruikt
>> mogen worden. Ik kan alleen geen informatie vinden over het beroep wat
>> PostNL tegen het vonnis zou hebben aangetekend.
>>
>> Heeft iemand meer informatie over de huidige s

Re: [OSM-talk-nl] BAG data en de Import Guidelines

[Frank Steggink]

On 21-10-2012 16:04, Sebastiaan Couwenberg wrote:
Nu de discussies over het importeren van BAG data goed op gang komen 
heb ik eens gekeken hoe hiervoor rekening te houden met de Import 
Guidelines [1]. We zijn al een heel eind op weg wat dat betreft, maar 
nog niet aan alle details is al invulling gegeven.


[1] http://wiki.openstreetmap.org/wiki/Import/Guidelines

De checklist noemt acht punten om rekening mee te houden.

"1.  Gain familiarity with the basics of OpenStreetMap, including 
editing, such as adding details of your neighbourhood. Consider 
following the beginners' guide."


Ieder van ons voldoet aan dit criterium. Het is inderdaad niet 
verstandig als nieuwe mappers direct aan de slag gaan met BAG data 
voordat we hier een beginners vriendelijke handleiding voor hebben 
opgesteld.


"2.  Contact the relevant local OSM community to make sure you're not 
heading down a path someone else has tried and to get a sense of how 
receptive the community is to imports. Check for local user groups, 
local chapters, and country-specific mailing lists."


De discussies met de lokale community zijn gestart op de mailinglist 
[2] en forum [3], en de reacties tot nu zijn nog niet echt negatief. 
Ik verwacht geen bezwaar van de NL community tegen de BAG imports 
zolang de uitvoering hiervan geen problemen gaat verzorgen. Zolang de 
BAG panden maar geen custom edits verwijderen, en BAG woonplaats 
grenzen de bestaanden kunnen aanpassen ipv vervangen lijkt mij de weg 
vrij. Maar het is ook nog wat vroeg om over duidelijke consensus te 
spreken. Nog niet veel verschillende mensen hebben zich in de 
discussies gemengd. Veel meer mensen verwacht eerlijk gezegd ook niet 
echt, er zijn niet erg veel NL mappers die zich ook nog eens met de 
community communicatie bezig houden lijkt het.


[2] 
http://lists.openstreetmap.org/pipermail/talk-nl/2012-October/014215.html

[3] http://forum.openstreetmap.org/viewtopic.php?id=18311

"3.  Check the license of the data. If the license of the data is not 
compatible with the OpenStreetMap license, you can not use the data."


De open data portal van de Nederlandse overheid [4] is heel expliet in 
de vrije licensering van de BAG data. Licentie: Publiek Domein.


[4] 
https://data.overheid.nl/data/dataset/basisregistratie-adressen-en-gebouwen-bag-


Op de home page van de open data portal staat dit wat uitgebreider:
http://lists.openstreetmap.org/pipermail/talk/2012-October/064868.html
"Wat is open data?

 *  De data is openbaar;
 *  Er berust geen auteursrecht of andere rechten van derden op;
 *  De data zijn bekostigd uit publieke middelen, beschikbaar gesteld
voor de uitvoering van die taak;
 *  De data voldoen bij voorkeur aan ‘open standaarden’ (geen barrières
voor het gebruik door ICT-gebruikers of door ICT-aanbieders);
 *  Open Data is bij voorkeur computer-leesbaar, zodat zoekmachines
informatie in documenten kunnen vinden."

De situatie rond de postcode is mogelijk nog wel een struikelblok. 
Ondank dat de overheid de data vrij geeft, procederen PostNL en 
Cendris nog steeds tegen het vrij geven van de postcode database. Zie 
de dreigbrief tegen postcodeatlas.nl:


http://www.postcodeatlas.nl/pages/postcodebestand.html

In het vonnis van 21 december 2011 [5] word gesteld dat de postcodes 
die de overheid van PostNL krijgt niet uit het postcodebestand van 
PostNL noch de postcodetabel van Cendris komen, en de databaserechten 
die beide partijen hebben niet van toepassing zijn op de postcodes in 
de BAG. Dat na de privatisering van de PTT het toewijzen van postcodes 
niet meer door een overheidsinstantie gedaan word maakt het tot een 
vreemde situatie. Alle drie partijen stellen nu hun eigen database op 
met de gegevens die zijn gezamenlijk vast stellen zoals ze dat vroeger 
als staatsbedrijf onder een dak deden. De BAG database van de overheid 
word duidelijk als losstaand werk gezien, wat geen afgeleide is van de 
postcode databases van PostNL en Cendris.


Het vonnis word nader toegelicht in Jurispundentie Nr 1 [6].

[5] http://zoeken.rechtspraak.nl/detailpage.aspx?ljn=BU9147
[6] http://www.ivir.nl/publicaties/eechoud/Annotatie_Mf_2012_4.pdf

Mocht in het beroep dat PostNL heeft aangetekend tegen dit vonnis 
geoordeeld worden dat PostNL toch rechten heeft op de postcodes in de 
BAG, dan verwacht ik dat de overheid licentiegelden aan PostNL zal 
gaan betalen voor het gebruik van de postcodes. Wat OSM betreft zullen 
we de postcodes dan mogelijk achterwege moeten laten bij het 
importeren indien de postcodes uit de BAG niet vrijelijk gebruikt 
mogen worden. Ik kan alleen geen informatie vinden over het beroep wat 
PostNL tegen het vonnis zou hebben aangetekend.


Heeft iemand meer informatie over de huidige stand van zake in deze zaak?

"4.  Find out what data layers the organization offers. This might be 
street centerlines, building outlines, waterways, addresses, etc."


Gebouwen, adressen en administratieve grenzen. Binnen de BAG bekend 
als de PND, NUM en

[OSM-talk-nl] BAG data en de Import Guidelines

[Sebastiaan Couwenberg]

Nu de discussies over het importeren van BAG data goed op gang komen heb 
ik eens gekeken hoe hiervoor rekening te houden met de Import Guidelines 
[1]. We zijn al een heel eind op weg wat dat betreft, maar nog niet aan 
alle details is al invulling gegeven.


[1] http://wiki.openstreetmap.org/wiki/Import/Guidelines

De checklist noemt acht punten om rekening mee te houden.

"1.  Gain familiarity with the basics of OpenStreetMap, including 
editing, such as adding details of your neighbourhood. Consider 
following the beginners' guide."


Ieder van ons voldoet aan dit criterium. Het is inderdaad niet 
verstandig als nieuwe mappers direct aan de slag gaan met BAG data 
voordat we hier een beginners vriendelijke handleiding voor hebben 
opgesteld.


"2.  Contact the relevant local OSM community to make sure you're not 
heading down a path someone else has tried and to get a sense of how 
receptive the community is to imports. Check for local user groups, 
local chapters, and country-specific mailing lists."


De discussies met de lokale community zijn gestart op de mailinglist [2] 
en forum [3], en de reacties tot nu zijn nog niet echt negatief. Ik 
verwacht geen bezwaar van de NL community tegen de BAG imports zolang de 
uitvoering hiervan geen problemen gaat verzorgen. Zolang de BAG panden 
maar geen custom edits verwijderen, en BAG woonplaats grenzen de 
bestaanden kunnen aanpassen ipv vervangen lijkt mij de weg vrij. Maar 
het is ook nog wat vroeg om over duidelijke consensus te spreken. Nog 
niet veel verschillende mensen hebben zich in de discussies gemengd. 
Veel meer mensen verwacht eerlijk gezegd ook niet echt, er zijn niet erg 
veel NL mappers die zich ook nog eens met de community communicatie 
bezig houden lijkt het.


[2] 
http://lists.openstreetmap.org/pipermail/talk-nl/2012-October/014215.html

[3] http://forum.openstreetmap.org/viewtopic.php?id=18311

"3.  Check the license of the data. If the license of the data is not 
compatible with the OpenStreetMap license, you can not use the data."


De open data portal van de Nederlandse overheid [4] is heel expliet in 
de vrije licensering van de BAG data. Licentie: Publiek Domein.


[4] 
https://data.overheid.nl/data/dataset/basisregistratie-adressen-en-gebouwen-bag-


Op de home page van de open data portal staat dit wat uitgebreider:
http://lists.openstreetmap.org/pipermail/talk/2012-October/064868.html
"Wat is open data?

 *  De data is openbaar;
 *  Er berust geen auteursrecht of andere rechten van derden op;
 *  De data zijn bekostigd uit publieke middelen, beschikbaar gesteld
voor de uitvoering van die taak;
 *  De data voldoen bij voorkeur aan ‘open standaarden’ (geen barrières
voor het gebruik door ICT-gebruikers of door ICT-aanbieders);
 *  Open Data is bij voorkeur computer-leesbaar, zodat zoekmachines
informatie in documenten kunnen vinden."

De situatie rond de postcode is mogelijk nog wel een struikelblok. 
Ondank dat de overheid de data vrij geeft, procederen PostNL en Cendris 
nog steeds tegen het vrij geven van de postcode database. Zie de 
dreigbrief tegen postcodeatlas.nl:


http://www.postcodeatlas.nl/pages/postcodebestand.html

In het vonnis van 21 december 2011 [5] word gesteld dat de postcodes die 
de overheid van PostNL krijgt niet uit het postcodebestand van PostNL 
noch de postcodetabel van Cendris komen, en de databaserechten die beide 
partijen hebben niet van toepassing zijn op de postcodes in de BAG. Dat 
na de privatisering van de PTT het toewijzen van postcodes niet meer 
door een overheidsinstantie gedaan word maakt het tot een vreemde 
situatie. Alle drie partijen stellen nu hun eigen database op met de 
gegevens die zijn gezamenlijk vast stellen zoals ze dat vroeger als 
staatsbedrijf onder een dak deden. De BAG database van de overheid word 
duidelijk als losstaand werk gezien, wat geen afgeleide is van de 
postcode databases van PostNL en Cendris.


Het vonnis word nader toegelicht in Jurispundentie Nr 1 [6].

[5] http://zoeken.rechtspraak.nl/detailpage.aspx?ljn=BU9147
[6] http://www.ivir.nl/publicaties/eechoud/Annotatie_Mf_2012_4.pdf

Mocht in het beroep dat PostNL heeft aangetekend tegen dit vonnis 
geoordeeld worden dat PostNL toch rechten heeft op de postcodes in de 
BAG, dan verwacht ik dat de overheid licentiegelden aan PostNL zal gaan 
betalen voor het gebruik van de postcodes. Wat OSM betreft zullen we de 
postcodes dan mogelijk achterwege moeten laten bij het importeren indien 
de postcodes uit de BAG niet vrijelijk gebruikt mogen worden. Ik kan 
alleen geen informatie vinden over het beroep wat PostNL tegen het 
vonnis zou hebben aangetekend.


Heeft iemand meer informatie over de huidige stand van zake in deze zaak?

"4.  Find out what data layers the organization offers. This might be 
street centerlines, building outlines, waterways, addresses, etc."


Gebouwen, adressen en administratieve grenzen. Binnen de BAG bekend als 
de PND, NUM en WPL data sets. De stand- en ligplaatsen zijn ook n

Re: [OSM-talk-nl] Het taggen van BAG data.

[Gertjan Idema]

On Sun, 2012-10-21 at 14:42 +0200, Just van den Broecke wrote:

> On 20-10-12 22:58, Stefan de Konink wrote:
> > On Sat, 20 Oct 2012, Gertjan Idema wrote:
> >
> >> Heb je een voorbeeld van een mutatie bestand? Ik heb er nog nooit een
> >> gezien.
> >
> > Volgens mij staat die op nlextract.nl
> Klopt:
> https://github.com/opengeogroep/NLExtract/tree/master/bag/test/mutatie

En aangezien ik een Git clone heb dus ook gewoon op mijn eigen pc'tje ;-).

Bedankt beiden voor de tip.

Groeten, Gertjan

> Just
> >
> > Stefan
> >
> >
> > ___
> > Talk-nl mailing list
> > Talk-nl@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-nl
> >
> >
> > !DSPAM:1,5082f4f0256191152810491!
> >
> >
> >
> > ___
> > Talk-nl mailing list
> > Talk-nl@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-nl
> >
> 
> 
> 
> 
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Het taggen van BAG data.

[Just van den Broecke]

On 20-10-12 22:58, Stefan de Konink wrote:

On Sat, 20 Oct 2012, Gertjan Idema wrote:


Heb je een voorbeeld van een mutatie bestand? Ik heb er nog nooit een
gezien.


Volgens mij staat die op nlextract.nl

Klopt:
https://github.com/opengeogroep/NLExtract/tree/master/bag/test/mutatie

Just


Stefan


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl


!DSPAM:1,5082f4f0256191152810491!



___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl







___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Het taggen van BAG data.

[theun]

Ik zou me kunnen voorstellen dat je dat pas doet vanaf "bouw gestart". 
Hier in de buurt zag ik ook al een groot pand staan waar de 
bouwvergunning is verleend, al op het moment dat de BAG data vrijkwam. 
Dan is het in deze tijd natuurlijk nog wel nodig om de financiering etc. 
rond te krijgen en het pand daadwerkelijk te bouwen. De kans bestaat dus 
dat het pand als "niet gerealiseerd pand" eindigt. Die data lijkt mij 
niet nuttig voor OSM.


Op 21-10-2012 13:17, Gertjan Idema schreef:

On Sun, 2012-10-21 at 11:52 +0200, Frank Steggink wrote:

Als een bouwvergunning verleend is, hoeft nog niet te betekenen dat al
met de bouw gestart is. Ik wist trouwens niet dat deze status ook in de
BAG aanwezig kan zijn. Geldt dit ook voor sloopvergunningen?
Het klopt dat de bouw meestal niet start zodra de bouwvergunning is 
verleend. Mijn overweging om zo'n gebouw toch aan aan een .osm file 
toe te voegen is de volgende:
In de praktijk zal er tijd zitten tussen het moment van genereren van 
een .osm file en het moment dat een mapper er mee aan de gang gaat. 
Door het pand als "building=construction" toe te voegen, weet de 
mapper dat er op die plek iets gaat gebeuren en kan hij bijvoorbeeld 
in de BAG web kijken wat de huidige status van het pand is.
Iets als "building=planned" is volgens mij niet gedocumenteerd in OSM 
en zal door Mapnik cs als bestaand pand gerenderd worden.


Sloop vergunningen staan ook in de BAG. Hier is het complete lijstje:
Bouwvergunning verleend
Niet gerealiseerd pand
Bouw gestart
Pand in gebruik (niet ingemeten)
Pand in gebruik
Sloopvergunning verleend
Pand gesloopt
Pand buiten gebruik

Groeten, Gertjan

Groeten,

Frank

On 21-10-2012 11:36, Hugo Hölscher wrote:
>
> Lijkt me de goede benadering. Hugo
>
> Op 21 okt. 2012 11:07 schreef "Gertjan Idema" mailto:g.id...@zonnet.nl>  
> > het volgende:

>
> On Sun, 2012-10-21 at 10:49 +0200, Hugo Holscher wrote:
>> Het viel mij op dat de gegevens van het BAG (tenminste zo als ik
>> ze in de BAG viewer zie), data bevat die nog niet bestaan. Als je
>> deze id zoekt: 039710014064, vind je een huis en adres in
>> Heemstede waarvan de bouw nog niet eens begonnen is. Verder weet
>> ik dat de bouw vergunning aan verandering onderhevig is. Gaan we
>> met bulk up-loads nu de mogelijk toekomstige kaart van Nederland
>> maken of is het wijsheid om de locaties waarvan de status is:
>> "bouwvergunning verleend" er nog uit laten?
>> Hugo
>
> Mijn insteek op dit moment is om gebouwen met status "Bouw
> gestart" te taggen als building=construction. Voor "Bouwvergunning
> verleend" kan je overwegen om dat ook te doen, om wat meer
> informatie te geven aan een mapper die ziet dat er wat gaande is
> op een stukje grond. Daarnaast voeg ik een tag "bag:status" toe.
>
> Gertjan
>> *From:*Gertjan Idema 
>> *Sent:*Saturday, October 20, 2012 8:54 PM
>> *To:*talk-nl@openstreetmap.org    

>> *Subject:*Re: [OSM-talk-nl] Het taggen van BAG data.
>> On Sat, 2012-10-20 at 13:21 +0200, Just van den Broecke wrote:
>>> Beste Gertjan e.a,
>>>
>>> Een goed plan, ik wil wel meedenken. btw: De BAG is net deze week
>>> ververst met versie 8 sept en 8 okt:
>> Fijn dat je meedenkt :-)
>>>http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml   
>>> (Atom).

>>> e.e.a. moet ook simpeler worden in de toekomst:
>>>http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds
>>>
>>> Ik probeer wat aan te vullen onder...het blijft een taai onderwerp.
>>>
>>>
>>> On 17-10-12 13:11, Gertjan Idema wrote:
>>> > Er is een aantal initiatieven gaande voor het opnemen van BAG data in
>>> > Openstreetmap.
>>> > - ruudblank heeft veel werk verricht in Gorinchem.
>>> > - rullzer in de omgeving Purmerend
>>> > - mijn eigen initiatief op basis waarvan Minko (Amersfoort), PeeWee
>>> > (Leusden) en Sebastiaan (Oldambt) nu  kleinschalig
>>> >aan het testen zijn.
>>> > - en ongetwijfeld nog meer.
>>> >
>>> > Helaas is er nog geen standaard voor het taggen van BAG data. Mijn 
idee
>>> > van deze discussie is om hier samen te vatten wat er tot nu toe gedaan
>>> > en besproken is over het taggen van data afkomstig uit de BAG.
>>> > Vervolgens hoop ik dat we het samen eens kunnen worden over een
>>> > standaard. Deze kan dan opgenomen worden op de Wiki pagina en
>>> > geïntegreerd in tools en scripts. Het doel hierbij is niet om zoveel
>>> > mogelijk BAG dat in openstreetmap te krijgen, maar om te zorgen dat 
dit
>>> > consistent gebeurt.
>>> >
>>> > Eerst maar eens een inventarisatie:
>>> >
>>> > Adres tags op pand of losse nodes
>>> > =
>>> > De BAG maakt onderscheid tussen panden, verblijfsobjecten en
>>> > nummeraanduid

Re: [OSM-talk-nl] Het taggen van BAG data.

[Sebastiaan Couwenberg]

On 10/21/2012 11:52 AM, Frank Steggink wrote:

Als een bouwvergunning verleend is, hoeft nog niet te betekenen dat al
met de bouw gestart is. Ik wist trouwens niet dat deze status ook in de
BAG aanwezig kan zijn. Geldt dit ook voor sloopvergunningen?


Sloopvergunning verleent is ook een status die ik in de BAG ben tegen 
gekomen.


Bijvoorbeeld ref:bagid=18951227
Burgemeester Schonfeldplein 2B, Winschoten

De volgende statussen kom ik in de BAG tegen:

  count   |pandstatus
--+--
   135090 | Pand gesloopt
   109979 | Bouw gestart
   330795 | Pand in gebruik (niet ingemeten)
52579 | Sloopvergunning verleend
 11109687 | Pand in gebruik
   239848 | Bouwvergunning verleend
 1656 | Pand buiten gebruik
41025 | Niet gerealiseerd pand
(8 rows)

Mvg,

Bas

--
GnuPG: 0x77A975AD

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Het taggen van BAG data.

[Gertjan Idema]

On Sun, 2012-10-21 at 11:52 +0200, Frank Steggink wrote:

> Als een bouwvergunning verleend is, hoeft nog niet te betekenen dat al 
> met de bouw gestart is. Ik wist trouwens niet dat deze status ook in de 
> BAG aanwezig kan zijn. Geldt dit ook voor sloopvergunningen?

Het klopt dat de bouw meestal niet start zodra de bouwvergunning is
verleend. Mijn overweging om zo'n gebouw toch aan aan een .osm file toe
te voegen is de volgende:
In de praktijk zal er tijd zitten tussen het moment van genereren van
een .osm file en het moment dat een mapper er mee aan de gang gaat. Door
het pand als "building=construction" toe te voegen, weet de mapper dat
er op die plek iets gaat gebeuren en kan hij bijvoorbeeld in de BAG web
kijken wat de huidige status van het pand is.
Iets als "building=planned" is volgens mij niet gedocumenteerd in OSM en
zal door Mapnik cs als bestaand pand gerenderd worden.


Sloop vergunningen staan ook in de BAG. Hier is het complete lijstje:

Bouwvergunning verleend
Niet gerealiseerd pand
Bouw gestart
Pand in gebruik (niet ingemeten)
Pand in gebruik
Sloopvergunning verleend
Pand gesloopt
Pand buiten gebruik

Groeten, Gertjan

> Groeten,
> 
> Frank
> 
> On 21-10-2012 11:36, Hugo Hölscher wrote:
> >
> > Lijkt me de goede benadering. Hugo
> >
> > Op 21 okt. 2012 11:07 schreef "Gertjan Idema"  > > het volgende:
> >
> > On Sun, 2012-10-21 at 10:49 +0200, Hugo Holscher wrote:
> >> Het viel mij op dat de gegevens van het BAG (tenminste zo als ik
> >> ze in de BAG viewer zie), data bevat die nog niet bestaan. Als je
> >> deze id zoekt: 039710014064, vind je een huis en adres in
> >> Heemstede waarvan de bouw nog niet eens begonnen is. Verder weet
> >> ik dat de bouw vergunning aan verandering onderhevig is. Gaan we
> >> met bulk up-loads nu de mogelijk toekomstige kaart van Nederland
> >> maken of is het wijsheid om de locaties waarvan de status is:
> >> “bouwvergunning verleend” er nog uit laten? 
> >> Hugo 
> >
> > Mijn insteek op dit moment is om gebouwen met status "Bouw
> > gestart" te taggen als building=construction. Voor "Bouwvergunning
> > verleend" kan je overwegen om dat ook te doen, om wat meer
> > informatie te geven aan een mapper die ziet dat er wat gaande is
> > op een stukje grond. Daarnaast voeg ik een tag "bag:status" toe.
> >
> > Gertjan
> >> *From:*Gertjan Idema  
> >> *Sent:*Saturday, October 20, 2012 8:54 PM 
> >> *To:*talk-nl@openstreetmap.org  
> >> *Subject:*Re: [OSM-talk-nl] Het taggen van BAG data. 
> >> On Sat, 2012-10-20 at 13:21 +0200, Just van den Broecke wrote:
> >>> Beste Gertjan e.a,
> >>>
> >>> Een goed plan, ik wil wel meedenken. btw: De BAG is net deze week
> >>> ververst met versie 8 sept en 8 okt:
> >> Fijn dat je meedenkt :-)
> >>> 
> >>> http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml
> >>>   
> >>> (Atom).
> >>> e.e.a. moet ook simpeler worden in de toekomst:
> >>> http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds
> >>>
> >>> Ik probeer wat aan te vullen onder...het blijft een taai onderwerp.
> >>>
> >>>
> >>> On 17-10-12 13:11, Gertjan Idema wrote:
> >>> > Er is een aantal initiatieven gaande voor het opnemen van BAG data 
> >>> in
> >>> > Openstreetmap.
> >>> > - ruudblank heeft veel werk verricht in Gorinchem.
> >>> > - rullzer in de omgeving Purmerend
> >>> > - mijn eigen initiatief op basis waarvan Minko (Amersfoort), PeeWee
> >>> > (Leusden) en Sebastiaan (Oldambt) nu  kleinschalig
> >>> >aan het testen zijn.
> >>> > - en ongetwijfeld nog meer.
> >>> >
> >>> > Helaas is er nog geen standaard voor het taggen van BAG data. Mijn 
> >>> idee
> >>> > van deze discussie is om hier samen te vatten wat er tot nu toe 
> >>> gedaan
> >>> > en besproken is over het taggen van data afkomstig uit de BAG.
> >>> > Vervolgens hoop ik dat we het samen eens kunnen worden over een
> >>> > standaard. Deze kan dan opgenomen worden op de Wiki pagina en
> >>> > geïntegreerd in tools en scripts. Het doel hierbij is niet om zoveel
> >>> > mogelijk BAG dat in openstreetmap te krijgen, maar om te zorgen dat 
> >>> dit
> >>> > consistent gebeurt.
> >>> >
> >>> > Eerst maar eens een inventarisatie:
> >>> >
> >>> > Adres tags op pand of losse nodes
> >>> > =
> >>> > De BAG maakt onderscheid tussen panden, verblijfsobjecten en
> >>> > nummeraanduidingen. Een pand kan meerdere verblijfsobjecten 
> >>> bevatten.
> >>> Ja het meestvoorkomende, maar ook omgekeerd (meerdere Panden bij VBO),
> >>> maar moet daarvan nog voorbeeld zien.
> >> Hier is een mooi voorbeeld: VBO 034401091735 (Ambachtsweg 52,
> >> Utrecht) ik heb ook nog even geen
> >> idee hoe we dit het beste in OSM zouden k

Re: [OSM-talk-nl] Het taggen van BAG data.

[Frank Steggink]

Dat zou je kunnen melden via het terugmeldformulier.

Frank

On 21-10-2012 11:51, Minko wrote:

Het omgekeerde komt ook voor, panden die wel bestaan maar niet in de BAG 
voorkomen.
Bv restaurant Dara (uit 2009): http://www.openstreetmap.org/?way=186870059
Is dat een bekend fenomeen?


Het viel mij op dat de gegevens van het BAG (tenminste zo als ik ze in
de BAG viewer zie), data bevat die nog niet bestaan.

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl




___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Het taggen van BAG data.

[Frank Steggink]

Als een bouwvergunning verleend is, hoeft nog niet te betekenen dat al 
met de bouw gestart is. Ik wist trouwens niet dat deze status ook in de 
BAG aanwezig kan zijn. Geldt dit ook voor sloopvergunningen?


Groeten,

Frank

On 21-10-2012 11:36, Hugo Hölscher wrote:


Lijkt me de goede benadering. Hugo

Op 21 okt. 2012 11:07 schreef "Gertjan Idema" > het volgende:


On Sun, 2012-10-21 at 10:49 +0200, Hugo Holscher wrote:

Het viel mij op dat de gegevens van het BAG (tenminste zo als ik
ze in de BAG viewer zie), data bevat die nog niet bestaan. Als je
deze id zoekt: 039710014064, vind je een huis en adres in
Heemstede waarvan de bouw nog niet eens begonnen is. Verder weet
ik dat de bouw vergunning aan verandering onderhevig is. Gaan we
met bulk up-loads nu de mogelijk toekomstige kaart van Nederland
maken of is het wijsheid om de locaties waarvan de status is:
“bouwvergunning verleend” er nog uit laten? 
Hugo 


Mijn insteek op dit moment is om gebouwen met status "Bouw
gestart" te taggen als building=construction. Voor "Bouwvergunning
verleend" kan je overwegen om dat ook te doen, om wat meer
informatie te geven aan een mapper die ziet dat er wat gaande is
op een stukje grond. Daarnaast voeg ik een tag "bag:status" toe.

Gertjan
*From:*Gertjan Idema  
*Sent:*Saturday, October 20, 2012 8:54 PM 
*To:*talk-nl@openstreetmap.org  
*Subject:*Re: [OSM-talk-nl] Het taggen van BAG data. 
On Sat, 2012-10-20 at 13:21 +0200, Just van den Broecke wrote:

Beste Gertjan e.a,

Een goed plan, ik wil wel meedenken. btw: De BAG is net deze week
ververst met versie 8 sept en 8 okt:

Fijn dat je meedenkt :-)
http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml  
(Atom).

e.e.a. moet ook simpeler worden in de toekomst:
http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds

Ik probeer wat aan te vullen onder...het blijft een taai onderwerp.


On 17-10-12 13:11, Gertjan Idema wrote:
> Er is een aantal initiatieven gaande voor het opnemen van BAG data in
> Openstreetmap.
> - ruudblank heeft veel werk verricht in Gorinchem.
> - rullzer in de omgeving Purmerend
> - mijn eigen initiatief op basis waarvan Minko (Amersfoort), PeeWee
> (Leusden) en Sebastiaan (Oldambt) nu  kleinschalig
>aan het testen zijn.
> - en ongetwijfeld nog meer.
>
> Helaas is er nog geen standaard voor het taggen van BAG data. Mijn idee
> van deze discussie is om hier samen te vatten wat er tot nu toe gedaan
> en besproken is over het taggen van data afkomstig uit de BAG.
> Vervolgens hoop ik dat we het samen eens kunnen worden over een
> standaard. Deze kan dan opgenomen worden op de Wiki pagina en
> geïntegreerd in tools en scripts. Het doel hierbij is niet om zoveel
> mogelijk BAG dat in openstreetmap te krijgen, maar om te zorgen dat dit
> consistent gebeurt.
>
> Eerst maar eens een inventarisatie:
>
> Adres tags op pand of losse nodes
> =
> De BAG maakt onderscheid tussen panden, verblijfsobjecten en
> nummeraanduidingen. Een pand kan meerdere verblijfsobjecten bevatten.
Ja het meestvoorkomende, maar ook omgekeerd (meerdere Panden bij VBO),
maar moet daarvan nog voorbeeld zien.

Hier is een mooi voorbeeld: VBO 034401091735 (Ambachtsweg 52,
Utrecht) ik heb ook nog even geen
idee hoe we dit het beste in OSM zouden kunnen mappen.
Een ander voorbeeld is VBO 034410054743 (Hoogravenseweg
140A). Hier zijn 2 panden samengevoegd en vervolgens opgedeeld in
7 verblijfsobjecten.
Ik kom 161 VBO's met meerdere panden tegen in Utrecht stad, de
meesten met 2 panden per VBO.

> Tot nu toe heb ik de adressen als volgt getagd:
> Voor panden met een enkel verblijfsobject heb ik de adres tags
> (addr:housenumber, addr:postcode, addr:street) aan het pand gekoppeld
> met in tag "ref:bagid" het BAG id van het pand.
> Voor panden met meerdere verblijfsobjecten heb ik aan het pand geen
> adres tags gekoppeld, dit kunnen immers verschillende straten zijn. De
> adres tags heb ik aan losse nodes gekoppeld met in tag "ref:bagid" het
> BAG id van de nummeraanduiding.
>
> ruudblank heeft er in Gorinchem voor gekozen om alle adressen los te
> koppelen van het pand. Als BAG referentie gebruikt hij het BAG id van
> het verblijfsobject in de tag "bag:vbo_id" en op de panden het BAG id
> van het pand in "bag:pand_id".
>
> rullzer maakt hetzelfde onderscheid als ik tussen panden met 1 of met
> meer verblijfsobjecten, maar gebruikt geen BAG id op de adres nodes.
Een lastige, ik zou in ieder geval zo dicht mogelijk bij het BAG model
blijven...Bijv. kunnen VBOs en (LIG/STA) niet gewoon zelf OSM punt-nodes
 

Re: [OSM-talk-nl] wegen in drievoud

[Frank Steggink]

JOSM heeft soms last van deze kuren. Het is mij ook wel eens overkomen. 
Je kunt als je met relaties of andere complexe zaken aan de gang gaat 
beter vaker uploaden. Je kunt in JOSM er ook voor kiezen om de changeset 
niet af te sluiten, dus ook al doe je veel veranderingen, dan komen ze 
in dezelfde changeset. OSM sluit de changeset automatisch nadat een uur 
geen wijzigingen zijn veranderd. Je kunt dat doen in het upload-scherm.


Frank

On 21-10-2012 10:53, Hugo Holscher wrote:
Ik heb ook iets dergelijks meegemaakt. Wat ik er van geleerd heb, is 
een tag mee te geven (in bijvoorbeeld een note als dat kan), waarmee 
je, je eigen wijziging kunt selecteren en veranderen. Maar misschien 
had dat in dit specifieke geval niet geholpen.

Hugo
*From:* dbuss...@goudappel.nl 
*Sent:* Saturday, October 20, 2012 10:47 PM
*To:* OpenStreetMap NL discussion list 
*Subject:* Re: [OSM-talk-nl] wegen in drievoud
Vreemd verhaal.
Ik moest alles handmatig herstellen omdat door de dubbeling de 
relaties (bus en fietsknopen) zo in de war waren dat terugdraaien geen 
optie meer was. Bljikbaar was iemand anders tegelijk of net na mij met 
de buslijnen bezig op "mijn" drievoudige wegen...

Nu is volgens mij alles weer netjes.
Vervolgens ben ik op zoek gegaan of er elders dubbele wegen zijn maar 
kon er geen vinden.
Het is dus niet zo dat JOSM dit vaker doet maar een idee hoe deze 
changeset kon ontstaan heb ik nog steeds niet.



-Johan C  schreef: -
Aan: OpenStreetMap NL discussion list 
Van: Johan C 
Datum: 10/20/2012 04:22PM
Onderwerp: Re: [OSM-talk-nl] wegen in drievoud

Ik zie twee mogelijkheden:
1. terugdraaien
2. checken met de validator en de crossing ways handmatig verwijderen

Op 20 oktober 2012 01:31 schreef > het volgende:


vandaag iets te enthousiast teveel tegelijk in een changeset gepackt.
JOSM heeft daarop een aantal keren timeout gegeven tot het
uiteindelijk gelukt is.
Effect is nu dat alle objecten die ik geraakt heb drie keer boven
elkaar in OSM staan.
Weet iemand hoe dat komt en of het eenvoudig ongedaan gemaakt kan
worden?

Het gaat om http://www.openstreetmap.org/browse/changeset/13561955

Voorbeeld: de volgende ways (allen behorende tot changeset
13561955) zijn identiek:
http://www.openstreetmap.org/browse/way/186703099
http://www.openstreetmap.org/browse/way/186691521
http://www.openstreetmap.org/browse/way/186693939

Groeten, Dirk





Disclaimer

De informatie opgenomen in dit bericht kan vertrouwelijk zijn en
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken
en de afzender direct te informeren door het bericht te
retourneren. De afzender sluit iedere aansprakelijkheid uit die
voortvloeit uit elektronische verzending.
___
Talk-nl mailing list
Talk-nl@openstreetmap.org 
http://lists.openstreetmap.org/listinfo/talk-nl

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

 


Disclaimer

De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is 
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de 
afzender direct te informeren door het bericht te retourneren. De 
afzender sluit iedere aansprakelijkheid uit die voortvloeit uit 
elektronische verzending.



___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl



___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Het taggen van BAG data.

[Minko]

Het omgekeerde komt ook voor, panden die wel bestaan maar niet in de BAG 
voorkomen.
Bv restaurant Dara (uit 2009): http://www.openstreetmap.org/?way=186870059
Is dat een bekend fenomeen?

> Het viel mij op dat de gegevens van het BAG (tenminste zo als ik ze in
> de BAG viewer zie), data bevat die nog niet bestaan. 

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Het taggen van BAG data.

[Hugo Hölscher]

Lijkt me de goede benadering.  Hugo
Op 21 okt. 2012 11:07 schreef "Gertjan Idema"  het
volgende:

> **
> On Sun, 2012-10-21 at 10:49 +0200, Hugo Holscher wrote:
>
> Het viel mij op dat de gegevens van het BAG (tenminste zo als ik ze in de
> BAG viewer zie), data bevat die nog niet bestaan. Als je deze id zoekt:
> 039710014064, vind je een huis en adres  in Heemstede waarvan de bouw
> nog niet eens begonnen is. Verder weet ik dat de bouw vergunning aan
> verandering onderhevig is. Gaan we met bulk up-loads nu de mogelijk
> toekomstige kaart van Nederland maken of is het wijsheid om de locaties
> waarvan de status is: “bouwvergunning verleend” er nog uit laten?
>
>
>
>  Hugo
>
>
> Mijn insteek op dit moment is om gebouwen met status  "Bouw gestart" te
> taggen als building=construction. Voor "Bouwvergunning verleend" kan je
> overwegen om dat ook te doen, om wat meer informatie te geven aan een
> mapper die ziet dat er wat gaande is op een stukje grond. Daarnaast voeg ik
> een tag "bag:status" toe.
>
> Gertjan
>
>
>
>  *From:* Gertjan Idema 
>
>  *Sent:* Saturday, October 20, 2012 8:54 PM
>
>  *To:* talk-nl@openstreetmap.org
>
>  *Subject:* Re: [OSM-talk-nl] Het taggen van BAG data.
>
>
>
>  On Sat, 2012-10-20 at 13:21 +0200, Just van den Broecke wrote:
>
> Beste Gertjan e.a,
> Een goed plan, ik wil wel meedenken. btw: De BAG is net deze week ververst 
> met versie 8 sept en 8 okt:
>
>  Fijn dat je meedenkt :-)
>
> http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml
>  (Atom).e.e.a. moet ook simpeler worden in de 
> toekomst:http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds
> Ik probeer wat aan te vullen onder...het blijft een taai onderwerp.
>
> On 17-10-12 13:11, Gertjan Idema wrote:> Er is een aantal initiatieven gaande 
> voor het opnemen van BAG data in> Openstreetmap.> - ruudblank heeft veel werk 
> verricht in Gorinchem.> - rullzer in de omgeving Purmerend> - mijn eigen 
> initiatief op basis waarvan Minko (Amersfoort), PeeWee> (Leusden) en 
> Sebastiaan (Oldambt) nu  kleinschalig>aan het testen zijn.> - en 
> ongetwijfeld nog meer.>> Helaas is er nog geen standaard voor het taggen van 
> BAG data. Mijn idee> van deze discussie is om hier samen te vatten wat er tot 
> nu toe gedaan> en besproken is over het taggen van data afkomstig uit de 
> BAG.> Vervolgens hoop ik dat we het samen eens kunnen worden over een> 
> standaard. Deze kan dan opgenomen worden op de Wiki pagina en> geïntegreerd 
> in tools en scripts. Het doel hierbij is niet om zoveel> mogelijk BAG dat in 
> openstreetmap te krijgen, maar om te zorgen dat dit> consistent gebeurt.>> 
> Eerst maar eens een inventarisatie:>> Adres tags op pand of losse nodes> 
> => De BAG maakt onderscheid tussen panden, 
> verblijfsobjecten en> nummeraanduidingen. Een pand kan meerdere 
> verblijfsobjecten bevatten.Ja het meestvoorkomende, maar ook omgekeerd 
> (meerdere Panden bij VBO), maar moet daarvan nog voorbeeld zien.
>
>  Hier is een mooi voorbeeld: VBO 034401091735 (Ambachtsweg 52,
> Utrecht) ik heb ook nog even geen
> idee hoe we dit het beste in OSM zouden kunnen mappen.
> Een ander voorbeeld is VBO 034410054743 (Hoogravenseweg 140A). Hier
> zijn 2 panden samengevoegd en vervolgens opgedeeld in 7 verblijfsobjecten.
> Ik kom 161 VBO's met meerdere panden tegen in Utrecht stad, de meesten met
> 2 panden per VBO.
>
> > Tot nu toe heb ik de adressen als volgt getagd:> Voor panden met een enkel 
> > verblijfsobject heb ik de adres tags> (addr:housenumber, addr:postcode, 
> > addr:street) aan het pand gekoppeld> met in tag "ref:bagid" het BAG id van 
> > het pand.> Voor panden met meerdere verblijfsobjecten heb ik aan het pand 
> > geen> adres tags gekoppeld, dit kunnen immers verschillende straten zijn. 
> > De> adres tags heb ik aan losse nodes gekoppeld met in tag "ref:bagid" het> 
> > BAG id van de nummeraanduiding.>> ruudblank heeft er in Gorinchem voor 
> > gekozen om alle adressen los te> koppelen van het pand. Als BAG referentie 
> > gebruikt hij het BAG id van> het verblijfsobject in de tag "bag:vbo_id" en 
> > op de panden het BAG id> van het pand in "bag:pand_id".>> rullzer maakt 
> > hetzelfde onderscheid als ik tussen panden met 1 of met> meer 
> > verblijfsobjecten, maar gebruikt geen BAG id op de adres nodes.Een lastige, 
> > ik zou in ieder geval zo dicht mogelijk bij het BAG model blijven...Bijv. 
> > kunnen VBOs en (LIG/STA) niet gewoon zelf OSM punt-nodes zijn (plm 9 
> > miljoen in NL!)? En gekoppeld via relaties aan Panden ? In het achterhoofd 
> > ook het soort gebruik van OSM adressen: Geocoders, Door-to-door navigation. 
> > En verder aansluiten bij algemene OSM-conventies voor adressen.
>
>  Relaties tussen panden en verblijfsobjecten/adressen worden voor zover
> ik weet niet gebruikt in OSM. En gezien het feit dat associatedStreet
> relaties amper gebruikt worden vanwege de complexiteit, denk ik dat een
> eventuele associatedBuilding relatie

Re: [OSM-talk-nl] Het taggen van BAG data.

[Gertjan Idema]

On Sun, 2012-10-21 at 10:49 +0200, Hugo Holscher wrote:
> Het viel mij op dat de gegevens van het BAG (tenminste zo als ik ze in
> de BAG viewer zie), data bevat die nog niet bestaan. Als je deze id
> zoekt: 039710014064, vind je een huis en adres  in Heemstede
> waarvan de bouw nog niet eens begonnen is. Verder weet ik dat de bouw
> vergunning aan verandering onderhevig is. Gaan we met bulk up-loads nu
> de mogelijk toekomstige kaart van Nederland maken of is het wijsheid
> om de locaties waarvan de status is: “bouwvergunning verleend” er nog
> uit laten?
>  
> Hugo

Mijn insteek op dit moment is om gebouwen met status  "Bouw gestart" te
taggen als building=construction. Voor "Bouwvergunning verleend" kan je
overwegen om dat ook te doen, om wat meer informatie te geven aan een
mapper die ziet dat er wat gaande is op een stukje grond. Daarnaast voeg
ik een tag "bag:status" toe.

Gertjan
>  
> From: Gertjan Idema 
> Sent: Saturday, October 20, 2012 8:54 PM
> To: talk-nl@openstreetmap.org 
> Subject: Re: [OSM-talk-nl] Het taggen van BAG data.
>  
> 
> On Sat, 2012-10-20 at 13:21 +0200, Just van den Broecke wrote: 
> 
> > Beste Gertjan e.a,
> > 
> > Een goed plan, ik wil wel meedenken. btw: De BAG is net deze week 
> > ververst met versie 8 sept en 8 okt:
> 
> Fijn dat je meedenkt :-) 
> 
> > http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml
> >  
> > (Atom).
> > e.e.a. moet ook simpeler worden in de toekomst:
> > http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds
> > 
> > Ik probeer wat aan te vullen onder...het blijft een taai onderwerp.
> > 
> > 
> > On 17-10-12 13:11, Gertjan Idema wrote:
> > > Er is een aantal initiatieven gaande voor het opnemen van BAG data in
> > > Openstreetmap.
> > > - ruudblank heeft veel werk verricht in Gorinchem.
> > > - rullzer in de omgeving Purmerend
> > > - mijn eigen initiatief op basis waarvan Minko (Amersfoort), PeeWee
> > > (Leusden) en Sebastiaan (Oldambt) nu  kleinschalig
> > >aan het testen zijn.
> > > - en ongetwijfeld nog meer.
> > >
> > > Helaas is er nog geen standaard voor het taggen van BAG data. Mijn idee
> > > van deze discussie is om hier samen te vatten wat er tot nu toe gedaan
> > > en besproken is over het taggen van data afkomstig uit de BAG.
> > > Vervolgens hoop ik dat we het samen eens kunnen worden over een
> > > standaard. Deze kan dan opgenomen worden op de Wiki pagina en
> > > geïntegreerd in tools en scripts. Het doel hierbij is niet om zoveel
> > > mogelijk BAG dat in openstreetmap te krijgen, maar om te zorgen dat dit
> > > consistent gebeurt.
> > >
> > > Eerst maar eens een inventarisatie:
> > >
> > > Adres tags op pand of losse nodes
> > > =
> > > De BAG maakt onderscheid tussen panden, verblijfsobjecten en
> > > nummeraanduidingen. Een pand kan meerdere verblijfsobjecten bevatten.
> > Ja het meestvoorkomende, maar ook omgekeerd (meerdere Panden bij VBO), 
> > maar moet daarvan nog voorbeeld zien.
> 
> Hier is een mooi voorbeeld: VBO 034401091735 (Ambachtsweg 52,
> Utrecht) ik heb ook nog even geen
> idee hoe we dit het beste in OSM zouden kunnen mappen.
> Een ander voorbeeld is VBO 034410054743 (Hoogravenseweg 140A).
> Hier zijn 2 panden samengevoegd en vervolgens opgedeeld in 7
> verblijfsobjecten.
> Ik kom 161 VBO's met meerdere panden tegen in Utrecht stad, de meesten
> met 2 panden per VBO. 
> 
> > > Tot nu toe heb ik de adressen als volgt getagd:
> > > Voor panden met een enkel verblijfsobject heb ik de adres tags
> > > (addr:housenumber, addr:postcode, addr:street) aan het pand gekoppeld
> > > met in tag "ref:bagid" het BAG id van het pand.
> > > Voor panden met meerdere verblijfsobjecten heb ik aan het pand geen
> > > adres tags gekoppeld, dit kunnen immers verschillende straten zijn. De
> > > adres tags heb ik aan losse nodes gekoppeld met in tag "ref:bagid" het
> > > BAG id van de nummeraanduiding.
> > >
> > > ruudblank heeft er in Gorinchem voor gekozen om alle adressen los te
> > > koppelen van het pand. Als BAG referentie gebruikt hij het BAG id van
> > > het verblijfsobject in de tag "bag:vbo_id" en op de panden het BAG id
> > > van het pand in "bag:pand_id".
> > >
> > > rullzer maakt hetzelfde onderscheid als ik tussen panden met 1 of met
> > > meer verblijfsobjecten, maar gebruikt geen BAG id op de adres nodes.
> > Een lastige, ik zou in ieder geval zo dicht mogelijk bij het BAG model 
> > blijven...Bijv. kunnen VBOs en (LIG/STA) niet gewoon zelf OSM punt-nodes 
> > zijn (plm 9 miljoen in NL!)? En gekoppeld via relaties aan Panden ? In 
> > het achterhoofd ook het soort gebruik van OSM adressen: Geocoders, 
> > Door-to-door navigation. En verder aansluiten bij algemene 
> > OSM-conventies voor adressen.
> 
> Relaties tussen panden en verblijfsobjecten/adressen worden voor zover
> ik weet niet gebruikt in OSM. En gezien het feit dat associatedStreet
> relaties amper gebruikt worden vanwege de complexiteit, denk ik dat
> een eventuele associat

Re: [OSM-talk-nl] wegen in drievoud

[Hugo Holscher]

Ik heb ook iets dergelijks meegemaakt. Wat ik er van geleerd heb, is een tag 
mee te geven (in bijvoorbeeld een note als dat kan), waarmee je, je eigen 
wijziging kunt selecteren en veranderen. Maar misschien had dat in dit 
specifieke geval niet geholpen.

Hugo

From: dbuss...@goudappel.nl 
Sent: Saturday, October 20, 2012 10:47 PM
To: OpenStreetMap NL discussion list 
Subject: Re: [OSM-talk-nl] wegen in drievoud

Vreemd verhaal.
Ik moest alles handmatig herstellen omdat door de dubbeling de relaties (bus en 
fietsknopen) zo in de war waren dat terugdraaien geen optie meer was. Bljikbaar 
was iemand anders tegelijk of net na mij met de buslijnen bezig op "mijn" 
drievoudige wegen...
Nu is volgens mij alles weer netjes.
Vervolgens ben ik op zoek gegaan of er elders dubbele wegen zijn maar kon er 
geen vinden. 
Het is dus niet zo dat JOSM dit vaker doet maar een idee hoe deze changeset kon 
ontstaan heb ik nog steeds niet.


-Johan C  schreef: - 
Aan: OpenStreetMap NL discussion list 
Van: Johan C 
Datum: 10/20/2012 04:22PM
Onderwerp: Re: [OSM-talk-nl] wegen in drievoud


Ik zie twee mogelijkheden:
1. terugdraaien
2. checken met de validator en de crossing ways handmatig verwijderen


Op 20 oktober 2012 01:31 schreef  het volgende:

  vandaag iets te enthousiast teveel tegelijk in een changeset gepackt.
  JOSM heeft daarop een aantal keren timeout gegeven tot het uiteindelijk 
gelukt is.
  Effect is nu dat alle objecten die ik geraakt heb drie keer boven elkaar in 
OSM staan.
  Weet iemand hoe dat komt en of het eenvoudig ongedaan gemaakt kan worden? 

  Het gaat om http://www.openstreetmap.org/browse/changeset/13561955

  Voorbeeld: de volgende ways (allen behorende tot changeset 13561955) zijn 
identiek:
  http://www.openstreetmap.org/browse/way/186703099
  http://www.openstreetmap.org/browse/way/186691521
  http://www.openstreetmap.org/browse/way/186693939

  Groeten, Dirk


  

 
  Disclaimer 

  De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is 
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht 
ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te 
informeren door het bericht te retourneren. De afzender sluit iedere 
aansprakelijkheid uit die voortvloeit uit elektronische verzending. 
  ___
  Talk-nl mailing list
  Talk-nl@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-nl



___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl



 
Disclaimer 

De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend 
bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u 
verzocht de inhoud niet te gebruiken en de afzender direct te informeren door 
het bericht te retourneren. De afzender sluit iedere aansprakelijkheid uit die 
voortvloeit uit elektronische verzending. 



___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Het taggen van BAG data.

[Hugo Holscher]

Het viel mij op dat de gegevens van het BAG (tenminste zo als ik ze in de BAG 
viewer zie), data bevat die nog niet bestaan. Als je deze id zoekt: 
039710014064, vind je een huis en adres  in Heemstede waarvan de bouw nog 
niet eens begonnen is. Verder weet ik dat de bouw vergunning aan verandering 
onderhevig is. Gaan we met bulk up-loads nu de mogelijk toekomstige kaart van 
Nederland maken of is het wijsheid om de locaties waarvan de status is: 
“bouwvergunning verleend” er nog uit laten?

Hugo


From: Gertjan Idema 
Sent: Saturday, October 20, 2012 8:54 PM
To: talk-nl@openstreetmap.org 
Subject: Re: [OSM-talk-nl] Het taggen van BAG data.

On Sat, 2012-10-20 at 13:21 +0200, Just van den Broecke wrote: 
Beste Gertjan e.a,

Een goed plan, ik wil wel meedenken. btw: De BAG is net deze week 
ververst met versie 8 sept en 8 okt:
Fijn dat je meedenkt :-) 
http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml 
(Atom).
e.e.a. moet ook simpeler worden in de toekomst:
http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds

Ik probeer wat aan te vullen onder...het blijft een taai onderwerp.


On 17-10-12 13:11, Gertjan Idema wrote:
> Er is een aantal initiatieven gaande voor het opnemen van BAG data in
> Openstreetmap.
> - ruudblank heeft veel werk verricht in Gorinchem.
> - rullzer in de omgeving Purmerend
> - mijn eigen initiatief op basis waarvan Minko (Amersfoort), PeeWee
> (Leusden) en Sebastiaan (Oldambt) nu  kleinschalig
>aan het testen zijn.
> - en ongetwijfeld nog meer.
>
> Helaas is er nog geen standaard voor het taggen van BAG data. Mijn idee
> van deze discussie is om hier samen te vatten wat er tot nu toe gedaan
> en besproken is over het taggen van data afkomstig uit de BAG.
> Vervolgens hoop ik dat we het samen eens kunnen worden over een
> standaard. Deze kan dan opgenomen worden op de Wiki pagina en
> geïntegreerd in tools en scripts. Het doel hierbij is niet om zoveel
> mogelijk BAG dat in openstreetmap te krijgen, maar om te zorgen dat dit
> consistent gebeurt.
>
> Eerst maar eens een inventarisatie:
>
> Adres tags op pand of losse nodes
> =
> De BAG maakt onderscheid tussen panden, verblijfsobjecten en
> nummeraanduidingen. Een pand kan meerdere verblijfsobjecten bevatten.
Ja het meestvoorkomende, maar ook omgekeerd (meerdere Panden bij VBO), 
maar moet daarvan nog voorbeeld zien.
Hier is een mooi voorbeeld: VBO 034401091735 (Ambachtsweg 52, Utrecht) ik 
heb ook nog even geen
idee hoe we dit het beste in OSM zouden kunnen mappen.
Een ander voorbeeld is VBO 034410054743 (Hoogravenseweg 140A). Hier zijn 2 
panden samengevoegd en vervolgens opgedeeld in 7 verblijfsobjecten.
Ik kom 161 VBO's met meerdere panden tegen in Utrecht stad, de meesten met 2 
panden per VBO. 
> Tot nu toe heb ik de adressen als volgt getagd:
> Voor panden met een enkel verblijfsobject heb ik de adres tags
> (addr:housenumber, addr:postcode, addr:street) aan het pand gekoppeld
> met in tag "ref:bagid" het BAG id van het pand.
> Voor panden met meerdere verblijfsobjecten heb ik aan het pand geen
> adres tags gekoppeld, dit kunnen immers verschillende straten zijn. De
> adres tags heb ik aan losse nodes gekoppeld met in tag "ref:bagid" het
> BAG id van de nummeraanduiding.
>
> ruudblank heeft er in Gorinchem voor gekozen om alle adressen los te
> koppelen van het pand. Als BAG referentie gebruikt hij het BAG id van
> het verblijfsobject in de tag "bag:vbo_id" en op de panden het BAG id
> van het pand in "bag:pand_id".
>
> rullzer maakt hetzelfde onderscheid als ik tussen panden met 1 of met
> meer verblijfsobjecten, maar gebruikt geen BAG id op de adres nodes.
Een lastige, ik zou in ieder geval zo dicht mogelijk bij het BAG model 
blijven...Bijv. kunnen VBOs en (LIG/STA) niet gewoon zelf OSM punt-nodes 
zijn (plm 9 miljoen in NL!)? En gekoppeld via relaties aan Panden ? In 
het achterhoofd ook het soort gebruik van OSM adressen: Geocoders, 
Door-to-door navigation. En verder aansluiten bij algemene 
OSM-conventies voor adressen.
Relaties tussen panden en verblijfsobjecten/adressen worden voor zover ik weet 
niet gebruikt in OSM. En gezien het feit dat associatedStreet relaties amper 
gebruikt worden vanwege de complexiteit, denk ik dat een eventuele 
associatedBuilding relatie het niet gaat redden.
Voor de meeste toepassingen zal een relatie tussen pand en adres niet echt 
belangrijk zijn, hoewel Cartinus aangaf dat de relatie tussen hoofdadres en 
nevenadressen (leveranciersadressen) in de transportsector wel gebruikt wordt.


>
> AssociatedStreet relaties
> =
> AssociatedStreet relaties bieden veel voor en nadelen en het laatste
> woord is er nog niet over gesproken. Een voordeel dat in mijn ogen
> onderbelicht is, is het bij elkaar voegen van losse stukjes van dezelfde
> straat. Hierdoor kunnen gemakkelijke relaties gelegd worden tussen
> straten in OSM en straten uit andere bronnen. Dat gaat echter alleen
> werken associate