Les noms commençant par des nombres sont-ils une mauvaise convention de dénomination des données?

17

Mon entreprise utilise ArcGIS et dispose d'un projet et de normes de dénomination des fichiers de données en place et (pour la plupart) suivies. Quelque chose qui m'a toujours dérangé dans les normes de dénomination, c'est qu'il oblige à démarrer tous les noms de projet et de fichier de données avec le numéro de projet - un nombre à huit chiffres . J'ai toujours cru que nommer des fichiers SIG commençant par des nombres était une mauvaise chose et que les processus (en particulier avec GRIDS) avaient échoué à cause du nom du fichier.

Je cherche à modifier les normes d'entreprise pour supprimer l'exigence de numéro de projet, mais je ne trouve pas beaucoup de documentation sur la raison pour laquelle "les nombres en tant que premier caractère" dans le nom de fichier est une mauvaise chose.

Quelqu'un peut-il m'orienter dans la bonne direction en ce qui concerne les ressources pour soutenir cet argument?

hgil
la source
Je vais creuser pour la documentation mais généralement les nombres comme premier caractère dans les noms de table db et les structures de dossiers sont une mauvaise idée sinon complètement illégaux (invalides). de nombreux outils y adhèrent également. cela vient de plus tôt. gis.stackexchange.com/questions/3571/…
Brad Nesom
2
@Bienvenue sur le site! Parce que vous avez parfaitement cadré votre question, j'ai pris la liberté de supprimer le paragraphe initial afin que les lecteurs puissent y répondre immédiatement.
whuber
1
Les nombres dans les noms de fichiers ne sont pas un problème, mais vous ne pouvez pas démarrer les noms de classe d' entités
Derek Swingley

Réponses:

10

Cette convention ne fait que mendier pour faire ressortir les bogues des mauvais interprètes de commande . (Il est trop facile de confondre les premiers chiffres avec un nombre.)

Le succès de votre logiciel aujourd'hui à éviter de tels bogues n'est pas une garantie qu'ils n'apparaîtront pas dans les futures versions. Cela s'est produit plusieurs fois, au cours des décennies, avec le logiciel SIG d'ESRI. Ce comportement a été largement rapporté et amplement documenté. Vous n'avez pas besoin de chercher plus loin que les propres forums d'utilisateurs d'ESRI, qui remontent à une décennie. (Des recherches plus approfondies dans les anciennes archives du serveur de liste vous ramèneront encore plus tôt, vers 1995.) Les recherches Google intéressantes incluent

Site "ERREUR GRD": forums.esri.com

nom du fichier 8.3 site: forums.esri.com

Ensemble, ceux-ci fourniront une centaine d'exemples réels des problèmes que ces noms de fichiers ont causés et pourraient potentiellement causer à nouveau.

whuber
la source
1
Qu'entendez-vous par mauvais interprètes de commande?
Nathanus
2
@Nathanus Chacune des interfaces de "calculatrice raster" jamais publiées pour ArcGIS 8.x et 9.x. Autre exemple: l'interpréteur interne du moteur GRID qui avait été au cœur de toutes les analyses raster dans tous les logiciels ESRI pendant un quart de siècle jusqu'à il y a quelques années seulement. Aussi (dans une moindre mesure) l'interpréteur Avenue dans ArcView 2.x et 3.x. Tous ces éléments échouent à certains endroits cruciaux pour analyser correctement leur langue d'entrée.
whuber
@whuber .. Merci. en conjonction avec le souffle de référence Mapperz JET, cela m'a procuré d'excellents blocs de construction / examens pour effectuer, espérons-le, un changement de normes.
hgil
Oh. Vous vouliez dire que la convention faisait référence à leur pratique actuelle, pas la convention de dénomination. J'ai un peu mélangé mon esprit là-bas.
Nathanus
9

Évitez les chiffres si vous le pouvez -

Les sciences de la Terre ont un bon exemple http://library.oceanteacher.org/OTMediawiki/index.php/General_File-Naming_Convention_for_Earth_Science_Datasets#Filename_Sections_in_the_Order_They_Should_Appear

Les espaces peuvent vous faire trébucher - certaines anciennes commandes DOS pour déplacer des fichiers se cassent si l'espace est impliqué - utilisez "_" (soulignements) est une idée judicieuse - cela revient à la station de travail ArcInfo - seulement 8,3 (8 caractères et le format de fichier) . Ces jours-ci, vous pouvez en avoir plus - mais rendez-le lisible par l'homme pour la livraison. éviter les dates (la plupart des fichiers sont horodatés)

* Fondamentalement, passez par cette déclaration Exemple:

Les règles de convention de dénomination, comme indiqué par le moteur Microsoft JET, qui permet aux applications Windows comme ArcMap de lire divers formats de table, sont les suivantes:

  • Le nom doit commencer par une lettre, pas un chiffre.
  • Le nom ne doit pas contenir d'espaces.
  • Le seul caractère spécial autorisé est un trait de soulignement.

ArcMap

entrez la description de l'image ici

Mapperz
la source
4

Toute boîte de dialogue de fichier "Ouvrir" ou "Sélectionner" va faire un tri en supposant que les fichiers sont nommés à l'aide de lettres. Donc, si vous utilisez un numéro unique à huit (!) Chiffres pour chaque projet, le tri des fichiers deviendra rapidement illogique. Par exemple

1
10
2
20
3 etc. 

En outre, il y aura de nombreux outils SIG qui supposeront toujours des fichiers conformes au format de nom de fichier MS DOS 8.3 .

L'utilisation des noms de fichiers eux-mêmes comme clé d'un projet semble au mieux une exigence lourde. Il serait bien préférable de stocker tous les fichiers dans une sorte de contrôle de version dans les référentiels de projet pertinents.

geographika
la source
Je suis d'accord. C'est l'une des raisons pour lesquelles j'essaie de modifier la norme existante. Non seulement encombrant, mais dans notre cas également redondant, car nous avons le numéro de projet inclus dans une autre partie du chemin de fichier global.
hgil
+1 Bon point sur le tri et belle suggestion d'alternative. (Il y a des chances, cependant, que cette convention force les zéros initiaux à apparaître, donc le tri pourrait fonctionner de toute façon ...).
whuber
2

Il semble y avoir une absence de restriction sur la première lettre numérique comme convention, sauf ici dans la convention NPS.

Noms des fichiers et des tables d'attributs
A. Produits finaux SIG - Les couvertures, les fichiers de formes et les autres formats doivent être conformes à une structure de dénomination des fichiers 10.3 (c'est-à-dire, cxxxxxxxxx.ext, où «c» est un caractère alpha et «x» est alphanumérique, pour un total de 13 caractères et une période séparant le nom de fichier de l'extension). Les conventions suivantes doivent être utilisées pour générer des noms de fichiers: ccccccc99c.ext
i. Un préfixe à 4 caractères pour le code de parc (voir le tableau 1).
ii. Un code de projet à 5 caractères, comme indiqué dans la base de données de suivi de projet du NCCN. Reportez-vous à NCCN Tracking Project Information (NCCN 2005b, en cours d'élaboration).
iii. Un seul caractère différenciant les couches SIG dans le même projet. Ce caractère unique est appelé code produit du projet SIG et est conservé dans la base de données de suivi des projets du NCCN. Il doit s'agir d'un caractère alpha sélectionné dans l'ordre (c'est-à-dire, commencez par a, b, c, etc.) à mesure que davantage de couches SIG sont créées ou ajoutées au projet. Par exemple, en supposant qu'il existe déjà deux autres couches SIG pour ce projet, un fichier d'exportation ESRI Arc / Info du point de départ du transect du projet NOCA Landbird Inventory aurait un nom de fichier «nocabda02c.e00»
. Iv. L'extension. Un fichier de formes ESRI serait composé d'au moins cinq fichiers portant le même nom et les extensions suivantes: .shp, .shx, .dbf, .shp, shp.xml et .prj. <<

Désolé pour le paragraphe ci-dessus.
D'après mon expérience, lorsqu'il existe une convention de dénomination de qualité inférieure,
1. les gens la brisent en raison de difficultés d'adhésion.
2. les gens le cassent pour adhérer à d'autres conventions de dénomination standard.

Le fait est qu'il existe des outils qui n'autorisent pas les noms de fichier et de champ de premier caractère numérique, et la dénomination RDBMS suit presque toujours ces mêmes règles.

Documentation de l'Indiana Documentation de l'
Oregon Documentation de
Jason Birch Documentation de
Nat Park Serv Documentation de
la sécurité publique multi-agences Les
codes d'accès aux rivières semblent ignorer les meilleures pratiques
Documentation de San Antonio
Plus de documentation NPS

Brad Nesom
la source