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
