DOC
|
No one from ESRI ever showed any interest in fixing the problem. I didn't like their redesign using the Query endpoint anyway. I ended up going directly to the REST Identify endpoint instead. It took a couple of days but I am happy with the results. I was able to leverage that same code to hit the FIND endpoint which is missing from the RT API. All in all time well spent.
... View more
05-14-2018
08:28 AM
|
0
|
0
|
1833
|
DOC
|
IdentifyLayerAsync is not returning all features in Version 100.2.0. It is working fine with version 100.1.0. Using Fiddler I compared the two versions and discovered this method was completely re-written. The previous version utilized the Identify REST endpoint of the map service. One simple transaction. The latest version uses the Query endpoint, one for each visible layer. That is 20+ transactions in my case and is noticeably slower. I have discovered two or more problems. Problem 1: The Query generated by IdentifyLayerAsync fails to return the feature in some cases. I noticed the failing Query result includes the error “exceededTransferLimit":true” so I experimented with the value for “resultRecordCount=1000” without success. When I removed the parameter completely the Query worked correctly. The Query result contained a single feature. Problem2: The Query returns the correct result but it is not added to the IdentifyLayerResult for some reason. There were two items in the result. One had the error message “The item to be created already exists in the database.” and did not have a corresponding Query, it was some random layer. The second result had the error “Error performing query operation” which I was able to match up with one of the REST Queries. I was not able to debug this any further. Problem 3: The application will suddenly stop with exit code 3 when calling the IdentifyLayerAsync method. Never on the first call, usually on the second try after having one of the above failures the first time. Details of the REST Queries can be found in the attached Word document.
... View more
01-10-2018
01:28 PM
|
1
|
2
|
2096
|
POST
|
A roadmap would be very helpful. I convinced my manager that Quartz was the way to go but now my project is on hold because I don't know when to expect required features. I need support for time-enabled layers. I see some of the service info but no way to specify a time extent. Support for stream layers would be really nice. I have already invested a lot of time in my GeoEvent server. That is how I sold Quartz for a future release.
... View more
07-06-2017
09:07 AM
|
0
|
0
|
1395
|
POST
|
Recreated network service on ArcGIS Server version 10.5 and it is working now.
... View more
01-31-2017
12:54 PM
|
0
|
1
|
619
|
POST
|
This works for me: if (MyMapView.SketchEditor.CancelCommand.CanExecute(null)) MyMapView.SketchEditor.CancelCommand.Execute(null);
... View more
01-23-2017
12:06 PM
|
2
|
0
|
496
|
POST
|
The following line is throwing an "Invalid response" error when called: RouteTask rt = await RouteTask.CreateAsync(new Uri("http://mapcache.friscotexas.gov/arcgis/rest/services/RoadNetwork/NAServer/Route")); I am using the release version WPF 100. The routing service is currently working with my Silverlight application. It is running on version 10.3.1. It is not secured. I assume there is a problem with the service configuration or perhaps it being an older version but I haven't found any specific requirements. Any thoughts?
... View more
01-23-2017
11:49 AM
|
0
|
2
|
1623
|
POST
|
As Morten and Antti mentioned the order of the GeoProcessing paramters does not matter. The order is defined when you publish the service. The arcpy script may access them by index. The Silverlight API happened to keep them in order. When inspecting the web request with Fiddler the only thing I noticed between the working Silverlight application and the failing RT application was the order of the parameters. After further inspection I realized my existing service was set up for Synchronous execution. I created a duplicate service configured for Asynchronous execution. Problem solved. Thank you Antti for all your work on the problem. I appreciate your help. I am embarrassed to say I have spent days on this. It just confirms my life philosophy: Don't sweat the big stuff, it's the little things that will bite you in the ass.
... View more
01-10-2017
09:38 AM
|
0
|
1
|
1134
|
POST
|
My original post shows the order of the parameters as coded and as captured in Fiddler. The list captured with Fiddler is clearly out of order. For example "xMin" was the first item added but it appears third from the end in Fiddler. The GeoprocessingParameters Inputs are defined as IDictionary. The order of elements in IDictionay are not guaranteed since it is a hash. Per Microsoft: "The IDictionary<TKey, TValue> interface allows the contained keys and values to be enumerated, but it does not imply any particular sort order" I think ESRI should have used an OrderedDictionary to maintain the order of the Inputs
... View more
01-05-2017
08:19 AM
|
0
|
1
|
1134
|
POST
|
Sample code: GeoprocessingParameters parameters = new GeoprocessingParameters(GeoprocessingExecutionType.AsynchronousSubmit); parameters.Inputs.Add("xMin", new GeoprocessingDouble(XMin)); // #0 parameters.Inputs.Add("yMin", new GeoprocessingDouble(YMin)); // #1 parameters.Inputs.Add("xMax", new GeoprocessingDouble(XMax)); // #2 parameters.Inputs.Add("yMax", new GeoprocessingDouble(YMax)); // #3 etc Output viewed in Fiddler: Include_Attributes=false&Layout=S_Portrait_8x11&LineGraphics=&Map_Scale=6000&Map_Title=test2&PointGraphics=&PolyGraphics=&Spatial_Reference=2276&TimeStart=&Visiblelayers=&env%3AoutSR=%7B%22wkid%22%3A102100%2C%22latestWkid%22%3A3857%7D&f=json&returnM=false&returnZ=false&xMax=2480009&xMin=2476167&yMax=7106436&yMin=7103763
... View more
12-27-2016
11:49 AM
|
0
|
6
|
2082
|
Title | Kudos | Posted |
---|---|---|
1 | 01-10-2018 01:28 PM | |
2 | 01-23-2017 12:06 PM |
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:23 AM
|