Unique IDs for Asset Data

1490
2
09-11-2019 08:58 AM
BrennanWalters
New Contributor

Good morning y'all. I have just started a new role for a new local government where I've stepped midway into an ongoing process of assigning unique asset ID tags for asset data. The goal of the IT director is to create a system of assigning IDs to our assets (facilities, roads, stormwater infrastructure, utilities, etc) shared among all departments. The IT director is hoping to indicate a hierarchical relationship  (grandparent-parent-child-etc) somehow in a field (15 characters) by identifying the Township-Section-Range of each asset, followed by a numeric value indicating it's location within the township/section/range (i.e  01=the most westerly portion of the section), and a letter code for the it's type (i.e. Land=L, Transportation = T, and so on). I don't see how we can create a sustainable method for assigning unique values given this method. I understand his desire to maintain an intuitive method for understanding the hierarchy of different features (i.e. a park is an asset, a pavilion or a boardwalk is a sub-asset of the park) and having a shared ID to link facilities from our finance, public works, etc to our spatial data, but this particular method has brought me great confusion.

Has anyone dealt with with this type of issue before? I'm willing to recommend throwing out the existing process if anyone has suggestions for a simpler method for assigning unique IDs AND somehow providing inside into the hierarchical relationships among the asset features.

Any help would be GREATLY appreciated!!!!!!!!

Thanks,

Brennan

0 Kudos
2 Replies
SallieVaughn
Occasional Contributor

If you have GIS layers for all the spatial constraints you mentioned (Township, Section, Range, park, etc.) and the desired identifiers are stored in those layers, you could use the Attribute Assistant to calculate those IDs for you. I do think 15 characters is a little ambitious for what you are trying to accomplish.

https://solutions.arcgis.com/shared/help/attribute-assistant/

There are a lot of unknowns here. For example, how many data editors do you have? Is there a risk that someone in public works could add an ID to a water fountain in a park and then someone from parks and rec duplicates the effort?

Also, information that defines each feature could be stored in more than 1 field. For a given transportation asset, you could have 1 field for the PLSS information, a second field for additional location information, a third field for unique ID, etc. To me, that makes more sense.

ChrisDonohue__GISP
MVP Alum

Sallie Vaughn has some good points. 

Some added comments:

At the City I worked at, we had Township Section Range information, but it was a separate feature class.  On demand, you could spatial join it to find out where the features are located, since in theory assets don't move.  We found this to be much more effective than trying to hard-code it into a feature class.   In a way, its redundant data to have hard-coded in a feature class.

So that brought up a thought, let me back up.  Does your municipality have an enterprise geodatabase or are they using File Geodatabases/Shapefiles, etc?   Knowing that will also determine to some extent what options you have in coming up with the most effective system.  For example, in an enterprise geodatabase it is fairly easy to set up Subtypes to help categorize data, plus this helps limit entry errors by constraining the categories to only valid values.

Introduction to subtypes—Geodatabases | ArcGIS Desktop 

Also, who will use the data?  What for?  For example, will it be hosted to a web service?  Will other systems be tied into it? Who are the downstream users and what are they/their systems expecting as input?  Knowing that will then provide options and constraints for how one sets this up. 

At the City I was at, we didn't try to come up with one universal unique ID for everything.  Instead, we had unique IDs for each feature class.  So I guess part of figuring this out will be determining the business need for one big universal ID.  It may be that its very needed.  But it would be good to know the why before moving forward.  I would dig a bit more to find out the rationale more.  It may be that somewhere in your organization there is a non-GIS data consumer that reads the GIS data from a linked system and needs the proposed ID to be able to do its process (and has little capability to be adjusted).  I was often surprised at the City that even after working a few years there that I would discover there were systems using our data that we had never even heard of.  We would propose changes, conduct outreach, go through a review process with all the City departments, then once we implemented even a small change (like eliminating one obsolete zoning code) someone call us from out of nowhere and ask why the data was broken now.  Even my boss, who had been there many years, who knew everyone and everything going on in this mid-sized city government, would often be surprised.  So ask around.  And then ask again.  Seriously.  Don't expect to be able to see the whole picture in one day.  It may take asking many people in various parts of the city over a period of time to get the full picture.

Anyways, keep at it.  That's my 2 cents. 

Chris Donohue, GISP