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@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
_______________________________________________
grass-user mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/grass-user
