3

Using ArcGIS Server's JS API it is possible to generate a heatmap at runtime, as in the example at http://tmappsevents.esri.com/website/heatmap/index.html

This requires having client-side access to the individual points in the heatmap, for example by downloading a feature layer to the browser.

The problem is that the browser becomes unusably slow when working with more than a few thousand points.

Has anyone been able to generate the heatmap on the server-side, and send it down as a cached or dynamic layer?

I need the ability to generate the heatmap at runtime, so that the points could be filtered with the change immediately visible in the heatmap.

Stephen Lead
  • 21,119
  • 17
  • 113
  • 240
  • I had the same problem. Initially I solved by writing a GPService to filter and generate the heatmap. After I discovered that a SOE was more efficient. Few months ago I discovered MapET Spatial Feature Server. It is compliant with Geoservice REST specification ESRI and for the points allows server-side generation of the heatmap. Just configure the renderer "Heatmap" for the points and publish the service. Also it reads data from MySQL in addition to the usual DB used by ArcGISServer. – lele3p Jun 15 '16 at 07:46

2 Answers2

2

Well, the problem I see with this is that you're asking for help developing a server side solution with a client side language. Javascript is run in-browser along with the HTML and CSS, so any Javascript is inherently going to lend itself to a client side solution. Now, you may be able to write or find some plug-in that uses a server side scripting language to generate the dynamic map on the fly and then makes it accessible via a Javascript API or at least a javascript URL request, but a complete javascript solution it's likely to really meet what you need, there would have to be a server side component there.

Now, with that said, I see two options that come to mind that I know of. First, you could create different user interactions with the data depending on the zoom level they are at. You could aggregate the data, create a geoprocessing model/script that aggregates the data in some manner at various levels (there are tools to help with this in the Spatial Statistics Toolbox in ArcToolbox). Ex: for a world wide view you may only need one point (color/size coded to represent how "hot" that spot is) for each country, but as you zoom in past a particular zoom level it turns off the aggregated layer and turns on the feature service and does the standard client side rendering based on the points (but it would only have to use the points visible instead of all the points in the entire service because you're only zoomed in to a smaller area). And of course you could add more levels of aggregation in-between if you still had too many points (ex: all data aggregated by 500 miles for X zoom level, data aggregated by 100 miles for Y zoom level, and raw data shown at Z zoom level, or such as that). Just a thought though...

Honestly though, I'd look at Google Fusion Tables. So long as you are willing to upload your data and either manually or write the bit of code to automate the maintenance of the data within their Fusion Table framework, the heat map is relatively simple. The fusion table map component has a server side generated heat-map (at least last time I checked it was still server side, but you have to use that for server side not the fusion table layer access within the Google Map API because that is client side). Anyway, try Google Fusion tables out, I really think, it might help you out with your server side issue (so long as working within the Google licensing limitations doesn't bother you). You can get to it via a having a Google account and going to Google Drive and one of the create options should be a fusion table (so long as you're not using an organizational account that has all beta features turned off).

John
  • 3,853
  • 12
  • 17
  • Fusion Tables is a good idea - thanks, I'll explore that. However I think the terms of service will probably not allow me to use the output on a non-Google map. – Stephen Lead Feb 05 '14 at 07:16
2

Although a different technology and different type of question I want to point you to this answer I wrote for GeoServer. As long as your AGS service is configured to support WMS this should work for you. It will require some work but can result in a robust and highly dynamic solution. You don't necessarily have to use feature IDs to solve your problem, you could just create rules based on the attributes you want to generate heat maps for.

In summary: serve your maps using AGS's WMS interface and pass either an SLD parameter (URL) or an SLD_BODY parameter (XML document). The SLD can be dynamically generated from your data using whichever attributes you want to map. Once applied to your WMS you will be generating dynamic maps server-side on the fly. How you pass the SLD to your WMS depends on what kind of access the map server has to the web server where you implement your SLD-generation code.

Community
  • 1
tomfumb
  • 3,678
  • 1
  • 31
  • 59
  • Where in this process would the heatmaps actually be generated? I'm a novice at SLD but I believe this file only tells an existing dataset how to draw, and doesn't actually generate the heatmap (right?) – Stephen Lead Feb 05 '14 at 07:19
  • the SLD is a stylesheet that tells the map server which colour / size (if points) / border thicknes etc. to use when drawing features. You make one WMS request to the map server and that request includes some information about the SLD you want to use. The map server retrieves that SLD under the covers - which is generated dynamically to say either a) feature 1 is green, feature 2 is red etc. or b) population 0 to <= 1,000 is blue, population 1001 to <= 2000 is pink etc. - and then the map server renders and returns the image using those colours – tomfumb Feb 05 '14 at 14:20
  • generating XML can be extremely fast so the additional time required to generate the SLD really just depends on how long the database query takes to retrieve the data that the SLD is based on. – tomfumb Feb 05 '14 at 14:23