Richard wrote: > I feel a forehead-slapping moment coming on... to see if I get this: > 1) Import DEM (say, East Coast of Australia) to new location creates a > region with the extents of the DEM. > 2) Import second DEM which is outside the region of the first DEM = null > values *because* it's outside the original extents.
r.in.* modules will (ie should generally) ignore the region settings. On the other hand, r.proj and GeoRect tools may observe the region settings (e.g. to pick target resolution). It may not be strictly necessary, but for those I usually first do v.in.region+v.proj then in the target location zoom to that projected bounding box and make sure the rows/cols are a nice round number slightly more than in the source region so no information is lost. If true-north is rotated between the two projections you'll need to be more than the original rows/cols, as the original cells are now along a hypotenuse. see i.rectify bug # 3166 (3rd order transform) https://intevation.de/rt/webrt?serial_num=3166 I go to this trouble as I'm still confused by the region cropping algorithms and can never remember which of the bugs have been fixed or not, so I use that method and it works. Probably it's not needed, but I prefer the comfort of overkill. I don't claim it is the correct method to use. After import with r.in.* you will need to change the computational region's zoom to cover that new data if you want to see/process it. (g.region) > And to conclude this story, Hamish: Thanks, the fix worked fine. > > So there may be something to put in the manuals? If someone wants this > written, I am happy to do so, as long as someone tells me which manual > page this should be added to (so I can fit it in context!). http://grass.ibiblio.org/grass63/manuals/html63_user/rasterintro.html Hamish _______________________________________________ grassuser mailing list [email protected] http://grass.itc.it/mailman/listinfo/grassuser
