[Mapserver-dev] Adding a Time extent to Mapserver

[Steve Lime]

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