[mapserver-dev] RFC-108 : heatmap generation

[Rahkonen Jukka (Tike)]

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