ThinkGeo.com    |     Documentation    |     Premium Support

Heat MAP?

Hello,


Could you explain how the heat map is interpreting the data?  is it on the number of data points density or ?


thanks.


 



Hi Jean-marie,


Welcome to ThinkGeo support forum.


The heat layer's data isn't based on the number of data points. Firstly, we should set a FeatureSource (typically a shape file with point type) for a HeatLayer, there are two ways to interpret heat map's data.


1. Use column value as intensity value ( by setting HeatStyle.IntensityColumnName) 


2. Use predefined value as intensity value (by setting HeatStyle.PointIntensity)


The following link demonstrates how to use heat map.


wiki.thinkgeo.com/wiki/Map_S...eat_map.3F


Please let us know if you have further questions.


Regards,


Ivan



Jean-marie, 
  
   To be more precise the HeatMapStyle uses GDI+ to create the densities and not strict interpolation.  By setting the point density the point is drawn with a circle which goes from white to black from its edge.  This is done using greyscale values and after all the points are drawn then we color the greyscale using the color range specified.  This is very quick but sacrifices accuracy.  For spatial analysis, GRID is the appropriate tool. Although a heat map looks like a GRID, it is not one and it cannot substitute GRID for spatial analysis. If you need interpolation using IDW or something similar then I suggest you use the GridFeatureLayer I believe.  This layer allows you to setup a number of data points, a grid size, an interpolation method and will generate a proper grid.  You can then use another style to color the grid values. 
  
 If GRID is something you are more interested in let me know and I can create a sample. 
  
 David

I would like to see a sample, David.  I was not aware that you had a GridFeatureLayer that had these interpolation options.

 Ted,


 
  This is something we developed for supporting isoline / contour maps.  The isolines we have working well but don't have a nice API wrapped around it yet.  On the grid side I think we have everything in place but I need to refresh myself on how this works so give me a day or so.
 
Attached is a picture of the well depths in Grey County Kansas.  We had to do the interpolation to get the grid to then generate the isolines.  Anyway we will post something soon.
 
David
 


That’s great.   We have a pretty good IDW interpolation engine, but had not yet done iso lines or polygons with it.   I was being pushed to do this for our June release.  Maybe you’ve already nailed it :)

I am also interested in this - I have a GRIB file converted to a MIF file with points at 1 degree intervals and a column of values related to wind speed. I am trying to find the best way to represent this. The ideal situation would be a contour map showing the different speeds, with each polygon being different (translucent) colour.

David, you have touched on a key point.   Most applications do what ThinkGeo has done… they generate isolines (contour lines).   These lines represent a value… something like 1000 feet elevation.   And another line represents 1100 feet elevation.   Most applications do not generate a polygon that represents 1000-1100 feet of elevation.   I, too, need a polygon representing the range between isolines, rather than the actual isolines.   However, in a past application, I built the polygons by cutting the original boundary with the iso lines, and then went back and queried the sites in each polygon to establish the actual average value within the polygon.   If ThinkGeo gets me isolines but stops short of polygons, I would contribute the next step.

Ted, 
  
  Thank you for the suggestion. Indeed, it would be convenient to support also polygons. We added this features to our Issue Tracker.

 Guys,


Here is a sample of how to create a grid file.  The sample uses a class break rendered to show the points used to create the grid and then another to actually display the grid.  On the interpolation model class there is a power property and a search radius you can mess with.  The sample will very soon go up on the Code Community after the release.  This means you need that latest developer build as of 4.5.171.0 for this to work.  The API is setup so you can extent the interpolation model with whatever you want and I suspect we will have a few more, less famous, models added in the new few weeks.


  We have the isolines stuff working but do not have it wrapped in a nice API just yet.  Ted, if you want it early I can ship what we have with instructions.  If not I think we would have something nicely wrapped in two weeks or so. (Release is taking up all our time now).  The way I remember it is that most of the Isolines so create polygons and you can cut them out.  I think we have code for this already.  This feature has been pseudo done for awhile but havent had the time to take it that extra step to make it produciton ready.  Any input would be great once you see it.


David



CreateGridFile.zip (103 KB)

Ted, 
  
   If you are doing analysis then it might be best to just use the grid data itself and not the isoline polygons.  With the grid data you could combine all of the cells of a certain range to create the polygons.  This may be more precise and faster for analysis.  The GridFeatureSource and GridFeatureLayer treats all the cells as little rectangle polygons so you can spatially query them etc.  Any scenarios you have would be helpful. 
  
 David

David, I can wait for this tool.   I would like to have by mid-June.     
  
 I agree with staying with grids for analysis.   We create prescription files for fertlizer controllers from grids, though.   They have to be delivered as coverages, and many controllers cannot support the number of cells associated with a grid if you get down to 3 meter resolution on a 160 acre field.   In our old COM app, we take the iso lines, reduce them to make them a little coarser by removing points that are close together, and then cut the field boundary with them.   This makes fewer polygons and the controllers can handle them. 
  
 I’ve heard of something called a marching squares algorithm to merge adjacent grid cells with similar values, too.   That might be a better option for what we are doing. 
  
 Your May release is the top priority, though.   Looking forward to it.

Ted, 
  
   I will keep you posted.  I think Marching Squares is at the heart of all of the ISOLine algorithms.  You do the marching squares and, in a way, connect the dots with lines for the polygons. 
  
 Just a heads up the release will come out May 16th. :-)  We wanted to fit in iPad support for the Web and a preview of our new WYSIWYG dynamic layout printing stuff.  We should officially announce it pretty soon with a list of all the features and fixes.  We are trying in the future releases to release the list of features well ahead of the product.  We are also going to integrate the Enhancement Tracker more deeply into our road map and releases.  In the near future, I hope, we will post the status of the projects in the tracker and work off of that for new enhancements. 
  
 David

Ted, 
  
   I wanted to let you know we are really close on this and have added the the feature you wanted. 
  
 1. Build grids (with latest release) 
 2. API to Generate Iso Lines 
 3. API to Generate Iso Polygons 
 4. API to generate the breaks if necessary 
 5. IsoLineLayer that displays the isolines and can run from a grid file or dynamically generate the grid on the fly as you move around for the visible area (Great for large datasets). 
  
 It will go into the daily build next week.  Any chance we could get you to take a look at it then? 
  
 David 


Yes.  That timing will be great.   We are planning to update from 4.5 to 5.0 next week, and thought we would go with the daily build.

Ted, 
  
   Great…  Let’s touch base early next week and I can make sure the bits are in the daily build.  Also let me know if you have ANY issues with the 5.0 stuff.  I will be around for you if you have questions. :-) 
  
 David