Add Display Filters compatibility

10-15-2020 04:47 PM
Status: Open
New Contributor III

Add Display Filters compatibility between ArcGIS Pro and ArcGIS Online.

Filter queries that limit which features of a layer are displayed at certain scales are essential in the AGOL environment.
Please consider making the portal use the filters defined in ArcGIS Pro.

Fábio Luiz



scale ranges

1 Comment

@FabioLuiz Not sure if you are able to change the community after the fact, but this Idea got filed under Experience Builder when it probably should have just been under ArcGIS Online as a whole.


Fully support this idea and my organization would be thrilled to see it happen. I just got this logged as an enhancement with Support Services as well.

  • ENH-000150894 : Allow for ArcGIS Pro display filter functionality in ArcGIS Online


Here is my organization's use case:

Three Rivers Park District has developed it’s own custom vector tile basemap using a single authoritative ArcGIS Pro Map file that is also used in all 80+ static map exports we create as well. We display this map on our website( using the javascript api. We currently create a separate hosted feature layer so we can generate a dynamic legend that only shows what is visible in the map extent. Unfortunately the process to develop this hosted feature layer is tedious because we utilize multi-scale symbology and display filters in ArcGIS Pro to make our map file and vector tiles more efficient. Both multi-scale symbology and display filters are currently not supported in feature layers, so to get around this we need to split apart our each layer from our authoritative Pro map into separate layers to represent each scales display filter & symbology. It’s not the easiest thing to keep track of since we essentially have to remake each layer from scratch and copy over the symbology and definition query. If we make changes in the authoritative map we then have to adjust the legend service as well. If multi-scale symbology and display filter data was supported in a feature service then I can see this being very useful for our use-case but just a lot more efficiency within the portal environment.