serving multiple orbits as mosaic

[Brent Fraser]

> >  One method you may want to look at is using a TileIndex
> > Layer for the data
> > (http://mapserver.gis.umn.edu/docs/howto/raster_data).
In
> > it's current form, using a TileIndex requires that the
index
> > and all the raster data it references be in the same
> > coordinate system (e.g. geographic), and the Mapserver
will
> > re-project the data to the coordinate system requested
by
> > the client browser.
>
> thanks.  so the order they are drawn in will be the order
they are defined in
> the mapfile correct?  does this hold for dynamically added
layers?

There would be only one layer in the mapfile, the layer with
the tileindex, and they only thing dynamic about it would be
your process to add polygons to the shapefile (or better yet
the database table) showing the extents of the images.  I
suspect they would be drawn in the order their polygons are
defined in the tileindex, but I'm not sure.

>
> >
> >  The how-to link given above shows how to use a single
layer to specify the
> >  TileIndex ()and the Raster data.    If you've got a lot
of data being added
> >  on a daily basis
>
> would you say 10gb(~ 20 files)/hr is alot?

Yes!  For most applications, the raster files are very
static representing say a landsat mosaic, or airphotos of
2001.

>
> > you may want to use a relational database to store your
TileIndex (but not
> > your raster data). In this case, the way to set up a
TileIndex is with two
> > layers: one (TYPE TILEINDEX) to define the TileIndex ,
and another to
> > specify the raster it contains (TYPE RASTER).
> >
>
> what advatage would this give?  right no i have a
dependancy chain where
> mapfiles are atomically created as new data arrives and
that's working well.
> are you suggesting that rebuilding the tile index is
expensive?

Using a database table for a tileindex means the mapfile
would never change (it would always point to the same
table).  You would have to write a routine to insert a
record in the table every time a new image came in.  This
way (with a little client-side coding) the user could select
the date, and be shown only the imagery for that date by
putting a query on the filter statement in the layer.  You
would use the mapfile-variable/CGI runtime substitution
technique (http://mapserver.gis.umn.edu/docs/howto/runsub).
Of course you could use the same substitution technique to
get at a specific raster file if you didn't want to tdo the
tileindex thing...

Hmm. Now that I think about it, the scenario above would not
be very good for showing only the lastest imagery.  The
performance would be awful since mapserver would be
rendering all imagery (including the outdated stuff) on
every pan and zoom (and have the overhead of a database
query).

A better way would be to use gdalwarp to populate an
existing set of tiles representing the latest available
imagery in a tiled pre-built mosaic.  The tiles would be
non-overlapping each with an extent of 1 degree x 1 degree
(or maybe 2 degrees?).  Every time an image came in, you
would run gdalwarp to overwrite the old pixels in the tile
set with the pixels from the new image.   Watch out for file
locking during the writing...


>
> > There are few examples at
> >
http://mapserver.gis.umn.edu/docs/howto/WCSServerFormatHowTo
>
> i looked at that but was too stupid to grok anything from
it!  ;-)

The important part (at least w.r.t tileindexes) is

LAYER
  NAME 'time_idx'
  TYPE TILEINDEX
  DATA 'timeIndex'
  FILTERITEM 'time'
  FILTER '%time%'
END

LAYER
  NAME 'TempData'
  STATUS OFF
  TYPE RASTER
  DUMP TRUE
  TILEINDEX 'time_idx'
  PROJECTION
    "init=epsg:4326"
  END
    :