<html>
<head>
<style type="text/css">
<!--
body { margin-top: 4px; margin-right: 4px; margin-left: 4px; font-variant: normal; margin-bottom: 1px; line-height: normal }
p { margin-top: 0; margin-bottom: 0 }
-->
</style>
</head>
<body style="margin-top: 4px; margin-right: 4px; margin-left: 4px; margin-bottom: 1px">
<p style="margin-bottom: 0; margin-top: 0">
<font face="Comic Sans MS" size="3">All,</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Comic Sans MS" size="3">Just to mix it up a little, what about doing a half and half approach. MapServer could generate something simpler (the data basics from a data read on the fly, and return a simple ramping config file, which could be used to pass back as a file for the custom aspects.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Comic Sans MS" size="3">Just having these two options would open up some doors, MapServer returning a simple ramp structure as a file, could be used in a User interface to do more complicated theming for example. Once the basic data limits are known, the ramping divisions are much easier to decide on.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Comic Sans MS" size="3">Could this work as a compiled in module for those that need/want it instead of always in? or would it make more sense to build in, ?? Something similar to a mode=legend sort of thing, like mode=ramp_txt ??</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font face="Comic Sans MS" size="3">bobb</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<br>
<br>
>>> "Lime, Steve D (DNR)" <Steve.Lime@state.mn.us> wrote:<br> </p>
<div style="background-color: #f3f3f3; border-left: solid 1px #050505; margin-top: 0; padding-left: 7px; margin-left: 15px; margin-right: 0; margin-bottom: 0">
<p style="margin-bottom: 0; margin-top: 0">
At one point I toyed with the idea of supporting a .stats file for a layer and supplying a routine (command-line) that would populate it. The file would contain data like you're talking about. Doesn't help with the on-the-fly needs Bart was articulating.<br><br>Steve<br><br>-----Original Message-----<br>From: mapserver-users-bounces@lists.osgeo.org [mailto:mapserver-users-bounces@lists.osgeo.org] On Behalf Of Stephen Woodbridge<br>Sent: Wednesday, February 03, 2010 10:39 AM<br>To: Jan Hartmann<br>Cc: Lime, Steve D (DNR); MapServer Dev Mailing List; mapserver-users@lists.osgeo.org<br>Subject: Re: [mapserver-dev] RE: [mapserver-users] colorramp and datarange on the fly?<br><br>Right, I think there are two use cases:<br><br>1) data exploration   - can be slower but needs flexibility<br>2) production serving - needs to be fast, and probably limits<br>flexibility to some predefined models<br><br>I think that there is also another angle to this, which is how the<br>summary data is computed for example:<br><br>1) min/max/average/std<br>2) statistical analysis<br>3) binning into some number of classes<br>4) removing outliers so the results are not skewed by them<br>5) etc<br><br>There are a lot of ways the people might need to summarize they data.<br><br>If the data is in a database, then you can add all the analysis, slicing<br>and dicing to the database and the rendering to mapserver.<br><br>So, I think that it would be nice to be able to read some "metadata"<br>about a layer and then use that for building the display using something<br>like colorramp and datarange. We might want to look at ways that we<br>could establish in mapserver for fetching the "metadata" about a layer.<br>For example:<br><br>1) define the "metadata" in the METADATA object<br>2) define a .met file for a shapefile or tileindex that contained the<br>"metadata" for that layer<br>3) define a separate SQL query that could be used to fetch the<br>"metadata" for the layer<br>4) something similar for other layer providers.<br>5) scan the data in two passes to compute some simple "metadata"<br><br>Thoughts?<br><br>-Steve W<br><br><br>Jan Hartmann wrote:<br>> If you allow two passes, you can have all sorts of summarized values in<br>> the template, to be used in the second pass, like Bart's actual extent<br>> used for coloring. Doesn't look to difficult to implement to me, as long<br>> as the two passes only get called when really necessary. I'm not sure if<br>> performance is an issue for MapServer itself: if you really want high<br>> performance, you should use the underlying format or database directly.<br>><br>> Jan<br>><br>> On 3-2-2010 17:02, Lime, Steve D (DNR) wrote:<br>>> How big a change would depend on the implementation. The brute force<br>>> approach where you simply loop through features once to compute ranges<br>>> and then again to draw would be probably pretty straight forward and<br>>> driver independent. Wouldn't be fast (but would be simple). Complexity<br>>> would be added as you try and boost performance by:<br>>><br>>>    - allowing drivers to compute stats in their own way (e.g. add to<br>>> the layer API something like msLayerGetStats(...))<br>>>    - caching geometries from a first pass through the shapes for the<br>>> second<br>>><br>>> Steve<br>>><br>>> BTW The color ramp support needs to be cleaned up first. I think we<br>>> scared the originator of that code away when an RFC was originally put<br>>> together.<br>>><br>>> -----Original Message-----<br>>> From: mapserver-users-bounces@lists.osgeo.org<br>>> [mailto:mapserver-users-bounces@lists.osgeo.org] On Behalf Of Bart van<br>>> den Eijnden<br>>> Sent: Wednesday, February 03, 2010 5:12 AM<br>>> To: mapserver-users@lists.osgeo.org<br>>> Subject: [mapserver-users] colorramp and datarange on the fly?<br>>><br>>> Hi list,<br>>><br>>> is it possible to have a colorramp in Mapserver based on the min and<br>>> max value in the current extent?<br>>><br>>> So instead of predefining the min and max in DATARANGE, have Mapserver<br>>> use the min and max value of the dataset in the current extent?<br>>><br>>> If not, would it be an easy change or a very complex one?<br>>><br>>> Best regards,<br>>> Bart_______________________________________________<br>>> mapserver-users mailing list<br>>> mapserver-users@lists.osgeo.org<br>>> <a href="http://lists.osgeo.org/mailman/listinfo/mapserver">http://lists.osgeo.org/mailman/listinfo/mapserver</a>-users<br>>> _______________________________________________<br>>> mapserver-dev mailing list<br>>> mapserver-dev@lists.osgeo.org<br>>> <a href="http://lists.osgeo.org/mailman/listinfo/mapserver">http://lists.osgeo.org/mailman/listinfo/mapserver</a>-dev<br>>>   <br>> _______________________________________________<br>> mapserver-dev mailing list<br>> mapserver-dev@lists.osgeo.org<br>> <a href="http://lists.osgeo.org/mailman/listinfo/mapserver">http://lists.osgeo.org/mailman/listinfo/mapserver</a>-dev<br><br>_______________________________________________<br>mapserver-users mailing list<br>mapserver-users@lists.osgeo.org<br><a href="http://lists.osgeo.org/mailman/listinfo/mapserver">http://lists.osgeo.org/mailman/listinfo/mapserver</a>-users<br>_______________________________________________<br>mapserver-dev mailing list<br>mapserver-dev@lists.osgeo.org<br><a href="http://lists.osgeo.org/mailman/listinfo/mapserver">http://lists.osgeo.org/mailman/listinfo/mapserver</a>-dev<br>
</p>
</div>
</body>
</html>