[OSM-talk-nl] BAG

Lennard ldp at xs4all.nl
Wed Jun 1 14:36:08 UTC 2011


On 1-6-2011 16:02, dbussche at goudappel.nl wrote:

> Synchronisatie hoeft volgens mij niet super-moeilijk zijn. De automaat
> kijkt dan naar het datum van de laatste wijziging. Als de BAG recent heeft
> gewijzigt "wint" die, anders OSM. Dit inderdaad per attribuut (en geometry
> als verzameling van alle nodes is voor het gemak een attribuut). Ook
> verwijderen is een "wijziging" die kan winnen. Dus een welbewust
> weggehaald pand in osm wordt niet indirect via de BAG weer hersteld. Daar
> waar afwijkingen zijn kunnen wij die als een extra tag (SYNC of zo)
> expliciet maken zodat plaatselijke mappers dat eventueel op kunnen pakken.
> Wat dat betreft met Vincent eens.

Ik zie veel heil in een interim database, waar alle BAG objecten in 
komen. Dit maakt meerdere dingen mogelijk:

1) BAG updates zijn eenduidig te verwerken, doordat het BAG id nooit 
verloren kan gaan.
2) Elk object kan vlaggetjes krijgen dat de status van dat object in OSM 
aanduidt: geïmporteerd (+timestamp), niet geïmporteerd, gesloopt, etc. 
Geen dubbel werk en als er twijfel is over een gebied/pand, kan dat 
later nog een keer aan de orde komen. Lokale mappers kunnen benaderd worden.
3) Vanuit deze db kunnen overlays gerenderd worden alsook diagnosetools 
draaien.
4) Je zou er als locale mapper een plukje gebouwen uit moeten kunnen 
selecteren, die dan met de hand verwerkt kunnen worden in OSM.
5) Het maakt spatiële analyse andersom mogelijk: pak een OSM gebouw en 
kijk of dit in de BAG ook bestaat. Komen de adrestags overeen? Kan OSM 
aangevuld worden? Is het gebouw in OSM een eenvoudige BAG-dump of zitten 
er verrijkende tags (amenity, etc) op?

En het voorkomt dat je iedere keer opnieuw 'het wiel moet uitvinden' of 
door zowel de hele OSM-db als BAG moet lopen om wijzigingen te detecteren.

Zoals Frank al aangaf: BAG id's op OSM objecten hangen biedt geen enkele 
zekerheid.


-- 
Lennard





More information about the Talk-nl mailing list