ID Widget 3.6.5: offset between identified pixel and blue circle for non-WGS84 datums

[BarnabyRockwell]

Hello Robert and others,

I have raster data layers with NAD27 datum in an mxd with GCS_WGS_84 data frame projection.  The NAD_1927_To_WGS_1984_6 transformation is being applied in the data frame to convert the NAD data to WGS84.  The mxd is published to a service and displayed in a Flex 3.6 app along with ESRI basemaps (inherently in WGS 1984 Web Mercator (aux sphere), EPSG 3857).

https://www.sciencebase.gov/flexviewer/USMinMap/

The NAD27 raster data layers are re-projected on the fly to WGS84 and overlie the basemaps and other data perfectly.  Using ID Widget 3.6.5, queries of pixels operate perfectly, with the correct attribute being reported for a pixel.  However, the blue circle generated by the widget is offset from the pixel which was queried (clicked).

[ATTACH=CONFIG]31957[/ATTACH]

To see what I mean, go to the above Flex app and turn on Regional Studies>Bodie Hills, CA-NV and zoom way, way in.  Turn off Landsat layer at bottom of TOC.  Then use ID widget to query an individual pixel and note offset between clicked pixel and blue circle.

If the image is reprojected to WGS84 datum before publishing, there is no offset between clicked pixel and the blue circle.

I am wondering if the widget should generate the blue circle based on the coordinate units sent to the server for the query (which I think are in the "service" coordinates, WGS84 Web Mercator aux sphere), and not in the units reported back from the data layer being queried (NAD27).  As it is now, it appears that the offset will be there any time a layer having a non-WGS84 datum is in a Flex App.  Is there a way to remove the offset other than reprojecting the NAD27 data to WGS84?

Or is the offset an expected feature that is meant to show that the layer being queried has a different coordinate system/datum than the service or overall Flex app?

Thank you in advance...

[RobertScheitlin__GISP]

Barnaby,

   OK, So I am a little confused... You are saying that the raster data is NAD 27 and the MXDs dataframe is set to WGS1984 (WKID 4326). Yet when I check the map service it is reporting:

arcgis/rest/services/usminmap/Regional_Studies_pub/MapServer

Spatial Reference: 102100  (3857)

What you are reporting (I have checked and can verify), is not the intended behavior. For me to find some time to look at this, I really need to understand your exact configuration.

As a side not you need to clean all the unused layers from your IdentifyWidget_1.xml so that you can improve performance (you probably do not see the error if you do not have Flash Player Debugger, but the widget is trying to connect to all my sample map services that were originally in the XML and erroring out due to crossdomain.xml restrictions).

[BarnabyRockwell]

Hi Robert,

Thank you for your reply.  You are correct.  I'm working with 2 servers, their configurations below.

sciencebase.gov:

Server 10.2/Flex 3.6/ID Widget 3.6.5
Regional Studies data frame projection: WGS 1984 Web Mercator (aux sphere), EPSG 3857

internal private server:

Server 10.2.1/Flex 3.6/ID Widget 3.6.5
Regional Studies data frame projection: GCS_WGS_1984, EPSG 4326

I see the offset in both of the above configurations when the widget is used to query data that are in UTM/Clarke 1866 spheroid/NAD27 datum.  There is no offset when data are in UTM/WGS84 datum.

----------------------

I'll strip out your layers from my widget XML.  Did you notice that I followed your advice and edited the XML heavily so that only the desired fields are reported by the widget from my raster layers?  That took a while, but it works great now.  🙂

Let me know if there is any other information you need to diagnose this issue.

Best regards,
Barnaby

[RobertScheitlin__GISP · Accepted solution]

Barnaby,

   I do see that. The investment is worth the results (I think). Well I have bad news for you on this.

This appears to be an ArcGIS Server issue/bug.

If I do an identify operation only using the REST Service Endpoint and give it some XY in 102100 the result for the operation should return the value from that location and the return geometry that has the same XY coords in 102100. But the reality is the return geometry is not the same and is shifted.

Here is an example that you can use to talk with tech support about:

https://www.sciencebase.gov/arcgis/rest/services/usminmap/Regional_Studies_pub/MapServer/identify?f=...

and the result is:

{"results":[{"layerId":4,"layerName":"","displayFieldName":"","attributes":{"Pixel Value":"68","OID":"68","Count":"554","Red":"0.670588","Green":"0","Blue":"0.560784","Opacity":"1","MaterialID":"hydrous silica:  opal and/or chalcedony"},"geometryType":"esriGeometryPoint","geometry":{"x":-13271482.338249963,"y":4643676.6552328682,"spatialReference":{"wkid":102100,"latestWkid":3857}}}]}

Input Geometry was:
{"y":4643663.032034932,"x":-13271590.227852684}

Output Geometry was:
{"y":4643676.6552328682,"x":-13271482.338249963}

[RobertScheitlin__GISP]

Barnaby,

   A work around for you is to set the returngeometryforzoom="false", but that will definitely remove some key functionality when identifying Features and not Rasters.

[BarnabyRockwell]

Hi Robert,

I figured it was a Server issue.  Is the output geometry reporting coords in utm/NAD27 units of the data layer when it should be reporting in the units of the input geometry? 

I've already started reprojecting all NAD27 data layers to WGS84 to work around the problem.  I'm almost done!

I'll also experiment with the returngeometryforzoom="false" settings.

If I have time I will file a support case.

As usual, thank you very much for your help and advice! 

Best regards,
Barnaby

[BarnabyRockwell]

Interesting:

NIM086597
ArcGIS 10.1 REST queries and Identify operations that include the geometry of a polygon using
a different spatial reference than the map service return no results unless the input spatial
reference (inSR) parameter is used.

A Desktop issue that is set to be fixed in 10.2.2.  Not the same as our issue, but perhaps related?

http://downloads.esri.com/support/downloads/other_/1022-IssuesAddressedList.pdf