Latest Contributions by JoeHershman

‎12-07-2018

The feature layer definition for an ArcGIS Enterprise based service contains the following information included in the following sample information which defines subtypes. { "subtypeField": "ASSETGROUP", "defaultSubtypeCode": 0, "subtypes":[ { "code": 0, "name": "Unknown", {"defaultValues": {...}, "code": 1, "name": "Value1", {"defaultValues": {...} ] }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ This is in addition to the types array which you describe and is defined in both the Enterprise definition and the agol definition (e.g.) "types": [ ]‍‍ The ArcGIS Runtime API parses the json elements and the API has an object model around Subtypes (see the original response to this post). Because agol does not include these elements in the json, the API can obviously not parse them. So code written to work with Enterprise 10.6 does not work with agol because the agol feature layer definition does not include the subtype elements

‎12-07-2018

You don't support subtypes. What you describe is not support of subtypes. Telling me that I can make a rest call and pass in all subtpe information as a huge json object is not a valid workaround. Maybe with a couple services that are going to remain static it could be done, but not at a large scale.

‎12-07-2018

I know how to get the information using the current agol definition, and it is very convoluted and far more complex from a coding standpoint. Plus I am now required to have two completely different approaches in a Runtime application depending on if it uses ArcGIS Server 10.6 or agol. This is a very poor way to support people developing for the Esri platform. We do have a project to expose and preserve subtypes if you do not specify renderer based on subyptes. This is also an enhacment enterprise has and did not make it in online. This is also planned for UC2019. First you are not really preserving subtype in the current approach, there is just a way to get to the information throuugh the featureTypes. These are inherently different things. As users of esri technology I should be able to expect that both ArcGIS Enterprise and agol grow together. If Enterprise adds some so significant I should be able to expect it be available in agol.

‎12-07-2018

I understand what you are saying. And I am not criticizing that the API supports Subtypes. I find that great and have used it to much benefit and was very glad to see this support was added (I believe I had once listed that as a desired improvement). And this is not meant as pointed towards you, and perhaps I should have posted elsewhere. What I am saying that as someone who makes their livelihood using the APIs it is not unreasonable to expect that both agol and the current ArcGIS Server would follow the same standard of service definition. Esri likes to tell as at conferences how wonderful all this works together, but this is a glaring example of a huge shortcoming. Runtime API does a great job abstracting Portal away from the developer (despite some nuances with authentication). I was very happy at how simple it was for me to move an application developed for Portal to agol. That was until our editing tools exploded because they took advantage of Subtypes.

‎12-06-2018

My issue is more along the, it sure would be nice for developers if the ArcGIS Server, the agol, and the Runtime teams were on the same page. Runtime adds features to the API and these are supported by ArcGIS Server but not by agol? That is something that negatively impacts Runtime developers.

‎12-05-2018

I have an application developed using on on-premise portal which we planned to also deploy using agol (making the bold assumption that feature layers would be defined the same). Now that we have moved to agol I find that agol feature services do not have subtype definition. I have published the same service to portal and to agol. In portal if I look at the json I see the subtype definition, but this does not exist in the agol layer definition. How can this be? How could there possibly be a core new feature of the 100.3 API and not have it supported when using an agol layer. So all this nice clean logic based on subtypes developed for a featurelayers created in ArcGIS Enterprise cannot be used in the application when it uses agol layers and instead have to go backwards and use logic based on FeatureTypes (which was removed from the application in favor of the subtype logic). All I can do is shake my head as I work late into the night trying to fix the application to work with agol. -Joe

‎11-30-2018

Hi, I had a tool before that let us do the popup configuration in an editor and then reload into the web map. This was really easy because the WebMap was just a simple dictionary and I just had to replace the ['operationalLayers'] for a file. This cannot be done in the newest API. What I am trying to do instead is remove the layers and then re-add them. The issue is when trying to add the layer using WebMap.add_layer it does not allow it. I have copied the exact layer object from a Map and then tried to add and it does not allow, so I know it is not an issue with the json. How do I create a layer that can be added using WebMap.add_layer from the definition json? Here is a code sample that shows the issue adding layers. I use the identical definition to remove and works fine, try to add the same layer and it fails web_map = arcgis.mapping.WebMap(web_map_item) # create a copy of the layers layers = [] layers.extend(web_map.layers) # remove layers for layer in layers: web_map.remove_layer(layer) #try to add layers back - see error below for layer in layers: web_map.add_layer(layer) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-55-3865d40b28c6> in <module>() 8 9 for layer in layers: ---> 10 web_map.add_layer(layer) 11 C:\Program Files (x86)\Microsoft Visual Studio\Shared\Anaconda3_64\lib\site-packages\arcgis\mapping\_types.py in add_layer(self, layer, options) 339 else: 340 raise TypeError("Input layer should either be a Layer object or an Item object. To know the supported layer types, refer" + --> 341 'to https://developers.arcgis.com/web-map-specification/objects/operationalLayers/') 342 # endregion 343 TypeError: Input layer should either be a Layer object or an Item object. To know the supported layer types, referto https://developers.arcgis.com/web-map-specification/objects/operationalLayers/‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Thanks -Joe

‎11-27-2018

If that is not giving enough information your only option is hitting the rest API directly using HttpClient. That will give all the information available (Portal services ). Make a call to https://[domainurl]/portal/sharing/rest/community/users/[username]?f=json and you will get a big json object with everything about the user. As far as knowing the actual level of the Runtime license I don't know. I have always used named user approach to get a license and not used an embedded license

‎11-26-2018

PortalUser.Privileges Property. Gives you an iteration of the PortalPrivilege Class. From there get the PortalPrivilege Class object and the PortalPrivilege.Role Property should give you want you want

‎11-21-2018

As Antti mentioned in his response. MMPK created from Pro are not-editable. The only way to create anything for offline use is to create a feature service first and use that service for creating the offline data

‎11-15-2018

Yes don't get me going on the schema change thing. Another area that the old Windows for Mobile API handled better. We have gone the route of fully breaking out our data into single layer replicas. We also present certain layers in multiple symbology so it is required to separate these out. We don't use related data in the field so haven't had to address issues with that. Something else we have done with syncing is just doing delta syncs on data that only needs to be pushed on a nightly basis. The delta files are generated from a python script using the rest API and zipped. Then a rest endpoint is provided for the clients to ping, download, and update using GeodatabaseSyncTask.ImportGeodatabaseDeltaAsync . If not connected it will try the next time the application is opened. If I could figure out a way to find the edits in the .geodatabase file I would have gone the custom sync engine route long ago. But I have searched through those databases and just cannot figure out how I would query them to find the edits. I know there has to be a way, but no luck so far. All that is done in the core C++ libraries so cannot use reflection to look at the code. We do continuous background syncs to keep the field up to date. If not connected it just skips tries again. If the users needs data faster then the clock they can just do a manual sync (that means multiple people need to coordinate at times). With certain mission critical types of data the field is trained to sync immediately after adding the features. In the old API we could do the background sync on a 5 minute interval and the entire field crew 600+ was current in near real-time and they almost never needed to do a manual sync. No longer with the new sync model, too much of a server hit to sync that much. I have been frustrated with the new replica sync model since day one. Honestly, think it is a big step backwards from how the old API worked and performance stinks.

‎11-15-2018

We've done it all If you are using archive enabled databases, the best approach performance wise follows the idea of zipping. With replicas generated off archive enabled databases you can just generate a single copy of the database and then run GeodatabaseSyncTask.RegisterGeodatabaseAsync (GeodatabaseSyncTask.RegisterGeodatabaseAsync Method) from the client. Generate the single copy of the .geodatabase and zip and store on the server. Download > Unzip > Register. We have done by storing the zips in Portal and just storing on a server and using HttpClient to download. The portal approach is nice because you can use the API for downloading and not need your own Web Server configuration (we have a custom rest service as an endpoint for that approach). If you are using versioned database this won't work, but I would highly recommend against a versioned database because it does not scale well at all. We have also worked on breaking out replicas into more manageable sizes, so each only contains a small number of layers. An advantage of this is that if data does need to be replaced on the client it is easier to manage. The current sync tools do not allow for any schema changes. If for any reason something changes on the database side (add a new field) you need to push an entire new replica to the field. Breaking in multiple databases also gives you a way to manage syncing if some data does not change frequently. Enjoy!

‎11-15-2018

3) You don't need to use Portal you can just use ArcGIS Server and generate the replicas from the feature services. You do lose security with this approach, but it is possible. I agree with Antti Kajanus‌ if you can do a workflow that allows you to use the offline map approach it does simplify things

‎11-15-2018

I use direct rest calls when generating and downloading replicas because of the download time you are experiencing. I am not sure why but the download through the API is absurdly slow compared to the time it actually takes to download the file through normal means Improve replica transport performance? You can test by using the Web API. Generate the replica and that will give you the link to the file on the server, then you can manually download through the browser. This download time is what you would see using the rest api directly and my experience is it is orders of magnitude faster.

‎11-02-2018

To give a little more context an ObservableCollection responds to items being added or deleted to the collection. So when bound to a list type control it will reflect those changes to the list. With an ObservableCollection changes to the objects within the collection do not send notification (raise IPropertyChanged). In normal C# if you wanted to have a bound list and also be able to see changes to the objects in that list you would use a BindingList. With adding Graphics the Graphics property on the GraphicsOverlay changes, so there is no type of notification sent by the ObservableCollection. The GraphicsOverlayCollection was provided to fire the proper notifications to see changes to the graphics (I'm assuming). Cheers

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

My Ideas

Latest Contributions by JoeHershman

Re: No Subtypes in AGOL Layers?

Re: No Subtypes in AGOL Layers?

Re: No Subtypes in AGOL Layers?

Re: No Subtypes in AGOL Layers?

Re: No Subtypes in AGOL Layers?

No Subtypes in AGOL Layers?

How to create a WebMap layer from json

Re: How to get license level from arcgis portal login

Re: How to get license level from arcgis portal login

Re: Edit data and sync it back - what is the best way?

Re: Replica Generation Failing During Download

Re: Replica Generation Failing During Download

Re: Edit data and sync it back - what is the best way?

Re: Replica Generation Failing During Download

Re: How to Update MapView with Graphics via ViewModel?

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...