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

Inconsistência na decodificação de domínio

JimmyBowden

<\/HEAD>

Estou usando ArcGIS Pro 2.2 para publicar uma camada web tanto como um serviço de mapa quanto como um serviço de feição em um Portal local (10.6.1). A fonte dos dados é Postgres 10.3. O popup está configurado no ArcGIS Pro e alguns dos valores são decodificados e outros não (os destacados não estão decodificados):<\/P>

<\/P>

Quando acesso o popup na camada do serviço de mapa no visualizador padrão do Portal, as decodificações estão corretas:<\/P>

<\/P>

Então, quando acesso o popup na camada do serviço de feição no visualizador padrão do Portal, essas decodificações estão corretas, mas outras não são mais decodificadas:<\/P>

<\/P>

Estou preocupado com a inconsistência; se houver um problema com a forma como os domínios são definidos, eu esperaria que víssemos os mesmos problemas. Alguma sugestão de como corrigir isso ou seria um bug?<\/P><\/BODY><\/HTML>

Encontre mais publicações marcadas com

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

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

MikeMillerGIS

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

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

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

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

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.

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?

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.

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.

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

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,

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

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

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