Get the feature count of all layers in a Map service using a single HTTP request

740
2
08-11-2023 09:21 AM
YohanBienvenue
Occasional Contributor II

For our GIS application I need to get the feature count of each layer in a map service and display them.

Right now I can do this by querying each layer individually using the returnCountOnly parameter. However when we have map services with 100+ layers, this generates a lot of HTTP requests on the map service. I can manage this by adding a delay between each request, but I fear this many requests might also skew our usage statistics of these map services.

If there is a way to get the feature count of all layers in a single HTTP request, I would like to know. If this isn't possible directly using the ArcGIS REST API, then I'm also open to other suggestions (e.g. publish a geoprocess on ArcGIS Server ?)

Thanks

0 Kudos
2 Replies
JamesCrandall
MVP Frequent Contributor

If you go the gp service route and implement python api to I guess access a FeatureLayerCollection, there may be something there to go at it in one shot but I'm not sure what is under the hood behind that operation (ie, maybe it just makes all 100 requests too).  Also, this seems overly complex for such a simple request to get feature counts!

 

Anyway -- sorry no real good answer for you just a quick comment and will get notified of any other answers you may get, I am curious myself!

0 Kudos
YohanBienvenue
Occasional Contributor II

Indeed there might be no magic and this would result in 100+ requests internally too. We have a lot of users so this could get heavy fast.

We discussed it a bit more and we are now thinking of caching the values somewhere. Most of our data is static, so we believe it would be acceptable to display a feature count that might be several days old. We could have a simple bash script fetch the feature counts from the Map services at regular intervals, and save this in a table. Then our GIS application would simply fetch the feature counts from that table directly.

This is probably what we'll do if there's no better way. Thanks.