topic Re: Domain decode inconsistency in Water Utilities Questions

Domain decode inconsistency

JimmyBowden — Thu, 02 Aug 2018 21:19:19 GMT

I’m Using ArcGIS Pro 2.2 to Publish a web layer to both a map service and a feature service to an onsite Portal (10.6.1). The data source is Postgres 10.3. The popup is configured in ArcGIS Pro and some of the values are decoded and others are not (highlighted are not decoded):

When I access the popup in the map service layer in the Portal default map viewer the decodes are correct:

Then when I access the popup in the feature service layer in the Portal default map viewer those decodes are correct but other ones are no longer decoded:

I’m concerned about the inconsistency if there is a problem with the way the domains are defined I would expect that we would see the same issues. Any suggestions on how to fix this or is this a bug?

Re: Domain decode inconsistency

JonathanFarmer_oldaccount — Mon, 06 Aug 2018 20:46:08 GMT

Hi Jimmy,

I have a couple of things you can check here:

In ArcGIS Pro, before you published, did you check the box in the attribute table options to "Show domain and subtype descriptions"? This would be for every field in the layer but a good thing to know.
I also wonder if the maxDomainCodeCount could be causing an issue here? It represents the maximum number of domain codes that can be returned.Try updating this parameter to a larger value and seeing what you get.
1. Set map service properties—Documentation | ArcGIS Enterprise
We do have some bugs on this issue for Web App Builder and Collector, are you using either of those? They are pretty specific bugs but I can get some details on those if needed.
Did you apply the domains through a subtype on the feature layer? Or are you applying the domains directly to a field?

Thanks,

Jonathan

Re: Domain decode inconsistency

JimmyBowden — Wed, 08 Aug 2018 00:42:51 GMT

Thanks Jonathan,

1. Yes that box is checked. And as shown in my first image even in ArcGIS pro the decode isn't working.

2. I upped the maxDomainCodeCount to 50000 then to 75000 and didn't get different results.

3. No

4. We are applying domains to both subtypes and at the field level.

Re: Domain decode inconsistency

JonathanFarmer_oldaccount — Wed, 08 Aug 2018 22:33:51 GMT

Hi Jimmy,

Thanks for the reply. Is this specific to one feature class (and thus one service) or can you reproduce this on multiple feature classes (and multiple services) in your PostgreSQL database? If it is specific to one, have we tried republishing to see what impact that has?

Re: Domain decode inconsistency

JimmyBowden — Mon, 13 Aug 2018 18:20:34 GMT

I've done some additional testing and this issue seems to be related to using the Water Utility Network asset package as a source for the data structure. Feature classes created by different processes seem to be working.

Re: Domain decode inconsistency

JimmyBowden — Mon, 13 Aug 2018 21:14:54 GMT

With further testing I have found a couple of items.

When data modeling you must have a domain applied at the subtype level even if it's the same as is applied at the field.
I can replicate the issue with the feature service by creating symbology that does not use the "asset group" field. If I symbolize off of another field(s) (asset type) then the domains do not decode in a feature service. This is an issue when I want fire hydrants, valves, service connections, etc in individual layers that can be turned on/off independently.

Re: Domain decode inconsistency

JonathanFarmer_oldaccount — Mon, 13 Aug 2018 21:24:40 GMT

Jimmy,

Can you reproduce this outside of the Utility Network Management Extension? With just a standard feature class published as a feature layer in Pro?

Re: Domain decode inconsistency

RobertKrisher — Mon, 13 Aug 2018 22:08:41 GMT

Jimmy,

I've run into this issue with the UN extension with a slightly different case (for which there is a bug that is logged).

You can also replicate this behavior my sharing a web map authored in ArcGIS Pro (take a fully functional layer like the one you've published it, pull it into pro, share the web map, now that map is broken).
My way around this is to publish my initial feature service just using the asset group field, since I usually need to apply additional configuration (definition queries, additional symbology, etc) in a web map to make use of the data. Because of the previous point I'm left authoring maps in Portal / AGOL until they resolve the bug.

Re: Domain decode inconsistency

MikeMillerGIS — Mon, 20 Aug 2018 13:06:33 GMT

All, here are some details of how subtypes are supported in the definition of the layer.

Summary:

The renderer is required to match the list of subtypes exactly as this is how values assigned at the subtype level are stored in the definition of the service.

Details:

The service definition for a layer has a parameter “typeIdField”, Once would think this is for the subtype of a layer, but it is not. It defines the field the unique value render is based on:

Here is a simple example where the typeIdField is based on a string field, this clearly shows that this parameter is not for subtypes as a subtype can never be based on a text field:

"typeIdField" : "Render",

If you review the types of the json:

"types" : [

      "id" : "Blue",

      "name" : "Blue",

      "domains" :

        "Render" : {"type" : "inherited"}

},

      "templates" : [

          "name" : "Blue",

          "description" : "",

          "drawingTool" : "esriFeatureEditToolPoint",

          "prototype" : {

            "attributes" : {

              "Render" : "Blue"

},

You can see domains based on the renderer types. Since this is not a subtype layer in the example above, the domain is inherited from the field

Now compare this to a layer with subtypes and renderered by the subtype:

- "typeIdField" : "subtypetest",

Now review the types, you can see that the one subtype(1) has the domain that is set at the subtype layer, where the first one(0) is using the value specified at the field(inherited)

"types" : [

      "id" : 0,

      "name" : "New Subtype",

      "domains" :

        "Render" : {"type" : "inherited"}

},

      "templates" : [

          "name" : "New Subtype",

          "description" : "",

          "drawingTool" : "esriFeatureEditToolPoint",

          "prototype" : {

            "attributes" : {

              "Render" : null,

              "subtypetest" : 0

},

      "id" : 1,

      "name" : "other",

      "domains" :

        "Render" :

          "type" : "codedValue",

          "name" : "testother",

          "codedValues" : [

              "name" : "blah",

              "code" : "blahcode"

},

              "name" : "foo",

              "code" : "boo"

},

      "templates" : [

          "name" : "other",

          "description" : "",

          "drawingTool" : "esriFeatureEditToolPoint",

          "prototype" : {

            "attributes" : {

              "Render" : null,

              "subtypetest" : 1

],

Re: Domain decode inconsistency

RobertKrisher — Wed, 22 Aug 2018 12:22:52 GMT

This still sounds like a bug. Just because I'm symbolizing off of something other than the subtype field doesn't mean that I should lost all of my domain and subtype information. The other thing is that if I author a web map using Portal or AGOL I won't lost all the subtype and domain information. Using AGOL or Portal to author all my web maps isn't a good workaround at this point because I have hundreds of customer symbols across half a dozen styles that I need to use in my map and there's no way for me to load a custom style into my ArcGIS Enterprise site (unless its a style for 3d points).

Re: Domain decode inconsistency

RobertKrisher — Thu, 23 Aug 2018 13:03:48 GMT

Michael,

I just revisited this and @ 10.6.1 with ArcGIS Pro 2.2.1 I lose domains and subtype descriptions in my map document definition in a shared web map even if I symbolize using only the subtype field. If I look at the map definition I can see that the domains element is blank (even though the field has domains) and even though the type has an id its still unrecognized as a subtype by the map (I wouldn't the order would matter, but the id is typically at the beginning of the json element but for a pro web map its located at the end).

"types": [           {             "name": "Anode",             "domains": {                            },             "templates": [               {                 "name": "Anode",                 "prototype": {                   "attributes": {                     "assetgroup": 15,                     "assettype": 0,                     "rotation": 0,                     "insulatordevice": 0,                     "ownedby": 1,                     "cpsubnetworkname": "Unknown",                     "depth": 0,                     "terminalconfiguration": "Default",                     "devicestatus": 1,                     "accessible": 1,                     "maintby": 1,                     "lifecyclestatus": 3                   }                 },                 "drawingTool": "esriFeatureEditToolPoint"               }             ],             "id": 15           },

Re: Domain decode inconsistency

MikeMillerGIS — Thu, 23 Aug 2018 18:24:45 GMT

I am not sure, can you zip up the entire rest def so I can look at it?

Re: Domain decode inconsistency

RobertKrisher — Thu, 23 Aug 2018 18:32:39 GMT

I've included a copy of the service definition and the ArcGIS Pro Web Map definition. I thought about including the web map definition from a map created in ArcGIS Enterprise, but it behaves exactly as you described 😃

Re: Domain decode inconsistency

MikeMillerGIS — Thu, 23 Aug 2018 18:56:42 GMT

The service def looks correct. You can see the definition in the types. The layer definition in the webmap from ArcGIS Pro looks wrong. Looks like a legit bug. I would suggest logging it.

Service Def

Layer Def in webmap from pro