(This is Part 4 of a week long series of posts on the current project I am working on, to develop a reasonable GIS data maintenance strategy for Asset Management data. Read Part 1, Part 2 and Part 3 here).
Once all the new data has been processed and captured, or existing data flagged as asset upgrades, we have to extract several attributes for use by the asset guys. This includes the all important GIS ID, which will be used to link the asset register back to the GIS. The asset register contains a mountain of information about the status of the assets, remaining useful life and other financial information. In the GIS data, we are purely concerned with geometry: is this asset in its correct physical location, with the correct dimensions?
We will carry a few other attributes, such as material type, diameter of pipe, name (if relevant) and town. Once I’ve compiled all the data into this structure, I convert it to a spreadsheet filtered by feature type and including the lengths of the line data. The GIS length is used over the length supplied by the client as it represents the situation on the ground.
Once everything has been submitted to the client, a short while later the auditors will appear. Using some algorithm, they select a sample of the assets and send us a list of GIS IDs or asset names. I link this list up to our GIS and provide a KML file of the locations. This proves that we know where those assets listed on the asset register are (and that no one is trying to fabricate assets). Sometimes the auditors will only provide the asset names – that makes it a bit harder for me to link since we don’t always have the name attribute. It’s the reason why the GIS ID should appear in all documentation.
For one client, I went along with the project leader and sat with an auditor in front of ArcMap. I had to physically look up the assets as she read out the GIS ID or asset name. At that time, the data was not in a good state to begin with, so fortunately she had only sampled assets that I could easily retrieve. As part of this methodology development, I’m documenting the state of the data as it was received, the problems it causes (including unnecessary delays) and the estimated time it would take to clean up the full database for each client.
That’s the part I’m most excited about in this process. I can finally get my hands into the data and standardise it, so if there are any auditor queries, or someone wants to know something quickly about a particular asset, I will know exactly where to find it.