Setup UNM structure best practice input.

[Maulingo]

Hello. We are in the process of combining all the information of our underground assets, and combining them in a UNM. We have a plethora of different types of assets, and I'm kind of hitting a wall when it comes to structuring the network. I'm coming at this from a road drainage perspective, but also has to think in other disciplines to add to the UNM. Sorry for the long wall, I'll get down to business.

Stormwater part:

* Should I add information about manhole dimension, to the structure table (Structure Junction - Sewer storm vault) or would that be more useful to add in another table?

* Should the information about "Last cleaned date" lie in the structure table?

* Most of our road drainage is via manholes that has a slottet inlet at the top of the manhole. I'm not sure if I should add inlets, and have them be contained inside the sewer storm vault, or if there is a way to have the manhole act as an inlet in it self. It seems rather risky to start messing about the structure tables, since I'm presuming the Structure tables will contain elements from other disciplines sometime in the very near future.

No matter how many times I read the descriptions for setting up UNM's etc. I can't get my head around the way the UNM is modelling assets and connections. It is very counterintuitive for a guy that has been used to "Place manhole dot -> define manhole dot (type, dimension, elevations etc.) -> Place next dot -> connect dots with line -> Next project."

I have access to FME, and got Python on a novice level ability, but something tells me I should not just throw all the current tabular information and dots directly into the Structure Junction -> Manhole asset group all nilly willy (do people still say that?) because I am bound to break something.

Sorry for the wall of text, and for any language errors (I'm from Denmark - Europe) but I think I have been swimming out for too long, and I can't even see the bottom anymore.

[Anonymous User]

Hey Maulingo,

All of the dataloading workflow, would ideally be something that can run automatically which is why I'm spending so much time trying to figure out what the smartest way to go about it would be. But I'll set fire to that bridge when I get to it. 

The data loading tools are not really meant to be run programmatically although they could for sure.  In my experience, it is good to use a file geodatabase to stage everything in and test.  In the data reference workbook set the "deletequery" to 1=1 and this will delete all features each time the process is run. This will allow you to not have a backup that you are constantly replacing.  Just keep trying new things in this scratch environment until you get it how you want it.  Once everything looks good in the file gdb, then apply it to a enterprise database.

Oh and another thing that sprung to mind. Would it be smart to save some time in the remapping process by defining rules for the different tables?
Example: If an assettype is of "X, Y or Z" value, set cover type to "X" value

Again, I would test all of this in a file gdb but you can also set rules to run as batch calculations so you could run them after you migrate your data. 

[VishApte]

For Sewer Networks, I would prefer to model Manholes as Sewer Devices rather than Structure Junctions. It  can then control the flow of the resource like sewer. In reality, manhole can get blocked, flooded etc. and is important to trace to/from.

I have a customer who wants to model Manhole as a Sewer Line instead of junction or device, albeit it will be a vertical line. And then model inlet and outlet as junctions that connect to manhole. I dont see anything wrong with this modeling but just haven't found courage to try implement it this way 🙂 

For inlets and outlets, I can imagine three ways to model them.

1. As attributes for manhole as a sewer device. One of my customer deployed it this way. Inlet level and type, Outlet level and type, cover type, cover elev etc were captured as attributes. 

2. Model them as sewer junctions that connect to manholes as devices. Inlet and Outlet can have Z value that represents depth or can have attribute for depth. Pipe(s) connects to inlet or outlet.

3. Model inlet and outlet as "terminals" for manholes. There will be editing overheads to specify terminals for pipes.  

Re. 80 different types of manholes, inlets etc specified by an abbreviated code, using FME's AttributeFilter transformer, you can apply filter and specify attribute mapping differently before writing to output UN feature class.

Hope this helps,

Vish

[Maulingo]

The client who would like to create the manhole as a vertical line. That actually sound smart. I have often been tasked with creating lines from top to bottom in manholes (This was in CAD software). It had something to do with the machinery used to do the excavation for new drainage systems. They have some IFC software (I think) that can read simple linetypes only. And I know length you pay for, when buying X distance pipes, is calculated from the center of the starting manhole to the center of the receiving manhole. It's certainly one way of modelling your assets 🙂

Thank you for the replies, I have started to make some progress with your suggestions 🙂

[Maulingo]

Oh, going to add a follow up question. Would there be an issue with me adding a lot of extra fields to the structure junction table to act as information holders? There are fields in the source data describing the Microstation element name of a point, the project specific coordinate system etc. It's not information needed by the UNM, but I would rather have it there and not display it, than missing the info and have a request for it down the line. You never know what need may arise, and as a good little GIScout (I'm a dad so I'm allowed to make bad puns) I would love to be able to facilitate requests. 

Again I'm afraid the performance might suffer, but I'm just not sure and if anyone have had any similar ideas and know that I will crash and burn I would love to be prepared 🙂

[Maulingo]

And another follow up!

Would it be advisable to add, change, edit rules, relations etc. In a Utility network model and then export said model as an asset package, or would you make any adjustments in an assetpackage and then applying that to a Utility network model?

If I'm reading the documentation Introduction to the asset package correctly, applying an asset package that I have made an edit in, to an existing UNM will not change the property in the UNM. Hence why I'm thinking I should make the change in the UNM, then do the exporting. This might be useful when trying to configure a package to apply to an UNM on an enterprise server. (I'm thinking the communication with the server will be slower than internal on my SSD)

I'm going to stick to the recommended coded value ranges (with overlapping ranges for shared structures between disciplines).