Centraliser les données du fichier de formes dans la base de données

13

J'ai des centaines de fichiers de formes provenant de divers projets SIG différents que je veux commencer à consolider dans une plate-forme de base de données unique, essayant actuellement cela avec Postgres / PostGIS.

Presque aucune des données n'est normalisée - ce qui signifie qu'il s'agit en grande partie des mêmes types de données , mais les noms / types d'attributs particuliers ne correspondent pas.

Où dois-je commencer à résoudre ce problème? Dois-je développer un modèle standard pour migrer chaque fichier de formes en premier (par exemple Hydro_line, transport_line, Hydro_poly standards, etc.)?

Une alternative consiste à simplement importer chaque fichier de formes dans Postgres individuellement, de sorte que chaque shp devienne une table dans la base de données, mais je n'en suis pas sûr en termes de performances et d'organisation. C'est un peu comme retarder l'inévitable ...

Avez-vous des conseils pour faire face à cette tâche intimidante?

colemanm
la source

Réponses:

7

Jetez un œil aux logiciels ETL spatiaux (Extraction - Transformation - Charge), ils sont dédiés à de telles tâches. Le plus connu est FME de Safe, mais certaines alternatives open source (partielles) sont maintenant disponibles, comme SDI (Spatial Data Integrator) et GeoKettle .

Laurent Jégou
la source
2
J'ai demandé une comparaison dans une question précédente, donc si vous suivez cette voie, veuillez rédiger un article. gis.stackexchange.com/questions/5049/spatial-etl-comparisons
RyanKDalton
J'ai pris une version d'essai de FME et j'ai installé SDI et GeoKettle. Je vais les essayer et voir si je peux les comprendre. FME ressemble à une solution de soupe aux noix, mais je devrai d'abord franchir la courbe d'apprentissage :).
colemanm
1
@ colemanm- Qu'avez-vous fini par faire à ce sujet? Quel produit avez-vous trouvé le plus utile?
RyanKDalton
6

Bonjour

Je voudrais d'abord l'importer dans PostGIS. Il existe des outils pour charger plusieurs formes dans des tables individuelles. L'extension de broche QGIS en est une. Le nouveau shp2pgsql graphique dans le tronc PostGIS ou les binaires expérimentaux est une autre alternative. Ou vous pouvez simplement écrire un script batch avec shp2pgsql.

Je commencerais par là, tout importer dans un schéma appelé original ou quelque chose comme ça. Ensuite, je structurerais les données. Fusionner ensemble dans des tableaux le cas échéant et ainsi de suite.

La bonne chose à faire comme ça, c'est que si vous enregistrez toutes les requêtes que vous utilisez pour effectuer ces transformations, vous disposez d'une excellente documentation sur l'historique de vos données. Il est également très facile de le refaire si nécessaire. Une fois que vous êtes prêt avec votre travail d'organisation, vous sauvegardez une sauvegarde de votre schéma "original" et rangez quelque part.

Je pense que c'est une façon structurée et propre de le faire. Et comme dit précédemment, vous obtiendrez une documentation très solide de quel champ a changé de nom en quel nouveau nom, et quelles tables originales sont fusionnées dans ce nouveau grand et ainsi de suite.

Dans FME et des logiciels comme celui-ci, vous pouvez bien sûr également enregistrer ce que vous avez fait, mais en plus d'être très lent par rapport aux requêtes de base de données internes, ce n'est pas cette façon universelle de documenter ce qui est fait sous forme de requêtes sql. Ils seront utilisables et lisibles tant qu'il y aura des fichiers texte et des bases de données relationnelles.

J'utilise pour finir avec des fichiers texte ressemblant à quelque chose comme:

-- 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;

etc. Ce fichier enregistré sous forme de texte a une grande valeur après quelques années.

Cordialement Nicklas

Nicklas Avén
la source
1
+1 Je pense que c'est une très bonne approche. Tout est fait dans Postgres, très transparent et facilement reproductible si besoin.
underdark
1
pas une bonne recommandation pour le SIG basé sur ESRI. Open source "seulement", ce serait acceptable. ESRI a beaucoup plus de dépendances qui ne seraient pas accessibles via cette méthode. la connexion directe à postgis n'est pas autorisée sans interop, serveur gis ou arcsde.
Brad Nesom
2
@Brad Hmm, je me demande si c'est un argument qui consiste à faire les choses de manière transparente et reproductible et rapide ou un argument contre le fait de s'enfermer en mettant sde entre moi et mes données ... ;-)
Nicklas Avén
1
@Brad: colemanm n'a pas mentionné ESRI, donc la réponse semble bonne.
underdark
J'ai fait un travail similaire à celui-ci avec ESRI Sde featureclasses et SQL Server 2008 (avec géométrie native) - J'ai d'abord créé la featureclass, puis chargé avec une série d'instructions d'insertion. IIRC, j'ai dû exporter la classe de fonctionnalités à la fin vers une nouvelle classe de fonctionnalités car je ne pouvais pas générer correctement de nouveaux objectids. une fois que je l'ai fait, les affaires continuent.
Jay Cummins
4

Ma suggestion serait de choisir 2-5 de vos couches de données utilisées plus lourdes (fichiers de formes) et de les migrer vers un rdbms.
Recherchez et implémentez des workflows pour ces données. S'habituer aux limitations et exigences des rdbms vs données basées sur des fichiers.

Les limitations incluent: exportation requise, zone d'atterrissage, coordsys, type de fichier pour la collaboration.

Il y a beaucoup d'avantages à ce que vous proposez.
Côté NOTE: (Mon grand-père a dit à mes parents de passer 6 mois à chercher une maison avant d'acheter) considérez que vous cherchez une maison (à long terme) pour vos données, vous ne voulez pas payer quelque chose dans 30 ans à partir de maintenant que vous n'aime pas.

Ma recommandation serait d'écrire (numérique ou analogique) une liste arborescente de vos sources de données et de les visualiser dans une vue d'ensemble, cela devrait vous permettre d'organiser les données en groupes plus concis.

Il existe des méthodes dans arcgis (mon assupmtion: vous n'avez pas spécifié votre système préféré) pour intégrer des données disparates.

Vous pouvez essayer certaines de ces informations si vous souhaitez apprendre les bonnes pratiques de conception ...

présentation de la conception de la
géodatabase documentation de la géodatabase
Il existe également des liens similaires pour l'arc 10.
Centre de
ressources géodatabase arc10

Brad Nesom
la source