¿Gestionando grandes cantidades de datos geoespaciales? [cerrado]

82

¿Cómo gestionas tus 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 nombre de dominio para cada conjunto de datos. Esto funciona principalmente, pero tiene sus propios problemas.

También me interesa escuchar si alguien administra sus datos geoespaciales en un sistema de control de revisiones; Actualmente utilizo uno para mi código y conjuntos de datos pequeños, pero no para conjuntos de datos completos.

    
pregunta scw 15.10.2015 - 06:46

8 respuestas

51

Creo que la respuesta obvia / obvia sería utilizar una base de datos espacial (PostGIS, Oracle, SDE, MSSQL Spatial, etc.) junto con un servidor de metadatos como el GeoPortal de Esri o la aplicación de GeoNetwork de código abierto, y en general creo Esta es generalmente la mejor solución. Sin embargo, es probable que siempre tenga una necesidad de snapshots / branch / tags basados 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 coherente y nuevamente un registro de metadatos (incluso algo de baja tecnología como una hoja de cálculo) que le permita Rastrearlos y asegurarte de que estén bien administrados. Por ejemplo, en el caso de archivos basados en proyectos, esto puede significar eliminarlos cuando lo exija la política de administración de registros, o incluirlos en el repositorio central cuando finalice el proyecto.

Aunque he visto algunas soluciones interesantes ...

Cuando el Ministerio de Medio Ambiente de BC estaba ejecutando cosas fuera de las coberturas de Arc / Info, tenían un proceso de sincronización bidireccional basado en rsync realmente genial en su lugar. Las coberturas que estaban bajo el control central se enviaron a las regiones cada noche, y los datos regionales se devolvieron. Esta transferencia diferencial a nivel de bloque funcionó muy bien, incluso en enlaces de 56k. Hubo procesos similares para replicar las bases de datos de atributos basadas en Oracle, pero no creo que, por lo general, funcionaran 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 ETN cruzados todas las noches usando FME. Sin embargo, hay una sobrecarga bastante importante aquí cuando se trata de mantenimiento; el esfuerzo por crear cualquier conjunto de datos nuevo 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 una forma de consolidación para evitar esta sobrecarga.

    
respondido por el JasonBirch 04.08.2010 - 10:00
22

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

Teniendo 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. Una parte de esto se puede resolver con una extensa documentación de los datos (metadatos) y los otros problemas probablemente se resuelvan con un repositorio central, en el que PostGIS brilla.

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

El problema complicado es quién estará a cargo de QA / QC, estos conjuntos de datos y sus metadatos. Aunque los procesos controlados por computadora funcionan bien, no pueden ser tan rigurosos como un buen administrador de datos / guardián de datos, lo cual se hizo en esta compañía 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.

    
respondido por el George Silva 06.08.2010 - 18:20
11

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 el CD / DVD que obtuvimos del proveedor) de cualquier conjunto de datos derivados que produjimos dentro de nuestra empresa.

El sistema de archivos hace que sea realmente fácil ingerir los datos 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 en el jerarquía) para los conjuntos de datos de uso más frecuente.

Para facilitar la gestión dentro de los proyectos, usamos enlaces simbólicos. Mantenemos nuestros vectores en una base de datos (Oracle) y establecemos como 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 ellos. Además, nos gusta mantener las instancias de nuestra base de datos lo más livianas posible.

Y sí, tenemos a alguien a cargo de 'vigilar' todo el asunto para que no se ensucie demasiado.

El mayor problema que tenemos con esta configuración actualmente es la falta de una interfaz de usuario agradable que nos ayude a tener una mejor visión general de todo esto, y hemos estado planeando incluir un almacenamiento de metadatos por encima 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á hecho para grandes conjuntos de datos, especialmente si son en su mayoría archivos binarios, por lo que no lo haría. Recomiende eso, excepto si está tratando con GML o algo parecido a un texto (los problemas incluyen grandes gastos generales en el uso del disco del lado del servidor, así como que los clientes se bloqueen al revisar grandes repositorios).

    
respondido por el mkadunc 09.08.2010 - 01:40
6

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

También hemos encontrado que un flujo de trabajo apropiado es muy importante. Por ejemplo, cuando recopilamos datos de campo, tendemos a utilizar bases de datos provisionales donde los datos de campo pueden ser QA antes de ser combinados en el conjunto de datos maestro. Sin embargo, dependiendo de la cantidad de datos que se necesiten para el control de calidad, esto siempre generará cierta sobrecarga.

Además, si no lo has visto, te recomiendo que eches un vistazo al Geo-comunicación y diseño de información ebook por Lars Brodersen, al menos por algo de lo que tiene que decir sobre el modelado de datos.

    
respondido por el om_henners 11.08.2010 - 01:37
5

Postgres hasta el final, 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 administración, pero QG puede PUEDE hablar directamente con una base de datos GIS habilitada por spatialite sin ningún problema.

En realidad uso SQLite + Spatialite para hacer copias de seguridad, tengo un servicio de Windows que se ejecuta en segundo plano (Escrito a medida) que supervisa mi instancia de PGSql y refleja mis datos GIS en varios DB de SQLite que residen en unidades USB externas.

Un consejo más con PG también, use schemas

Muchas personas que conozco simplemente dejan todo en "público" y terminan con esto, pero si organizas tu base de datos correctamente, el mundo de la diferencia es excelente.

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 de Postgis también está habilitada solo en el esquema público, pero es accesible desde todos los otros esquemas en uso.

    
respondido por el shawty 23.06.2014 - 10:09
4

Como se menciona en las publicaciones anteriores, las bases de datos espaciales y un servidor de metadatos son la configuración habitual. Creo que una cosa clave a recordar es que "una talla no se ajusta a todas". Terminará con los datos que mejor se adapten a Oracle, servidores de archivos, servidores SQL, lo que sea. He intentado calzar todas las necesidades de datos en una solución y generalmente falla.

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

    
respondido por el Laine 06.08.2010 - 00:00
2

Estoy de acuerdo con 'George' en que los metadatos deben desempeñar un papel importante en la gestión de datos geoespaciales. Realmente, con cualquier dato digital, los metadatos son la clave: piense en un fotógrafo que intente 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 acerca de 'administrar datos geoespaciales' es bastante amplia: podrían ser formatos de datos para almacenar, convenciones de nomenclatura, jerarquía de conjuntos de datos y características, roles de edición y privilegios, etc. etc.

    
respondido por el Kevin 09.08.2010 - 14:37
1

El patrón de almacenamiento para datos geoespaciales depende de cómo desea consultarlos / qué quiere hacer con ellos. A continuación hay 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 alta, no lo recomendaría.

MongoDB: Esto soporta 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 versión 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. Piense en esto como su caché.

    
respondido por el Amit Rathi 31.08.2017 - 11:43

Lea otras preguntas en las etiquetas