I have searched the internet high and low and the closest I have come to a solution is a way to manipulate JS in the API in a GitHub article. I need to provide a label that shows the number of points clustered as you scale in and out on the map. I have tried to figure out a way in Arcade to do this but thus far have not succeeded. With that being said, is there a way to do this and if so how do I do it. If it is something that QGIS does out of the box, then why is it not something that ESRI can do and make available? Thanks for any help.
Sorry for the lack of information on this. We want to add label clustering for 4.x (we are expecting that cluster support will come in either 4.14/4.15), but I'm not sure if it will make it into the initial release.
Very, very soon (you should hear more in the next few days). Beta clustering will be added in 4.14, but we won't have cluster labeling initially. Right now we're thinking either 4.15/4.16 (can't guarantee this) depending on how other issues get prioritized. Once clustering does land, there are a few more areas specific to clustering that we need to work on before labeling, including adding some basic querying capability for the clusters, as well as supporting arcade. We'd also like to improve some of the rendering quality as well (have better transitions when zooming in), but that would likely happen after we have all of this functionality in place.
Matt George over on the Map Viewer Beta forum, Russell Roberts is indicating that cluster labeling isn't planned? Will someone please calm my nerves? I've been flipping tables all weekend long. No way in banana republic you can not add labels for clustering at some point.
One other thought - I'd question why one might prioritize the ability to query a cluster or access it in Arcade over the most basic functionality of labeling the cluster. Arcade I kinda get because if I could just write an Arcade expression to cluster and label my point features, that'd be just fine with me.
As for the querying of a cluster I mean, it sounds cool and useful and I get it if you need that capability in order to label the cluster in the first place, but I don't think that's the case because it that functionality already exists in one state or another given that currently you can get the cluster feature count in the cluster's popup. We just don't want to have to click on the cluster to read the count out of a popup, that's all.
Look guys, it's like a chocolate chip cookie. Right now, you're giving me a cookie (the cluster) and a bag of chocolate chips (the counts for each cluster). For a while, I was fine just popping a a chocolate chip into my mouth with every bite of cookie but at this point, getting annoyed. I don't want to have to grab a chocolate chip out of the bag with every bite of cookie (analogous to clicking on the popup to see the cluster count).
We have the cookies (clusters)!
We have the chocolate chips (cluster counts)!
Take the chocolate chips out of the bag (the popup) and just bake them into the cookies so I get all that goodness in every bite.
Hi John. Sorry for the confusion -- yes, cluster labeling is definitely planned, and it will likely arrive before cluster queries. Currently it's not in the plan for the MapViewer yet because it's not in the API, but once it lands in the API I imagine it would come very quickly to the MapViewer. (I'll double check with the MapViewer team on this)
Main difficulty here is that we need to both persist this information (webmap spec change), and we're thinking we might want to provide the ability to not just label counts, but label other aggregate info (e.g., maybe instead of counts you clusters representing temperature observations and want to label the average temperate). That second part involves adding an API to specify how input fields can map to statistic fields (internally the engine logic to handle this is pretty much done).
If we go with more extensive labeling, clusters should be able to support the full LabelClass API. Otherwise we might expose this as some kind of `showClusterCounts` property on the featureReduction instead. If we do decide to go with the full `featureReduction.labelingInfo` approach, we may be able to get this out before we have the full statistic fields logic as that way it could still be used with the implicit `CLUSTER_COUNT` field.
Really trying to get this in (in at least some form) for 4.15 or 4.16. So far in the 4.15 cycle we've been working on a very large internal refactor of the way labeling is handled to make way for this.