nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Inspection Workflows with Utility Network and Field Maps

kvincent

Hello everyone,

What are your workflows for tracking inspections within the Utility Network? I'm trying to create a map to be used in Field Maps to track Hydrant Painting. Right now, I have a "Hydrant Painting" table related to our Water UN. In the related table, I have a dropdown to select Painting Phase. Ideally, I would like to symbolize off of Painting Phase, so the field crews can keep track of their progress. However, since we cannot symbolize off of a related table, I'm stumped on how the field crews can use this app to track progress. To further this, I don't want the inspections written directly to the UN because of all the different types of inspections we conduct. I don't want the attribute table getting overloaded, so a related tables seems like the best way to stay organized. I just can't figure out how to visualize status for the project. We are running Utility Network in Enterprise 11.5.

Any thoughts or suggestions would be greatly appreciated! Thank you.

Find more posts tagged with

Accepted answers

wesztt

Hi @kvincent

We are in the UN and ran into this same issue creating a Field Maps workflow for hydrant inspections. We couldn't find a reliable solution to symbolize directly from an attribute value in a related table. There needs to be a field on the parent hydrant that drives the symbology change. We already had an "inspection status" field, but you may need to add that if you don't already have it.

The solution that worked for us was creating a calculation attribute rule on the related table and using edit dictionary to write back to the parent hydrant. When an inspection record is submitted in Field Maps, the attribute rule looks up the related parent hydrant and updates the "inspection status" field to "Complete". The point symbology is set up to turn green when marked complete - that change is visible immediately after the field workers hit "Submit" on the inspection form.

Hope this helps! Happy to share the Arcade if useful.

All comments

kvincent

Thank you!

kvincent

Sorry, I should have been more clear. We don't want the data on the hydrant itself, it's just a matter of finding the right process combination to get that symbology to update for inspection tracking purposes, especially since we could have multiple types of inspections happening at once (or at least each year), we need a way to keep it all organized - for example, hydrant painting and hydrant flushing. I just don't want to have to export a snapshot in time dataset, but I think I follow more what you're saying about the separate feature class and how that is preventable. Thank you!

Brett_Lessner

Ah yes, this is true.

If you do have access to ArcGIS Online, it could still be worth deploying the solution - even just to get some ideas. ArcGIS Solutions a free to deploy with your ArcGIS Online account so no reason not to use them as a resource.

Moving forward, I can share this post as input for Water Operations Tasks and getting inspection solutions in Enterprise.

wesztt

Sure thing! The calculation rule should be applied to the related table with insert as the trigger. This has worked great for the Yes/No or Complete/Incomplete scenario, but I'm not sure how well it would translate to a more complex symbology with multiple attribute values.

// Get related parent feature
var parentTable = FeatureSetByRelationshipName($feature, "RELATIONSHIP_NAME", ['STATUS_FIELD'], false);
var parentFeature = First(parentTable);

// Abort if no parent found
if (parentFeature == null) return{};

// Return edit dictionary to update parent
return {
"edit": [{
"className": "PARENT_CLASS",
"updates": [{
'objectID': parentFeature.OBJECTID,
"attributes": {"STATUS_FIELD": "STATUS_VALUE"} // Updates field in feature class
}]
}]
};

RobertKrisher

@kvincent there needs to be something done, and while it could be done manually it could just as easily be done through Python or Arcade (if you are proficient with those languages). The problem with doing all this work directly against the versioned data is that history is going to accumulate, and you don't have the degree of separation between your live network data and the historic of your asset registry.

RobertKrisher

Is there a reason why you need to put it on the hydrant itself instead of using a separate point class that represents the inspections? If you are setting/updating a flag on the hydrant (or any other feature) that represents its inspection status you're going to need to push multiple updates to each of those features every year (resetting the flag saying it needs to be inspecting, marking the feature as inspected, then updating the last inspected date). Because the UN data is versioned, all these edits are tracked and archived forever. A more sustainable approach for inspection is to manage the history, status, etc using separate tables. Not just for hydrants, but for any kind of asset you are performing preventative maintenance/inspections on (valves, pump, etc).

It also solve the problem of what to do when a hydrant is abandoned or removed and you don't want to lose the history of the asset for liability reasons.

kvincent

Thanks, @wesztt. I like that approach. You still have the related table to store all the inspection records, but just one field in the UN so the attribute table doesn't get too overloaded. I think something like this could work for us. If you could share the Arcade, that would be great!

wesztt

Hi @kvincent

Hope this helps! Happy to share the Arcade if useful.

kvincent

Thanks for the reply, @Brett_Lessner. I don't believe this would work in my case, though. The documentation shows that solution as ArcGIS Online only (Enterprise options are greyed out). I would be looking for something in Enterprise 11.5.

kvincent

Thanks for this information, @RobertKrisher! Both of those options won't allow for "live updates", though, right? So, if a new hydrant is added in the UN (by office staff, for example), there would need to be some manual work to get that hydrant into the inspections feature class? And vice versa, when a hydrant is removed, the geometry of that point would remain in the feature class?

kvincent

Hi @SaraRogers. Thank you for your reply! From @RobertKrisher's comment below, it sounds like the db view option won't work in my case with the UN. I appreciate your time sharing this, though!

Brett_Lessner

Hi @kvincent,

Have you looked into the Hydrant Inspection ArcGIS Solution? If not, I would highly recommend exploring it. Based on your post, you'll likely need to adapt the solution slightly and copy your hydrants over, but it would give you a big head start.

In addition, the ArcGIS Solutions team is currently developing a solution called Water Operations Tasks. The goal of this solution is to create, assign, perform, and monitor work, like your hydrant painting, that water utilities often need to perform. One thing we're working towards is 'associating' this work with assets instead of relationships or views. This would allow users to bring their existing asset layers to the solution without needing to alter their databases.

If you're interested, I'd be happy to discuss this further because your workflow is a prime example of what we're trying to address.

-Brett

RobertKrisher

Creating database views isn't a viable option because the data is registered as versioned. However, in the past the way I've tackled this a few different ways. One way is to have the inspection information be a feature class, whose geometry is populated when a user clicks the hydrant they want to inspect.

The other way is to create all the inspections ahead of time, with the geometries and status you want. This approach has the benefit of being able to symbolize the status in the map and provide a dashboard breaking down inspect, uninspected, and exceptions for the year.

SaraRogers

Hi @kvincent, we do not use UN yet, so there might be some nuance I am missing. However, we do quite a few inspections workflows using related tables like you mentioned. We are able to symbolize the attributes of the inspection by creating and publishing a Database View using the JOIN SQL function in the view definition in ArcGIS Pro. We take this new layer and add it to the map.

We do this with our pavement markings layer and have a related inspections table. Our field map has the following layers:

Pavement Marking Symbol (the authoritative marking layer)
Pavement Marking Status (this is the join layer: Pavement Marking + Inspections Table)
Pavement Marking Symbol Inspections (the inspections table related to the polygon layer)

In your case, my understanding would be that you create a database view (Geoprocessing tool = Create Database View), joining your Hydrant Painting table with the hydrant layer in your UN. Publish and add it to your map, then you can pull the inspection attributes in with your hydrant info to symbolize accordingly.

What I am not accounting for is how to only pull the latest inspection's status into the layer, but I think that plays into your view definition when you create the db view. I'm not an expert at this by any means, but I hope this helps get you started!

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.