[mapserver-dev] RE: [mapserver-users] colorramp and datarange on the fly?

Stephen Woodbridge woodbri at swoodbridge.com
Wed Feb 3 11:38:43 EST 2010


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: mapserver-users-bounces at lists.osgeo.org 
>> [mailto:mapserver-users-bounces at lists.osgeo.org] On Behalf Of Bart van 
>> den Eijnden
>> Sent: Wednesday, February 03, 2010 5:12 AM
>> To: mapserver-users at lists.osgeo.org
>> 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
>> mapserver-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>> _______________________________________________
>> 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



More information about the mapserver-dev mailing list