[mapserver-dev] RFC-108 : heatmap generation

[Lime, Steve D (MNIT)]

You could want to draw the features with the same size as being used for heatmap intensity. If so you wouldn't need a classgroup and your original example would work.

Steve

-----Original Message-----
From: thomas bonfort [mailto:thomas.bonfort at gmail.com] 
Sent: Monday, February 10, 2014 11:46 AM
To: Lime, Steve D (MNIT)
Cc: MapServer Dev Mailing List
Subject: Re: [mapserver-dev] RFC-108 : heatmap generation

Could there be a case when you'd want to apply the classgroup logic to the point layer when it is acting as the source for the heatmap layer?
That's what's in the code for the time being.

--
thomas

On 10 February 2014 18:16, Lime, Steve D (MNIT) <Steve.Lime at state.mn.us> wrote:
> I did mean axis (stupid text suggestion functionality). I think specifying the kernel through a processing directive as you mention would be sufficient. Would just need examples for users.
>
> Steve
>
> -----Original Message-----
> From: thomas bonfort [mailto:thomas.bonfort at gmail.com]
> Sent: Friday, February 07, 2014 8:36 AM
> To: Lime, Steve D (MNIT); MapServer Dev Mailing List
> Subject: Re: [mapserver-dev] RFC-108 : heatmap generation
>
> 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
>>>
>>
>>
>