[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