Ich verwende ArcGIS Pro 2.2, um eine Web-Layer sowohl als Map Service als auch als Feature Service in ein onsite Portal (10.6.1) zu veröffentlichen. Die Datenquelle ist Postgres 10.3. Das Popup ist in ArcGIS Pro konfiguriert und einige der Werte werden dekodiert, andere nicht (hervorgehoben sind die nicht dekodierten): Wenn ich das Popup im Map Service Layer im Portal-Standardkartenbetrachter aufrufe, sind die Dekodierungen korrekt: Wenn ich dann das Popup im Feature Service Layer im Portal-Standardkartenbetrachter aufrufe, sind diese Dekodierungen korrekt, aber andere werden nicht mehr dekodiert: Ich bin besorgt über die Inkonsistenz. Wenn es ein Problem mit der Art und Weise gibt, wie die Domains definiert sind, würde ich erwarten, dass wir dieselben Probleme sehen. Gibt es Vorschläge, wie man das beheben kann, oder ist das ein Bug?

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

Inkonsistenz bei der Domain-Dekodierung

JimmyBowden

<\/HEAD>

Ich verwende ArcGIS Pro 2.2, um eine Web-Layer sowohl als Map Service als auch als Feature Service in ein onsite Portal (10.6.1) zu veröffentlichen. Die Datenquelle ist Postgres 10.3. Das Popup ist in ArcGIS Pro konfiguriert und einige der Werte werden dekodiert, andere nicht (hervorgehoben sind die nicht dekodierten):<\/P>

<\/P>

Wenn ich das Popup im Map Service Layer im Portal-Standardkartenbetrachter aufrufe, sind die Dekodierungen korrekt:<\/P>

<\/P>

Wenn ich dann das Popup im Feature Service Layer im Portal-Standardkartenbetrachter aufrufe, sind diese Dekodierungen korrekt, aber andere werden nicht mehr dekodiert:<\/P>

<\/P>

Ich bin besorgt über die Inkonsistenz. Wenn es ein Problem mit der Art und Weise gibt, wie die Domains definiert sind, würde ich erwarten, dass wir dieselben Probleme sehen. Gibt es Vorschläge, wie man das beheben kann, oder ist das ein Bug?<\/P><\/BODY><\/HTML>

Finde mehr Beiträge mit dem Tag

Water Distribution

Accepted answers

MikeMillerGIS

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

],

All comments

JonathanFarmer_oldaccount

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

JimmyBowden

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.

JonathanFarmer_oldaccount

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?

JimmyBowden

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.

JimmyBowden

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.

JonathanFarmer_oldaccount

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?

RobertKrisher

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.

MikeMillerGIS

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

],

RobertKrisher

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).

RobertKrisher

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

MikeMillerGIS

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

RobertKrisher

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 😃

MyDef.zip

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

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