Define and stick with logical directory structure for file-based data
In every mapping related job I’ve worked, one issue that always arises is data management. Unless you have a spatial database implemented already, the likelihood is that the majority of your data is in some file-based format. Heck, even if you have a spatial database, you are still going to receive data in a file-base format of some sort. You will also likely have project files that need to be organized, and other files that you may not want to load into a database, like aerial photos.
I’m sure most of you out there can relate to coming into an organization and seeing directory upon directory filled with a mix of shapefiles, aerial photos, mxd’s, excel files, MS Access databases, and what have you. They all tend to be jumbled together, oftentimes nested multiple layers deep, and always with duplicates of each other.
There are a lot of reasons this structure is a bad idea, but primarily, it is extremely difficult to find anything. The whole point of building a geographic information system, and collecting data, is to be able to utilize it to streamline your management or business processes. If you can’t find the data, you can’t use it effectively.
Okay, lecture over. We’re all about solutions, so here is how to fix the problem:
- Do a review of your data and projects to see what you have.
- Create a directory structure that separates project files, and data files.
- Try to keep the top level directories to a relatively small number
- Go wider vs deeper with subdirectories. This will help prevent data from getting buried. If you see this problem developing, find ways of breaking your projects out into components to widen the structure further.
- Implement naming conventions on both directories and files once they have been moved to their final location.
- Sort data and move to new locations. As you do this, remove obvious duplicates and mark others for review.
- Review duplicates that may have unique data, transfer this data to fields in layer to be kept, and discard other duplicated data.
Here is a sample directory structure:
As you can see, I have kept the top level relatively limited. Two directories I would probably add are
Orthophoto. Media would be any sort of video, photos or other documents that you may want to link to features. I separate orthophotos because though they are data, they generally are very static. Also, since they are very large, it is sometimes necessary to have them in a different location, so separating them out makes more sense.
Hopefully, this gives you a starting point for organizing your file-based data in a manner that makes it more concise and easier to find. One challenge I’m faced with often, is being asked to make a map with data that I might not use very often. Since I have defined my directory structure, and been strict about where I place things, it enables me to quickly locate the layers I need. Being more responsive can be challenging, so we must use all resources at our disposal to make it easier.
Let me know your preferred directory structures in the comments.