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: [email protected]
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
[email protected]
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
---------------------------------------------------------------------------------------------------
_______________________________________________
Talk-nl mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-nl
