[mapserver-dev] RFC-108 : heatmap generation

[Lime, Steve D (MNIT)]

Hmmm... Could use CLASSGROUP to define custom classification. That way you could cover both cases. The default would be to use no class group, just an idea. Example mapfile snippet is below.

Steve

LAYER
    NAME "heatmap"
    TYPE raster
    CONNECTIONTYPE KERNELDENSITY
    CONNECTION "input-heatmap"
    STATUS ON
   PROCESSING "KERNEL_DENSITY_INTENSITY_CLASSGROUP=intensity"
    ...
END

 LAYER
   TYPE POINT
   NAME "input-heatmap"
   CLASSITEM "risk"
   CLASS
     CLASSGROUP "intensity" 
     EXPRESSION "high"
     STYLE SIZE  5 END
  END
  CLASS
     CLASSGROUP "intensity" 
     EXPRESSION "medium"
     STYLE SIZE  3 END
  END
 CLASS
     CLASSGROUP "intensity" 
     EXPRESSION "low"
     STYLE SIZE  1 END
  END
  CLASS
    # normal rendering behavior goes here
   END
END



-----Original Message-----
From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of thomas bonfort
Sent: Monday, February 10, 2014 9:55 AM
To: Rahkonen Jukka (Tike)
Cc: MapServer Dev Mailing List
Subject: Re: [mapserver-dev] RFC-108 : heatmap generation

There's a trade-off between legibility/maintainability and functionality that has to be made. I've favored functionality and that means that yes, you'd need to duplicate your point layer, or override the style->size by url. The previous method was also unclear in the sense that the attribute to use of the vector layer had to be specified as a processing key of the raster layer, and further filtering/classification in the long run would have to been done through even more additional processing keys.

--
thomas

On 10 February 2014 16:06, Rahkonen Jukka  (Tike) <jukka.rahkonen at mmmtike.fi> wrote:
> Hi,
>
> About the STYLE-SIZE thing, isn't it a reasonable use case to show 
> also the point layer on a map as in the picture in section 2.2 of the RFC?  If the data layer has classes class
>     expression "medium"
>     style
>       size 3
>     end
>   end
>
> Does it mean that points of the data layer are also plotted with different sizes? Or does this mean in practice that there must be one technical layer for feeding the heatmap layer and another layer for plotting the data points? Then these layers will be unconnected and once the DATA line of one or another is edited it is up to the user to remember to edit also the other for keeping them in sync => guaranteed to fail every now and then.
>
> -Jukka Rahkonen-
>
>
>
>
> thomas bonfort wrote:
>
>> >> 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?
>>
>> I have updated the RFC and code to use this class->style->size 
>> notation for specifying alternate weightings. The default is to use 
>> uniform weighting if the source vector layer has no CLASSes defined.
>> Although the syntax is a little more verbose than the proposed 
>> PROCESSING "ATTRIBUTE=attr" notation, it is much more feature-full 
>> and closer to classical mapfile notation.
>>
>> regards,
>> thomas
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-dev