No Subtypes in AGOL Layers?

2590
19
12-05-2018 07:17 PM
JoeHershman
MVP Regular Contributor

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

Thanks,
-Joe
0 Kudos
19 Replies
dotMorten_esri
Esri Notable Contributor

Sorry just realized this is more of an ArcGIS Online question, and not a question of the Runtime API

0 Kudos
JoeHershman
MVP Regular Contributor

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.

Thanks,
-Joe
0 Kudos
dotMorten_esri
Esri Notable Contributor

I'm not sure I get the point? Runtime adds support for as much as it can, and if one server doesn't have a particular feature supported, it won't affect Runtime. The alternative would be to only support the common set of features, but then you wouldn't get subtype support when using servers that does support subtypes*.

*disclaimer: I don't know if AGOL supports subtypes, and if it does, how to enable it. I moved the post to the AGO forum, so hopefully someone can answer if/how it's supported.

0 Kudos
JoeHershman
MVP Regular Contributor

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.

Thanks,
-Joe
0 Kudos
KellyGerrow
Esri Frequent Contributor

Hi,

ArcGIS Online Hosted Feature Layers do support subtypes. There is a very limited authoring experience (configuring category rendering using unique symbols) from the ArcGIS Online UI. You can however construct subtypes through the Update definition REST API call:

Update Definition (Feature Service)—ArcGIS REST API: Services Directory | ArcGIS for Developers 

or constructing subtypes and domains in ArcMap or ArcGIS Pro and publishing to ArcGIS Online. This thread contains an example:Restricting Field Visibility Based on SubType

How are you publishing the data? Are you able to share the layer?

-Kelly

0 Kudos
KhaledHassen
Esri Contributor

Online feature service supports types/template from service definition file (SD). This when you configure renderer based on subtypes. We do not currently preserve subtype when publishing filegdb though (we have this as enhancment-Maybe UC2019). 

Pl. try to go to ArcMap or Pro and try to publish your data (from filegdb). You can use your filegdb as the source of the data. You would have to configure renderer based on subtypes in order to get them to online as types metadata.

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.

Thanks

Khaled

0 Kudos
KhaledHassen
Esri Contributor

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

Yes this is our goal and we are trying hard to make this happens. But as you might have seen, there are always new WebGIS development in online FS that is not yet in server/enterprise and vise versa. This is mainly related to the the different requirements we have for enterprise versus online and their release plan.

As far as the sub types, we do support it online it as described and used. We are working on adding the support of adding subtypes during publishing and expose them even if they are no referenced by any renderer. This is the only missing spec in online FS but our understanding this functionality is used only by Pro. So this is why it was not a high priority in development for online FS.

To get around this limitation you can use the feature service layer update admin API to update the layer types or templates. If this is not the issue, pl. let us know and we can help you providing a workaround for any missing specs if possible and add the missing functionality to online in future releases

Thanks

Khaled

 

0 Kudos
JoeHershman
MVP Regular Contributor

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.

Thanks,
-Joe