GIS Best Practice for Legacy Data

Question

We have an enterprise GIS system and lately there has been some discussion about keeping track of legacy or retired infrastructure. For example if a Watermain is replaced or a new hydrant was put in, what is the good industry practice to track all this information?

Is it appropriate to keep information (e.g., Inactive or Retired) as an attribute within the operational Feature Class or would it be better to have a separate Table or Feature Class that would contain all the retired infrastructure information?

BillFox · Answer

Trash it or move it to a completely separate layer (No spaghetti geometry or attribute confusion)

ThomasHamill · Answer

@aam, keeping information (e.g., Inactive or Retired) as a "Legacy" attribute (like "Legacy_Material," "Legacy_Diameter," Legacy_Manufacturer," etc.) within the operational Feature Class(es) would work well if only the attributes were subject to change.  In my experience it becomes a suboptimal (and confusing) solution when new feature geometry is introduced, like with a hydrant being relocated across the street or a water main replacement having shifted slightly in relation to the old one.  My approach used to be to just make an archive/backup copy of the feature geodatabase (with a YYYYMMDDHHMM timestamp suffix before the .gdb file extension) prior to a major "campaign" of edits/revisions, but I realize that this isn't a very sophisticated approach.

Perhaps there are some special versioning tools or other functionality in you enterprise GIS system that would support a simple archiving-aware workflow.

jcarlson · Answer

I'm sure it's different for utilities, but in the parcel fabric, everything has a pair of "created" and "retired" fields that can be used to query out historic features. It's one less layer to keep track of, and assuming that every feature does have a created date and may potentially be retired at some point, attributes seem like a good way to go. I'd be interested to hear other takes on it, though.