Nomenclature for file and layer naming in Multi-user data systems

Question

We are moving our very outdated and unorganized system to the Enterprise Geodatabase format. My biggest fear is people are going to be creating content, naming it randomly (or names only they understand), and dropping it willy-nilly into our shiny new system. In 3 years, we'll be back to this mess we have now. I'd love hear people's thoughts and systems for file organization, especially data file/layer naming nomenclature. What works for your organizations?

Bud · Answer

FAQ: What are the recommended naming conventions for geodatabase objects?

How To Name Things In ArcGIS

Source: Idea - Geodatabase object naming convention recommendations

Bud · Answer

Not sure if you’re looking for SDE object naming conventions or not, but a few come to mind:

* Use common prefixes so that like-objects will be sorted together in Catalog:* ROAD
* ROAD_EVENTS
* ROAD_INSPECTIONS

* Plural vs singular: “ROAD” vs. “ROADS”.
* Define a case standard: all caps, title case, etc.
* Define a standard for underscores or no underscores.
* Suffix database views with “_VW" or "_V” — so that you can tell what objects are tables vs. views in Catalog.
* Suffix tables/FCs that are generated/loaded by a scheduled job as “_SKD”, or something like that.
* Use feature datasets to group like-layers, where possible. Unfortunately, we can’t put non-spatial tables in feature datasets.
* Other standards as needed.

Edit:

* Avoid creating lots of unnecessary owners/schemas/users in enterprise GDBs. When there are lots of owners, it's hard to remember where a FC lives. "What owner was it in again?"

jcarlson · Answer

@ThomasHamill  Agreed! Especially the suffixes part. When we moved our stuff from a legacy system to our new setup, we had so many badly-named files, like "layer_final", "layer_final_2", "layer_final_final_x". It was impossible to know what was what.

I don't know how much of this applies to your situation, but we moved as many of our GIS layers to our Portal as possible, and the Enterprise Geodatabase is not available directly, only via registered services. Since layers there are referenced by URL or ID, the visible name, categorization, ownership, etc., can all be endlessly reconfigured to make things easier to find and interact with.

For our non-spatial stuff like files, some of it can also be added to a Portal, like shared project packages and templates. For other operational documents, we use GitHub to manage things like scripts and custom-built viewers, so that any of our staff can pull in the latest official version of things, on any machine, and you can then take advantage of things like multiple branches to develop new ideas or test things out without risking "damage".

Of course, not everything makes sense to have on GitHub, and sometimes it's just a folder on the network. I don't have as much helpful advice on that, because our network drive is a bit of a mess. If you can establish a folder structure ahead of time and maybe some basic filename conventions, and then get other staff to actually stick to it, I think that's a start.

Sort of "above" all of that, we maintain a department wiki. Any time we need to document, establish, or refine a process or standard, we do it there. That way, any current and future staff will be able to easily reference standard operating procedures. I'm a big fan of having internal wikis, I think they're very helpful. (And I'd highly recommend wiki.js for anyone thinking about making one!)