Centralizando datos de archivos de forma en la base de datos

Tengo cientos de shapefiles de varios proyectos SIG diferentes que quiero comenzar a consolidar en una sola plataforma de base de datos, actualmente lo intento con Postgres / PostGIS.

Casi ninguno de los datos está estandarizado, lo que significa que son muchos de los mismos tipos de datos , pero los nombres / tipos de atributos particulares no coinciden.

¿Dónde debería comenzar a abordar esto? ¿Debería desarrollar un modelo estándar para migrar cada shapefile al primero (por ejemplo, Hydro_line, transport_line, Hydro_poly, etc.)?

Una alternativa es importar cada archivo de forma en Postgres individualmente, de modo que cada shp se convierta en una tabla en la base de datos, pero no estoy seguro de esto en términos de rendimiento y organización. Se siente como retrasar lo inevitable ...

¿Algún consejo para lidiar con esta tarea desalentadora?

Eche un vistazo a los softwares ETL espaciales (Extraer - Transformar - Cargar), están dedicados a tales tareas. El más conocido es FME de Safe, pero algunas alternativas de código abierto (parciales) ahora están disponibles, como SDI (Spatial Data Integrator) y GeoKettle .

Hola

Lo importaría primero a PostGIS. Hay herramientas para cargar múltiples formas en tablas individuales. QGIS spit extension es uno. El nuevo gráfico shp2pgsql en troncales PostGIS o binarios experimentales es otra alternativa. O simplemente podría escribir un script por lotes con shp2pgsql.

Comenzaría allí, importaría todo a un esquema llamado original o algo así. Entonces, a partir de eso, estructuraría los datos. Fusionarse en tablas donde sea adecuado, etc.

Lo bueno de hacerlo así es que si guarda todas las consultas que usa para hacer esas transformaciones, tiene una excelente documentación sobre el historial de sus datos. También es muy fácil rehacerlo si es necesario. Una vez que esté listo con su trabajo de organización, descarga una copia de seguridad de su esquema "original" y la guarda en algún lugar.

Creo que esta es una forma estructurada y limpia de hacerlo. Y como se dijo anteriormente, obtendrá una documentación muy sólida de qué campo cambió de nombre a qué nombre nuevo, y qué tablas originales se fusionaron en ese gran nuevo y así sucesivamente.

En FME y software como ese, por supuesto, también puede guardar lo que ha hecho, pero además de ser muy lento en comparación con las consultas internas de la base de datos, no es esa forma universal de documentar lo que se hace como consultas sql. Serán utilizables y legibles siempre que haya archivos de texto y bases de datos relacionales.

Solía ​​terminar con archivos de texto parecidos a:

-- A query to merge all roads in Norway

Create table road_tables.all_roads as
SELECT id as roadid, status, the_geom from original.big_roads
union all
SELECT rid as roadid, condition as status, the_geom from original.small_roads;

y así. Este archivo guardado como texto tiene un gran valor después de unos años.

Saludos Nicklas

Mi sugerencia sería elegir 2-5 de sus capas de datos más pesadas (archivos de forma) y migrarlas a un rdbms.
Investigue e implemente flujos de trabajo para esos datos. Acostumbrarse a las limitaciones y requisitos de rdbms vs datos basados ​​en archivos.

Las limitaciones incluyen: exportación requerida, zona de aterrizaje, coordsys, tipo de archivo para colaboración.

Hay muchos beneficios para lo que está proponiendo.
NOTA lateral: (Mi abuelo les dijo a mis padres que pasaran 6 meses buscando una casa antes de comprar) considere que está buscando una casa (a largo plazo) para sus datos, no quiere pagar por algo 30 años a partir de ahora que usted no me gusta

Mi recomendación sería escribir (digital o analógico) una lista de árbol de sus fuentes de datos y verlas en una imagen general, esto debería permitirle organizar los datos en agrupaciones más concisas.

Hay métodos dentro de arcgis (mi suposición: no ha especificado su sistema preferido) para integrar datos dispares.

Puede probar parte de esta información si está interesado en aprender buenas prácticas de diseño ...

Descripción general del diseño de la
geodatabase Documentación de la geodatabase
Hay algunos vínculos similares para el arco 10 también.
Centro de
recursos de la geodatabase arc10