Support point clustering in the Map Service properties

BernieConnors

Many "ideas" have been submitted about implementing point clustering in AGOL or the various APIs for ArcGIS Server. Wouldn't it be smarter to implement point clustering in the map service properties? I understand there will still be a need for point clustering implementations in the APIs but for Esri users that have their own ArcGIS Server installation it would be great to implement clustering in the map service and then the point clustering would be available in any client that we chose to display the map service.

Best regards,
Bernie.

KevinSayer · ‎11-11-2014

I couldn't agree more. I have maps with a few million points when zoomed right out and they take ages to draw. I want to consume them from several different clients and shouldn't have to individually implement clustering for each one. I'm frankly amazed that you can't do this in ArcMap.

KarenRobine · ‎05-28-2015

Agreed. Would be sweet to see Point Clustering applied Server-side, and then only download the clusters at the current extent.

JohnDye · ‎10-08-2016

THIS!!! To the power of 100!!!

We have point features that are very close in proximity and its just awful in Portal and ArcGIS Online to not be able to cluster by proximity and show a nice circle with the number of features in that area until the user zooms in enough to be able to display them clearly.

ThomasEdghill · ‎11-14-2019

Hello Bernie Connors‌, with ArcGIS Enterprise 10.7.1, we introduced a capability called feature binning which clusters nearby points into dynamic polygons, and is a service-side property supported with map services published from ArcGIS Pro 2.4 and later. Below is an animation of this feature, taken from the doc:

For some further reading on how to implement feature binning with your point data, check out the following documentation and blog links:

Aggregate features into bins—ArcGIS Pro | Documentation

Introduction to Dynamic Feature Binning in ArcGIS Pro

With this new capability, does this satisfy your requirements? Feel free to share any additional feedback and let us know if this works for you.

Also tagging Kevin Sayer‌, Karen Robine‌, and John Dye who commented on this - We're happy to hear your feedback as well.

JohnMDye · ‎11-14-2019

I can’t speak for the others but for me, the answer is “cool, but nope, this is not what I wanted.”

I want clustering in the Map Viewer in Portal to be enhanced. My problem with the current clustering in the Map Viewer is pretty simplistic. It doesn’t support displaying the count of how many features a given cluster represents. It’s just graduated symbols. Which is fine, but it needs to add the capability to also be able to display the number of features the given cluster represents and not leave that up to visual interpretation all the time.

Personally, I hate map legends and I judge the usefulness and intuitiveness of a map by the size of a legend. I dont want to look at a legend to figure out what something means. With really complex maps that have a lot of information, sometimes they are a necessary evil but I always strive to reduce the size of my legend by making symbology intuitive so that it doesn’t need to be put in a legend. Point symbology, imho, should almost never be in a legend. We can make symbology that makes obvious sense. The green tree is a park. The shopping bag or even better, individual retail or logo is a store. Fire Dept. logo is a fire station. The graduated circle with 24 inside of it represents 24 items in the general vicinity of that point.

Rene Rubalcava‌’s cluster-js repo on github is the EXACTLY what I’d want in clustering. That small touch makes it a billion times better. The amazing Carsten Piepel‌ also wrote an SOE which is similar, but of course SOE’s have the drawback of only working on traditional services, not hosted services (womp, womp). Maybe Kelly Gerrow‌ and team will be able to get this functionality into the new Map Viewer since it will be built off of JS4? Or maybe it’s not a Map Viewer limitation at all and Philip Heede would need to prioritize it for the Hosted Feature Service spec. Hard - that dude’s got a lot going on. Really looking forward to ArcGIS for Docker - make sure there’s support for Kubernetes too Philip Heede! Pretty please! I’ll buy you a beer, multiple beers!

Idk what the deal is with it, but feature binning - while admittedly cool, valuable and a worthwhile investment of dev time - is not what I was asking for. Thanks for the mention though!

ThomasEdghill · ‎11-19-2019

Thank you for sharing this feedback, John! Helping to understand how feature binning does not meet your needs is equally valuable, so I appreciate this perspective. Thanks as well for providing those additional resources to illustrate point clustering.

To provide a bit more context, one key aspect of feature binning is that it's done server-side, instead of being a client-side operation through an API, or through the Map Viewer. Given this fact, I do believe we have at least partially implemented the idea as originally stated. That being said, other ideas on improving client-side clustering behaviors like you mention are definitely worth attention and continued exploration.

JohnMDye · ‎11-19-2019

Meh. I disagree.

KarenRobine · ‎11-20-2019

Sorry guys. A bit late to the conversation (was on vacation).

I am interested in seeing something in the REST endpoint that can support server side clustering and provide the ability in the JavaScript API that renders point features that represents numbers of features (not necessarily point features) within variable distances at certain scales. I pulled it off in my app here: www.fs.fed.us/ivm.. If you click on one of the opportunities (ie., Hiking), you can see how it works. At zoomed out scales we summarized by states or FS districts (ie., how many hiking trails in a FS district) and clustered those. Then used real clusters when zoomed in. Took a lot of manipulating to keep the performance up there (when dealing with huge amounts of linear features). But worked pretty good in the end! Would be great to see something like this show up in the REST endpoint so I wouldn't need to do the summary bit.

I've had this same issue come up for other clients, so know there's a greater need for this out there. Thanks.