[despammed] Re: [Mapserver-dev] Adding a Time extent to Mapserver

Steve Lime steve.lime at dnr.state.mn.us
Tue Apr 1 22:34:21 EST 2003


The %variable% functionality is only implemented for the CGI version,
once tests for WMS/WFS processing have failed. It's a single code block
so it would be easy enough to move/copy and to extend to metadata. The
issue is where to put it in the WMS. Dan, thoughts or preferences?

Steve

>>> John Hagstrand <john.hagstrand at interageresearch.com> 03/31/03 17:22
PM >>>
Hi,

This is a thread from a couple months ago.  I wonder what ever happened
to 
this.

I use the WMS interface and I need TIME and one other dimension.  I
don't 
really care about strict WMS syntax, I just need the functionality.  A 
%variable% replacement would work.  Also the "changing map file
parameters 
via a form or a URL" technique would work if it was available in the WMS

version.

Can you help?
John


At 11:24 AM 1/3/2003, Steve Lime wrote:
>Dan's right the list is long... For 3.7 I'll add DATA to the list of
>parameters that
>gets processed for replacements, and will move that code to a place
>where
>WMS requests can take advantage of it too. That should provide a
>suitable
>workaround until it can re visited fully later.
>
>Steve
>
> >>> Daniel Morissette <morissette at dmsolutions.ca> 01/02/03 09:07PM >>>
>While we're at it, should we consider implementing more general
>support
>for dimensions as specified in the recent WMS specs?  This has been
>requested via bugzilla a little while ago:
>   http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=131
>
>I haven't looked at the details in the spec, but I assume that the
>same
>trick (%variable% replacement in layer params and filters) could be
>used
>for any type of dimension parameters in WMS requests (TIME is just one
>specific application of the dimension parameter in WMS requests).  We
>would also have to decide how a dimension is specified in MapServer
>metadata for the GetCapabilities output.
>
>BTW, the ToDo list for 3.7 is already quite long, so unless someone
>(Steve?) is planning to implement this soon then perhaps we should
>file
>the conclusions of this discussion in a bug report in bugzilla to make
>sure the details of our plan of attack don't get lost.
>
>Daniel
>
>
>
>Steve Lime wrote:
> >
> > I like Dan's idea. It'd be real easy to implement for WMS and for
>the
> > CGI implementation. In fact the bulk of the code is there, just
needs
>to
> > be applied to the DATA field (EXPRESSION, FILTER and CONNECTION
>already
> > support this via the CGI). Might need to generalize the variable
> > substitution beyond the CGI though. The definition of a default time
> > parameter is not done, easy to add though, just call it "time". The
>only
> > missing piece would be some code to ingest a date string and parse
>it
> > into components so that substitutions could be done. One would think
> > that code would exist though. Anyone seen such a beast?
> >
> > Steve
> >
> > Stephen Lime
> > Data & Applications Manager
> >
> > Minnesota DNR
> > 500 Lafayette Road
> > St. Paul, MN 55155
> > 651-297-2937
> >
> > >>> Daniel Morissette <morissette at dmsolutions.ca> 12/30/02 02:10PM
> >>>
> > Hi David,
> >
> > Your suggestion is a good start and would work for several cases,
>but
> > if
> > you want to represent 50 years of monthly data then you would need
>600
> > layers which is not practical in the current mapfile architecture.
>We
> > also need to account for situations like what John H. reported in
> > another message where the data is all in a single file (or database
> > table) and the selection needs to be made using an attribute filter.
> >
> > Maybe another potential approach would be to use the equivalent of
> > %variable% replacements (added by Steve in CONNECTION strings) in
>the
> > layer parameters, so let's say you receive a getMap request with
> > TIME=2002-12-27 for instance, the following variable replacements
> > would
> > be available (this is just an example, more could be added):
> >
> >    %time%         -> "2002-12-27"
> >    %time-yyyy%    -> "2002"
> >    %time-mm%      -> "12"
> >    %time-dd%      -> "27"
> >    %time-yyyymmdd% -> "20021227"
> >
> > Then your layer defn could look like this:
> >
> >  LAYER
> >     DATA "temporal_data/%time-yyyy%/%time-mm%/mydata"
> >     CLASS
> >       ...
> >     END
> >  END
> >
> > Or if your data is all in the same table we could use something like
> > this:
> >
> >  LAYER
> >     DATA "temporal_data/mydata"
> >     FILTER "[StartDate] < '%time%' and [EndDate] > '%time%'"
> >     CLASS
> >       ...
> >     END
> >  END
> >
> > This would require some special processing in mapwms.c to handle the
> > %variable% replacements, but could open lots of possibilities.  I'm
> > sure
> > Steve would have some ideas too since he is the most familiar with
>the
> > mapfile parameters processing.  Let's see what he thinks.
> >
> > Daniel
> >
> > David Graham wrote:
> > >
> > > Hello everyone:
> > >
> > > I just got in a request for serving up geospatial data with a
> > temporal
> > > nature.  Basically we would have the same data available for
>various
> > > time.  It would likely be served via WMS which does support
>temporal
> > > data.  The problem is that Mapserver is not set up to deal with
>it.
> > >
> > > In the WMS spec the getCapablilities reads:
> > >
> > > For a time range:
> > > <Extent name="time" default="2000">1990/2000/P1Y<Extent>
> > >
> > > For a single time:
> > > <Extent name="time" default="1998">1998</Extent>
> > >
> > > For a set of specific times:
> > > <Extent name="time"
> > >
> >
>default="2002-12-27">2002-01-14,2002-05-18,2002-07-04,2002-10-31,2002-12-27</Extent>
> > >
> > > The getMap request contains a time attribute that can be set to
>set
> > the
> > > request for a certain time.
> > >
> > > So I have been thinking how to accomplish such a thing in
>mapserver
> > with
> > > a minimal amount of code change.
> > >
> > > I did come up with one senario that seemed like it would not break
> > the
> > > architecture.  Here it is:
> > >
> > > - Add a wms_min_time and a wms_max_time metadata tag to each
>layer.
> > >
> > > - Add a wms_temporal_layer_name metadata tag to each layer.
> > >
> > > - Reconfigure the WMS capabilities document to present a single
> > layer
> > > for each unique wms_temporal_layer_name found.   The time extent
> > would
> > > be calculated from the available wms_min_time and wms_max_time
> > numbers
> > > for every mapserver layer contained in the wms_tempral_layer_name
> > group.
> > > - i.e. group the mapserver layers together to represent the same
> > data
> > > across the temporal dimension.
> > >
> > > - Reconfigure getMap such that if the layer attribute passed by
>the
> > WMS
> > > client is a wms_temporal_layer_name it will then use the time
> > attribute
> > > to look up exactly which mapserver layer is applicable.
> > >
> > > Now this is one suggestion.  I am looking for other suggestions.
>I
> > see
> > > that Daniel developed most of the code for the WMS so I would
>enjoy
> > > hearing his take on issue.
> > >
> > > Dave
> > >
> > > --
> > > David W. Graham
> > > Director of Geospatial Applications Development
> > > information integration and imaging, LLC
> > > 201 Linden St, Third Floor
> > > Fort Collins, CO 80524
> > > (970) 482-4400
> > > dgraham at i3.com
> > > http://www.i3.com
> > >
> >
>_______________________________________________
>Mapserver-dev mailing list
>Mapserver-dev at lists.gis.umn.edu
>http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
>_______________________________________________
>Mapserver-dev mailing list
>Mapserver-dev at lists.gis.umn.edu
>http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
>
>----------------------------------------------
>Filtered by despammed.com.  Tracer: MAA123371041615510
>Remember: you can forward any spam that slips through the filters
>to the abuse desk here at Despammed.


-------------------------------------------------
John Hagstrand
Interage Research, Inc.
847 838 5371
Software Development Consulting for Internet Content Management
We make knowledge accessible, useful, and relevant for everyone.
http://www.interageresearch.com


_______________________________________________
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev




More information about the mapserver-dev mailing list