topic Re: Migration Data Constructed Different Than UN Standards in ArcGIS Utility Network Questions

Migration Data Constructed Different Than UN Standards

SSMIC3038 — Tue, 16 Mar 2021 14:11:16 GMT

We have a lot of GIS data and an example of one issue is sewer pipe connections. We use one standard approach of pipes connect directly to manholes.

In UN the Manhole is a container with 2 pipe connection points, the pipes actually connect to the connection points and not the manhole. Ok, I see the logic in the construction technique. But how are people porting thousand of existing manhole/pipe connections from geometric network into utility network?

The load will bring in the old construction method (pipes connect to manhole) which is not proper build for UN. Does each manhole have to be visited, post load, and manually rebuilt as container with 2 pipe connection points and then snap lines to those points?

Re: Migration Data Constructed Different Than UN Standards

AlexKabak — Tue, 16 Mar 2021 18:49:19 GMT

Hello,

With the currently released Sewer UN models, this type of manhole editing is done manually.

We are simplifying this in the next release by providing a couple of attribute rules that will automate this process. The automation will work with both editing and migrating data.

Re: Migration Data Constructed Different Than UN Standards

Anonymous User — Tue, 16 Mar 2021 19:18:09 GMT

One thing we have done in the past is a "double mapping" of sorts. We use the esri data loading tools to map the manhole to both pipe connections and manholes. Just add it as a source twice and map one to device the other to structure junction. This will bring everything in with the pipe snapped to the connection to provide network connectivity.

Re: Migration Data Constructed Different Than UN Standards

SSMIC3038 — Tue, 16 Mar 2021 19:28:01 GMT

Wouldn't the result be 3 points stacked atop one another? Since the source manhole is seeding the 2 pipe connections and the new manhole.

Actually, this got me thinking that there's probably a way in the source data to break lines a set distance (3m) from each manhole (buffer/clip??) which then creates geonet errors on the pipe ends, those errors could likely be isolated and used to seed the pipe connection in UN. The stub (3m) pipe segments could also likely be isolated and deleted.

Re: Migration Data Constructed Different Than UN Standards

AlexKabak — Tue, 16 Mar 2021 19:38:06 GMT

The first rule triggers when a manhole is added to a map. It will automatically add and contain a Manhole Channel (this is a device and new feature).

The second rule triggers when a pipe is snapped to the manhole channel. It pulls the pipe back 2 feet, adds a pipe connection, contains the pipe connection, and connects the pipe connection by association to the manhole channel. This attribute rule occurs when a pipe ends at a manhole or begins at a manhole.

Re: Migration Data Constructed Different Than UN Standards

SSMIC3038 — Tue, 16 Mar 2021 19:42:29 GMT

That's pretty impressive, are you referring to the new tools your working on or Randall's double mapping approach in the current model?

Re: Migration Data Constructed Different Than UN Standards

AlexKabak — Tue, 16 Mar 2021 19:44:46 GMT

They are new Attribute Rules that will be included in the next release of Sewer UN

Re: Migration Data Constructed Different Than UN Standards

CherylTrine — Tue, 16 Mar 2021 20:23:10 GMT

When is the next planned release of Sewer UN?

Re: Migration Data Constructed Different Than UN Standards

Anonymous User — Wed, 17 Mar 2021 09:48:00 GMT

In our experience, no. However all source data we have come across is typically one point to represent a manhole. We double map this single manhole to both pipe connection and structure junction/manhole. It should be noted, this doesn't account for the container addition. That manual work still has to be done. This just allows full network connectivity while still modeling the manhole asset as well in the structure network.

Re: Migration Data Constructed Different Than UN Standards

AlexKabak — Wed, 17 Mar 2021 13:16:45 GMT

Hi Cheryl,

We are targeting the 10.9 release, which should be in Q2, likely May or June.