<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Comic Sans MS";
panose-1:3 15 7 2 3 3 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";
mso-believe-normal-left:yes;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<![if mso 9]>
<style>
p.MsoNormal
{margin-left:3.0pt;}
</style>
<![endif]><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple style='margin-left:3.0pt;margin-top:
3.0pt;margin-right:3.0pt;margin-bottom:.75pt'>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>You’re always mixing things up aren’t you… <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I don’t think you need a special mode. This strikes
me as just another special form of template output based on a query. Presently
you can get layer level query data (e.g. number of results) and of course
spatial and non-spatial attributes for each feature. What’s needed here
is the mechanism to gather layer stats (and a definition of what those are) in
either draw or query context and then a means of using or presenting them.
Imaging in a new “stats” tag within a result set like so (within a
resultset tag):<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> [stats item=”foo” format=”$stddev,$min,$max”]<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>You could use that to populate XML, JSON or just plain HTML output
for use on the client. This tag would draw from a populated layerStatsObj which
might consist of an array or hash of itemStatsObj’s… You
could populate those objects on-the-fly or perhaps even from a file. Would
probably need a new STATS … END block within a layer to drive this. Just
thinking out loud.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Steve<o:p></o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal style='margin:0in;margin-bottom:.0001pt'><b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Bob Basques
[mailto:Bob.Basques@ci.stpaul.mn.us] <br>
<b>Sent:</b> Thursday, February 04, 2010 8:19 AM<br>
<b>To:</b> Lime, Steve D (DNR); Stephen Woodbridge; Jan Hartmann<br>
<b>Cc:</b> MapServer Dev Mailing List; mapserver-users@lists.osgeo.org<br>
<b>Subject:</b> RE: [mapserver-dev] RE: [mapserver-users] colorramp and
datarangeon the fly?<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p><span style='font-family:"Comic Sans MS"'>All,</span> <o:p></o:p></p>
<p class=MsoNormal style='margin:0in;margin-bottom:.0001pt'><o:p> </o:p></p>
<p><span style='font-family:"Comic Sans MS"'>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.</span> <o:p></o:p></p>
<p class=MsoNormal style='margin:0in;margin-bottom:.0001pt'><o:p> </o:p></p>
<p><span style='font-family:"Comic Sans MS"'>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.</span> <o:p></o:p></p>
<p class=MsoNormal style='margin:0in;margin-bottom:.0001pt'><o:p> </o:p></p>
<p><span style='font-family:"Comic Sans MS"'>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 ??</span> <o:p></o:p></p>
<p class=MsoNormal style='margin:0in;margin-bottom:.0001pt'><o:p> </o:p></p>
<p><span style='font-family:"Comic Sans MS"'>bobb</span> <o:p></o:p></p>
<p class=MsoNormal style='margin:0in;margin-bottom:.0001pt'><o:p> </o:p></p>
<p><br>
<br>
>>> "Lime, Steve D (DNR)" <Steve.Lime@state.mn.us>
wrote:<o:p></o:p></p>
<div style='border:none;border-left:solid #050505 1.0pt;padding:0in 0in 0in 5.0pt;
margin-left:11.25pt'>
<p style='background:#F3F3F3'>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<o:p></o:p></p>
</div>
</div>
</body>
</html>