[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