Nieuws

ArcGIS Utility Network: evaluatie naar inzetbaarheid van versie 7

Geschreven door Maja D'Haen | Apr 23, 2026 6:00:00 AM

Auteur: Katrien Verbeeck

Is het ArcGIS Utility Network (UN) een geschikte standaard voor modern netwerkbeheer? In deze blog onderzoeken we of het Utility Network een antwoord kan bieden op de huidige complexiteit van het energielandschap.

Voor wie is het ArcGIS Utility Network aangewezen?

Het UN geldt als de moderne standaard voor het beheren van nutsnetwerken. Het managen van een elektriciteits-, gas-, telecom- of (afval)waternetwerk is complex en vereist een hoge mate van schaalbaarheid, tracing en datakwaliteit. Hoe groter het verzorgingsgebied of hoe meer soorten nutsvoorziening in beheer, hoe interessanter het wordt om over te stappen naar het UN.

Architectuur: service-based en rule-driven netwerkmodellering

Het UN is volledig service-based binnen ArcGIS Enterprise (kleine kanttekening: het is tegenwoordig mogelijk om bv. voor POC of studie-doeleinden een UN enkel op een geodatabase (gdb) offline te laten draaien). REST feature services zullen alle acties afhandelen die een gebruiker op het netwerk uitvoert: CRUD, tracing, validatie, …

Er zijn een aantal architecturale vereisten waaraan voldaan moet worden:

  • De feature classes moeten geregistreerd zijn met een enterprise geodatabase en moeten aangesproken worden via branch versioning. Hierdoor wordt het ondersteunen van multi-user editing mogelijk gemaakt, waarbij de users automatisch elk in hun eigen sessie kunnen werken. Via reconcile, post en eventuele conflict handling raken de uitgevoerde aanpassingen vervolgens in de SDE.default.
  • De features moeten deel uitmaken van een feature dataset, m.n. een Utility Network dataset. Deze bevat naast de feature classes ook alle systeemtabellen die de netwerk logica opbouwen en afdwingen. Via de properties van de UN laag in de map kan je de meeste van deze eigenschappen opvragen (o.a. utility network rules, domain specificaties, asset groups & asset types,…).
  • De UN service zelf moet gepubliceerd worden als een branch versioned feature service. Deze ontsluit het UN via REST voor verschillende clients zoals ArcGIS Pro of web apps.


Figuur 1: Softare componenten van een Utility Network

De utility network rules die hierboven aangehaald worden, bepalen via white listing welke assets binnen het netwerk geconnecteerd of geassocieerd mogen worden met elkaar. Deze worden gedefinieerd op het niveau van de asset groups en asset types. In de paragraaf Associaties wordt hier dieper op ingegaan.

Hiernaast bestaan er ook attribute rules, onderverdeeld in drie types:

  • Calculation Rules. Deze worden typisch gebruikt tijdens het editeren om bv. automatisch een uuid te genereren bij een nieuw geplaatste feature.
  • Constraint Rules. Met deze rules kan je vermijden dat foutieve (combinaties van) waarden ingevuld worden. Bv. een bepaald type kabel heeft altijd een bovengronds voorkomen.
  • Validation Rules. Deze worden ingezet op een later moment in het proces om de gebruiker niet te hinderen bij het intekenen. Het uitvoeren van de rules betekent immers een zekere performantie hit. Dit kan bv. gebruikt worden om te controleren of er geen tekenfouten gemaakt zijn zoals een verlichtingstoestel te ver van een paal.

Het datamodel

Domain en structuur netwerk

Een utility netwerk bevat altijd één of meerdere domain networks, meestal één per discipline. Hierin zitten de assets vervat die effectief de discipline vervoeren of waar deze gemanipuleerd worden, zoals een elektriciteitskabel, verlichtingstoestel of een gasafsluiter. Deze worden vaak opgehangen aan of gecontained in een fysieke drager. Dit is het structuur netwerk van palen, mantelbuizen en gebouwen.

Wanneer een organisatie meerdere disciplines in zijn beheer heeft, moet de overweging gemaakt worden om een structuurnetwerk per domain netwerk aan te maken of dat alle structuur assets in één structuur netwerk ondergebracht worden en dus gemeenschappelijk is over alle domeinen heen. De laatste optie sluit meestal het best aan bij de praktijk en is ook technisch het meest lean omdat je geen redundante data gaat creëren. Echter stelt dit wel (kleine) uitdagingen naar map visualisatie toe, want meestal wordt immers de vraag gesteld om te kunnen visualiseren per utility en dan liefst mogelijk ook nog te switchen binnen dezelfde map. Het is dan niet de bedoeling om ook nog de structuur assets te zien waarin of waaraan geen assets zitten van de utility of interest. De flexibiliteit en uitbreidbaarheid van het utility datamodel toont hier dan één van zijn sterktes.

Figuur 2: Basis van het Utility Network datamodel

Associaties

Naast fysieke geometrische connectiviteit is er ook de mogelijkheid om connectiviteit op te bouwen via associaties. Hierbij zijn verschillende types te onderscheiden:

  • Connectivity association: hier vloeit de utility tussen de 2 geassocieerde features. Een connectivity association is eigenlijk inwisselbaar met een lijn feature, maar het is een keuze om het niet te doen. Enkele tips voor wanneer je een associatie zou verkiezen boven een fysieke lijn zijn:
    • Het gaat om een beperkte lengte zoals bv. de aansluitkabel van een verlichtingstoestel naar het aftakpunt op de voedende kabel.
    • Het gaat om de interne wereld van bv. een cabine. Via de associations view kan je er dan gemakkelijk voor kiezen om de associaties in bepaalde gevallen wel of niet te tonen om de kaart view te ontdoen van clutter.
  • Structural Attachment association: deze vormen de overgang van het utility domain network naar het structuur netwerk. In de praktijk gaat het meestal over structure junctions (palen) waaraan één of meerdere assets hangen.
  • Containment association: hiermee bepaal je welke assets onder een andere asset horen, wat dit in mijn mening een zeer krachtig type associatie maakt. Immers, geneste containment associaties behoren eveneens tot de mogelijkheden. Containment associaties kunnen bestaan binnen hetzelfde domain network of tussen het domain network en het structuur netwerk. Een goed (sterk gesimplifieerd) praktijkvoorbeeld is dat van een distributiecabine voor elektriciteit. De cabine bestaat als ElectricAssembly en als StructureBoundary waarbij de assembly gecontained zit in de structure. De cabine ElectricAssembly op zijn beurt bevat dan alle elektrische elementen. Op het eerste niveau kunnen de verdeelborden zitten, ook als assembly met op een niveau daaronder de zekeringen als ElectricDevices.

Ook attachment en containment associaties zijn intuïtief raadpleegbaar, wat van hen ook een grote troef maakt. De attribute pane bij een selectie laat zien welke features gecontained zijn in de geselecteerde feature en tot welke containment deze geselecteerde feature op zijn beurt behoort.



Figuur 3: Voorbeeld van associaties zichtbaar via associations view & attributes pane

Nog een belangrijke voorwaarde om associaties te kunnen leggen tussen twee features in het netwerk is dat de associatie tussen die twee asset types toegelaten is via de Utility Network Rules.

Figuur 4: Containment relaties via Network Properties pane van Utility Network layer

Dit betekent ook dat voor het aanpassen van deze associatie rules (voornamelijk het verwijderen ervan) dat er moet nagegaan worden of deze al dan niet reeds in gebruik waren in het netwerk, wat logisch is. Maar een addertje (of beter gezegd een bug) onder het gras hier is dat als je gebruik maakt van preset templates, waarin de te verwijderen associatie verwerkt is, deze corrupt wordt. In ArcGIS Pro 3.5.6 met UN v.7 is er geen mogelijkheid om de associaties in templates te raadplegen of (via de client interface) aan te passen. De verwachting is dat dit nog opgelost wordt.

Topologie

Wanneer er CRUD acties gedaan worden op het netwerk, heeft dit invloed op de connectiviteit en topologie. Deze geven aanleiding tot de introductie van dirty area’s. Deze kunnen grosso modo ingedeeld worden in gewoon dirty area of een error. Dirty betekent dan dat het netwerk op die plaats aangeraakt is en louter opnieuw gevalideerd moet worden, terwijl bij een error area effectief fouten gemaakt zijn tegen de netwerk rules of attribute rules en deze opgelost moeten worden alvorens het netwerk gevalideerd kan geraken.

Conclusie

Het Utility Netwerk is door de jaren heen uitgegroeid tot een volwaardig GIS systeem om assets die deel uitmaken van een nutsnetwerk te managen. Uiteraard zijn er nog steeds verbeteringen mogelijk, maar de technologie is met v.7 volwassen genoeg om geïmplementeerd te worden. Versie 7 is compatibel met ArcGIS Pro vanaf 3.3 en met ArcGIS Enterprise vanaf 11.3. Deze blog is echter geschreven vanuit de ervaring met ArcGIS Pro 3.5 en Enterprise 11.5.