Latest Contributions by JoeHershman

As I was doing some group searches I notice some very odd results.  If I do a group search by user name and the search string contains a trailing space two of the three groups owned by that user are returned.  If I do the same search without the trailing space two of three groups are returned.  One group is returned in both searches and the other group returned is different in each search.  Obviously, the users name does not have a trailing space in it (users are added from Windows AD).  Yes I have confirmed there is no trailing space in the group title, even re-saving to confirm. If someone could explain this I would love to understand why and how I am supposed to actually search correctly.  This was discovered because I get really bizarre results when doing group searches from a Runtime application and I wanted to compare to search results in Portal itself. -Joe ... View more

I have been looking through this and while promising the one key I was really hoping for is not resolved: Limitations Advanced symbols are supported only if they are defined in the original service. Any overrides with advanced symbols will result in empty symbols in an offline map. geometries that cross the dateline are not currently supported. If more that one feature layer in a map refers to the same feature service end point only one feature layer will be taken offline. The other feature layers will raise an error. This still seems to be the holy grail of the new replication model. While the new features are nice and would work well in a situation where (1) the service area could be broken out into small areas and (2) the workforce relatively small.  I like the idea of being able to download only the schema which could be very useful in situation where the need is for a field inventory that can then be compared to the existing GIS back at the enterprise.  Also I think this gives the ability to develop a custom application with a Collector like workflow.  However, for our purposes there is a significant flaw and that is that there is not included functionality (that I observed) to register the offline map onto another machine.  It seems the workflow is to use the OfflineMapTask to download all the services and then Sync with the OfflineMapSyncTask, which will sync all the layers in the map.  This means for every user you need to do a full download of the map and that includes creating the replicas which is a performance nightmare for a large service area that cannot be broken out.  Combine that with 500+ users and it really is not a possible deployment workflow.  The offline map package does look to basically just be a folder that holds the offline replicas along with some information about WebMap configuration.  So, it seems a possible workaround would be to side load the map package and then loop through the services using the existing register replica methods.  A downside here is that with a large service area and a number of layers the map package (even zipped) is going to be rather large.  Plus you run into the limitation highlighted above that if you want two layers pointing to the same class you need to come up with another method to get those layers setup on the client and included in the map. A goal I have been trying to achieve is to give the user a similar experience both in portal and when disconnected and to have all configuration done in portal.  I have written a server tool that offers the similar functionality that is being offered the new classes, while certainly more limited.  It loops through through the layers and does a download on each layer and then used the rest API and calls the  /data on the item and grabs all the popup configuration and capabilities, etc.  This is bundled up and doing a bit of extending JSON.net the configuration can be re hydrated into the popup definition classes and associated to the layers when they load on the client.  Using the capabilities property it can be determined which layers are editable on the client.  Because I just download each service as it's own autonomous geodatabase, there is no limitation about having multiple layers pointing to the same feature classes as long as they are not in the same service.  Granted this does mean we sync the same data multiple times because those duplicated layers are synced individually, however, there is really no way (that I see) around that.  Once generated on the server the layers are zipped up and placed in portal.  The client downloads,  unzips, and calls register so we avoid having to generate a replica for each client and because the replicas are small downloading updates that might result due to a schema change or because something went awry performs well.  On the server performance is good because the replication is all done in parallel so it only takes as long as the largest replica to generate and upload the entire map.  On the client a similar approach makes even the initial deployment download perform well. Cheers -Joe Michael Branscomb‌ ... View more

I have a situation where we have an offline tile cache used for a basemap for imagery.  We also want to be able to use the online streets basemap if connected.  This seems straightforward, however, does not work.  If I initially load a tiles layer as basemap I am unable to switch the basemap to a basemap that uses service layers and vice-versa. So if I initially load tiles: var tileCache = new TileCache(@"D:\Mobile\Imagery\Layers"); ArcGISTiledLayer imageLayer = new ArcGISTiledLayer(tileCache); map = new Esri.ArcGISRuntime.Mapping.Map(new Basemap(imageLayer)) { InitialViewpoint = new Viewpoint(extent) };‍‍‍‍‍‍ The offline cache loads correctly.  However, when I try to switch the reference to a service based basemap RuntimeControls.MapView.Map.Basemap = Basemap.CreateStreets();‍ The base map simply disappears (in the above RuntimeControls is used to share the MapView across the application. If instead of the first code block I start with: map = new Esri.ArcGISRuntime.Mapping.Map(Basemap.CreateImageryWithLabelsVector()) { InitialViewpoint = new Viewpoint(extent) };‍ Switching basemaps in the second block works fine.  The opposite behavior is also observed.  If I initially start with a Streets layer for basemap, I am unable to switch the basemap to the TileCache.  However, when I switch back to the TileCache after the failed attempt to change to streets the basemap is displayed. The only thing that works is to create a new Map instance.  The problem with this is the OperationalLayers are lost.  I tried a workaround to see if I can recreate the map.  Along these lines RuntimeControls.MapView.Map.Basemap = Basemap.CreateStreets(); LayerCollection operationalLayers = RuntimeControls.MapView.Map.OperationalLayers; Envelope extent = RuntimeControls.MapView.VisibleArea.Extent; RuntimeControls.MapView.Map = null; Map map = new Map(Basemap.CreateStreets()) { InitialViewpoint = new Viewpoint(extent) }; foreach (var layer in operationalLayers.OfType<FeatureLayer>()) {      FeatureLayer featureLayer = new FeatureLayer(layer.FeatureTable);      map.OperationalLayers.Add(featureLayer); }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ This, though, throws an exception:  Esri.ArcGISRuntime.ArcGISRuntimeException was unhandled ErrorCode=24 HResult=-2146233088 Message=Object already owned.: Already owned. Source=Esri.ArcGISRuntime I put the line setting the map to null in there hoping it would release the layer ownership, I even tried to force a garbage collection to see if that would release it, but no luck. Any thoughts?  This is a pretty critical aspect to our application users need to be able to see a streets map when they are connected Thanks -Joe ... View more

Hi, I am curious if anyone else sees the same issue.  I am unable to generate a replica through the API for any service that is created in ArcGIS Pro.  These are feature services which use referenced data (not hosted).  The database is archive enabled non-versioned data following the esri suggested approach. I create the service in Pro, go to Server Manager to enable replication and then trying to create the replica via the API fails. Always!.  I have seen this behavior on two different AGS/Portal servers and have tried using Pro 2.0. If I use the same exact data and the exact same code but create the Feature Service in ArcMap everything works fine. Replica created and downloaded as expected. I cannot believe this would not have been tested during development, so would love some insight into why I see this issue Thanks -Joe ... View more

I have noticed something setting up Web Maps which causes a serious issue in trying to use these maps from a Runtime application.  There are two scenarios for publishing a Web Map which should produce identical Web Maps.   Prior to setting up the Web Maps all layers are published from ArcGIS Pro as Feature Services to our local Portal I setup maps in ArcGIS Pro adding the layers created earlier from Portal.  This map is then published to Portal as a WebMap. I setup a WebMap in Portal using the Map Viewer On the surface the WebMap produced are the same.  There is one critical difference, though.  The layers in the WebMap produced through Pro are just services (the same layer type you would get using the "Add Service From the Web" approach in Portal)  The layers in the map created in Portal are Portal Items. From a Runtime development standpoint this difference makes (for our purposes) the map produced in Pro useless.  We need access to the underlying Portal item of the Feature Service to get to properties of the item.  In the WebMap produced in Pro there does not seem to be a way to get access to that underlying Portal Item. Why this would be? I added the layers in Pro from Portal, not from services they should be treated as Portal Items.  Is there any chance this would be fixed in ArcGIS Pro 2.0?  This is a huge issue for us, because it means that we are unable to use Pro as part of our proposed workflow for publishing WebMaps which will result in much greater time spent producing the required Web Maps Michael Branscomb‌ ... View more