2011/6/1 Vincent Zweije <vinc...@zweije.nl>:
> On Wed, Jun 01, 2011 at 02:04:01PM +0200, Martijn van Exel wrote:
>
> ||  2011/6/1 Floris Looijesteijn <o...@floris.nu>:
> ||  > Er zit aan elke gebouw een id, die nemen we gewoon mee.
> ||  > Net als de AND id's, die we achteraf nooit gebruikt hebben.
>
> ||  Dat is de makkelijke kant van het verhaal. De uitdagingen liggen
> ||  ietsje onder de oppervlakte (maar niet ver):
> ||  * Wat doen we met alle panden plus hun attributen die al in OSM
> ||  zitten? Dit [1] wil je toch niet al te veel met de hand gaan doen.
> ||  * Wat gebeurt er met de menselijke updates tussen twee import-updates in?
> ||  * Als een pand volgens de import niet meer bestaat en volgens de
> ||  community nog wel, wie heeft er dan gelijk?
>
> De ultieme oplossing is, net als in (distributed) version control systems,
> het (automatisch) mergen van wijzigingen.
>
> Daarvoor moet je de wijzigingen die door mappers met de hand zijn
> aangebracht als precies dat: wijzigingen, representeren. Vervolgens moet
> je hetzelfde doen met de nieuwe BAG data: representeren als wijzigingen.
>
> Daarna kun je alle wijzigingen die niet conflicteren automatisch
> doorvoeren.
>
> De wijzigingen die wel conflicteren moeten met de hand worden
> uitgezocht. Daarin ligt het grootste probleem. Je kunt dit minimaliseren
> door slimme representaties van wijzigingen uit te vinden, die weinig
> conflicten opleveren.
>
> Uiteindelijk zal er altijd handwerk overblijven; daar kom je niet
> onderuit.
>
> Helemaal mooi zou het zijn als de conflicten ook in OSM kunnen worden
> opgeslagen, zodat mappers ze op hun gemakje kunnen oplossen.
>
> One can dream...
>

Ja dat is inderdaad de ultieme oplossing. Ik heb de vraag maar eens in
de groep gegooid bij de GIS-experts op StackExchange[1].
Dat heeft zijdelings te maken met een ander onderwerp waar ik
momenteel mee bezig ben: de brakke manier waarop geschiedenis op dit
moment in OSM wordt opgeslagen. Omdat ways en relations geen eigen
geometrie hebben, zitten er aan het ophalen van alle versies van een
way- of relation-object nogal wat haken en ogen[2]. Iets wat in één
klap zou kunnen worden opgelost met dit probleem.

[1] 
http://gis.stackexchange.com/questions/10493/how-to-deal-with-versioning-in-openstreetmap
[2] 
http://wiki.openstreetmap.org/wiki/User:MaZderMind/Reading_OSM_History_dumps#The_Problem
-- 
Martijn van Exel
http://about.me/mvexel

_______________________________________________
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Antwoord per e-mail aan