[mapserver-dev] RFC-108 : heatmap generation

[thomas bonfort]

On 7 February 2014 15:01, Lime, Steve D (MNIT) <Steve.Lime at state.mn.us> wrote:
> This really the first practical use of the range mapping stuff and moves it out of alpha status so they're kind of connected at the hip. With the image you don't need styles so maybe just pair RANGEIMAGE with RANGEITEM at the layer level in the pure RFC 6 case. In the RFC 108 case, as I understand it, you're computing the value you'd normally get from RANGEITEM from the kernel - correct?
That's basically it. The application of RFC6 to rasters was/is a bit
different in the sense that you're not using the RANGEITEM but
directly reading out the pixel intensity (said pixel intensity being
computed by applying the filtering kernel to the vector samples in the
rfc108 case rather than being directly read from the raster band in
rfc6).

>
> Also, any reason to allow for user-defined kernels? I think about instances where you want to bias a points contribution based on the distance from center, or maybe along an access.

did you mean "axis" instead of "access" ?

I was also thinking of providing a user defined kernel. The gaussian
one is actually 1D and is applied twice (once horizontally, once
vertically), so I was thinking you could provide something similar,
e.g.
PROCESSING KERNEL="0.1 0.2 0.4 1 0.4 0.2 0.1" for a radius=3 kernel.
Giving the full 2D kernel would be needed if you need to skew the
results along an axis. Not sure if there's an immediate need for that,
but definitely something that could be added with marginal changes.
Did you already have a mapfile syntax in mind?

>
> Only other thing I wonder about is the kerneldensity_attribute. Often you have non-numeric values that you'd like to apply. In my case we have high, medium and low values for wildfire susceptibility. High values would contribute more to intensity. I'm not sure how the feature attribute is use, but any idea on we might work from those?
That's what I was trying to hint at in the second point of
http://mapserver.org/development/rfc/ms-rfc-108.html#open-issues . We
sorta use the same mechanism for CHART layers, where the value of each
class is read from the style->size; that could also be used in your
case, e.g.:

layer
 type point
 name "input-heatmap"
 classitem "risk"
 class
  expression "high"
  style
   size 5
  end
 end
 class
  expression "medium"
  style
   size 3
  end
 end
 class
  expression "low"
  style
   size 1
  end
 end
end

To mimick the proposed ATTRIBUTE=VAL processing you'd use

class
 style
  size [val]
 end
end

I find the syntax rather clunky, but it is clearly more powerful.
thoughts? could this be done differently?

--
thomas


>
> Steve
>
> ________________________________________
> From: thomas bonfort [thomas.bonfort at gmail.com]
> Sent: Friday, February 07, 2014 4:41 AM
> To: Lime, Steve D (MNIT)
> Cc: mapserver-dev at osgeo.org
> Subject: Re: [mapserver-dev] RFC-108 : heatmap generation
>
> Steve,
> This is actually more related to the DATARANGE rfc rather than this
> one, but I'll keep it in mind if I have the time some day (maybe
> during the codesprint...). How would you activate that in mapfile
> syntax?
>
> --
> thomas
>
> On 31 January 2014 19:58, Lime, Steve D (MNIT) <Steve.Lime at state.mn.us> wrote:
>> What about possibly defining the color ramp with an image. I've built these sort of products outside of MapServer using GDAL and ImageMagik and the latter used images to store the ramp. The interpolated pixel value is used to lookup the appropriate color (based on y value). The nice thing was that I could build the ramp using a tool like Photoshop pretty easily and the image would almost act as sort of a preview. Attached is an example of one I use in combination with ImageMagik...
>>
>> Steve
>>
>> -----Original Message-----
>> From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Thomas Bonfort
>> Sent: Thursday, January 30, 2014 10:58 AM
>> To: mapserver-dev at osgeo.org
>> Subject: [mapserver-dev] RFC-108 : heatmap generation
>>
>> Devs,
>>
>> please have a look at RFC-108 [1]. The associated code and the RFC are still beta, so there's still plenty of room for modification or remarks.
>>
>> best regards,
>> thomas
>>
>> [1] http://mapserver.org/development/rfc/ms-rfc-108.html
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
>
>