[GRASS5] New bash scripts for vector and raster processing

Cedric Shock cedricgrass at shockfamily.net
Mon Mar 6 02:08:34 EST 2006


Hello,

I have written two scripts that are related to vector and raster maps.

The first, v.group, works similarly to v.reclass, but will reclassify on 
multiple columns of types that aren't just int. It can, for example, 
reclassify a land use map with a separate category for each feature to a 
category for each combination of jurisdiction, owner, and manging agency:

v.group input=messylanduse output=landuse columns=jurisdiction,owner,manager

http://www.shockfamily.net/cedric/grass/v.group

There are a couple of issues with this; the type definitions of the columns 
are not preserved (I wasn't sure how to get the type definitions from the old 
table) and it does not alter the history of the output map to explain what 
has been done (What is the correct way to do that?)


The second script produces tilings for relating one projection to raster 
regions in another. This is useful when requesting data from WMS servers and 
in other network data operations. The script only produces descriptions 
(bounding box in source, rows, and columns) of the tiles, and only for those 
tiles overlapping the current region. It uses the current region as the 
bounds and desired resolution for the requested data.

r.tileset sourceproj="+init=epsg:4326"

http://www.shockfamily.net/cedric/grass/r.tileset

This script has a number of small issues:
* It doesn't know about meridians of projections. (I assume the C 
implementations of bounding box code do unlike my little bash functions. 
Would hopping languages solve this?)
* Does not generate optimal (smallest request) tilings. In degenerate cases 
involving latitude longitude source data up to twice as much as necessary may 
be requested; degenerate cases of other projections (poles of cylindricals 
and opposing sides of conics diverge) can be worse. In the regions I've tried 
it's about 1% unnecessary overhead. If you need optimal tilings ask; I can 
add that feature.
* The aspect ratios of the tiles aren't tailored to the destination region. 
Near the critical points of a projection the images can be quite strange. Not 
a problem for grass, but some map servers don't like handing out images with 
very different horizontal and vertical resolutions. "Solved" by optimal 
tilings, assuming your chosen coordinate system is appropriate for the data 
handled.
* It does not produce bounding box independent tilings. These are useful when 
caching data so as to avoid requesting it again (like virtual globes do). I 
don't imagine grass users wanting this. This is fairly easy to do, especially 
once optimal tilings are in place. If you have a need for it ask. These 
tilings usually add another column and row of tiles to requests. 
* It does not produce resolution independent tilings. This is an orthogonal 
problem, so it's not very important, and also quite easy to solve.
* It takes about a second per tile on my clunky machine, since it runs cs2cs 
four times per tile.

--Cedric Shock




More information about the grass-dev mailing list