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