I have tried for several years to come up with/stick to a decent naming convention for GIS data. A colleague of mine came up with a 3 letter prefix scheme followed by an underscore which was pretty nifty:
- ftr – Feature class
- tbl – Table
- svw – Spatial view
- cvd – Coded value domain
- vew – Table view
- loc – Address locator
- gcs – Geocoding service
- svc – Service
- ras – Raster
- rvd – Range domain
This was done because when looking at the tables via SQL Server Management Studio, one cannot determine which tables are actually GIS tables/feature class attribute tables, and which are native SQL tables at a glance. This solved that problem, and conveniently grouped the different types of data at the same time.
However, a convention only works when everyone sticks to it. The use of plural vs singular is another bone of contention. I am of of the opinion that all feature classes should be named in the singular. This approach has stuck with me since mapwork classes in primary school (ah the 90s). Legends on maps always indicated “River”, “Road”, “Farm”, never “Rivers”, “Roads”, or “Farms”.
This is why when someone gives me shapefiles or whatever that have plural names, I immediately change it to singular. I WILL NOT TOLERATE THIS LUNACY. These naming issues fall under the greater problem of ever expanding formats for GIS data, along with the issue of “How on earth are we going to store all this stuff?!”
And no, saying “in the cloud” is not a solution. Someone still has to manage that data, and structure it in a way that makes sense and somehow anticipate further expansion of the system. That, however, is a story for another day.