Re: [OSM-talk] How to deal with versioning
Martijn, On 06/01/11 19:59, Martijn van Exel wrote: I don't think that will be a tenable attitude in the longer run. OpenStreetMap and public sector data (that's what we're mostly dealing with when we consider imports) will not continue to be two totally disparate entities, who have 'ownership' over the data that is in their respective databases. I foresee[1] a future reality in which the flow of information between OpenStreetMap and the public sector can be more bi-directional and also more continuous It is, in my opinion, short-sighted to try and incorporate such data into OSM. OSM is for data that we maintain, that we improve, change, or delete. Anything else has no place in OSM. That is not to say that government data can be *useful* - it's just that OSM is not primarily a data storage, but a data editing and maintenance system. Any data that does not require our editing and maintenance should be outside of OSM, and merged with OSM data at the rendering/processing stage. Our editors should not be burdened with such inert information. Conflicts would never arise, because either *we* are the master for something, or the external source is. Stuff for which we are not the master will not be in OSM; it will live separately. But also for much simpler situations this may be a useful thing. That's a different issue. Maybe in the long run we'll throw away our svn-like central database, and everyone can simply fork the planet on github ;) Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to deal with versioning
On 6/1/11 4:18 PM, Frederik Ramm wrote: Hi, On 06/01/11 15:55, Martijn van Exel wrote: 1 A building object is being imported from an open public sector dataset 3 The building receives some modifications by human contributors (attributes, geometry, or both) 3 A new version of the public sector data becomes available and is imported. Currently, in step 3. the human contributions would be lost, unless each building that received community modifications is manually merged with the new import. How can we deal with this situation? Don't import anything that has a life (i.e. is continuously maintained) elsewhere. Only import stuff of which OSM then takes ownership. I don't think that will be a tenable attitude in the longer run. OpenStreetMap and public sector data (that's what we're mostly dealing with when we consider imports) will not continue to be two totally disparate entities, who have 'ownership' over the data that is in their respective databases. I foresee[1] a future reality in which the flow of information between OpenStreetMap and the public sector can be more bi-directional and also more continuous - where public bodies and OSM mutually benefit from each other's unique capabilities to maintain geodata. Enabling this would require much more elaborate version control, with smart conflict resolution. But also for much simpler situations this may be a useful thing. I don't know about you, but there have been occasions where I forgot to save my edits in JOSM only to get a conflict warning when I wanted to save the edits later. Don't get me wrong - it's great that JOSM provides the conflict resolution tools that it does, but I feel that a) this does not scale well and b) it could be simpler (read: automatic) in many cases. [1] Disclaimer: I don't have any Sylar-esque superheroic precognition capabilities. -- Martijn van Exel Senior Researcher - Geodan S&R President Kennedylaan 1 1079 MB Amsterdam (NL) - Tel: +31 (0)20 - 5711 318 Fax: +31 (0)20 - 5711 333 - E-mail: mart...@geodan.nl Website: www.geodan.nl KvK-nummer: 33 247475 Disclaimer: www.geodan.nl/disclaimer - ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to deal with versioning
> > > How can we deal with this situation? Do we need to look at distributed > version control in software development? How can methods of DVC be > adapted to deal with distributed spatial data maintenance? > > Tag each object additionally with a changeset ID (e.g: a timestamp or a sequence number). That way you can see the history of a group of changes, and do sensible conflict resolution. In the case of imports (where you know the previous changeset ID), you can then probably do a considerable amount of automatic conflict resolution. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to deal with versioning
Martijn van Exel rtijn.org> writes: >1A building object is being imported from an open public sector dataset >2The building receives some modifications by human contributors >(attributes, geometry, or both) >3A new version of the public sector data becomes available and is imported. > >Currently, in step 3. the human contributions would be lost, This is why doing an 'import' of external data is not possible, except when there is no existing data in OSM that overlaps. Rather, the external data needs to be reconciled against OSM and 'merged' rather than imported. Conflicts would usually need to be fixed manually. However, for specialized data you can tag in a separate namespace where it's generally understood that changes should be made in the upstream data source (and thus fed back to OSM in due course) rather than in OSM directly. The NaPTAN bus stop import in the United Kingdom is like this: it uses 'naptan:' tags which are not changed by mappers directly. However, that setup is not an option for bread-and-butter things like road layout and naming, where we want everybody to be able to edit the map. -- Ed Avis ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to deal with versioning
On Wednesday 01 June 2011 16:18:21 Frederik Ramm wrote: > Don't import anything that has a life (i.e. is continuously maintained) > elsewhere. > > Only import stuff of which OSM then takes ownership. That only works for stuff that is completely maintained outside or inside OSM. But it is far more likely that the external source only maintains properties A, B and C of an object, while OSM is also interested in properties 1, 2 and 3. It would be nice if we could find a way to make that practically possible. -- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to deal with versioning
Like in any other case when somebody edits OSM data its the job of whoever is doing the edit to make sure he does not destroy valuable information and is actually improving the data thats in the OSM database. This has nothing to do with distributed version control, because OSM is centralized. It just means that when a new version of some data becomes available you have to do a proper merge. And yes, it would be nice to have tools for distributed version control of geodata. For instance built upon git. But thats not the OSM way of doing things. It has been proposed a few times, but nobody came up with a coherent plan how this is supposed to work. But I do see many cases where having a distributed versioning system of geodata would be nice. It makes much sense for instance if you are not trying to create "one description of the world" (as OSM is doing), but "many different descriptions". Say you want to create a overview world map, just continents, countries, a few big cities etc. Somebody else might want to use the same map, but adds, say capital cities, even if they are small. Somebody else might do other changes. If all of this is in different git repositories that are forked from each other, changes in one map can migrate to others if the owners of those other maps like them. Jochen On Wed, Jun 01, 2011 at 03:55:29PM +0200, Martijn van Exel wrote: > Date: Wed, 1 Jun 2011 15:55:29 +0200 > From: Martijn van Exel > To: Talk Openstreetmap > Subject: [OSM-talk] How to deal with versioning > > Hi all, > Hi all, > > This came up during an import discussion on talk-nl and I am curious > about your thoughts and ideas. > > Below is an edited down version of a question I posted on the GIS > StackExchange[1]: > > We currently deal with object versioning in a rudimentary way: each > object has a integer version number, and only object with the highest > version is exposed in the live database. The database uses optimistic > locking, so users must resolve all conflicts that occur when uploading > contributions manually. > > This all works reasonably well as long as human contributions through > the editors are the only mode of contribution - but they aren't. > Increasingly, imports of open public sector data are conducted. These > make for more complex versioning issues. Consider the following > scenario: > > 1A building object is being imported from an open public sector dataset > 3The building receives some modifications by human contributors > (attributes, geometry, or both) > 3A new version of the public sector data becomes available and is > imported. > > Currently, in step 3. the human contributions would be lost, unless > each building that received community modifications is manually merged > with the new import. > > How can we deal with this situation? Do we need to look at distributed > version control in software development? How can methods of DVC be > adapted to deal with distributed spatial data maintenance? > > [1] > http://gis.stackexchange.com/questions/10493/how-to-deal-with-versioning-in-openstreetmap > > -- > Martijn van Exel > http://about.me/mvexel > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to deal with versioning
Hi, On 06/01/11 15:55, Martijn van Exel wrote: 1A building object is being imported from an open public sector dataset 3The building receives some modifications by human contributors (attributes, geometry, or both) 3A new version of the public sector data becomes available and is imported. Currently, in step 3. the human contributions would be lost, unless each building that received community modifications is manually merged with the new import. How can we deal with this situation? Don't import anything that has a life (i.e. is continuously maintained) elsewhere. Only import stuff of which OSM then takes ownership. With very, very few exceptions. Seriously. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
