by G. Peterson                                         

Are you fed up with GIS files being so randomly scattered around your hard-drive that your precious analysis time is losing out to the ever-dull "finding that file" time?  Or is this your first attempt at conducting a large-scale GIS analysis (e.g., six month effort, or greater) and you have an inkling that some structure and direction are called for, but do not know where to start?  Well, you may never be totally satisfied with your organizational efforts but you will go a long way toward creating a superior end-product by following some basic guidelines.

 

With any data-intensive GIS analysis one of the first decisions is identifying which measurement unit to use as a standard.  It may not matter to you at the beginning of the project whether you measure in meters, feet, acres, or miles, but when you are mid-way through and bringing up a file you have not had occasion to use in the past 3 months you will thank yourself.  When you open up this file you will instantly know that the “RdLengthPerParcel” field is in feet units and not spend the next 5 to 10 minutes zooming in on a parcel, finding your road layer, and measuring the road so that you can reassure yourself as to whether it is 100 feet or 100 meters. 

 

Next, decide on the number of decimal places to use.  Obviously you are constrained both by your data scale and your analysis scale.  If you do not set a standard for significant digits at the beginning of the project, take notes on it as you go along so that you can refer back as needed.  Whenever the analysis is updated in the future, or redone entirely, this becomes very important so that the numbers from the previous study and the new numbers are comparable.

 

A picture of the analysis (i.e., analysis diagram) is a handy tool to facilitate an understanding of how the various steps are going to take place.  You have no doubt heard and used various types of diagram modeling tools and techniques such as Unified Modeling Language (UML).  Even if you are not versed in these tools you ought to be able to at least draw some bubbles on a white board and make arrows connecting them.  Whatever method, it is wise to keep all iterations of your analysis model and date them accordingly so you can see how the analysis evolves over time. This informs future analyses during the time and resource planning phases, gives you a map of how the project was done when transferring it to another analyst, and gives your brain a quick refresher should you be required to present your work 1 or 2 years after it was completed (which is not at all unusual).

 

A recent dialog on the James Fee GIS Blog pointed to the fact that GIS professionals have many ways of storing project data and related files but also that some of us may begin a project with no structure in mind at all.  A file structure is a must.  My advice is not to get hung-up on which structure to use as it could be a project in itself to find the perfect one (is there such a thing?).  Find a system that looks reasonable and go with it until you have reason to change it.  One consideration is where to store project-specific data versus data that are commonly used in all projects.  Some will lump them together into one folder with subfolders for data type.  Some will have a separate folder for commonly used data (itself broken down by data type) with another for project-specific data (under the project master-folder).  Perhaps your unique project lends itself to a less common method such as arranging files by date and time rather than subject.

 

The folder hierarchy that I use, which is appropriate only for a smaller office or individual, is shown below-right in abbreviated format: 

Lastly, I make it a point to diligently keep track of all those intermediate files that are inevitably created as the analysis gets underway.  They can be hard to decipher even an hour from when you created them, and even harder when it has been weeks or months.  While a simple computerized log of the file names and dates as you create them is helpful, I like to go the old fashioned route and keep a notebook (or digital document) where I jot down the file name and usually a few informative bits about the file such as: “merge of x and y” or “summary of watersheds, average area.”  If this method is followed, the file names are automatically put into a time-sequence and there is a bit of metadata to refer to, hopefully setting off that light-bulb in your head so that you can recall just how you arrived at that file called “ParcelSumAreaImperviousMerge.”  If you use your notes for other analysis process-steps, be sure to underline or otherwise highlight all the file names for easy reference. 

And that leads to file naming conventions.  I am not going to get too into this.  Suffice to say that we should all know better by now than to name a file “sum_output4.”  If you have done so inadvertently, immediately change the name to something that describes what the file contains.

 

I hope these few tips, though certainly not comprehensive of everything you may want to consider prior to embarking on that exciting analysis project, will help get you organized.  Remember that a few extra minutes a day in planning can add up to a lot of time saved and, more importantly, ensures a higher quality end-product.  Do not take this to the extreme and spend all of your time planning and none implementing.  There is no way you can foresee all of the strange twists and turns your track will take you on and indeed, what would be the fun of the ride if it weren’t so?  Follow these simple guidelines and I am sure your next project will be less grief-inducing and more productive.