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