To add a little more to this...
What I have done in the past for thematic maps is to do the analysis in
the database and to bin the data into a new column or columns for each
analysis. Then in my mapfile, I can select the column that I want to
display. This made it easy to get fast maps because mapserver only had
to render based on a simple value 1-n based on the number of bins I
computed.
I have also create a stored procedure in the past that I could pass in
the number of bins and the type of analysis, and it would then compute
the binned values on the fly. I found that there was a lot of
flexibility doing this in postgresql and have mapserver generate the maps.
This would also be a good way to prototype up the various analysis that
you might want to explore. The one big missing piece to doing this is
that there is not easy way to dynamically change the number of classes
(bins) that are being generated in mapserver and assign them colors,
which the colorramp and datarange would help with especially if there
were a way to get those values dynamically from the data source.
-Steve W
Stephen Woodbridge wrote:
Right, I think there are two use cases:
1) data exploration - can be slower but needs flexibility
2) production serving - needs to be fast, and probably limits
flexibility to some predefined models
I think that there is also another angle to this, which is how the
summary data is computed for example:
1) min/max/average/std
2) statistical analysis
3) binning into some number of classes
4) removing outliers so the results are not skewed by them
5) etc
There are a lot of ways the people might need to summarize they data.
If the data is in a database, then you can add all the analysis, slicing
and dicing to the database and the rendering to mapserver.
So, I think that it would be nice to be able to read some "metadata"
about a layer and then use that for building the display using something
like colorramp and datarange. We might want to look at ways that we
could establish in mapserver for fetching the "metadata" about a layer.
For example:
1) define the "metadata" in the METADATA object
2) define a .met file for a shapefile or tileindex that contained the
"metadata" for that layer
3) define a separate SQL query that could be used to fetch the
"metadata" for the layer
4) something similar for other layer providers.
5) scan the data in two passes to compute some simple "metadata"
Thoughts?
-Steve W
Jan Hartmann wrote:
If you allow two passes, you can have all sorts of summarized values
in the template, to be used in the second pass, like Bart's actual
extent used for coloring. Doesn't look to difficult to implement to
me, as long as the two passes only get called when really necessary.
I'm not sure if performance is an issue for MapServer itself: if you
really want high performance, you should use the underlying format or
database directly.
Jan
On 3-2-2010 17:02, Lime, Steve D (DNR) wrote:
How big a change would depend on the implementation. The brute force
approach where you simply loop through features once to compute
ranges and then again to draw would be probably pretty straight
forward and driver independent. Wouldn't be fast (but would be
simple). Complexity would be added as you try and boost performance by:
- allowing drivers to compute stats in their own way (e.g. add to
the layer API something like msLayerGetStats(...))
- caching geometries from a first pass through the shapes for the
second
Steve
BTW The color ramp support needs to be cleaned up first. I think we
scared the originator of that code away when an RFC was originally
put together.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Bart
van den Eijnden
Sent: Wednesday, February 03, 2010 5:12 AM
To: [email protected]
Subject: [mapserver-users] colorramp and datarange on the fly?
Hi list,
is it possible to have a colorramp in Mapserver based on the min and
max value in the current extent?
So instead of predefining the min and max in DATARANGE, have
Mapserver use the min and max value of the dataset in the current
extent?
If not, would it be an easy change or a very complex one?
Best regards,
Bart_______________________________________________
mapserver-users mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapserver-users
_______________________________________________
mapserver-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapserver-dev
_______________________________________________
mapserver-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapserver-dev
_______________________________________________
mapserver-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapserver-dev
_______________________________________________
mapserver-users mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapserver-users
