Latest Contributions by MichaelBranscomb

Hi, Apologies for the delay in replying - we're still investigating this issue as a high priority. Regards Mike ... View more

Hi, Thanks for the post, and apologies for the delay in replying. We're still looking into this - there may be a bug - but in the meantime there are a couple of alternative approaches you can take: #1. Call SubmitJobAsync on the UI thread - the overhead is minimal and should still provide a good user experience. #2. Keep the separate thread approach and disable the automatic JobStatus checks (which normally result in JobCompleted) by calling Geoprocessor.CancelJobStatusUpdates() and then perform the checks manually using Geoprocessor.CheckJobStatusAsync() which will result in the Geoprocessor.StatusUpdated event being raised. The default interval for the automatic checks is 5 seconds (changed via the Geoprocessor.UpdateDelay) but if you're doing this manually the interval is up to you. I've modified your code to show a quick example which will give feedback whether it's running on a background thread or on the UI thread. public MainWindow() {     InitializeComponent();     this.Completed += (sender, result) =>     {         Application.Current.Dispatcher.Invoke(new Action(() =>         {             MessageBox.Show("Result: " + result.Token);         }), null);     };     LocalGeoprocessingService.GetServiceAsync(gpkLocation, GPServiceType.SubmitJob, localGpService =>     {         if (localGpService.Error != null)             return;         lgs = localGpService;         Thread thread = new Thread(new ParameterizedThreadStart(this.ExecuteGPTask));         thread.Start("Background Thread");         this.ExecuteGPTask("UI Thread");     }); } public void ExecuteGPTask(object token) {     //Set up parameters     List<GPParameter> parameters = new List<GPParameter>();     string input = "5+5";     GPString inputParam = new GPString("input", input);     parameters.Add(inputParam);     // Check local GP service is running and there are >=1 tasks     if (this.lgs.Status != LocalServiceStatus.Running || this.lgs.Tasks.Count == 0)         return;     // Assumes only one task in GP Package (GPK)     string taskUri = this.lgs.Tasks[0].Url;     // Create a new Geoprocessor task     Geoprocessor gpContour = new Geoprocessor(taskUri);     gpContour.Token = token.ToString();     // Create a timer to schedule CheckJobStatusAsync calls     System.Timers.Timer timer = null;     // Handler for StatusUpdated event (in response to CheckJobStatusAsync)     gpContour.StatusUpdated += (s, e) =>     {         Geoprocessor geoprocessingTask = s as Geoprocessor;         switch (e.JobInfo.JobStatus)         {             case esriJobStatus.esriJobSubmitted:                 // Disable automatic status checking.                 geoprocessingTask.CancelJobStatusUpdates(e.JobInfo.JobId);                 break;             case esriJobStatus.esriJobSucceeded:                 if (this.Completed != null)                 {                     this.Completed(this, new MyEventArgs() { Token = gpContour.Token });                     if (timer != null)                     {                         timer.Stop();                         timer.Dispose();                     }                 }                 // Get the results.                 // geoprocessingTask.GetResultDataAsync(e.JobInfo.JobId, "<parameter name>");                 break;             case esriJobStatus.esriJobFailed:             case esriJobStatus.esriJobTimedOut:                 MessageBox.Show("operation failed");                 break;         }     };     JobInfo jobInfo = gpContour.SubmitJob(parameters);     timer = new System.Timers.Timer(3000);     timer.Elapsed += (s, e) =>     {         gpContour.CheckJobStatusAsync(jobInfo.JobId);     };     timer.Start(); } Cheers Mike ... View more

Hi, Ok, the next thing we can try is to enable logging. To enable logging you'll need to make a small change in a text file within the ArcGIS Runtime local server directory. At Beta 2 you need to do this manually, but we have since created a much more user/developer-friendly GUI app to do this. #. Open Windows Explorer [the following steps assume you're on a 64-bit machine - for 32-bit drop the x86, etc] #. Browse to "C:\Program Files (x86)\ArcGIS SDKs\WPF10.1\ArcGISRuntime10.1\LocalServer64\bin" #. Find the arcgisruntime.json file and open in a text editor. #. Change the following:      "logging"         : false, #. To:      "logging"         : true, #. Save and exit. #. Now when you run your application the local server will be creating log files in %temp%\ArcGISRuntimeLogs (e.g. C:\Users\mbranscomb\AppData\Local\Temp\ArcGISRuntimeLogs). #. you can open the log file in a text editor to see if there are any clues to the problem. If there's nothing useful in the logs, then to confirm that the MPK is definitely pointing to the correct we'll need to dive a little deeper. So I'd like you to check the following please: #. Browse to the exploded packages in my documents (e.g. C:\Users\mbranscomb\Documents\ArcGIS\Packages). #. Find the directory with the same name as your MPK (e.g. ch_test5) #. Browse to ...\ch_test5\v101 #. Use 7-zip to extract the files from the MSD file (e.g. extract ch_test5.msd to a new folder ch_test5.msd) #. Browse to ...\ch_test5\layers #. Open the xml file for one of the layers of your data in a text editor (e.g. myFeatureLayer.xml) #. Look for the <WorkspaceConnectionString> tag. #. This should contain a path like "DATABASE=V:\Data\..\ch5\ch_test5.gdb". #. This will confirm that the packaging process is correctly using the virtual / mapped drive for the externally referenced drive. If the path in the msd file looks ok then it should be behaving fine. If none of that helps - can you put together a reproducer app with data? I could test this by simply creating the same virtual /mapped drive here. Cheers Mike ... View more

Hi, You can check the existing Product Compatibility Matrix here: http://wikis.esri.com/wiki/display/SupportCenter/Product+Compatibility+Matrix. That currently details the compatibility of 10.0 and earlier releases. There is a statement on 10.1 Geodatabase inter-release compatibility on the Beta Resource Center: http://resourcesbetadev.arcgis.com/en/help/main/10.1/index.html#/Whats_new_for_geodatabases/016w00000031000000/. Cheers Mike ... View more

Hi, In order to edit standalone tables at Beta 2 you will need to use the FeatureLayer class in conjunction with the LocalFeatureService layer Url (e.g. aLocalFeatureService.UrlFeatureService + "/0"). The ArcGISLocalFeatureLayer class had an incorrect check which results in the error message "A layer with name <X> is a table and cannot be used for a FeatureLayer". We have since corrected this behaviour. Also - Note - to work with standalone tables you must have the FeatureLayer in Snapshot mode (or selection only). OnDemand mode does not work with FeatureLayers based on standalone tables because it uses the map extent geometry to request query the service. Cheers Mike ... View more

Hi, Apologies for the delay - I've been doing some research on both approaches and I'm still waiting for some more information. Cheers Mike ... View more

Hi, The GeometryService is actually a task which, like any other task in the API requires a URL to work. the LocalGeometryService is actually a class for administering a local instance of a geometry service. The slight difference in naming convention arises from trying to maintain consistency with the web APIs (JavaScript, Flex, SilverLight) and the mobile APIs (Windows Phone, etc). So all you need to do is start a LocalGeometryService then pass it's Url property to the GeometryService task. Fortunately, we've added a convenient local extension to the GeometryService class to help you do this - so the simplest code to achieve this becomes a two liner: GeometryService geometryTask = new GeometryService(); geometryTask.InitializeWithLocalService(); //... use the GeometryService to perform an operation e.g. Project(); ... Or if you want to do this asynchronously: GeometryService geometryTask = new GeometryService(); geometryTask.InitializeWithLocalServiceAsync(localGeometryService => { //... use the GeometryService to perform an operation e.g. Project(); }); The functionality is the same whether you are using an online GeometryService instance or a local/offline instance. This will help with most of your requirements. The polygon class of geometry supports multiple rings which will cater for exterior rings and interior rings. The geometry must have been created clockwise to be valid in this respect. If the geometry was created counter clockwise you can use the Simplify method on the GeometryService task class to generate topologically valid geometry. Cheers Mike ... View more

Hi, Unfortunately the workflow we've been discussing works fine in my testing: #1. Create virtual / mapped network drive to folder containing data (in my case I've been testing with a virtual drive created using the subst command) (I used "subst V: C:\") #2. Open ArcMap #3. Browse to and add data using virtual drive (in my case V:\Temp\DataToDeploy\DatatoDeploy.gdb) #4. Save Map document #5. Share as map package ensuring that both the "Support ArcGIS Runtime" AND "Reference all data" options are checked. #6. Copy DataToDeploy folder containing File GDB and MPK to a deployment machine. #7. Create virtual drive on deployment machine (I used "subst V: C:\Projects") #8. Open an ArcGIS Runtime application which references that MPK (e.g. via "V:\Temp\DataToDeploy\DataToDeploy.MPK") #9. Application loads MPK and correctly finds data referenced via "V:\Temp\DataToDeploy\DatatoDeploy.gdb" even though the deployment physical location is different to the physical source location. Cheers Mike ... View more

Hi, In the steps you outline, when you say you copied the MPK from the server to the client - did you also copy the File GDB? Or does that already exist on the client machine in C:\Data\... ? If you want to leave the GDB on the server and edit from the client you'll need to use a UNC path e.g. \\<server>\Data\... . Note that this would be single user editing of that server-side GDB, if you want multi-user editing you'll need to use ArcGIS for Server Basic (Workgroup or Enterprise). Cheers Mike ... View more

Hi, Sorry to hear you're experiencing problems getting this working, this workflow should work ok. If you're using a mapped network drive, you'll need the same named drive on both machines (e.g. V:\Data\... ). Otherwise, if you want to edit from the client machine to the other server machine you'll need to use a UNC path (e.g. \\SERVER\C\Data\...). In ArcMap you will need to add the data from the mapped network drive / virtual drive (I use the doc command subst to create a "virtual drive") so that when you create the map package and choose the "Reference all data" option it will persist the reference to the data via your V:\Data.. location. You should find the MPK that gets created is very small (probably <50KB). Then when the ArcGIS Runtime starts the LocalFeatureService it will unpack the MPK to your user profile (e.g. C:\Users\mbranscomb\Documents\ArcGIS\Packages\<package_name>\). In that location there will be a v101 (i.e. 10.1) folder which contains the just a couple of map documents (and MSD and an MXD) which the ArcGIS Runtime is using to create the service. You should not see a <map_name>.gdb Geodatabase or any other data. This means that the MPK was correctly created referencing the data by the original path (e.g. V:\Data\...). Starting a LocalFeatureService from this MPK should now be referencing the data in it's original location via the mapped network drive path. I've tested via both mapped network drives and virtual drives (the subst command approach) and in both cases the internal path within the package is correctly pointing to for example X: or Z: rather than C:. Cheers Mike ... View more

Hi, At Beta 2 the ArcGIS for Desktop packaging analyzers will prevent you creating an ArcGIS Runtime compatible package (MPK) with relative paths to ensure that valid packages are always created. The error you are seeing is most likely because the local feature service cannot find the File GDB which the Map Package (MPK) is referencing because it's using the path by which the Map Document (MXD) was originally referencing the data. The best approach is to us a UNC path / map a network drive so that ArcMap and the ArcGIS Runtime on their respective machines can both see the File GDB by the same path. Cheers Mike ... View more

Hi, There is just a minor issue in your approach here - which are most likely the cause of the problem you're experiencing. You're trying to start a LocalGeocodeService rather than a LocalGeometryService. Another thing to note, for when you do start working with geocode services, is that you can't start a local geocode service from a map package (MPK) - it needs to be an address locator package (APK). So your original code...             LocalGeocodeService geoServ = new LocalGeocodeService("C:\\Data\\GISS\\Geodatabaser\\test\\ch_test2.mpk"); ...Would work better like this (within the default constructor of your application):             LocalGeometryService localGeometryService = new LocalGeometryService();             localGeometryService.StartCompleted += (sender, eventargs) =>             {                 ESRI.ArcGIS.Client.Editor myEditor = LayoutRoot.Resources["MyEditor"] as ESRI.ArcGIS.Client.Editor;                 myEditor.GeometryServiceUrl = localGeometryService.UrlGeometryService;                   // Enable UI as required                 // e.g. AddButton.IsEnabled = true;             };             localGeometryService.StartAsync();    Cheers Mike ... View more

Hi, Apologies for the earlier misdirection. Unfortunately the dynamic layers capability does not work with feature services or feature layers. The capability is currently supported only by map services and therefore by the dynamic map service layers. When the contents of a map service are altered via the dynamic layers capability no changes are applied to the underlying service and therefore no changes will appear in the REST end point for that service. We'll need to do some more research on the legend control issue. Regarding the Dev Summit - several of the ArcGIS Runtime team (including me) will be there presenting tech sessions and demo theatres and manning the showcase - look forward to seeing you there! Cheers Mike ... View more

Hi, I believe the dynamic layers functionality can be used in the way you are asking. The code in the original example below uses the CreateDynamicLayerInfosFromLayerInfos() method which returns a DynamicLayerInfoCollection containing the existing layers in the map allowing you to make modifications to those. You can continue with that approach if you would like to maintain/modify the existing layers but also add new DynamicLayerInfo objects to that DynamicLayerInfoCollection to add brand new feature classes. Or alternatively you can simply create a new DynamicLayerInfoCollection and fill it with any number of DynamicLayerInfo objects (one for each feature class you would like to add). Note that the Geodatabase workspace must always be registered with the LocalMapService prior to starting the service, and obviously also that LocalMapService will need to be started from an MPK. This MPK will need to contain at least one layer - and for best performance the coordinate system of the MPK should match that of the new feature classes you are adding (although LocalMapServices will perform reprojection on-the-fly). Remember - no changes are made to the actual underlying LocalMapService or the MPK on which it is based. It is the client layer (ArcGISLocalDynamicMapServiceLayer) which manages the persistence of the new feature layers and renderer you have defined. The same functionality is also available in ArcGIS for Server 10.1 but in that case the workspaces must be accessible from the server and must be registered with the server via the ArcGIS Server Manager web app (or ArcCatalog). The registering of workspaces via the client API is only supported for LocalMapServices. Regarding the legend control - we'll investigate. Cheers Mike ... View more

Hi, Apologies for the delay in replying. Following your post on 20th December we logged an issue and are investigating this. Unfortunately I do not have any further information at this time. Cheers Mike ... View more