[GRASS-user] r.proj issue

[Rich Shepard]

On Sat, 14 Sep 2019, Markus Metz wrote:

> gdalwarp estimates the target extents unless you use the -te option. In
> contrast, r.proj uses the current region. r.proj can estimate the target
> extents with the -p or -g flag. I suggest to first check you current
> region in the target location/mapset and compare with r.proj -p or -g

Markus M, et al.:

I've worked on this for 2+ days and cannot get the DEM from the source
location to the target location when both have the same projection and
units.

Following the above still fails and I've no idea what to do now.

Source location:
> r.proj -p loc=Oregon map=topography in=n45w121
Input map <n45w121 at topography> in location <Oregon>:
Source cols: 80297
Source rows: 111356
Local north: 148340.8192959
Local south: 36984.78211177
Local west: 2459852.09770149
Local east: 2540149.13365527

Current (target) region:
> g.region -p
projection: 99 (NAD83(HARN) / Oregon North)
zone:       0
datum:      nad83harn
ellipsoid:  grs80
north:      307220.87234928
south:      -199204.29675669
west:       2161358.9640483
east:       2822158.25992759
nsres:      1.00000033
ewres:      1.00000045
rows:       506425
cols:       660799
cells:      334645133575

Reset current region to the source:
> g.region n=148340.8192959 s=36984.78211177 w=2459852.09770149 e=2540149.13365527 cols=80297 rows=111356

Unpack the DEM in the current location/mapset;
> r.unpack n45w121.pack 
WARNING: Difference between PROJ_INFO file of packed map and of current
          location:
          name: NAD83(HARN) / Oregon North
          datum: nad83harn
          ellps: grs80
          proj: lcc
          lat_1: 46
          lat_2: 44.33333333333334
          lat_0: 43.66666666666666
          lon_0: -120.5
          x_0: 2500000
          y_0: 0
          no_defs: defined
          - towgs84: 0.000,0.000,0.000
ERROR: Projection of dataset does not appear to match current location. In
        case of no significant differences in the projection definitions,
        use the -o flag to ignore them and use current location definition.

If I correctly understand gdalwarp it functions like r.proj in reprojecting
a raster map from one location to another location. Here, both the source
and target locations have the same projection. Will gdalwarp work in this
case? Isn't r.pack/r.unpack the correct module pair?

Please advise me of what I should do now or what other information I can
provide.

Regards,

Rich