???Identify??? on mxd and its ???service???,

Question

Original User: Jamal432@gmail.com

�??Identify�?� on mxd and its �??service�?�,

I�??m wondering why the �??identify�?� introduces different results if a particular feature is clicked on mxd and its services.

For example, in the screenshots below, as the same feature class is clicked by the �??identify�?� tool, then different �??display fields�?� are shown. In case of mxd, the values of �??ZoneClassification_Arabic�?� field are shown while in case of the �??service�?� the values of �??ZonecommunityName_Arabic�?� field are shown.

[ATTACH=CONFIG]30543[/ATTACH], [ATTACH=CONFIG]30544[/ATTACH]

This is despite the fact that the �??ZoneClassification_Arabic�?� field is set to be the �??display field�?�

[ATTACH=CONFIG]30545[/ATTACH]

What might be the issue here?

Why the behavior of the "identify" is different between the mxd and its service?

Thank you

Best

Jamal

Clip_3.jpg

Clip_2.jpg

Clip_4.jpg

AnnettePoole1_0-1644268956755.jpeg

SarahBell_0-1644268891648.png

bug-report-2020-11-17.gif

JamalNUMAN · Answer

Jamal,

I already pointed out another thread discussing display expressions and webservices in my previous post. It is an older thread (2011), and may no longer be accurate / relevant, but at least then, the REST API did not (fully) support display expressions from layers.

Also, the 10.2 Help talks about a default setting for the display expression. If webservices still do not support it, they may follow the same convention, that is:

"The display expression defaults to the first field of string type that contains the text name (case insensitive) in the field name. If no name field exists, the display field defaults to the first field of string type, then the first field of integer type, then the first field of any type."

This would at least explain the behaviour you are seeing in ArcGIS. Since ArcMap probably can not read the "display expression" property for your Map Service, ArcMap goes for the next best option, that is, to default to the first field with "name" as part of the field name. In your case, this is:

ZoneCommunityName_Arabic

I can't really comment on the behaviour of the web application in this regard. It may be a related issue, it may be not. You were using Geocortex, if I remember well. I don't know how it handles this stuff, you may need to contact Latitude Geographics for an answer.

Many thanks Marco for the prompt help and valuable input

Fortunately, the Geocortex has the option to override whatever set at the level of the mxd or its service as display field.

[ATTACH=CONFIG]30611[/ATTACH]

However, the problem persist to exist between the ArcGIS Desktop and the ArcGIS Server. This behavior does match your explinations

1. The display is set to be �??ZoneClassification_Arabic�?�

[ATTACH=CONFIG]30612[/ATTACH]

2. When a feature is clicked by the �??identify�?� tool in the mxd then the obtained values is from the �??ZoneClassification_Arabic�?� (correct)

[ATTACH=CONFIG]30613[/ATTACH]

3. Wehen the feature is lciked is clicked by the �??identify�?� tool in the mxd service then the obtained values is from the �??ZoneCommunityName_Arabic (incorrect).

[ATTACH=CONFIG]30614[/ATTACH]

I�??m not sure if this problem is resolved in 10.2.1

Clip_851.jpg

Clip_852.jpg

Clip_850.jpg

Clip_849.jpg

Anonymous User · Answer

Original User: mboeringa2010

Jamal,

I already pointed out another thread discussing display expressions and webservices in my previous post. It is an older thread (2011), and may no longer be accurate / relevant, but at least then, the REST API did not (fully) support display expressions from layers.

Also, the 10.2 Help talks about a default setting for the display expression. If webservices still do not support it, they may follow the same convention, that is:

"The display expression defaults to the first field of string type that contains the text name (case insensitive) in the field name. If no name field exists, the display field defaults to the first field of string type, then the first field of integer type, then the first field of any type."

This would at least explain the behaviour you are seeing in ArcGIS. Since ArcMap probably can not read the "display expression" property for your Map Service, ArcMap goes for the next best option, that is, to default to the first field with "name" as part of the field name. In your case, this is:

ZoneCommunityName_Arabic

I can't really comment on the behaviour of the web application in this regard. It may be a related issue, it may be not. You were using Geocortex, if I remember well. I don't know how it handles this stuff, you may need to contact Latitude Geographics for an answer.

JamalNUMAN · Answer

I don't have an ArcGIS for Server installation running to test this, but I guess it may have to do with you still needing to "refresh" some of the data or service configuration on the server to notify it of the change.

What happens if you re-publish the service after changing the display expression?

Other option is that display expression aren't supported on services, and ArcGIS merely picks the first field after the Shape field to use as "display expression", but again, this is just speculation on my side.

Well, I don't know if this still holds since it is an older thread, but this thread seems to suggest something like the latter:

http://forums.arcgis.com/threads/43945-Display-Field-Expression

Thank you very much Marco for the help.

What confuses me the most that I have deleted the service and republished it again but the problem persists to exist. The service doesn�??t respect the �??display field�?� assigned on the mxd and thus when a particular polygon is clicked with the �??Identify�?� tool, the result doesn�??t represent the field assigned on the �??display field�?�.

This problem is transferred to the web mapping application as sometimes the web mapping goes to the field assigned on the mxd and in other cases it goes for the values of the service

[ATTACH=CONFIG]30556[/ATTACH], [ATTACH=CONFIG]30557[/ATTACH], [ATTACH=CONFIG]30558[/ATTACH]

What might be the issue here?

Clip_34.jpg

Clip_32.jpg

Clip_33.jpg