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

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?

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 .

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

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