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; } } }

WebGIS Best Practices? - All fields MUST be visible when publishing ArcGIS Utility Network with Branch Versioning

JonathanDaweEsriUK

Hi Utility Network,

We are trying to understand the best practice advice for handling field visibility in the Web for Utility Network Services.

In ArcGIS Pro we have configured our data into subtype group layers and as part of this have altered the field visibility inside of the subtypes in order to only show applicable fields for our network assets (a number of fields are set to not visible).

We have noticed that when publishing a hosted version of our service with branch versioning that this results in an error that prevents publishing: 00302: All fields in datasets with <value> must be visible: field <value> in layer <value> is not

Ideally we want any client working with the hosted service to be able to inherit the correct field visibilities from the service, otherwise we will need to configure every location where the service is used to re-set this information which is a major configuration overhead….

Has anyone encountered this issue? Is there any guidance on how best to handle field visibility?

Encuentra más publicaciones etiquetadas con

Accepted answers

RobertKrisher

@TóthRóbert you can use the un properties extractor to extract all your field properties to a file, update them, then re-import them over a map. You can also copy/paste field properties between layers and different maps using the "Paste Properties" context menu option..

All comments

Anonymous User

Hey Jonathan,

We have encountered this issue as well when trying to publish. Our "work around" is to publish the service with all fields visible and then use the Editor Template that comes with the Esri solution to control field visibility. The real push needs IMO needs to be for the ability to publish subtype group layers--that limitation is indeed huge. We have also published services based off the UN for field editing and spent a tremendous amount of time configuring the individual services after they were published. We also encountered issues when building a def query to limit asset groups/types -- the web map doesn't display domain descriptions--just the codes.

I wish I had a better answer--I hope someone does. We have seen this and always plan for a sufficient amount of time to configure pop ups and field visibility in the web map/service.

PhilDunn

Your question is not unusual, Jonathan. Working with UN services is a bit of a paradigm shift with respect to how we look at geospatial services. As you discovered, you must expose all of the fields with your UN service if your intent is to access the service with Pro. If your intent is to publish without the UN service, the restrictions are lessened. The link below is very informative about this topic:

https://pro.arcgis.com/en/pro-app/latest/help/data/utility-network/publishing-and-consuming-services-with-the-utility-network.htm

AnthonyRyanEQL

Jonathan,

Could you please post the link that talks about hosted services having branch versioning capabilities. This sounds really interesting. Thanks

JonathanDaweEsriUK

Thanks Randall, its useful to know that this is a challenge that others share! It would be useful if the ArcGIS Pro publishing process could ignore field visibilities, but store them somewhere in the hosted service that is created.

After posting this I had a look at a semi-programmatic solution to the issue. I built a simple script that parses an ArcGIS Pro map file (which is essentially a json file) and extracts out all of the field visibility settings for the fields in each of my subtype group layers. I then apply this to a webmap/application definition and overwrite the portal item data.

The process has some manual parts due to the requirement due to having to physically match up some of my map file layers and the layers that are in the portal item.

Brian_Colson

@AnthonyRyanEQL ,

I think this is what you are looking for https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/overview/publish-branch-versioned-data.htm .

VishA

@JonathanDaweEsriUK

Your question is quite valid and there is no easy answer. With the under-normalised data model prescribed for the Utility Network, there should be some tools available to configure field visibility etc. Ideally, applicable fields should be configurable at the subtype (assetgroup) level just like domain names and default values. e.g. it is logically incorrect to display "Winding Type" for all devices when it is applicable only to a "Transformer" device. Other option is to provide relationship table at a subtype level e.g. TransformerAttributes as a related table only for Transformer subtype/assetgroup. We can then keep bare minimum attributes at Device/Line/Junction/Assembly level and all other attributes can be set as related tables for specific subtype.

Cheers,

Vish

TóthRóbert

A little later than you 🙂 but we are struggling with the same problem.

Given that all devices or junctions are in a single feature class, there are many fields that are not relevant for each AssetGroup=Subtype. These should be disabled. Not only in the pop-up config, but everywhere in general.

Before publishing the Feature Service with UN, none of the fields can be turned off.

So, to compile a map for publishing(/sharing as a WebMap), the data source for the Subtype Group Layers will be the Feature Service and not the database feature classes.

Then we save/share the configured map symbolized in this way as a WebMap.

We made a deep dive:

Pro does not treat the following two cases in the JSON schema "behind" aprx in the same way:

A: When the Map still exists "only" as a Project Item, (a regular Map before sharing the WebMap)

B: When the Map has already been published/shared as a WebMap and the WebMap has been downloaded (Add and open) and we are working on it in Pro. [This is the version that needs to be addressed, because WebMap must be able to change even after deployment.]

The schema of the downloaded and referenced WebMap CIM is more complex than usual Map behind APRX.

There is a JSON named based on a GUID which is the portal item of the downloaded (add an open) WebMap itself.

Which GUID to search for? can be found in GISProject.json.

In this file, we find that each layer has its own JSON, and if it is a Group or Subtype Group layer, each sublayer also has its own JSON. This is always referenced by its parent with a GUID.

This is how you should search for a specific JSON belonging to a "subtype group layer --> subtype

layer".

Pro stores the visibility of the field in this JSON. specified layer --> featureTable --> fieldDescriptions --> [id] --> visible: false/true

However, when we publish this on the actual WebMap, the portal saves the entire map as a single JSON file.

In JSON, this information is stored in a completely different way and in a different place:

For the layer where even a single field has one of the following properties set

Visibility
ReadOnly
Alias

It creates a fieldOverrides array in the json and lists ALL fields with potentially modified properties, EXCEPT FOR THE FIELD WHOSE VISIBILITY WE HAVE DISABLED IN PRO.

This array in WebMap can also be found here in the specification: https://developers.arcgis.com/web-map-specification/objects/fieldOverride/

However, there is no mention in the documentation that WebMap stores the visibility of a field in such a way that it creates a list containing the names of all other fields except for the one whose visibility is turned off.

If I’m right(?) this fieldOverrides attribute can ONLY be edited under PRO. There is no interface for it under MapsSDK for JS, and the portal cannot see it at all.

Consequence in WebMap:

So, if there is a fieldOverrides array for a layer in WEB MAP:

Then, the items listed there will influence which layers FieldInfo returns in the Maps SDK for JS and what properties they have.

If a layer does not have a fieldOverrides array, FieldInfo returns the original list provided by the service or the values specified in WebMap's own popupInfo --> fieldInfos.

In this Blog: https://www.esri.com/arcgis-blog/products/js-api-arcgis/developers/subtypegrouplayer-with-arcgis-api-for-javascript#:~:text=by%20Russell%20Roberts.-,More%20features%20of%20the%20SubtypeGroupLayer%20that%20we%20can%20take%20advantage%20of%20with%20the%20JS%20API,-In%20the%20previous

They suggest setting this in PopUp config. But if I want to disable the field for the given subtype layer in all other respects, this is not a solution.

What is the easiest way to solve this programmatically without having to click around in Pro for a week 🙂 ?

We think the best solution is to write the fieldOverrides arrays directly into the WebMap stored on the Portal using a JS script. And we leave out the irrelevant fields based on a configuration. This can be done in JS, and although it's not very elegant, BUT it seems MUCH simpler than the CIM-based solution with py in Pro.

What do you think?

Have you found a solution? What was it?

Regards,

Robert

RobertKrisher

TóthRóbert

@RobertKrisher Thanks a lot for the tip.
The funny thing is that I already have this AddIn downloaded and I used it to compile aprx. But somehow I didn't look through everything I could do with it 🙂
I'm testing it to solve this problem and it works great.
Thanks again.
Best regards,
Róbert

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

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