Latest Contributions by JoeHershman

‎01-16-2018

Pretty sure upgrading is your only option

‎01-09-2018

In our offline maps the users require that they be able to view a specific linear features in multiple ways. This is a pretty standard need within our industry. These layers also happen to be quite large ~600 Mb. The hope was that we could have a single replica of this data and render it multiple ways in the offline map. Identical to how you would do in ArcMap or ArcGIS Pro by adding a layer from the same table symbolized differently. I was able to write a tool and uses different services to generate the renderers serialized into json, which I thought was going to be the hurdle to overcome. Using these files it is possible to create a feature layer and use the json to create the renderer as hoped. Unfortunately, from what I see this approach is not possible. It would seem that for some reason a GeodatabaseFeatureTable can only be used as the source for a single FeatureLayer. When the application tries to create the second FeatureLayer the following error occurs: Esri.ArcGISRuntime.ArcGISRuntimeException: Object already owned.: Already owned. at Esri.ArcGISRuntime.ArcGISException.HandleCoreError(CoreError error, Boolean throwException) at RuntimeCoreNet.GeneratedWrappers.Interop.CheckError(IntPtr errorHandle, Boolean throwOnFailure, GCHandle wrapperHandle) at RuntimeCoreNet.GeneratedWrappers.CoreFeatureLayer..ctor(CoreFeatureTable featureTable) at Esri.ArcGISRuntime.Mapping.FeatureLayer..ctor(FeatureTable featureTable) Why? What is the reasoning behind only allowing a GeodatabaseFeatureTable to be 'owned' by a single FeatureLayer? Is there something else I am possibly doing that would cause this error or is this idea something that is not possible? The ability to apply different renders and/or definition expressions to the same GeodatabaseFeatureTable would allow us to greatly reduce the footprint of offline replicas and reduce the amount of data syncronization required so it would be a great solution. Thanks -Joe

‎01-04-2018

The downside is that the user needs to create a new checkout in order to see any new point that others have uploaded. This is a non-starter in our case. The replicas are far too large and users only have access over a mobile network most of the time. Both generation time and transport time individually preclude this as something we could consider, Certainly, hope this is resolved at upcoming 10.6 and Runtime 100.2 release because we would like to incorporate other fixes and new features from those upcoming releases

‎01-04-2018

I find the solution I documented above to be a lot of code for something I think should be pretty simple. It is also unstable and at times switching basemaps will freeze. The best fix would be to have basemaps in the same projection, but in our case that is not possible. We have purchased tile imagery that is delivered only in the local projection, and would like to also be able to use online basemaps, only available in specific projections

‎01-04-2018

Prism allows developers to use proven patterns and practices to create XAML and Xamarin Forms applications to target Windows and multi-platform development. Utilizing Prism and the ArcGIS Runtime, a loosely coupled, MVVM, modular application was built. With this approach, the complexity was broken down into smaller, simpler modules. By employing MEF for dependency injection and extensibility, runtime discovery of modules could be used to make the application features configurable at deployment.

‎11-15-2017

Scott..Thanks you for the reply and consideration. While it is true that having a completely unsecured server would allow allow for any editing of a replica it certainly would be a step backwards in what we are to be trying to achieve with the ArcGIS Enterprise model. I don't see this as a valid workaround when trying to implement the newest security models and infrastructure of ArcGIS Enterprise. I would see security working the same may that security is setup in Portal as a whole. Currently, to define security for data synchronization the portal group model is used. A service must be shared to any user that needs to synchronize data with that service. I think it would be very valuable if in the same way when a replica is created a group could be defined that all members of that group could synchronize that replica. This would allow a good security model for the common scenario of a field crew which has shared resources. Currently, the workaround being used is to elevate the permissions of the standard Level 2 User which grants too much rights to a standard user. I see the advantage in an ownership based model like currently exists. For certain type of data collection where a greater degree of security is required and for a small work force I believe this appropriate. But with a large work force having a single named user associated to the replica is a nearly impossible model to implement. In addition to the general case of a shared laptop there are issues associated to deployment to a large workforce. In many cases it is not realistic that the field worker themselves does setup of a field machine, this is often done by the IT group when a machine is built out. Allowing a group to share a replica, would allow this deployment approach Thanks -Joe

‎11-15-2017

Scott..Thanks you for the reply and consideration. While it is true that having a completely unsecured server would allow allow for any editing of a replica it certainly would be a step backwards in what we are to be trying to achieve with the ArcGIS Enterprise model. I don't see this as a valid workaround when trying to implement the newest security models and infrastructure of ArcGIS Enterprise. I would see security working the same may that security is setup in Portal as a whole. Currently, to define security for data synchronization the portal group model is used. A service must be shared to any user that needs to synchronize data with that service. I think it would be very valuable if in the same way when a replica is created a group could be defined that all members of that group could synchronize that replica. This would allow a good security model for the common scenario of a field crew which has shared resources. Currently, the workaround being used is to elevate the permissions of the standard Level 2 User which grants too much rights to a standard user. I see the advantage in an ownership based model like currently exists. For certain type of data collection where a greater degree of security is required and for a small work force I believe this appropriate. But with a large work force having a single named user associated to the replica is a nearly impossible model to implement. In addition to the general case of a shared laptop there are issues associated to deployment to a large workforce. In many cases it is not realistic that the field worker themselves does setup of a field machine, this is often done by the IT group when a machine is built out. Allowing a group to share a replica, would allow this deployment approach Thanks -Joe

‎11-10-2017

The issue is at 10.5.1 and 10.6 not at 10.5. Syncing works at 10.5. There is a 10.5 patch associated to sync at 10.5 Esri Support 10.5 (10.5.1) . This fixes a bug that occurs if you are using a workflow that includes copy and register of your replicas. Sync will fail without the patch is the user registering the replica did not create the replica or is an admin

‎10-23-2017

Not meant to sound critical to you. Changing your entire business process falls well outside what I would ever describe as a work-around. In my opinion, a versioning workflow is impossible to manage in a large deployment. Not to mention esri's recommends that the non-versioned archive enabled workflow. To me the only workaround is not upgrading beyond 10.5. Esri needs to get it together. This is a known issue, it has been submitted and it is documented by numerous people and yet it persists. Downloading new data is fine in a small deployment with small datasets but it is not in a large deployment (you cannot ask a few hundred people to just delete and download fresh data). Plus if versioned that means you now need to manage the versions that were just removed.

‎10-20-2017

We are using the WPF API. We are generating/downloading the replicas on Server 2012 and Windows 10 machines

‎10-20-2017

We haven't gotten around to using the new parts of the API. But we have the control that is shown above and display using the Overlays collection and call SetAnchorPoint to locate the pin. Our users want a popup that displays more than just a couple attributes, and this seems to be working. I do plan to try to integrate it into the Callout API stuff, but it is a low priority

‎10-20-2017

The replicas are created as offline databases to be synced, not as distributed data. Replicas in this case are created from the Rest API on a feature service. This can also be done in Runtime which basically wraps the Rest calls in the API. What happens when you create a replica in this manner is that AGS creates the file on the server, the Rest API then returns the Url of the replica and it can be downloaded. If I do this though the Rest API myself after receiving the Url in the response I can download the database in about a minute. However, using the Runtime API that minute of data transfer from server to client takes about 15 minutes for the identical database on the same machine. So for some reason it seems that the transport time through the Runtime API is much slower than transferring that exact same data over https in a browser.

‎10-18-2017

The amount of data required in the day is dependent on many things. In a deployment where work can not be broken out into AOI's, access to all the data is required. A blanket statement that this data is not required is inaccurate in some deployments (more often than folks on the development team probably realize ) . When data is associated to regulatory concerns this is generally the norm. Yes 1 GB is larger than would generally be expected and we likely will only have one that large. There are also a number in the 500 MB range. As I mentioned in my initial post we see a 15 minute to transport when running the application on the same server where the server side replica is created. After the initial deployment we will do this rarely, I just find it curious that this takes as long as it does and wondered if any setting would improve the copy operation. If I run the createReplica from the rest API when I use the return url and download it takes about 40 seconds. So an operation that is taking 40 seconds through a browser appears to be taking 15 minutes using the API.

‎10-16-2017

We have a utility that generate the initial replica for a pre-planned workflow. With large datasets (like almost 1 GB in size) the initial download is pretty slow even when generating on the server the hosts the services. We do see some improvements on the server cutting the time down from 29 minutes to 24 minutes. However, of this time the majority is transport between AGS and the download location. Monitoring the folder on server showed it took 9 minutes to create the replica. That would mean it took 15 minutes to transport the file when running on the same server and drive that the replica is generated. This seems to me like a long time to basically copy the file from the server location to the download location. I realize that even on the same server it is still transporting over https, but is there anyway to improve this transport? Thanks -Joe

‎10-14-2017

The sample does this so they can bind the button commands directly to the SketchEditor commands. There is no requirement that this approach is taken. If you want to bind to the SketchEditor commands you can make a SketchEditor property in your ViewModel (DataContext) and bind through the property

Online Status	Offline
Date Last Visited	‎06-23-2026 12:26 PM

My Ideas

Latest Contributions by JoeHershman

Re: Is there a way to turn off m-values for services in ArcGIS Server Manager (10.3.1)?

Add multiple layers to map pointing to same table

Re: Sync fails at 10.5.1 with 500 error

Re: Changing basemap from service to tile cache does not work

Building Modular Applications with Prism, MEF, and the ArcGIS Runtime API

Re: Need to be able to Sync replicas a user does not own

Re: Need to be able to Sync replicas a user does not own

Re: Sync fails at 10.5.1 with 500 error

Re: Download Sync not working in AGS 10.5.1

Re: Improve replica transport performance?

Re: Popups in ArcGIS Runtime SDK for .NET

Re: Improve replica transport performance?

Re: Improve replica transport performance?

Improve replica transport performance?

Re: How to use Sketch graphics without changing the DataContext

Re: NET 10 Support Maps SDK

Re: Trying to set preferredTimeReference in sddraf...

Re: Create PortalItem with zip file

Provide way to update a pre-packaged map definitio...

Re: Failure loading MapView after upgrade to 200.7...