[mapserver-dev] RFC-108 : heatmap generation

[thomas bonfort]

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