De bottleneck zit 'm in die 'medewerkers'. Wie gaat er door die gegenereerde rapporten heenwerken? We zijn allemaal vrijwilligers hier, met soms veel tijd maar meestal maar een klein beetje. Mensen komen, en mensen gaan ook weer. Ik heb zelf honderden, misschien wel duizenden building-objecten bewerkt in Nederland, maar woon nu in de VS en richt mijn schaarse vrije tijd op het verbeteren van de kaart hier. Zonder de continuiteit van een organisatie met vaste medewerkers kun je geen processen gaan inrichten die voor hun voortgang afhankelijk zijn van mensen. De geografische dimensie maakt het nog extra lastig. Iemand die in Schagen woont kan niet zonder meer BAG-mutaties samenvoegen met lokale OSM-mutaties in Ootmarsum, omdat de kans heel groot is dat je lokale kennis nodig hebt om te beslissen welke mutatie gehonoreerd moet worden in geval van conflicten.
Een dataset als de BAG, die al zo goed wordt bijgehouden (bij wet geregeld!) door de lokale overheden, kan in de dynamiek van OSM geen goede plek vinden en heeft er dan ook niets te zoeken. Martijn. 2011/10/30 Jo <[email protected]>: > Op 30 oktober 2011 19:56 heeft Cartinus <[email protected]> het > volgende geschreven: >> On Sunday 30 October 2011 19:26:09 Dick wrote: >>> Dan kunnen we, als de bag data is gewijzigd >>> de OSM data automatisch aanpassen. >> >> Het probleem is helemaal niet het volgen van de BAG wijzigingen. Dat is >> simpel. >> >> Het probleem is het respecteren van andere edits op hetzelfde object. In de >> BAG zit bijvoorbeeld nergens waar de ingang van een pand zit. Of welke winkel >> of restaurant er zit. Of... Of... >> >> Daar moet je bij nadenken. Iets wat een individuele mapper zou moeten kunnen, >> maar wat een update script niet kan. > > De oplossing voor dit probleem zoals ik het zie, is het maken van een > script dat niet automatisch gaat updaten, maar dat een rapport > aanmaakt met aandachtspunten waar medewerkers dan mee aan de slag > kunnen om wijzigingen van upstream te gaan samenvoegen met de > bijdragen van de medewerkers. Als daar vanwege upstream interesse voor > is, kunnen bepaalde wijzigingen misschien ook teruggekoppeld worden. > > Een ander probleem zijn wijzigingen die moedwillig (vandalisme) of per > ongeluk (onvervaren mapper o.i.d.) worden aangebracht. Eigenlijk > zouden we dat ook moeten kunnen detecteren. > > mvg, > > Jo > > _______________________________________________ > Talk-nl mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk-nl > -- martijn van exel geospatial omnivore 1109 1st ave #2 salt lake city, ut 84103 801-550-5815 http://oegeo.wordpress.com _______________________________________________ Talk-nl mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-nl
