Organisation et ordre de plusieurs copies de couches? [fermé]

À l'époque où j'étais à l'université, j'avais un problème "d'organisation et de rangement" - je n'étais pas organisé et je gardais mes calques dans des dossiers différents sans noms distincts et j'avais donc plusieurs copies de chaque calque.

Depuis que j'ai commencé à travailler, je me suis beaucoup amélioré - je garde des dossiers spéciaux avec des sous-dossiers spéciaux. Je nomme mes couches selon un système qui me permet d'être un peu plus soigné, mais comme je dois encore gérer plusieurs copies de couches (comme Autocad et ArcGIS ont leurs différences dans les langues non latines, je dois en garder une copie ajusté pour chaque programme), je voudrais entendre vos expériences et peut-être apprendre quelques conseils de votre part:

1. Comment organisez-vous vos calques? Comment les nommez-vous? Par nom, date, contenu, client?
2. Comment organiser ou gérer plusieurs copies (plus aigu: comment mettre à jour plusieurs copies à la fois)?

Remarque: je parle du PDV analyste / DBA et non du POV d'un développeur / gestionnaire Web (je parle d'organiser les couches pour moi-même et peut-être deux autres travailleurs SIG, pas plus).

Ceci est un mauvais problème . Nous avons essayé divers systèmes, qui ont tous fonctionné à des degrés divers pendant un certain temps, et qui se sont finalement compliqués et ont commencé à se désagréger à mesure que l'on rencontre de plus en plus de cas marginaux qui ne correspondent pas tout à fait. Cela dit, chacun des systèmes que nous avons utilisés est bien meilleur que rien, ce qui prouve la maxime que tout système est meilleur qu'aucun système.

Voici un aperçu miniature de notre pratique actuelle:

Placez tout sauf les rasters dans une géodatabase fichier, moins il y en a, mieux c'est. Ne pas imbriquer des classes d'entités dans des ensembles de données d'entités, sauf si elles sont liées d'une manière ou d'une autre (par exemple, hydro> ruisseaux, hydro> lacs, hydro> zones humides, etc.). Cela conduit à une longue longue liste en haut de la fgdb mais c'est un mal acceptable.

Créez des fichiers de couches pour toutes les classes d'entités et organisez-les à la place, ce qui donne beaucoup de liberté pour nommer selon les besoins, en utilisant des caractères non pris en charge, etc. *, et la possibilité de se déplacer et de renommer en fonction des circonstances. Il permet également la duplication sans redondance, par exemple un ensemble de couches regroupées selon l'échelle nominale (50k, 250k ...), une autre par région (AK, YT ...), une troisième par thème (caribou, utilisation des sols, transport ...), et un quatrième par client alors que le magasin de données lui-même reste inchangé.

Pour les doublons, utilisez des raccourcis au lieu des fichiers de calque eux-mêmes, sinon il y a trop de choses à mettre à jour lorsque les choses changent. Configurez ArcCatalog pour afficher les raccourcis: * Outils> Options> types de fichiers: .lnk (Limitations: l'aperçu et les métadonnées ne fonctionnent pas, vous ne pouvez pas suivre le raccourci vers sa source dans ArcCatalog. Cela peut être résolu en utilisant des liens symboliques au lieu de raccourcis , voir Link Shell Extension )

* (conseil: ajoutez le dossier Layers en tant que barre d'outils du menu Démarrer afin qu'ils soient toujours à portée de main.)

Z: \ Couches \
          Base\
          Thématique\
          Référence\
          Base toute garnie (250k) .lyr
          Limites d'administration (1000k) .lyr
          ...
Z: \ Raster \
          Landsat \
          Orthos \
Z: \ Data \
        Foo_50k.gdb
        Foo_250k.gdb
        NoScale.gdb

Les compositions cartographiques et les sorties (fichiers d'impression, pdf, exportations, etc.) qui par nature sont plus dynamiques et variables sont stockées et organisées différemment ailleurs. C'est la partie qui a été la plus difficile pour nous. Nous utilisons actuellement un lecteur dédié avec des dossiers nommés en fonction du Job # (en recommençant, j'utiliserais plutôt la date, '2010-10-26' ) et des sous-dossiers pour les données spécifiques au projet et les résultats / délibérables. Un index de feuille de calcul répertorie tous les numéros de tâche (nom du dossier), leurs titres de carte correspondants et le client. Ex:

W: \ Foo_0123 \
            Foobarmap_001.mxd
            Documents \
                 ReadMe.doc
            Les données\
                 buffers_2000m.shp
                 gps_tracks.csv
            Sortie\
                   Foobarmap_001.pdf
            Livrables

La mise à jour de l'index est un point de friction, les gens n'aiment pas le faire, l'évitent et ne sont pas cohérents avec le nom, etc. (l'utilisation d'une base de données au lieu d'une feuille de calcul aiderait). L'utilisation d'une convention de nom de dossier numérique rend également très difficile la cartographie du projet X sans l'index, une autre source notable de friction. Idéalement, l'index serait une page html cliquable qui est automatiquement générée à partir d'une application db. C'est tout un autre projet cependant.

Les principes clés:

• séparer les éléments changeant lentement et souvent réutilisés des éléments dynamiques et variables et les traiter différemment
• Ne dupliquez pas inutilement, utilisez des fichiers de couches et des raccourcis / liens dans la mesure du possible.
• ne changez pas les systèmes trop fréquemment, essayez chacun de vous.

Je me réjouis vivement des exemples d'autres structures, comme je l'ai dit, nous ne sommes pas satisfaits de ce que nous avons. :)

Si d'autres personnes accèdent aux données de votre système, vous ne pouvez pas rendre le schéma d'organisation significatif uniquement pour vous-même; vous devez garder à l'esprit leur utilisation du système. Si vous ne les considérez pas, vous passerez beaucoup de temps à répondre à des questions telles que "où sont les données sur l'utilisation des terres" et "pourquoi ne puis-je pas trouver [insérer l'ensemble de données ici]?"

En maintenant un tel système pendant de nombreuses années, j'ai constaté que les gens ne peuvent pas trouver de données si elles sont d'abord organisées par source, par exemple c:\CensusBureau\Roadset c:\ESRI\Countries. Au lieu de cela, je recommande de répertorier les données par thème d'abord, puis par source au cas où vous avez plusieurs sources, par exemple c:\Roads\CensusBureauet c:\Roads\LocalGovt.

De même, je ne séparerais pas les rasters et les vecteurs dans différents répertoires. Cependant, il peut être nécessaire de les diviser sur différents lecteurs physiques ou logiques si vous avez beaucoup de données raster qui ne tiennent pas sur un lecteur.

Je recommande la structure de répertoires suivante. Theme \ SourceYear, où Theme est la couche thématique, Source est un nom abrégé pour la source de données et Year est l'année que les données représentent au sol. Dans ce scénario, les routes TIGER du Bureau du recensement seraient situés dans \Roads\Census00et \Roads\Census10(ou remplacer « Recensement » avec « TIGER »).

Sachez que certaines extensions d'ArcGIS ne fonctionnent pas avec des noms de fichier de plus de 13 caractères. Je ne me souviens pas de quelle extension, je me souviens juste que c'était un problème.

Nous travaillons au niveau du projet pour les fichiers CAD, cela dépend de la façon dont votre flux de travail particulier est configuré, nous avons notre projet de travail principal, puis préparons toutes les banques de données supplémentaires à partir de cela dans un script d'exportation à la fin de la session d'édition.

datadir \ cad \ cadastre.dgn
datadir \ srv \ fuel.dgn
datadir \ srv \ sewerage.dgn
datadir \ map \ base.dgn
datadir \ map \ printsets.dgn
...

puis chaque fichier a des niveaux / couches / caractéristiques nommés avec un identifiant
SewPipe
SewManhole
SewPit
...

Nous exportons ensuite le tout vers SQL spatial au lieu de lire nos fichiers de projet de travail où ils sont affichés à l'utilisateur via Mapguide ou toute autre application SIG de saveur nécessaire.

Les couches SIG sont triées par nom d'entité avec des identifiants et une disposition de dossier similaire pour permettre le tri.