FeatureLayer - outSR parameter is invalid

[DavidLowther]

IN the SL API I have setup a FeatureLayer. Using fiddler I see that the request is:

GET /ArcGIS/rest/services/SampleLoc/MapServer/0/query?returnGeometry=true&spatialRel=esriSpatialRelIntersects&where=1%3d1&outSR=%7b%22wkt%22%3a%22PROJCS%5b%5c%22Mercator_2SP%5c%22%2cGEOGCS%5b%5c%22unnamed+ellipse%5c%22%2cDATUM%5b%5c%22D_unknown%5c%22%2cSPHEROID%5b%5c%22Unknown%5c%22%2c6378137.0%2c0.0%5d%5d%2cPRIMEM%5b%5c%22Greenwich%5c%22%2c0.0%5d%2cUNIT%5b%5c%22Degree%5c%22%2c0.0174532925199433%5d%5d%2cPROJECTION%5b%5c%22Mercator%5c%22%5d%2cPARAMETER%5b%5c%22false_easting%5c%22%2c0.0%5d%2cPARAMETER%5b%5c%22false_northing%5c%22%2c0.0%5d%2cPARAMETER%5b%5c%22central_meridian%5c%22%2c0.0%5d%2cPARAMETER%5b%5c%22standard_parallel_1%5c%22%2c0.0%5d%2cUNIT%5b%5c%22Meter%5c%22%2c1.0%5d%5d%22%7d&f=json& HTTP/1.1 

or:
{"wkt":"PROJCS[\"Mercator_2SP\",GEOGCS[\"unnamed ellipse\",DATUM[\"D_unknown\",SPHEROID[\"Unknown\",6378137.0,0.0]],PRIMEM[\"Greenwich\",0.0],UNIT[\"Degree\",0.0174532925199433]],PROJECTION[\"Mercator\"],PARAMETER[\"false_easting\",0.0],PARAMETER[\"false_northing\",0.0],PARAMETER[\"central_meridian\",0.0],PARAMETER[\"standard_parallel_1\",0.0],UNIT[\"Meter\",1.0]]"}

The response is:
{"error":{"code":400,"message":"","details":["'outSR' parameter is invalid"]}}

I believe this is because the API is using the SR or the layer - which is clearly verbose. I tried the request using outSR=102723 and received the features.

So, the question: Is there any way I can change the service or the client so that the request with the simpler outSR is made?

Thanks in advance.

[dotMorten_esri]

Is the server that throws this error running ArcGIS Server v10? (only v10 supports WKT)
Is the service where you are getting the WKT from exposing a WKID or a WKT for the spatial reference?

You can force the spatial reference or the layer like done in this example: http://help.arcgis.com/en/webapi/silverlight/samples/start.htm#DefineMapProjection

[DavidLowther]

The server is 9.3. I'm completely willing to change the service, but I don't know how to tell if it is exposing a WKT or WKID - likely WKT since that is what the API is pushing back at it, right?

[dotMorten_esri]

Enter the URL to the service in your browser. You should see the service metadata right there. If it specifies a number at the spatial reference its using WKID. If it's the long string, well then it's WKT.
If its showing WKT (very likely), you need to update your MXD to use a common SRID instead.

[DavidLowther]

OK. This cleans it right up. Thanks.

[BryanBaker]

I ran into this issue as well (our server is 9.3.1). In my case the one map service I'm using in the application uses a custom Albers-based projection. Since it's a dynamic service we could redefine the Map's coordinate system to use one with a WKID, but the service is already pretty slow, so we'd rather keep the map in the native projection (especially since this is the only place the WKT causes an issue).

I've worked around it by changing the layer from a FeatureLayer to a GraphicsLayer, where I query the features and add them to the layer. But it seems that the FeatureLayer should work here, or there should be some way to get the FeatureLayer to not send the WKT with the feature request.

[dotMorten_esri]

How can you request data using querytask/graphicslayer on a 9.3.x server in a projection that matches the basemaps' spatial reference if this is only defined as a wkt? Ie if you can get data from a 9.3.1 server that overlays correctly on your map, there must be a valid wkid for that map that you can use instead of the wkt.
Either that, or you are mixing spatial references which could lead to some major accuracy issues.

On a side note my experience is that projection on the fly is not really a big overhead at all. Most of the performance issues is usually from pulling shapes out of the database and rendering it to the image. If you have issues with performance this is really stuff you should be looking at instead (msd and/or caching will also help way more than what you loose on reprojection)

[BryanBaker]

How can you request data using querytask/graphicslayer on a 9.3.x server in a projection that matches the basemaps' spatial reference if this is only defined as a wkt? Ie if you can get data from a 9.3.1 server that overlays correctly on your map, there must be a valid wkid for that map that you can use instead of the wkt.
Either that, or you are mixing spatial references which could lead to some major accuracy issues.

On a side note my experience is that projection on the fly is not really a big overhead at all. Most of the performance issues is usually from pulling shapes out of the database and rendering it to the image. If you have issues with performance this is really stuff you should be looking at instead (msd and/or caching will also help way more than what you loose on reprojection)

Thanks for the reply, Morten. In our case the only map service in the map is the one that uses the WKT. So there is no WKID involved at all. I can query the service without specifying the spatial reference and it'll return OK.

It turns out that we cannot project the map service even if performance were not an issue, because the Silverlight client is getting coordinates from the hosting application for zooming the map etc., and those coordinates are in the custom projection of the WKT. We definitely don't want to have to project those input coordinates every time. So for now we'll stick with the graphics layer workaround. I'll note that I found a separate issue that I suspect is also related to spatial references using WKT (see http://forums.arcgis.com/threads/15650-Map.ZoomToResolution-fails-to-change-map?p=48472#post48472), so hopefully ESRI will investigate and fix any issues along these lines.