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


28

À 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).


6
Une bonne question. En fait, ce n'est pas une question, c'est une quête. Une question mène à un ensemble de réponses simples ou étroites, et une fois réglée, c'est fini. Une quête est une chose en cours, une aventure qui peut ne jamais avoir de fin définitive, et c'est ce que vous avez ici. Résignez-vous à la vérité que, quelle que soit la convention sur laquelle vous vous arrêtez, cela ne fonctionnera pas complètement ou complètement. Cela dit, il existe des conventions que vous pouvez utiliser pour rendre le chemin plus fluide et plus facile à parcourir. La réponse de Kevin et les commentaires qui suivent sont un très bon début à cet égard.
matt wilkie

Réponses:


21

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. :)


J'ai légèrement châtié quelqu'un hier pour avoir publié quelque chose de trop grand et de long, et je vais faire la même chose, juste sans les photos. Que pensez-vous, est-il préférable de présenter un ensemble cohérent ou de diviser les choses en morceaux modulaires, qui peuvent chacun voter pour / contre leur propre mérite, mais éventuellement briser ou cacher leur intégration avec les autres? Parlez-en sur Meta: Long et cohésif ou court et modulaire
Matt Wilkie

Sensationnel. Quel système de classement (je l'ai déjà lu quatre fois et je ne suis pas sûr d'avoir tout compris). Deux commentaires qui se sont démarqués pour moi, en tant qu'utilisateur d'AutoCAD et d'ArcGIS: 1. Comment puis-je intégrer dans ce système le stockage des fichiers DWG? 2. La géodatabase est un excellent moyen de rester organisé. Le seul problème que j'ai est que la carte AutoCAD ne voit pas GDB mais seulement les fichiers de formes. Mais merci, je vais prendre des conseils de votre système complet ...
jonatr

Gardez à l'esprit que ce système a évolué pour devenir ainsi au cours des 15 dernières années et est adapté à notre façon de travailler. Il devrait cependant y avoir des éléments portables. En ce qui concerne l'interopérabilité avec la CAO, gardez le cas d'ESRI pour honorer son engagement à publier une API ouverte dans la géodatabase fichier .
matt wilkie

1
Idem sur les jeux de données d'entités. C'est une sorte de fonctionnalité inutile, sauf dans ArcCatalog. Ils sont censés regrouper les couches d'utilisation courante et de référence spatiale, mais un programmeur ne voit jamais un jeu de données d'entité tant qu'il ne parvient pas à parcourir les couches dans un espace de travail. Lorsque vous utilisez différentes projections, des bases de données distinctes semblent meilleures que des ensembles de données d'entités.
Tim Rourke

1
@Tim Je crois que les jeux de données d'entité sont le décendant conceptuel des couvertures ArcInfo, à savoir qu'ils doivent être un moyen de regrouper des types de géométrie disparates qui décrivent une "chose" commune dans un même panier. Ainsi, vous pouvez avoir par exemple des cours d'eau (lignes), des plans d'eau (polygones) et des roches dans l'eau (points) ensemble. Je ne sais pas pourquoi ils ne sont pas présentés plus directement au programmeur.
matt wilkie

6

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.


Merci Kevin, qu'en est-il de la convention de nom de fichier? Je pense à une solution comme <Objet> _ <Emplacement> _ <Range> _ <Date> _ <FileFormat> _ <Resolution>. <ext> coast_eu_340509.76N0080201.23E_350509.76N_0090201.23E_2011_shp.zip box_eu_340509.76N0035050.27 .76N_0090201.23E_2011_tiff.zip. Pensez-vous que c'est une idée valable?
Jade

5
Ces noms de fichiers peuvent devenir très lourds à utiliser sur une ligne de commande ou dans un programme. Ils conduiraient également à une table des matières et / ou une légende très large dans ArcMap (par défaut au moins). J'opterais pour des noms de fichiers plus courts, par exemple simplement un objet ou un objet et une date, et j'utiliserais des métadonnées standard ou au moins un fichier Lisez-moi pour relayer le reste des informations. Juste mon avis.

4
Je suis d'accord avec Kevin. Mon entreprise actuelle a une convention de nom de fichier héritée (que je suis en train de changer) qui impose des noms de fichier trop longs et elle est très lourde pour les raisons mentionnées par Kevin. Deux réflexions supplémentaires 1) Une grande partie de ce que vous avez dans le nom de fichier peut être divisée en dossiers et triée dans la structure du fichier - pas le nom du fichier hte; 2) les multiples points / points (.) Dans le nom de fichier peuvent entraîner des problèmes d'accès aux fichiers via certains logiciels et / ou par programmation. généralement les caractères après un (.) sont l'extension de fichier et non les composants de nom de fichier supplémentaires.
hgil

2

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.