OGC WCS and TIME

[Norman Barker]

Hi,

Yes, wcs_timeposition does create very large files :-), it is however
easy for clients :-)

The WMS supports timeextent  "wms_timeextent"
"2003-08-01/2006-12-31/P5M", so I guess it wouldn't be too hard to put
this into MapServer WCS

The code for looking up the time parameters from mapwcs.c

if(msOWSLookupMetadata(&(layer->metadata), "COM", "timeposition") ||
msOWSLookupMetadata(&(layer->metadata), "COM", "timeperiod")) {
    msIO_printf("      <temporalDomain>\n");

    /* TimePosition (should support a value AUTO, then we could mine
positions from the timeitem) */
    msOWSPrintEncodeMetadataList(stdout, &(layer->metadata), "COM",
"timeposition", NULL, NULL, "
<gml:timePosition>%s</gml:timePosition>\n", NULL);

    /* TODO:  add TimePeriod (only one per layer)  */

    msIO_printf("      </temporalDomain>\n");
  }

And mapwms.c gives the code for looking up the time extent

It would be a good improvement to add this to the server.  I think the
comment about AUTO would probably me most useful :-)

I was in Boulder for the Summer, and will be back in Jan, I am actually
based in the UK.  Head Office is in Boulder, we do IDL + ENVI which I
think you use at NOAA.

Norman




-----Original Message-----
From: UMN MapServer Users List [mailto:MAPSERVER-USERS at LISTS.UMN.EDU] On
Behalf Of Ara T Howard
Sent: 20 December 2006 17:16
To: MAPSERVER-USERS at LISTS.UMN.EDU
Subject: Re: [UMN_MAPSERVER-USERS] OGC WCS and TIME

On Wed, 20 Dec 2006, Norman Barker wrote:

> Hi,
>
> Ok, to (try) answer your questions
>
> 1) Custom shapefiles can be created easily, you may find it easier to
create
> a shapefile first with gdaltindex and then abuse it to add the TIME
field,
> or create the shapefile from scratch as per the example script

right-0.  i'm going to take the from scratch route as i prefer to
understand
the inner workings.

> 2) You would create a layer index like
>
>    LAYER
>        NAME 'vis_mos_idx'
>        TYPE TILEINDEX
>        DATA 'data/vis_mos/index'     (refers to the shape file index)
>        FILTERITEM 'TIME'
>        FILTER '%time%'
>    END
>
> And the a coverage layer like
>
> LAYER
>        NAME 'vis_mos'
>        STATUS OFF
>        TYPE RASTER
>        DUMP TRUE
>        TILEINDEX 'vis_mos_idx'     (referencing above)
>        PROJECTION
>            "init=epsg:4326"
>        END
>        METADATA
>           :
>           :
>        wcs_timeposition '  ... list of all the times, generated from
> the filenames of the files in the shape index'
>        wcs_timeitem 'time'
>           :
> END

this seems extremely problematic.  if we interfaced to our archive, for
instance, we'd have

    wcs_timeposition => approx a list of 60000 times!!!

it seems redundant to enumerate the times both in the dbx file AND in
the
mapfile eh?  alas, this may simply be a limitation...  i worry, however
that
long lists of 'wcs_timeposition' may simply hit another internal compile
time
limit?

> 3) Looking at the wcs.c code (which was written by Steve Lime, and
Frank W),
> bands is a keyword, and this is deliberately matched to bands of a
data file
> (logically enough!).  However it is difficult to add metadata to the
band
> description as to what each level represents, and they are listed as
values
> 1,2,3,etc.  To add additional parameters you would have to change the
code.
>
> In summary I find the WCS interface to MapServer to be great, being
able to
> do time=..&bands=1,4,5,.. greatly reduces the client download, and
> simplifies my data on the server, since a coverage layer represents a
> collection of data files that could be constantly changing.

yes exactly.  it would be quite sufficient to break apart our data along
both
time and band dimensions.  more would be nice, but even just doing just
the
time dimension will reduce the size enough to fit in a reasonably sized
mapfile as it's by far the largest dim...

> Can you send a link to the list for your server when you have
finished,
> showing changing (2-3 per day) data is an interesting use case.
Currently I
> use WCS for historic data.

heh.  we're changing about 5gb per utday every 15 minutes!  the current
method
syncs data from a small linux cluster via nfs to the local disk, making
sure
the sync has data arrive atomically on local disk.  the fact that
mapserver is
stateless is a BIG plus here and the reason we were not able to use some
proprietary wcs solutions we already have here in-house.

i could post links now, but some of the data are classified for 3 hrs
after
aquistion.  once our security is finalized we will be providing half
resolution data to the public free of the charge.  the data will
initially be
near-real-time nighttime dmsp mosaics of both visible and thermal
channels.

thanks a ton for your replies btw!  where are you located btw?  i'm in
boulder.

kind regards.

-a
-- 
if you find yourself slandering anybody, first imagine that your mouth
is
filled with excrement.  it will break you of the habit quickly enough. -
the
dalai lama