[GRASS-user] Re: How to best access hundreds of orthophotos --
mapserver as WMS server?
Dylan Beaudette
dylan.beaudette at gmail.com
Sun Dec 16 13:47:12 EST 2007
On Sunday 16 December 2007 04:12:09 am Ivan Shmakov wrote:
> >>>>> Hamish <hamish_b at yahoo.com> writes:
>
> [...]
>
> > an idea: write a little script to make a vector coversheet index.
> > maybe output that with the HTMLMAP driver for an interactive web brower
> > pull up.
> >
> > I am not sure, but I think v.patch does not clean topology so overlap
> > may be ok.
>
> Wouldn't it be better to save non-overlapping parts and an
> intersection as separate polygons? A separate attribute will be
> needed to store the list of IDs of the covering images.
>
> [...]
>
> > this is just the idea. non functional...
> >
> > # store current region
> > g.region save=old_region
>
> It makes me wonder each time I see such a fragile construct like
> this, will GRASS ever support overriding the region
> ``temporarily''? (E. g., via a command line argument, or an
> environment variable.)
>
> > # create new empty map
> > v.in.ascii -e out=map_index
> > v.db.addtable map_index columns="image varchar(128)"
> >
> > i=0
> > for MAP in `g.mlist patt='ortho_*'` ; do
> > i=`expr $i + 1`
> > g.region rast="$MAP"
> > v.in.region out="${MAP}_box"
>
> Oh, perhaps `v.in.region' could be patched to print the category
> of the vector feature it creates (if requested)? I guess, this
> usage pattern is quite common for `v.in.region'?
>
> And, could there be something a bit more clever than storing the
> region of the image as a vector feature? A combination of
> downsampling, `r.mapcalc' (to obtain the fill mask), and
> `r.contour', may be?
Hi,
What you are asking for is starting to sound like a Mapserver driven WMS.
Here is how I have dealt with this problem in the past:
* get and compile the latest version of GDAL
* get and compile the latest version of GRASS
* get and compile the latest version of Mapserver
1. put all of your imagery somewhere, in a consistant format.
2. add overviews to the imagery (internal tiling) with gdaladdo
3. make a shapefile tile index with gdaltindex
4. make a spatial index on this shapefile with shptree (from the mapserver
source code)
5. create a very simple mapfile pointing to the tile index shapefile. I will
work up an example and post it back
6. fill in appropriate WMS metadata into the mapfile
7. use r.in.wms to import imagery into GRASS
-or-
7. once GDAL 1.5 is released it will be possible to an r.in.gdal and point it
to an XML file defining a WMS resource. A mini-script might be able to
construct the XML file on the fly...
Unfortunately you will still have to manage the images that are imported into
GRASS with GRASS commands, unless you constantly overwrite a temporary set of
files by always using the same names and the --o flag.
Once you have mapserver setup WMS is quite fast and flexible - it will even
project the data on the fly to other coordinate systems.
Dylan
>
> > ? v.edit to reset the region box centroid's cat to $i ?
> > # or a series of v.category del then add steps
> >
> > # merge into master index
> > g.remove vect=map_index_old
> > g.rename vect=map_index,map_index_old
> > v.patch in=map_index_old,"${MAP}_box" out=map_index
>
> May there `v.patch -a' be used instead? Like:
>
> v.patch -a in="${MAP}_box" output=map_index
>
> > # write map name to DB entry
> > v.db.update map_index column=image value="'$MAP'" where="cat = $i"
> > done
> >
> > #reset to original region
> > g.region old_region
>
> [...]
>
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
More information about the grass-user
mailing list