g.setproj, r.proj, rant about s.surf.**

Timothy Keitt tkeitt at algodones.unm.edu
Sat Aug 27 15:13:25 EDT 1994


Thanks for the tip.  I had in fact thought about using this approach,
but there are several problems.  Interpolation is fine for continous
sorts of data, but not categorical data where the numbers are labels
instead of values.  The best approach would be to first generate the
output raster grid.  Then visit each cell in the output, get its
coords and transform them back to the origional input projection.
Find the nearest neighbor to the transformed coordinate in the input
and place that value in the output.  This kind of resampling avoids
holes in the output and should preserve the "texture" of the image
(interpolation wreaks havoc when doing things like fractal analysis).
Preferably, this would be done transparently when copying data between
locations with different projections.  Just a thought.

T.

>
>>
>>I have 4.1 but I don't (generally) do vectors.  Is there an easy way
>>in GRASS to convert raster data between different projections?  Really
>>I'm just curious as I would like to be able to overlay images from
>>different sources with different projections.  I'm thinking of adding
>>this functionality into Khoros v2, but would be interested in knowing
>>if it already exists in GRASS or elsewhere.
>>
>>Tim -- "If only the world were flat!"
>
>Ah - this is the (by now getting old) r.proj problem.  To my knowledge this
>has not yet been written in a robust enough form to be included in any of
>the release.  Last time I needed to do this I think I did something like
>....
>
>(i)     starting in GRASS in the location that the original raster is in,
>write it out as a site-list using
>r.stats -1gz ...
>
>(ii)    exit from GRASS.  Use "proj" to convert the site list into the
>projection that you need (you may have to have an intermediate step of
>lat-long).  You may need also to use "awk" to reformat the columns at some
>stage.
>
>(iii)   fire up GRASS in the new location/projection etc.
>
>(iv)    import the site-list using s.in.ascii.
>
>(v)     interpolate the site-list onto a raster using s.surf.idw or
>s.surf.tps.
>
>For this last step, note that (a) due to its lack of intelligent indexing
>of the site list, s.surf.idw is excruciatingly slow for big data sets (more
>than a few hundred);  (b) however, since you _will_ want to produce a final
>raster at a similar resolution to the original one, you don't need to use
>many points to generate the new values - ie you can set npmin in s.surf.tps
>to a very small number (eg 10) to get a good result.
>
>However, I still think that using s.surf.tps is silly for a task like this,
>where a much simpler (eg bilinear) interpolation would be more than
>adequate - the new cell positions are surrounded by "sites" from the
>original cells.  The only reason I used tps was because it actually ran
>_faster_ than idw, due to the fact that an indexing scheme is used properly
>for tps!  I understand why the effort has gone into these clever
>interpolators, and am thankful that tps is available.  But I think the fact
>that there is not a fast bilinear or nearest neighbour s.surf.*** program
>is a serious deficiency in GRASS's armory.  At the very least, couldn't
>s.surf.idw incorpporate the quadtree from tps, or maybe a more general
>s.surf program could be written with -method=tps|idw|nn|bilin as an option,
>so that large chunks of the code are reused?
>
>(I'm sorry I don't have time to just do it myself.)
>
>When this has all been done, it should be possible to encapsulate the above
>in a script ...
>
>End of rant.            Simon Cox
>
>____
>__________________________________________________________________
>Dr Simon Cox                             __  L
>CSIRO Exploration & Mining            ,~'  L_|\       Australian
>39 Fairway, PO Box 437,            ;-'         \      Geodynamics
>Nedlands, WA  6009,  Australia     (            \     Cooperative
>      Phone +61 9 389 8421         +    ___     /     Research
>      Fax   +61 9 389 1906          L~~'   "\__/      Centre
>s.cox at dem.csiro.au                            7
>__________________________________________________________________
>
>



---
================================================================
| Timothy H. Keitt                       Landscape and Systems |      
| The University of New Mexico                         Ecology |
| Department of Biology                                        |
| Albuquerque NM 87131                tkeitt at algodones.unm.edu |
| 505/277-3431              ftp://algodones.unm.edu/pub/tkeitt |
================================================================






More information about the grass-user mailing list