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

John Hagstrand john.hagstrand at interageresearch.com
Thu Apr 10 21:25:32 EDT 2003


Hi,

I wonder if I could hire a developer to implement this for me.  I don't 
want to wait for a future release.  (I hope it's appropriate for me to ask 
for this in this forum.)

Ideally, I'd like the TIME parameter and the "other sample dimension" 
parameter, as described in the OGC WMS Implementation Specifications in 
Table 7 of Section 7.2.2.  I need to make selections from each layer based 
on those two parameters, so I need it to pass through to a variable 
substitution within the Map File.

I would like to receive a Build with these features implemented.  I also 
need OGR built in.
Anyone interested?
John


At 10:34 PM 4/1/2003, you wrote:
>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


-------------------------------------------------
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





More information about the mapserver-dev mailing list