¿Implementa el sistema de control de versiones para datos geoespaciales? [cerrado]

No es que tenga una necesidad inmediata de una respuesta correcta aquí, pero últimamente he visto algunos esfuerzos para introducir el concepto de "sistemas de control de versiones (distribuidos)" para datos geográficos. Algunos ejemplos (que yo sepa) son los tres libros blancos de OpenGeo ( 1 , 2 y 3 ) y el proyecto " Geosynkronisering (geosyncronization)" de los vendedores noruegos de software GIS y la Agencia Noruega de Mapeo. ¿También he encontrado versiones distribuidas de datos geoespaciales? , que menciona GeoGit (por OpenGeo) y Aplicación de control de versiones a los modelos de ArcGIS ModelBuilder? sobre el control de versiones en ArcGIS.

Como desarrollador, sé (al menos lo suficiente como para poder usarlos) cómo funcionan los sistemas de control de versiones para el código fuente (como SVN y Git), y mi experiencia en geomática me dice que existen algunos desafíos únicos con los datos geográficos que hacen que enfoque no completamente similar a la forma en que se maneja el código fuente (que es básicamente texto).

¿Cuáles son los desafíos cuando se trata con (d) VCS para datos geográficos, cómo los resolvería, los necesitamos y hay otros intentos de resolver estos problemas además de los que he mencionado?

Sé que los documentos técnicos de OpenGeo responderán algunas de mis preguntas, pero lo que realmente busco es una respuesta más "pedagógica", al estilo de "dime como si tuviera 10 años", de modo que Puedo recomendar a las personas una gran explicación de los desafíos y las soluciones que los datos geográficos aportan a la mezcla.

Espero que alguien con alguna idea se tome el tiempo para dar algunas ideas al respecto, ya que dije que actualmente no estoy buscando resolver un problema en particular, pero este tema es uno que me interesa.

Actualmente estamos trabajando en un rediseño completo de nuestras geodatastores. Tengo que decir que su evolución llevó más de 20 años hasta ahora. Identificamos las siguientes características clave en la gestión de datos geoespaciales:

• edición simultánea
• permisos para leer o escribir porciones de datos
• actualización en caliente al ejecutar servicios que dependen de datos (Transacciones y paradigma ACID)
• esquema interno y externo (modificar el esquema interno no debería afectar los servicios)
• capacidad de almacenar y acceder a grandes cantidades de datos (terabytes de ráster y cientos de gigabytes de datos vectoriales)
• consistencia de datos entre diferentes capas (cada parcela pertenece a un distrito, etc.)

Evaluamos los siguientes enfoques, esto es lo que puedo decir sobre ellos:

1. Geodatabase Enterprise de ESRI(ArcGIS 10.1); más o menos lo mismo que teníamos antes (SDE), pero con un amplio uso de la función de control de versiones para manejar transacciones. Pero simplemente no es realmente una geodatabase corporativa, en mi opinión, SDE solo funciona en un grupo de trabajo como un servidor de geodatos, donde las personas trabajan de 8:00 a.m. a 8:00 p.m., y puede desconectarlo para tareas de mantenimiento, confirmación de transacciones (conciliación de versiones y publicación en voz ESRI), replicación, etc. Si crea servicios sobre estos datos, debe manejar una base de datos provisional (donde se realiza el trabajo) y una base de datos de producción replicada. Esto es más o menos lo mismo que construir / probar e implementar en la programación. Si bien el paquete rico en funciones que ofrece ESRI es bastante bueno, carece de flexibilidad (cambios de esquema o tareas de mantenimiento mientras las personas trabajan, por ejemplo, la creación de índices).

2. Archivos planos y un sistema de control de versioneselegimos Git (no sabía que ya hay un GeoGit). Ah, sí, algunos de mis amigos y yo también venimos de la ingeniería de software. Todo podría ser tan simple. Creo que ese es su problema: es como un mecánico de automóviles construyendo un automóvil. Será fácil de mantener para él, pero también será molesto conducir y muy feo mirarlo con seguridad. Creo que también tiene algunas desventajas importantes: ¿Cómo controlar la versión de un Rasterdataset 2 TeraByte (o incluso más, binario)? ¿Y en qué formato? Los datos vectoriales se pueden controlar fácilmente si se utilizan formatos basados ​​en texto (GML, por ejemplo), pero también es difícil trabajar con un conjunto de datos de mil millones de filas. Todavía no estoy seguro de si podemos hacer una gestión efectiva de permisos de usuario, porque no todos deberían poder editar o incluso ver todo. ¿Y cómo se combina un conjunto de datos vectoriales que fue editado intensamente por 4 usuarios al mismo tiempo? Al menos tienes que ser un verdadero informático / programador para hacer todo esto de manera efectiva ... nuestros usuarios de SIG son planificadores, agrimensores, geólogos, etc. Simplemente es un problema para ellos pensar en linajes de versiones como lo hacen los programadores, o usar la ramificación de la forma en que se supone que debe hacerlo. Sin embargo, pensar en los almacenes de datos como repositorios compartidos es una idea interesante.

3. Base de datos de tabla plana como un contenedor simple. Lo mismo que SDE lo hace, pero sin las cosas de SDE. Todavía es difícil de mantener, porque en realidad no hace uso de las ventajas que le ofrece un RDBMS. Sí, es muy simple cargar todo en una base de datos, pero eso no es en absoluto la gestión de datos.

4. Bigdata y NoSQL . Los mismos problemas que los archivos planos y las tablas planas. En mi opinión, una API de sistema de archivos simple para usar en la web. Sí, funciona bien en la web, y sí, es fácil simplemente lanzar sus documentos, pero creo que si quiero realizar un análisis de datos espaciales en terabytes de datos (posiblemente ráster), me gusta que no se serialice y deserialice sobre la interfaz HTTP.

ACTUALIZACIÓN 2018: Aquí hay muchas cosas nuevas que crean un gran impulso. Para nombrar unos pocos:

• Almacenamiento en bloque en la nube y HDFS
• Python / bien proporcionado / pila de Dask

• Apache Spark

  • GeoMesa / GeoWave para datos vectoriales
  • GeoTrellis para datos ráster

• y mucho más

  5. Modelado completo de bases de datos clásicas(con un RDBMS). El principal problema es que es difícil simplemente dejar caer datos en cualquier lugar y esperar que se ajuste a cada necesidad futura. Pero si dedica una cantidad de tiempo para especificar un modelo de datos robusto (OSM también hizo esto de hecho) en una base de datos, puede aprovechar todas sus ventajas. Podemos editar y actualizar datos en transacciones distribuidas, también podemos modificar su esquema principal, mientras que los servicios aún dependen de esquemas externos de los mismos datos, podemos mantenerlos, podemos verificar su consistencia, podemos permitir y denegar permisos, estamos capaces de almacenar grandes cantidades de datos mientras aún podemos acceder a ellos de manera rápida, podemos construir modelos de datos históricos y activarlos de forma transparente, etc. Debido a que utilizamos el servidor SQL, todavía nos falta un tipo de ráster nativo, pero otros proveedores de bases de datos ya lo ofrecen.

Bueno, creo que el modelo de base de datos relacional acaba de surgir en el mundo espacial con tipos de datos espaciales en los últimos años (antes de eso, donde BLOB Containers) y sigue siendo la forma más flexible y profesional de almacenar datos. Eso no significa que no deba complementarse con enfoques VCS o NoSQL, pero veo estos enfoques más probablemente como una forma de distribución de datos en grupos de usuarios que como una forma de gestión de datos espaciales centralizada profesional. Además, OSM ha centralizado muchas tareas, que la multitud simplemente no puede proporcionar, como importar grandes cantidades de datos (la mayoría de los datos de OSM en Austria se importaron en un día, no de crowdsourcing) y la generación de mosaicos. La parte de colaboración (crowdsourcing) es muy importante, pero es solo la mitad del negocio.

Creo que tengo que reformular mucho de esto y proporcionar más datos. Una pregunta como esta es difícil de responder exhaustivamente en un par de horas, intentaré mejorar la calidad de mi respuesta los próximos días