Quoting Martijn van Exel <[email protected]>:
Gert et al,
2011/6/1 ce-test, qualified testing bv - Gert Gremmen <[email protected]>:
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
_______________________________________________
Talk-nl mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-nl
