Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

My company uses ArcGIS and has a project and data file naming standards in place and (for the most part) followed. Something that has always bothered me about he naming standards is that it mandates starting all project and data file names with the project number - an eight digit number. I've always held the belief that naming GIS files starting with numbers is a bad thing, and have had (especially with GRIDS) processes fail because of the file name.

I'm looking to amend the corporate standards to drop the project number requirement, however I cannot find much in the way of documentation on why "numbers as a first character" in filename is a bad thing. Can anyone point me in the right direction as far as resources to support this argument?

Thanks,

share|improve this question
    
I'll do some digging for documentation but generally numbers as first char in db table names and folder structures are a bad idea if not completely illegal (invalid). many tools adhere to that also. this just in from earlier. gis.stackexchange.com/questions/3571/… –  Brad Nesom Mar 29 '11 at 16:57
2  
@Welcome to the site! Because you have framed your question excellently, I have taken the liberty of removing the initial paragraph so that readers can get into your question immediately. –  whuber Mar 29 '11 at 17:24
1  
Numbers in file names is not an issue but you can't start feature class names with numbers: gis.stackexchange.com/questions/6686/… –  Derek Swingley Mar 29 '11 at 17:25

4 Answers 4

up vote 8 down vote accepted

This convention is just begging to bring out bugs from bad command interpreters. (It is all too easy to confuse initial digits with a number.)

Your software's success today in avoiding such bugs is no guarantee that they won't appear in future releases. This has happened multiple times, over decades, with ESRI's GIS software. This behavior has been extensively reported and amply documented. You need look no further than ESRI's own user forums, which date back a decade. (Deeper searches of old listserver archives will take you back even earlier, to around 1995.) Interesting Google searches include

"GRD ERROR" site:forums.esri.com

filename 8.3 site:forums.esri.com

Together these will provide around a hundred actual examples of the problems such filenames have caused and potentially could cause again.

share|improve this answer
1  
What do you mean by bad command interpreters? –  Nathanus Mar 29 '11 at 17:27
2  
@Nathanus Every one of the "raster calculator" interfaces ever released for ArcGIS 8.x and 9.x. Another example: the internal interpreter for the GRID engine that had been the core of all raster analysis in all ESRI software for a quarter century until just a few years ago. Also (to a minor extent) the Avenue interpreter in ArcView 2.x and 3.x. All of these fail in some crucial places to parse their input language correctly. –  whuber Mar 29 '11 at 17:33
    
@whuber.. Thanks. in conjunction with Mapperz JET reference bleow this has gotten me great building blocks/examlpes for hopefuly effecting a standards change. –  hgil Mar 29 '11 at 17:58
    
Oh. You meant the convention referring to their current practice, not the naming convention. I got my mind mixed up there for a bit. –  Nathanus Mar 30 '11 at 21:45

Avoid Numbers if you can -

Earth Sciences has a good example http://library.oceanteacher.org/OTMediawiki/index.php/General_File-Naming_Convention_for_Earth_Science_Datasets#Filename_Sections_in_the_Order_They_Should_Appear

Spaces can trip you up to - some old DOS based commands for moving files break if space are involved - use "_" (underscores) is a wise think - this stems back to ArcInfo workstation - only 8.3 (8 characters and the file format). These days you can have more - but make it human readable for delivery. avoid dates (most files are timestamped)

*Basically go by this statement Example:

Naming convention rules, as directed by the Microsoft JET engine, which enables Windows applications like ArcMap to read various table formats, include the following:

  • The name must start with a letter, not a number.
  • The name must not contain spaces.
  • The only special character allowed is an underscore.

ArcMap

enter image description here

share|improve this answer
    
+1 Good advice. –  whuber Mar 29 '11 at 17:25

Any "Open" or "Select" file dialog is going to do sorting assuming the files are named using letters. So if you are using an eight (!) digit unique number for every project file sorting will quickly become illogical. E.g.

1
10
2
20
3 etc. 

Besides there'll be plenty of GIS tools that will still be assuming files that conform to the MS DOS 8.3 filename format.

Using filenames themselves as a key to a project seems a cumbersome requirement at best. It would be far better to store all files in some sort of version control in relevant project repositories.

share|improve this answer
    
I agree. It's one ofthe reasons I'm trying to change the existing standard. Not only cumbersome, but in our case redundant too, as we have the project number included in another part of the overall file path. –  hgil Mar 29 '11 at 17:49
    
+1 Good point about the sorting and nice suggestion for an alternative. (Chances are, though, that this convention forces initial zeros to appear, so the sorting might work anyway...). –  whuber Mar 29 '11 at 23:07

There seems to be an absence of restriction on first letter numeric as a convention except here in the NPS convention.

File and attribute table names
A. GIS Final Products – Coverages, shapefiles and other formats must conform to a 10.3 file naming structure (that is, cxxxxxxxxx.ext, where “c” is an alpha character and “x” is alphanumeric, for a total of 13 characters and one period separating the filename from the extension). The following conventions should be used to generate file names: ccccccc99c.ext
i. A 4-character prefix for park code (see Table 1).
ii. A 5-character project code, as indicated in the NCCN project tracking database. Refer to NCCN Tracking Project Information (NCCN 2005b, in development).
iii. A single character differentiating GIS layers within the same project. This single character is referred to as the GIS project product code and is maintained in the NCCN project tracking database. This should be an alpha character selected in sequence (i.e., start with a, b, c, etc.) as more GIS layers are created for or are added to the project. For example, assuming that there already exist two other GIS layers for this project, an ESRI Arc/Info export file of the NOCA Landbird Inventory project transect starting points would have a file name of “nocabda02c.e00.”
iv. The extension. An ESRI shapefile would consist of a minimum of five files with the same name and the following extensions: .shp, .shx, .dbf, .shp, shp.xml, and .prj.<<

Sorry for above paragraph.
My experience has been that when there is a substandard naming convention that
1. people break it because of difficulty in adherance.
2. people break it to adhere to other standard naming conventions.

The fact is that there are tools the do not allow numeric first character file and field names, and RDBMS naming almost always follows these same rules.

Indiana documentation
Oregon documentation
Jason Birch documentation
Nat Park Serv documentation
Public Safety Multi-Agency documentation
River reach codes seems to ignore best practices
San Antonio documentation
More NPS documentation

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.