¿Administrar grandes cantidades de datos geoespaciales? [cerrado]

¿Cómo gestiona sus datos geoespaciales? Tengo terabytes de datos distribuidos en cientos de conjuntos de datos, y tengo una solución ad-hoc que utiliza enlaces simbólicos dentro de proyectos que se vinculan a un directorio de archivo basado en el nombre de dominio para cada conjunto de datos. Esto funciona principalmente, pero tiene sus propios problemas.

También me gustaría saber si alguien maneja sus datos geoespaciales en un sistema de control de revisión; Actualmente uso uno para mi código y conjuntos de datos pequeños, pero no para conjuntos de datos completos.

Creo que la respuesta común / obvia sería usar una base de datos espacial (PostGIS, Oracle, SDE, MSSQL Spatial, etc.) junto con un servidor de metadatos como GeoPortal de esri o la aplicación GeoNetwork de código abierto, y en general creo que esto es generalmente la mejor solucion. Sin embargo, es probable que siempre tenga la necesidad de instantáneas / ramas / etiquetas basadas en proyectos. Algunas de las bases de datos más avanzadas tienen formas de administrarlas, pero generalmente no son tan fáciles de usar / administrar.

Para las cosas que almacena fuera de una base de datos (imágenes grandes, archivos basados ​​en proyectos), creo que la clave es tener una convención de nomenclatura consistente y nuevamente un registro de metadatos (incluso algo de baja tecnología como una hoja de cálculo) que le permita rastrearlos y asegúrese de que se gestionen adecuadamente. Por ejemplo, en el caso de los archivos basados ​​en proyectos, esto puede significar eliminarlos cuando lo dicta la política de gestión de registros, o pasarlos al repositorio central al finalizar el proyecto.

Aunque he visto algunas soluciones interesantes ...

Cuando el Ministerio de Medio Ambiente de Columbia Británica estaba eliminando las coberturas de Arc / Info, tenían un proceso de sincronización bidireccional basado en rsync realmente genial. Las coberturas que estaban bajo control central se enviaban a las regiones todas las noches, y los datos regionales se volvían a introducir. Esta transferencia diferencial a nivel de bloque funcionó realmente bien, incluso a través de 56k enlaces. Hubo procesos similares para replicar las bases de datos de atributos basadas en Oracle, pero no creo que lo hicieran demasiado bien con el acceso telefónico :)

Mi lugar de trabajo actual utiliza una solución híbrida similar. Cada conjunto de datos tiene su copia autorizada (algunos en Oracle, otros en MapInfo, otros en geodatabases personales) y estos son cruzados ETL todas las noches usando FME. Sin embargo, hay algunos gastos generales bastante importantes aquí cuando se trata de mantenimiento; El esfuerzo para crear cualquier nuevo conjunto de datos y garantizar la visibilidad de la organización es considerablemente mayor de lo que debería ser. Estamos en el proceso de una revisión destinada a encontrar alguna forma de consolidación para evitar esta sobrecarga.

Los metadatos son, con mucho, el problema más importante aquí. Si los metadatos responden a quién, cuándo, por qué, dónde es un registro de metadatos aceptable.

Al tener experiencia laboral en grandes empresas con solo unos pocos usuarios de SIG (alrededor de 30), tuvimos problemas importantes para controlar los datos, especialmente las versiones y los permisos. Un lado de esto se puede resolver con una extensa documentación de datos (metadatos) y los otros problemas probablemente se resuelven con un repositorio central, en el que brilla PostGIS.

GeoNetwork es un buen comienzo para manejar problemas de metadatos. Resolver el repositorio central es más complicado, ya que puede necesitar una persona especializada para diseñar / mantener la base de datos.

El problema complicado es quién estará a cargo de QA / QC de estos conjuntos de datos y sus metadatos. Aunque los procesos impulsados ​​por computadora funcionan muy bien, no pueden ser tan rigurosos como un buen administrador de datos / guardián de datos, que se hizo en esta empresa en la que trabajé. Ahora hay alguien exclusivamente allí para revisar / confirmar metadatos y organizar datos geoespaciales que no están centralizados en un DBMS.

Hemos utilizado un sistema de archivos organizado jerárquicamente por: - extensión geográfica (país o continente) - proveedor de datos, licenciante - dominio / conjunto de datos - fecha / versión

Después de eso, tenemos una política para separar los datos de origen (en el mismo formato que estaba en cualquier CD / DVD que obtuvimos del proveedor) de los conjuntos de datos derivados que produjimos dentro de nuestra empresa.

El sistema de archivos hace que sea muy fácil ingerir cualquier información del cliente y también permite cierta flexibilidad en términos de almacenamiento físico: mantenemos nuestros archivos en discos más grandes y más lentos y tenemos servidores de archivos especiales (vinculados de forma transparente a la jerarquía) para los conjuntos de datos usados ​​con más frecuencia.

Para facilitar la gestión dentro de los proyectos, utilizamos enlaces simbólicos. Mantenemos nuestros vectores en una base de datos (Oracle) y hacemos una regla tener al menos una instancia de base de datos por cliente (y varios usuarios / esquemas para los proyectos). Sin embargo, no hemos mantenido muchos rásteres en una base de datos, ya que tienden a ocupar demasiado espacio incluso fuera de uno. Además, nos gusta mantener nuestras instancias de base de datos lo más livianas posible.

Y sí, tenemos a alguien a cargo de "vigilar" todo para que no se vuelva demasiado complicado.

El mayor problema que tenemos actualmente con esta configuración es la falta de una interfaz de usuario agradable que nos ayude a tener una mejor visión general de todo el asunto, y hemos planeado incluir un almacenamiento de metadatos además de todo eso. Todavía estamos considerando nuestras opciones aquí.

Estamos usando el control de versiones para nuestro código y lo hemos usado para documentos, pero resulta que el control de versiones no está realmente hecho para grandes conjuntos de datos, especialmente si son principalmente archivos binarios, por lo que no recomendaría que , excepto si se trata de GML o algo similar a un texto (los problemas incluyen grandes gastos generales en el uso del disco del lado del servidor, así como los clientes que fallan al retirar grandes repositorios).

Como dijo @JasonBirch, el control de versiones es un gran problema.

También hemos descubierto que un flujo de trabajo apropiado es sumamente importante. Por ejemplo, cuando recopilamos datos de campo, tendemos a usar bases de datos de ensayo donde los datos de campo se pueden controlar antes de fusionarlos en el conjunto de datos maestro. Sin embargo, dependiendo de la cantidad de datos que se deban controlar, esto siempre generará algunos gastos generales.

Además, si no lo ha visto, le recomiendo que eche un vistazo al libro electrónico de Geocomunicación y diseño de información de Lars Brodersen, al menos para ver algo de lo que tiene que decir sobre el modelado de datos.

Postgres todo el camino como han dicho otros, sin embargo, si desea mantenerlo portátil y fácil de mover, siempre puede mirar usando SQLite + la extensión Spatialite.

No es tan fácil de usar como Postgres en términos de herramientas de gestión, pero QGis PUEDE comunicarse directamente con una base de datos GIS habilitada para espacializar sin ningún problema.

De hecho, uso SQLite + Spatialite para la copia de seguridad, tengo un servicio de Windows que se ejecuta en segundo plano (personalizado) que monitorea mi instancia de PGSql y refleja mis datos SIG en varios DB de SQLite que residen en unidades USB externas.

Un consejo más con PG también, usa esquemas

Mucha gente que conozco simplemente deja todo en "público" y termina, pero si organizas tu base de datos correctamente, hace la diferencia.

Por ejemplo, mi base de datos "Ordnance_Survey" tiene esquemas para VectormapDistrict VectormapLocal Topo50 LookupGrids CodePointWithPolygons CodePointOpen

donde guardo todos los datos asociados.

Mientras tanto, las tablas de metadatos, como las columnas de geometría, etc., solo viven en Public, la extensión Postgis también solo está habilitada en el esquema público, pero es accesible desde todos los otros esquemas en uso.

Como se menciona en la publicación anterior, las bases de datos espaciales y un servidor de metadatos son la configuración habitual. Creo que una cosa clave para recordar es que 'una talla no sirve para todos'. Terminará con los datos que mejor se adapten a Oracle, servidores de archivos, servidor SQL, lo que sea. He intentado poner todas las necesidades de datos en una sola solución y generalmente falla.

Espere utilizar diferentes soluciones que se ajusten a los datos y planifiquen para ellos. Aquí es donde realmente entra el Geo-portal (servidor de metadatos).

Tengo que estar de acuerdo con 'George' arriba en que los metadatos deberían desempeñar un papel importante en la gestión de datos geoespaciales. Realmente con cualquier dato digital, los metadatos son clave: piense en un fotógrafo que intenta administrar sus archivos de fotos digitales sin metadatos adecuados. La vida se vuelve mucho más fácil si etiqueta las cosas religiosamente y tiene un buen software que puede utilizar los datos. Ahora la pregunta original sobre 'administrar datos geoespaciales' es bastante amplia: podrían ser formatos de datos para almacenar, convenciones de nombres, jerarquía de conjuntos de datos y características, funciones y privilegios de edición, etc., etc.

El patrón de almacenamiento de datos geoespaciales depende de cómo desea consultarlo / qué desea hacer con él. Las siguientes son algunas herramientas que puede considerar:

Postgres + PostGIS: admite índices geoespaciales y todo tipo de consultas que puedas imaginar. Para administrar sus terabytes de datos, deberá aplicar fragmentación, optimización de consultas, etc. Si su carga de escritura es pesada, no lo recomendaría.

MongoDB: esto admite grandes cantidades de datos. Ideal para almacenamiento simple, recuperación y consultas geoespaciales limitadas.

Almacenamiento de archivos: si en realidad solo es un sistema de archivo y usa solo una parte de los datos para realizar consultas, puede ser económico almacenar sus datos como archivos. Su requisito de control de versiones podría estar bien satisfecho con esto.

Redis: puede combinar cualquiera de las opciones anteriores con el soporte de Redis Geo para almacenar una pequeña cantidad de datos 'calientes' en redis a los que necesita acceder con frecuencia. Piensa en esto como tu caché.