[OSM-talk-nl] BAG

[steggink at steggink.org]

Quoting Martijn van Exel <m at rtijn.org>:

> Gert et al,
>
> 2011/6/1 ce-test, qualified testing bv - Gert Gremmen <g.gremmen at cetest.nl>:
>> Wat in de hele OSM strategy ontbreekt is een update strategie.
>> Deze BAG data heeft inderdaad de potentie om de hele community
>> te overspoelen met update werk . Aan de andere kant wordt de BAG data
>> ook bijgewerkt door de overheid.  Als we een geautomatiseerd   
>> systeem hadden om updates
>> in OSM te laden, dan zou deze hoeveelheid niet zo erg zijn.
>> (overigens : is het echt zoveel meer dan de 3d importen?)
>>
>> Op kleine schaal zie je dat met bijvoorbeeld de fietsroutes.
>> Als er iets veranderd is het maar de vraag of dat door iemand
>> van ons wordt opgemerkt.
>> Daar zouden we ons de komende jaren op moeten richten:
>> Hoe houden we de data up-to-date ?
>
> Dit was ook mijn zorg. Niet alleen voor de updates op zich, wat al een
> hoop werk is (ze komen maandelijks uit) maar ook hoe om te gaan met
> 'echte' edits door de community op gebouwen, zie mijn eerdere mail.
> Dit speelde met AND niet omdat het een eenmalige update was, en voor
> 3DShapes misschien in mindere mate omdat veel van het grondgebruik
> sowieso niet snel door de community in kaart zou worden gebracht:
> moeilijk en lage prioriteit, maar het ziet er nu wel fraai uit. Maar
> ook deze data veroudert op den duur.
>
> We moeten wat mij betreft ook onder ogen zien dat de BAG misschien
> niet per se in de OSM-database zou hoeven te worden geimporteerd. Het
> kan ook als afzonderlijke laag worden weergegeven. Importeren moet
> niet dogmatisch worden. Het is niet van: er is vrije data, *dus* het
> moet in OSM.
>

Mee eens. Deze trend is ook enige tijd op talk waar te nemen. Als ik  
deze kennis ca 1 1/2 jaar geleden had, weet ik niet of ik mij nog wel  
met volle overgave op de landuse van 3dShapes gestort zou hebben...

Waar bijna iedereen het wel over eens is, is dat het community-aspect  
van OSM veel belangrijker is dan het zijn van een open data-warehouse.  
Dat betekent ook dat het minder noodzakelijk is om na te denken over  
een update-strategie. Dat zal altijd lastig geworden.

Nieuwe gebruikers zullen zich niks aantrekken van ID's. Het is erg  
makkelijk om ze te vernaggelen met de huidige editors (bijv. door  
knippen en mergen van shapes). Niet de schuld van de editors, maar de  
identificatie van een objectje in OSM is de geometrie zelf (en in  
mindere mate het OSM ID) en niet een extern ID wat als attribuut eraan  
hangt. Dat gaat dus conflicten opleveren met systemen die wel  
ID-gebaseerd zijn, zoals de BAG. Zelfs het OSM ID kan gaan "wandelen"  
in de loop van de tijd. Het is geen permanent gegeven.

Frank