Select to view content in your preferred language

WMS Layer Bounding Box Issues

3971
2
Jump to solution
09-11-2013 10:31 PM
BenScott1
Deactivated User
I am trying to use a wms layer in my flex viewer (see http://sentinel.ga.gov.au/acres/sentinel/wfs_wms.shtml for details).  The layer supports the spatial reference (WGS84) I am passing, and works properly when requested from arcmap or when you pass it a request as a url string.

When I include it in a flex viewer, however, the result is returned in completely the wrong location - instead of being located around australia roughly 20-40 deg S, 110-150 deg E, the points are all located at tiny lat longs - 0-0.00036 S and 0.00099 - 0.0014 E.

Looking at the request the viewer makes in fiddler, it sends enormous coordinates for the bounding box.  There is clearly something strange about the way the flex viewer is interpreting the spatial reference.  If I leave the WKID=... item out of the config it tries to pass the esri spatial reference of 102100, which the wms server doesn't understand.  When I specify wkid="4283" it sends the massive bounding box values.

I am wondering if it is in some way related to this issue:

http://forums.arcgis.com/threads/84365-Change-Spatial-Reference-in-ArcGIS-Viewer


My config text for the layer is:

            <layer label="Sentinel" type="wms" wkid="4326" visible="true" alpha="1" url="http://sentinel.ga.gov.au/wmsconnector/com.esri.wms.Esrimap" imageFormat="png" visiblelayers="Modis48to72Hours" skipgetcapabilities="true" version="1.1.1"/>



The request sent by the viewer when I turn on the layer is:

GET /wmsconnector/com.esri.wms.Esrimap?SERVICE=WMS&VERSION=1%2E1%2E1&REQUEST=GetMap&TRANSPARENT=TRUE&LAYERS=Modis48to72Hours&SRS=EPSG%3A4326&WIDTH=1101&FORMAT=image%2Fpng&STYLES=&HEIGHT=590&BBOX=16427846%2E119045615%2C%2D4272829%2E881140223%2C17101103%2E464181416%2C%2D3912047%2E107634209 HTTP/1.1




Cheers,
Ben
Tags (2)
0 Kudos
1 Solution

Accepted Solutions
RobertScheitlin__GISP
MVP Emeritus
Ben,

   No it does not have anything to do with that issue. Your issue is you are try to use a layer that does not support WKID 102100 in a map that is using 102100. WMS Layers do not get reprojected by the Viewer on the fly. Thus your WMS layer has to support your maps WKID or you have to set your maps WKID to one that is supported by the WMS layer (This would involve changing Cached basemaps to dynamic as cached layer do not re-project on the fly either). There are several Dozen threads covering WMS layers in the forums that deal with WKID issues.

View solution in original post

0 Kudos
2 Replies
RobertScheitlin__GISP
MVP Emeritus
Ben,

   No it does not have anything to do with that issue. Your issue is you are try to use a layer that does not support WKID 102100 in a map that is using 102100. WMS Layers do not get reprojected by the Viewer on the fly. Thus your WMS layer has to support your maps WKID or you have to set your maps WKID to one that is supported by the WMS layer (This would involve changing Cached basemaps to dynamic as cached layer do not re-project on the fly either). There are several Dozen threads covering WMS layers in the forums that deal with WKID issues.
0 Kudos
BenScott1
Deactivated User
Ben,

   No it does not have anything to do with that issue. Your issue is you are try to use a layer that does not support WKID 102100 in a map that is using 102100. WMS Layers do not get reprojected by the Viewer on the fly. Thus your WMS layer has to support your maps WKID or you have to set your maps WKID to one that is supported by the WMS layer (This would involve changing Cached basemaps to dynamic as cached layer do not re-project on the fly either). There are several Dozen threads covering WMS layers in the forums that deal with WKID issues.


I see - I was unaware that wms layers could not be reprojected on the fly and had also not cottoned on to the fact that 102100 was a projected coordinate system (explaining the large bounding box numbers). 

Why the good folks who published the wms service should choose not to include 102100 (or 3857) in their list of supported spatial references is beyond me, seeing that it is used for just about every basemap service available.

Thanks,
Ben
0 Kudos