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?
Solved! Go to Solution.
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:
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
}
}
}
]
}
],
Hi Jimmy,
I have a couple of things you can check here:
Thanks,
Jonathan
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.
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?
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.
With further testing I have found a couple of items.
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?
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).
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:
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
}
}
}
]
}
],
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).