¿Cómo lidiar con el versionado en OpenStreetMap?

El tema de la gestión de datos geoespaciales en un sentido más general ha surgido antes aquí. El tema de las versiones también se mencionó allí, pero no se trató realmente.

La recopilación y el mantenimiento de datos geoespaciales tradicionales solo tienen que ocuparse de las versiones internas, ya que la base de datos solo se actualiza desde dentro de la organización. Este no es el caso en geodatabases de crowdsourcing como OpenStreetMap. Allí, cualquiera puede venir y agregar, modificar o eliminar objetos. En OpenStreetMap, esto se trata de manera rudimentaria: cada objeto tiene un número de versión entero, y solo el objeto con la versión más alta está expuesto en la base de datos en vivo. La base de datos utiliza un bloqueo optimista, por lo que los usuarios deben resolver todos los conflictos que ocurran al cargar contribuciones manualmente.

Todo esto funciona razonablemente bien siempre que las contribuciones humanas a través de los editores ( JOSM , Potlatch ) sean el único modo de contribución, pero no lo son. Cada vez más, se realizan importaciones de datos abiertos del sector público. Esto genera problemas de versiones más complejos. Considere el siguiente escenario:

1. Se está importando un objeto de construcción desde un conjunto de datos abierto del sector público
2. El edificio recibe algunas modificaciones por parte de colaboradores humanos (atributos, geometría o ambos)
3. Una nueva versión de los datos del sector público está disponible y se importa.

Actualmente, en el paso 3. las contribuciones humanas se perderían, a menos que cada edificio que recibió modificaciones de la comunidad se fusione manualmente con la nueva importación.

¿Cómo puede OpenStreetMap lidiar con esta situación? ¿Necesitamos analizar el control de versiones distribuidas en el desarrollo de software? ¿Cómo se pueden adaptar los métodos de DVC para hacer frente al mantenimiento de datos espaciales distribuidos?

He soñado con alguien que implemente la edición no destructiva de datos SIG. Es intensivo en cómputo, pero no debería ser difícil de implementar en un RDBMS.

Comience con una instantánea de los datos. Los cambios se guardan como ediciones, los datos originales permanecen sin cambios. En su ejemplo, los edificios provienen inicialmente de los datos del sector público. Cuando un usuario realiza una edición, el cambio o la diferencia se guardan en una tabla separada. Cuando alguien ve la función, se le da el original más cualquier edición aplicada. Las ediciones posteriores son la diferencia calculada entre la nueva forma de entidad y el original más todas las ediciones anteriores.

Esto le da la capacidad de deshacer en un nivel de grano fino. Es esencialmente lo que hace el control de versiones. Un buen ejemplo de edición no destructiva es Aperture de Apple. Las imágenes digitales importadas en Aperture no se modifican directamente. Los cambios en los niveles, nitidez, desenfoque, etc. se almacenan como ediciones y se aplican sobre la marcha cuando trabaja con una imagen. Cualquier cambio puede eliminarse instantáneamente.

Por supuesto, tomaría instantáneas de la base de datos para su distribución y uso en entornos de producción. Esto sería solo para desarrollo y edición.

Eche un vistazo a Versioning PostGIS , pgVersion y Post Facto para obtener ideas y posibles soluciones. Estos son sistemas de control de versiones implementados en bases de datos PostgreSQL.

OSM usa Postgres y Postgis que mantiene una instantánea de la base de datos.

Para implementar esto en su propio servidor y base de datos

http://wiki.openstreetmap.org/wiki/Databases#Choice_of_DBMS

La base de datos (plantet.osm) se actualiza semanalmente http://wiki.openstreetmap.org/wiki/Planet_dump

La ósmosis está acostumbrada a"tiene componentes para leer de la base de datos y del archivo, componentes para escribir en la base de datos y en el archivo, componentes para derivar y aplicar conjuntos de cambios a las fuentes de datos"

http://wiki.openstreetmap.org/wiki/Osmosis

Changsets: http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#Changeset_Derivation_and_Merging

Pensé en este problema y tuve una idea, pero no la probé. Podría funcionar:

Utilice el sistema de control de versiones como Mercurial o Git. Mercurial será más fácil, ya que permite crear fácilmente ramas anónimas.

Ahora, desde la revisión inicial, inicie una rama para las importaciones de conjuntos de datos públicos. Entonces, habrá 2 ramas:

1. línea principal (OSM)
2. conjunto de datos público X

Una importación desde el conjunto de datos público debe hacerse en la rama 2, luego fusionarse en la rama OSM.

Su escenario podría funcionar así:

• un objeto no existía
• luego se importa y se fusiona en la rama 1
• luego se modifica en la línea principal, incluida la geometría
• se importa nuevamente en la rama 2
• cuando se fusiona en la rama 1, solo los datos que se actualizaron en la rama 2 se actualizan en la rama 1

Esto podría requerir dividir los datos en múltiples archivos, uno por objeto y probablemente en un formato como json, para que VCS pueda manejar fácilmente los cambios en atributos separados.

{
     id: 1357
     lat: 1,
     lon: 2,
     tags: {
          'building': 'entrance'
     }
     type: 'node',
}
{
     nodes: [
         1357,
         2468
     ],
     tags: {
         building: 'yes',
     }
     type: 'way',
}

Sé que dividir una información en mil millones de archivos es demasiado para cualquier sistema. En su lugar, se debe usar el núcleo de VCS y los datos de OSM deben procesarse y alimentarse a VCS de forma versionable. (O un sistema de archivos puede ser burlado).

No puedo garantizar que esto funcione.