Allow Complex Symbology in Hosted Feature Layers

[RichardHowe]

It is ridiculous that vector data uploaded to AGOL, but intended for use in ArcGIS Pro cannot support complex symbology. From what I've read the intention of the downgrade is to make data intended for webmaps compatible with browsers, but there should be an opt-out for data that is solely intended for use with ArcGIS Pro.

Vector tile services do not provide the attribute based functionality our clients demand, the workaround draping tiles over invisible vectors is clunky (to say the least) and the use of layer files in AGOL pointed at feature layers is causing us authentication issues in collaborations.

All of this could easily be solved by supporting complex symbology in vector feature layers!

[RobertBorchert]

Don't use tiles.

[Vidar]

Further to the comment made on tiles: Vector Tile Services should just read Basemap Services - they really offer limited functionality from what I can see.

[jcarlson]

The symbology is defined by the client software, not AGOL. That is to say, hosted feature layers do support complex symbology.

The "downgrade" is simply altering its stored JSON definition to make it compatible with the ArcGIS JS API, but this is little more than a "default" symbology. You can have a simple line layer in AGOL, bring it into Pro, and symbolize it with as much complexity as you like.

[RichardHowe]

I wouldn't say they support it. Yes, you can retrospectively apply the symbology in Pro and it will hold for the session, but the software literally warns of the downgrade when you try and create a symbolised feature layer. All to satisfy browser compatibility? It's not good enough really.

The point is, there is no way to share pre-symbolised feature layers with complex symbology via AGOL...and there should be.

We have been working around this by also hosting layer files in AGOL, but this is now causing authentication issues.

It should not be too much to ask that we can host vector data pre canned with complex symbology for our clients.

[jcarlson]

It's not browser compatibility, it's the JavaScript API. When you publish a layer, it's creating a service JSON definition, which is currently constrained by the definitions in the 3.x API. It probably is too much to ask, as it would require a massive overhaul of an API that's already on its way out the door.

There are more complex possibilities currently available in the 4.x API, but it may be some time before that is the default API for service JSONs. Maybe an Esri dev can speak more to that point.

Have you considered sharing project packages instead of layer files?

[Vidar]

@jcarlson I still don't think that's a valid reason - there should be a way for AGOL to discern from the request the client type and if it's Pro asking for data then it should provide date that has not been downgraded. I'm sure this is technically possible.

[jcarlson]

The data is the data, symbology is just window dressing. But the way a service is defined in AGOL is just incompatible with other symbology types. I don't disagree that having this option would be nice, but it's like asking for a shapefile to somehow give you non-truncated field names if you open it in a specific software.

[RichardHowe]

@jcarlson I think describing symbology as "window dressing" is a little disingenuous and cartographers everywhere would probably have a lot to say about that, in complex data being served up to clients it has major importance. I also slightly disagree with the shapefile analogy, as in this case it's like us starting with a feature class and the middle part of the process downgrading that to a shapefile and us losing control of it.

I just think this is something ESRI needs to focus their attention on. AGOL is never going to rival Enterprise as a cloud storage solution until it can serve up nicely symbolised, fully attributed vector data.

In answer to the question, we haven't looked at project packages as we serve up near 40,00 individual layers which our clients wish to use in a variety of combinations. I have just started looking at layer packages but I still feel we're having to find workarounds for something which ESRI should be able to solve.

[jcarlson]

I'm sure a better solution is on the horizon, and for all our sakes I hope it's sooner than later. Myself, I'd like to see further development of the Hosted Image Layer on the AGOL front.

And you make fair points. I suppose I'm more of a "data person" in my org, and I'm primarily interested in the underlying data over the symbology, but you're right, I shouldn't project that attitude onto other valid use cases. I also don't serve anywhere near that many layers, so even a minor workaround clearly leads to untenable added time for you.

[KevinMacLeodCAI]

Agree with all of the above. It would be good to add:

1)  hosted Map Image Layers  (some 3rd party apps require it, it would allow for complex pre-rendered symbols, etc. Many other reasons) 

2) need to sync symbology from Pro up to AGOL  so AGOL supports almost everything Pro can do. 

3) make uploading custom images for symbols easier.