[OSM-talk-nl] Semi automatisch BAG voorstel

Thu Nov 3 19:59:09 UTC 2011

Stefan vroeg mij in een PM om wat meer van mijn idee te ontsluiten.
Helaas is die niet in de hele groep terecht gekomen.

Hier dan alsnog. Ik hoop hiermee een waardevolle bijdrage te leveren.

Hier een korte functionele beschrijving:

Nederland is opgedeelt in blokken (bv 5 bij 5 km) of in gemeentegrenzen. Dit 
is niet relevant voor het idee. Voor elk van deze 'blokken' kan de
gebruiker een aanvraag doen van klaarstaande wijzigingen in de BAG data.
Het moedersysteem heeft al enige zaken voorbereid voor de aanvraag gedaan 
kan worden.
- Het moeder systeem heeft alle updates van BAG opgesplitst in 
'blok-updates'. Merk op
dat voor ieder blok niet voor iedere maand een update is. Bij geen wijziging 
ontstaat er
voor dat blok geen blok-update.
Merk ook op dat ieder blok in het begin altijd 1 blok-update heeft en dat 
deze alle BAG
data uit dat blok bevat. BAG is in het begin immers nog niet op dat blok in 
OSM gebracht.
Deze blok-update wordt de 'init-update' genoemd. Iedere volgende blok-update 
bevat alleen
de wijzigingen uit een betreffende maand. Op een zeker moment kunnen er dus 
voor ieder
blok verschillende hoeveelheden blok-updates aanwezig zijn.

Een "Delta Uitlevering BAG" (DUB) van een blok heeft de volgende kenmerken:
- De uitlevering wordt gemaakt op het moment van aanvraag
- De uitlevering bevat de geaggregeerde BAG gegevens vanaf "Laatste Update 
Datum" (LUD)
(Voor de eerste uitlevering van ieder blok (init) is deze datum bv 
01-01-2011)
- Bestand heeft een unieke code.
- Bestand is in .OSM formaat zodat deze direct in JOSM geladen kan worden.

Activiteiten DUB site:
De DUB site is een site waarin de ingelogde OSM gebruiker op de kaart van 
OSM 1 blok kan
aangeven en vervolgens daarvan een DUB kan bestellen. De DUB site aggregeert 
alle
blok-updates vanaf de LUD. De gebruikersnaam, de aanvraag datum en een 
unieke code worden
in een database opgeslagen. De site controleert automatisch of de unieke 
code van een
uitstaande DUB voorkomt in de omschrijving van de changesets. Komt deze voor 
dan wordt
het record van de DUB verwijderd en krijgt het blok een LUD die gelijk is 
aan de uitgifte
datum van de net verwijderde DUB.
De geldigheid van een uitlevering kan gesteld worden op 1 maand. Heeft de 
aanvrager zijn
aanvraag niet omgezet in een valide changeset, dan kan via een mail het 
systeem hem
hiertoe aansporen dit alsnog te doen. (Eventueel kan voor voorkomende 
gevallen een
mogelijkheid geschapen worden om de DUB zonder changeset vrij te geven 
zonder de
aanpassingen door te hebben gevoerd in OSM. Het DUB record wordt wel 
verwijderd, maar de
LUD niet aangepast.
Wordt een aanvraag gedaan voor een blok waarvan reeds een DUB uitstaat, dan 
kan deze
geweigerd worden en verwezen worden naar de betrokken gebruiker. Onderling 
kan een
oplossing voor dit oponthoud gevonden worden. (Vrijgeven van het blok?)

De gebruiker vergelijkt na ontvangst de DUB.OSM met de huidige OSM gegevens 
en brengt op
deze laatste de wijzigingen aan. Is de gebruiker klaar dan upload hij de 
gegevens en
vernoemd in de omschrijving van de changeset de unieke code uit de DUB.

Voordelen:
- BAG data inclusief updates kunnen gecontroleerd in OSM worden ingebracht.
- Lokale gebruikers bepalen de update frequentie
- Mappers worden optimaal geholpen in het beschikbaar krijgen van de meest 
relevante BAG
gegevens voor een geografisch blok.
- Mappers hebben niet meer technisch kennis nodig dan JOSM 
technieken/vaardigheden.
- Er is een maximaal overzicht over de BAG status per geografisch blok.

Nadelen:
- De initiële update is een arbeidsintensief werk. De updates zullen 
relatief eenvoudig
zijn.
- Niet ieder blok in OSM zal voorzien zijn met OSM data.

Ik hoop met het bovenstaande duidelijk te hebben gemaakt hoe ik een 
mogelijkheid zie om
de BAG data beschikbaar te stellen aan de mappers-crowd.

mvrgr
Robert Elsenaar

-----Oorspronkelijk bericht----- 
From: Stefan de Konink
Sent: Wednesday, November 02, 2011 11:22 PM
To: talk-nl at openstreetmap.org
Subject: Re: [OSM-talk-nl] Semi automatisch BAG voorstel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Op 02-11-11 21:02, Oliver Heesakkers schreef:
> Een complete postGIS-database? Ik kan me voorstellen dat dat een
> flinke jongen moet zijn voor de hele BAG, zeker als die machine ook
> een (mapnik-)render moet maken en serveren.

Wat zou er niet 'beschikbaar zijn' aan een voor mapnik geschikte
PostGIS database op mijndev. Ik voel aan je eerste reactie al weer dat
je er compleet vijandig in staat. Halloween was je zeker compleet
ontschoten.

> Wie gaat dit dan (belangeloos) doen/opzetten? Hoeveel tijd is
> hiermee wel niet gemoeid?

Dezelfde mensen die hier belangeloos in de afgelopen jaren met
OpenStreetMap hebben gewerkt? Betaal jij mijn uurtjes als ik je vertel
hoelang ik daar mee bezig ben?

> Ik begrijp ook dat deze database niet beschikbaar zal zijn voor de
> gemiddelde mapper, hetgeen niet erg open is voor een
> _open_streetmap.

De database van OpenStreetMap.org is in zijn huidige vorm ook niet
bereikbaar ;) Dus ik zie niet in waarom een WFS/WMS/Mapnik server met
BAG opeens niet open zou zijn. Opnieuw FUD.

> Gaan die grenzen dan in de OSM-database of in die conceptuele
> database?

Die grenzen gaan in OSM, en vervangen alle bestaande data.

> Ik ben ermee akkoord dat die gemeentegrenzen centraal in een keer
> vanuit de BAG in de OSM-database kunnen. Kan er dan misschien ook
> een keer gekeken worden of de admin-levels niet herschikt kunnen
> worden zodat we na wijken ook buurten in kunnen voeren?

Roeland op dit voorstel op 18 april 2011 gereageerd.

> Ik denk dat we het er allemaal over eens kunnen zijn dat we zoveel
> mogelijk mappers moeten verzamelen om de werklast te verdelen en de
> betrokkenheid zo groot mogelijk te houden.

Je weet dat het ook in 1x kan he? Zonder 'betrokkenheid'.

> De voorgestelde losse database zou dan juist weinig motiverend
> zijn. Het huidige 'iedereen met een account kan bijdragen'-model is
>  volgens mij in grote mate verantwoordelijk voor het succes van
> OSM. Met het losse database voorstel misken je dat gegeven. De
> lokale mapper de gelegenheid en verantwoordelijkheid geven om zelf
> de gebouwen in te voeren zal juist veel meer bereidwillige mappers
> opleveren.

En daarmee krijgen we weer een geograbbelton die niemand bijhoudt,
terwijl er wel actuele data beschikbaar is.

> Centraal blijft dan alleen de taak over om het BAG-extract te
> verwerven, in partjes (gemeenten?) te verdelen en in een formaat
> aan te leveren aan de mappers die dat met JOSM of Merkaartor kunnen
> verwerken. De exacte procedure voor de lokale mapper kan
> gedocumenteerd worden in de wiki en eventueel op een meeting uit de
> doeken worden gedaan.

Je weet dat het bij de BAG alleen over gebouwen gaat, die in principe
al k/v tags hebben? Geen rocketscience, alleen er op toezien dat
dubbelen uit de database gaan.

Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAk6xwpgACgkQYH1+F2Rqwn2xogCfTCC4nkOYe8tr93oGlm3a5e/p
VzQAnR49ZKTHaP+zE5zL0yPiayCpVDfA
=GltD
-----END PGP SIGNATURE-----

_______________________________________________
Talk-nl mailing list
Talk-nl at openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

---------------------------------------------------------------------------------------------------
Tekst ingevoegd door Panda GP 2011:

Als het hier gaat om een ongevraagde e-mail (SPAM), klik dan op de volgende 
link om de e-mail te herclasseren: 
http://localhost:6083/Panda?ID=pav_10878&SPAM=true&path=C:\Windows\system32\config\systemprofile\AppData\Local\Panda%20Security\Panda%20Global%20Protection%202011\AntiSpam
--------------------------------------------------------------------------------------------------- 