Je lutte depuis assez longtemps maintenant pour organiser mes fichiers de projet.
Quels sont vos conseils pour organiser vos jeux de données, vos images, vos fichiers de formes, etc.?
Je lutte depuis assez longtemps maintenant pour organiser mes fichiers de projet.
Quels sont vos conseils pour organiser vos jeux de données, vos images, vos fichiers de formes, etc.?
Réponses:
Remarque: cette diatribe sera mise à jour au fur et à mesure
Je ne suis en aucun cas un ordinateur ou ArcGIS pro, mais voici ce que je fais:
projects
dossier et sont hébergés sur mon serveur Internet, mon ordinateur local et mon dropbox. J'ai toujours accès à eux, et ils sont très organisés, dis et agrégés. Vous passerez beaucoup de temps à les organiser.my_projects
dossier. Il contient tout ce qui concerne ce projet, si je copie et colle ce dossier ailleurs, il contiendra tout.projects/my_project/raw_data
, projects/my_projects/analyzed_data
et projects/my_projects/output_data
.my_projects/FINAL/date_submitted
my_proj_dec_22_11__13_20.mxd
par exempleRFP_TENDER_Dec_22_11__11_15.doc
et draft_ver5_Dec_31_11__12_30.doc
. Encore une fois, tous mes livrables finaux vont dans le dossier FINALmy_projects/code
dossier. Je fais cela car la plupart du code python est réutilisable. Si vous mettez tout votre code python en plus des projets, vous les oublierez. De plus, tout mon code python va sur github.base_layer_2006.shp
.Vous n'avez pas déclaré que vous travaillez uniquement avec le logiciel Desktop GIS, je vais donc partager certaines de mes expériences de la mentalité orientée programmation. Permettez-moi tout d'abord de dire que je suis d'accord avec ce que dit @dassouki. Je pense que la chose la plus importante n'est pas la façon dont vous vous organisez, mais que vous le faites.
Mais pour continuer mon workflow. Ce que j'aime dans l'utilisation d'un langage de programmation (R dans mon cas), c'est que le script que j'écris documente toutes les étapes que je prends. Cela contraste avec l'utilisation d'ArcGIS où je pense qu'il est plus difficile de voir comment un utilisateur est passé des données d'entrée brutes à ce que vous pouvez voir dans un fichier mxd. Bien sûr, vous pouvez garder un journal de toutes les étapes que vous effectuez dans l'interface graphique, mais je pense qu'un langage de programmation se prête beaucoup mieux à l'enregistrement du flux de travail exact que vous avez pris. Cela peut être particulièrement important lorsqu'un client / superviseur demande comment vous avez fait quelque chose ou ce que vous avez fait exactement pour produire un certain produit.
Donc, dans la pratique, j'ai plusieurs dossiers sur mon disque qui sont importants (notez que je suis un scientifique):
Quelques idées principales que j'utilise:
En général, j'aime utiliser un langage de programmation car dans un script, vous pouvez passer des données brutes aux images / tableaux résultants. R est un assez bon candidat car il peut lire et écrire facilement des données SIG et a une tonne d'analyses à bord, à la fois SIG et statistiques.
Je voudrais juste ajouter à la réponse ci-dessus - 2 choses.
J'aime avoir des dossiers dans le répertoire d'importation de données brutes - des dossiers pour chaque fois que vous recevez un ensemble de données - c'est-à-dire from_clientname-2011dec23. De cette façon, je peux remonter quand j'ai reçu chaque élément de données utilisé dans le projet.
J'aime aussi avoir un document de projet pliable en déplacement - je peux ensuite créer un document Word ou un simple fichier TXT ici où je peux écrire ce que j'ai fait sur le projet, la date et qui l'a demandé. De cette façon, je peux revenir en arrière et me couvrir est quelqu'un se demande pourquoi j'ai fait quelque chose. Cela peut sembler fastidieux pour les petites demandes, mais cela peut vous faire économiser au final.