OGC WCS and TIME

Ara T Howard ara.t.howard at NOAA.GOV
Wed Dec 20 12:16:22 EST 2006


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



More information about the mapserver-users mailing list