Re: [GRASS-user] imported .tif maps lose all data

[Rich Shepard]

On Sat, 25 Sep 2021, Moritz Lennert wrote:


You feed the information to g.region with the 'raster' parameter.
-p just means pretty print the region settings, it doesn't set the region.


Mortitz,

I know this. :-)


If you want to set the region to the extension covered by multiple raster
maps, just feed all the maps' names to the 'raster' parameter.


Ah! I hadn't thought of this.


But in your case, while still testing, you should set the region to one
map, then test with r.report, then set the region to the next map, test,
etc.


I don't think I need to test any more, but I'll probably do one more anyway.


Another hint: if you just want to quickly test if the imported map has any
values, use r.info which is region independent. With the -r flage you get
the min-max range.


r.info is what lead me to the issue. I didn't save the output from all the
maps. I seem to recall that as the script ran there were issues of the map
being imported not being in the current region's extent.

All my previous work with GRASS since 4.0 had one large map that covered a
larger region than needed for the project so I would define a project area
within it. These LiDAR topography maps cover a very large spatial area and I
have no idea with one (or two) actually include the project's area. So I
need to import them all then find the appropriate one or two.

Thanks very much,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] imported .tif maps lose all data

[Moritz Lennert]

Le 26 septembre 2021 00:50:13 GMT+02:00, Rich Shepard 
 a écrit :
>On Sat, 25 Sep 2021, Helmut Kudrnovsky wrote:
>
>> try the same steps as I've done (with adjusted paths) and _post the
>> command and the command output_ here.
>> - g.region -p
>> - r.in.gdal input=columbia_2010_e_dtm_35.tif output=columbia_2010_e_dtm_35
>> - g.region -p -a raster=columbia_2010_e_dtm_35 align=columbia_2010_e_dtm_35
>> - r.stats -l input=columbia_2010_e_dtm_35
>> - r.report map=columbia_2010_e_dtm_35
>
>Helmut,
>
>Results in attached 574 line file. There are some cells with data, but most
>without data (82%).
>
>I can display the data with cells; for this one map they appear to cover
>only the river and not the terrain north of it. But, this is only one of 77
>files.
>
>Since this test worked I need to figure out why it didn't work when I
>imported all 77 .tif files using the bash script. Ah! Thought: when
>r.in.gdal imports all 77 files where does GRASS get the values for setting
>g.region -p?

You feed the information to g.region with the 'raster' parameter.

-p just means pretty print the region settings, it doesn't set the region.


>
>If g.region -p displays the region of last map imported then the other 76
>maps will be outside that region. Is there a module that uses all maps in
>that mapset to set the region, or is that supposed to be done by default?

If you want to set the region to the extension covered by multiple raster maps, 
just feed all the maps' names to the 'raster' parameter.

But in your case, while still testing, you should set the region to one map, 
then test with r.report, then set the region to the next map, test, etc.

Another hint: if you just want to quickly test if the imported map has any 
values, use r.info which is region independent. With the -r flage you get the 
min-max range.

Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] imported .tif maps lose all data

[Rich Shepard]

On Sat, 25 Sep 2021, Moritz Lennert wrote:


The startup script expects you to provide the full path to a mapset, so
when you give it 'data/grassdata/rastertest' it assumes that 'rastertest'
is the mapset, so 'grassdata' must be the location. It then checks for a
PERMANENT mapset in that location but cannot find it.

After creating your location it only contains one single mapset:
'PERMANENT', so to start GRASS GIS, you have to use
grass /data/grassdata/rastertest/PERMANENT


Moritz,

Thank you. I've forgotten that and set the PWD to the location when starting
GRASS.

I just posted the rest of the raster test and worked in the PERMANENT
mapset.

Best regards,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] imported .tif maps lose all data

[Rich Shepard]

On Sat, 25 Sep 2021, Helmut Kudrnovsky wrote:


try the same steps as I've done (with adjusted paths) and _post the
command and the command output_ here.
- g.region -p
- r.in.gdal input=columbia_2010_e_dtm_35.tif output=columbia_2010_e_dtm_35
- g.region -p -a raster=columbia_2010_e_dtm_35 align=columbia_2010_e_dtm_35
- r.stats -l input=columbia_2010_e_dtm_35
- r.report map=columbia_2010_e_dtm_35


Helmut,

Results in attached 574 line file. There are some cells with data, but most
without data (82%).

I can display the data with cells; for this one map they appear to cover
only the river and not the terrain north of it. But, this is only one of 77
files.

Since this test worked I need to figure out why it didn't work when I
imported all 77 .tif files using the bash script. Ah! Thought: when
r.in.gdal imports all 77 files where does GRASS get the values for setting
g.region -p?

If g.region -p displays the region of last map imported then the other 76
maps will be outside that region. Is there a module that uses all maps in
that mapset to set the region, or is that supposed to be done by default?

Thanks very much,

RichPWD = /data/grassdata/rastertest:

g.region -p
projection: 99 (NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet)
zone:   0
datum:  ** unknown (default: WGS84) **
ellipsoid:  grs80
north:  152311
south:  106519
west:   1512164
east:   1544399
nsres:  3
ewres:  3
rows:   15264
cols:   10745
cells:  164011680

> r.in.gdal input=../columbia_2010_e_dtm_35.tif output=colum>
Importing raster map ...
 100%

g.region -p -a raster=columbia_2010_e_dtm_35 align=columbia_2010_e_dtm_35   
 
projection: 99 (NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet)
zone:   0
datum:  ** unknown (default: WGS84) **
ellipsoid:  grs80
north:  152311
south:  106519
west:   1512164
east:   1544399
nsres:  3
ewres:  3
rows:   15264
cols:   10745
cells:  164011680

g.list type=rast
columbia_2010_e_dtm_35

r.stats -l input=columbia_2010_e_dtm_35
 100%
159.315659-162.759598 from  to 
162.759598-166.203537 from  to 
166.203537-169.647476 from  to 
169.647476-173.091415 from  to 
173.091415-176.535354 from  to 
176.535354-179.979293 from  to 
179.979293-183.423233 from  to 
183.423233-186.867172 from  to 
186.867172-190.31 from  to 
190.31-193.75505 from  to 
193.75505-197.198989 from  to 
197.198989-200.642928 from  to 
200.642928-204.086868 from  to 
204.086868-207.530807 from  to 
207.530807-210.974746 from  to 
210.974746-214.418685 from  to 
214.418685-217.862624 from  to 
217.862624-221.306563 from  to 
221.306563-224.750502 from  to 
224.750502-228.194442 from  to 
228.194442-231.638381 from  to 
231.638381-235.08232 from  to 
235.08232-238.526259 from  to 
238.526259-241.970198 from  to 
241.970198-245.414137 from  to 
245.414137-248.858076 from  to 
248.858076-252.302016 from  to 
252.302016-255.745955 from  to 
255.745955-259.189894 from  to 
259.189894-262.633833 from  to 
262.633833-266.02 from  to 
266.02-269.521711 from  to 
269.521711-272.96565 from  to 
272.96565-276.40959 from  to 
276.40959-279.853529 from  to 
279.853529-283.297468 from  to 
283.297468-286.741407 from  to 
286.741407-290.185346 from  to 
290.185346-293.629285 from  to 
293.629285-297.073225 from  to 
297.073225-300.517164 from  to 
300.517164-303.961103 from  to 
303.961103-307.405042 from  to 
307.405042-310.848981 from  to 
310.848981-314.29292 from  to 
314.29292-317.736859 from  to 
317.736859-321.180799 from  to 
321.180799-324.624738 from  to 
324.624738-328.068677 from  to 
328.068677-331.512616 from  to 
331.512616-334.956555 from  to 
334.956555-338.400494 from  to 
338.400494-341.844433 from  to 
341.844433-345.288373 from  to 
345.288373-348.732312 from  to 
348.732312-352.176251 from  to 
352.176251-355.62019 from  to 
355.62019-359.064129 from  to 
359.064129-362.508068 from  to 
362.508068-365.952008 from  to 
365.952008-369.395947 from  to 
369.395947-372.839886 from  to 
372.839886-376.283825 from  to 
376.283825-379.727764 from  to 
379.727764-383.171703 from  to 
383.171703-386.615642 from  to 
386.615642-390.059582 from  to 
390.059582-393.503521 from  to 
393.503521-396.94746 from  to 
396.94746-400.391399 from  to 
400.391399-403.835338 from  to 
403.835338-407.279277 from  to 
407.279277-410.723216 from  to 
410.723216-414.167156 from  to 
414.167156-417.611095 from  to 
417.611095-421.055034 from  to 
421.055034-424.498973 from  to 
424.498973-427.942912 from  to 
427.942912-431.386851 from  to 
431.386851-434.830791 from  to 
434.830791-438.27473 from  to 
438.27473-441.718669 from  to 
441.718669-445.162608 from  to 
445.162608-448.606547 from  to 
448.606547-452.050486 from  to 
452.050486-455.494425 from  to 
455.494425-458.938365 from  to 
458.938365-462.382304 from  to 
462.382304-465.826243 from  to 
465.826243-469.270182 from  to 
469.270182-472.714121 from  to 

Re: [GRASS-user] imported .tif maps lose all data

[Moritz Lennert]

Le 25 septembre 2021 22:09:57 GMT+02:00, Rich Shepard 
 a écrit :
>On Sat, 25 Sep 2021, Helmut Kudrnovsky wrote:
>
>> try the same steps as I've done (with adjusted paths) and _post the command 
>> and the command output_ here.
>>
>> - grass78/grass80 -e -c columbia_2010_e_dtm_35.tif \grassdata\rastertest
>> - enter into the location just created
>
>Helmut,
>
>Problem at this step:
>
>$ grass -e -c columbia_2010_e_dtm_35.tif ./rastertest
>Starting GRASS GIS...
>Creating new GRASS GIS location ...
>Cleaning up temporary files...
>Cleaning up temporary files...
>
># PROBLEM (PWD is /data/grassdata/):
>$ grass rastertest 
>Starting GRASS GIS...
>ERROR:  is not a valid GRASS Location because PERMANENT 
>Mapset is missing
>Maybe you meant a different directory.
>Exiting...
>
>$ grass /data/grassdata/rastertest/
>Starting GRASS GIS...
>ERROR:  is not a valid GRASS Location because PERMANENT 
>Mapset is missing
>Maybe you meant a different directory.
>Exiting...
>
># The rastertest location exists with the PERMANENT mapset:
>ls rastertest/PERMANENT/
>DEFAULT_WIND  MYNAME  PROJ_INFO  PROJ_UNITS  PROJ_WKT  VAR  WIND  sqlite/
>
>So, grass here is seeing the GISDBASE as a location, even when the location
>is specified on the command line with either that mapset name or the full
>path?
>
>I've been having this issue the past few weeks.
>

The startup script expects you to provide the full path to a mapset, so when 
you give it 'data/grassdata/rastertest' it assumes that 'rastertest' is the 
mapset, so 'grassdata' must be the location. It then checks for a PERMANENT 
mapset in that location but cannot find it.

After creating your location it only contains one single mapset: 'PERMANENT', 
so to start GRASS GIS, you have to use

grass /data/grassdata/rastertest/PERMANENT

Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Imported .tif maps lose all data

[Carlos Henrique Grohmann de Carvalho]

Hi Micha

You're right. That's what happens when I try to answer quickly while
keeping an eye on a 5-year old. Thanks.

Carlos



On Sat, Sep 25, 2021 at 3:32 PM Micha Silver  wrote:

> Hi Carlos:
>
>
> On 9/25/21 9:16 PM, Carlos Henrique Grohmann de Carvalho wrote:
>
> Rich
>
> I believe r.in.gdal will require the region to match each of the tifs
> you're importing. Try using r.import with the option extent set to
>
> "input", so it won't do region cropping
>
>
> I don't think that is correct. r.in.gdal is one of the (very few) raster
> modules that does NOT honor the current region settings. You can import a
> raster from "anywhere", but then, as always, you must set the current
> region to match that raster for further analysis.
>
>
> What's more, in your previous post you mentioned that r.import "overrides
> region settings". IMHO this is also not correct. r.import will reproject
> an input dataset to current Location's coordinate system, if necessary.
> Regarding the region settings, by default with the extent parameter left at
> "input", the whole input raster will be imported. If you set the the extent
> parameter to "region" then only that subset of the input raster that falls
> in the current region will be imported. But in both cases, the current
> region is not altered.
>
>
> Best,
>
> Micha
>
>
>
> C
>
>
>
> On Sat, Sep 25, 2021 at 1:43 PM Rich Shepard 
> wrote:
>
>> On Sat, 25 Sep 2021, Carlos Henrique Grohmann de Carvalho wrote:
>>
>> > How is your region settings? Do they match the DEMs? Maybe importing
>> with
>> > r.import will help, as it can override region settings
>>
>> Carlos,
>>
>> Initially it was the default region. But, I changed the region to a test
>> map, dtm_35, and re-ran r.report and r.stats. There's still no data in any
>> of the cells.
>>
>> Thanks,
>>
>> Rich
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>>
>
>
> --
> Prof. Carlos Henrique Grohmann
> Institute of Energy and Environment - Univ. of São Paulo, Brazil
> - Digital Terrain Analysis | GIS | Remote Sensing -
>
> http://carlosgrohmann.com
> http://orcid.org/-0001-5073-5572
> 
> Can’t stop the signal.
>
> ___
> grass-user mailing 
> listgrass-user@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/grass-user
>
> --
> Micha Silver
> Ben Gurion Univ.
> Sde Boker, Remote Sensing Lab
> cell: +972-523-665918
>
>

-- 
Prof. Carlos Henrique Grohmann
Institute of Energy and Environment - Univ. of São Paulo, Brazil
- Digital Terrain Analysis | GIS | Remote Sensing -

http://carlosgrohmann.com
http://orcid.org/-0001-5073-5572

Can’t stop the signal.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] imported .tif maps lose all data

[Rich Shepard]

On Sat, 25 Sep 2021, Helmut Kudrnovsky wrote:


try the same steps as I've done (with adjusted paths) and _post the command and 
the command output_ here.

- grass78/grass80 -e -c columbia_2010_e_dtm_35.tif \grassdata\rastertest
- enter into the location just created


Helmut,

Problem at this step:

$ grass -e -c columbia_2010_e_dtm_35.tif ./rastertest
Starting GRASS GIS...
Creating new GRASS GIS location ...
Cleaning up temporary files...
Cleaning up temporary files...

# PROBLEM (PWD is /data/grassdata/):
$ grass rastertest 
Starting GRASS GIS...

ERROR:  is not a valid GRASS Location because PERMANENT Mapset 
is missing
Maybe you meant a different directory.
Exiting...

$ grass /data/grassdata/rastertest/
Starting GRASS GIS...
ERROR:  is not a valid GRASS Location because PERMANENT Mapset 
is missing
Maybe you meant a different directory.
Exiting...

# The rastertest location exists with the PERMANENT mapset:
ls rastertest/PERMANENT/
DEFAULT_WIND  MYNAME  PROJ_INFO  PROJ_UNITS  PROJ_WKT  VAR  WIND  sqlite/

So, grass here is seeing the GISDBASE as a location, even when the location
is specified on the command line with either that mapset name or the full
path?

I've been having this issue the past few weeks.

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] imported .tif maps lose all data

[Helmut Kudrnovsky]

>Am I
>missing an option?

nothing obvious.

try the same steps as I've done (with adjusted paths) and _post the command and 
the command output_ here.

- grass78/grass80 -e -c columbia_2010_e_dtm_35.tif \grassdata\rastertest
- enter into the location just created
- g.region -p
- r.in.gdal input=columbia_2010_e_dtm_35.tif output=columbia_2010_e_dtm_35
- g.region -p -a raster=columbia_2010_e_dtm_35 align=columbia_2010_e_dtm_35
- r.stats -l input=columbia_2010_e_dtm_35
- r.report map=columbia_2010_e_dtm_35

Helmut
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] imported .tif maps lose all data

[Micha Silver]

  
  
I can echo Helmut:
Freshly compiled 8.0-dev on Debian. I Imported
the columbia dtm_35 tif and displayed the stats fine.


On 9/25/21 9:42 PM, Helmut Kudrnovsky
  wrote:


  

  
Then the issue is with 8.0.dev.

  
  
just tested with 8.0.dev.; it works here the same as in 7.8

Helmut
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
  

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] imported .tif maps lose all data

[Rich Shepard]

On Sat, 25 Sep 2021, Helmut Kudrnovsky wrote:


just tested with 8.0.dev.; it works here the same as in 7.8


Helmut,

Okay. Then why might it not be working for me with 8.0.dev?

What's installed here is 8.0.dev (837d2136b) from yesterday morning.

My configuration file:
./configure \
--enable-64bit \
--with-libs=/usr/lib64 \
--with-postgres \
--with-postgres-includes=/usr/include/postgresql/server/ \
--with-postgres-libs=/usr/lib64/postgresql/12/lib/ \
--with-sqlite \
--with-sqlite-includes=/usr/include/ \
--with-sqlite-libs=/usr/lib/ \
--with-cairo \
--with-blas \
--with-lapack \
--with-freetype \
--with-freetype-includes=/usr/include/freetype2 \
--with-cxx \
--with-geos \
--with-gdal \
--with-nls \
--with-python3 \
--with-pthread \
--with-proj-share=/usr/share/proj \
--with-wxwidgets \
--enable-largefile \
--with-openmp \
--with-x \
--with-pdal

If it's working for you I need to find why it's not working here. Am I
missing an option?

Thanks!

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] imported .tif maps lose all data

[Helmut Kudrnovsky]

>Then the issue is with 8.0.dev.

just tested with 8.0.dev.; it works here the same as in 7.8

Helmut
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] imported .tif maps lose all data

[Micha Silver]

  
  


On 9/25/21 9:27 PM, Rich Shepard wrote:

On
  Sat, 25 Sep 2021, Helmut Kudrnovsky wrote:
  
  
  Helmut/Micha,
  
  
  Then the issue is with 8.0.dev.
  
  
  Where can I download the 7.8.x source so I can build it here?
  Following
  
  links from the web site's download for gneric linux
  



From github:
https://github.com/OSGeo/grass/tree/releasebranch_7_8



The first link in the list on this page points to the GRASS repo:
https://grass.osgeo.org/download/
Choose the version you want by switching to a different branch. 






  I find a zip file
  
  and an install shell script, but not the source that allows me to
  build it
  
  on this Slackware-14.2/x86_64 host. Are the source files available
  just like
  
  the 8.0.dev source tree is?
  
  
  Thanks,
  
  
  Rich
  
  
  ___
  
  grass-user mailing list
  
  grass-user@lists.osgeo.org
  
  https://lists.osgeo.org/mailman/listinfo/grass-user
  

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
  

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] imported .tif maps lose all data

[Helmut Kudrnovsky]

>Where can I download the 7.8.x source so I can build it here? Following
>links from the web site's download for gneric linux
>https://grass.osgeo.org/grass78/binary/linux/snapshot/> I find a zip file
>and an install shell script, but not the source that allows me to build it
>on this Slackware-14.2/x86_64 host. Are the source files available just like
>the 8.0.dev source tree is?

a simple github checkout of the grass78_releasebranch?

https://github.com/OSGeo/grass/tree/releasebranch_7_8

Helmut

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Imported .tif maps lose all data

[Micha Silver]

  
  
Hi Carlos:


On 9/25/21 9:16 PM, Carlos Henrique
  Grohmann de Carvalho wrote:


  
  
Rich


I believe r.in.gdal
  will require the region to match each of the tifs you're
  importing. Try using r.import with the option extent set to 
  


  
"input", so it won't do
  region cropping
  



I don't think that is correct. r.in.gdal
  is one of the (very few) raster modules that does NOT honor
  the current region settings. You can import a raster from
  "anywhere", but then, as always, you must set the current region
  to match that raster for further analysis.


What's more, in your previous post you mentioned that r.import "overrides region settings".
  IMHO this is also not correct. r.import 
  will reproject an input dataset to current Location's coordinate
  system, if necessary. Regarding the region settings, by default
  with the extent parameter left at "input", the whole input raster
  will be imported. If you set the the extent parameter to "region"
  then only that subset of the input raster that falls in the
  current region will be imported. But in both cases, the current
  region is not altered.


Best,
Micha



  


C




  
  
  
On Sat, Sep 25, 2021 at 1:43
  PM Rich Shepard 
  wrote:

On
  Sat, 25 Sep 2021, Carlos Henrique Grohmann de Carvalho wrote:
  
  > How is your region settings? Do they match the DEMs?
  Maybe importing with
  > r.import will help, as it can override region settings
  
  Carlos,
  
  Initially it was the default region. But, I changed the region
  to a test
  map, dtm_35, and re-ran r.report and r.stats. There's still no
  data in any
  of the cells.
  
  Thanks,
  
  Rich
  ___
  grass-user mailing list
  grass-user@lists.osgeo.org
  https://lists.osgeo.org/mailman/listinfo/grass-user

  
  
  
  -- 
  
Prof. Carlos Henrique Grohmann
  Institute of Energy and Environment - Univ. of São Paulo,
  Brazil
  - Digital Terrain Analysis | GIS | Remote Sensing - 
  
  
  http://carlosgrohmann.com
  http://orcid.org/-0001-5073-5572

  Can’t stop the signal.
  

  
  
  
  ___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
  

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Imported .tif maps lose all data

[Rich Shepard]

On Sat, 25 Sep 2021, Carlos Henrique Grohmann de Carvalho wrote:


I believe r.in.gdal will require the region to match each of the tifs
you're importing. Try using r.import with the option extent set to
"input", so it won't do region cropping


Carlos,

All .tif files in that directory have the same region. They cover the
Columbia River from the mouth to Bonneville Dam. But, those 146 miles are
separated into 77 separate reach files.

Regards,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] imported .tif maps lose all data

[Rich Shepard]

On Sat, 25 Sep 2021, Helmut Kudrnovsky wrote:

Helmut/Micha,

Then the issue is with 8.0.dev.

Where can I download the 7.8.x source so I can build it here? Following
links from the web site's download for gneric linux
 I find a zip file
and an install shell script, but not the source that allows me to build it
on this Slackware-14.2/x86_64 host. Are the source files available just like
the 8.0.dev source tree is?

Thanks,

Rich

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] imported .tif maps lose all data

[Helmut Kudrnovsky]

>>The data file sizes are all in the low 100Ks. I could upload an example to
>>fileconvoy.com if that's helpful.
>
>could you make one of the data files available?
>
>Helmut

for me it works

Driver: GTiff/GeoTIFF
Files: columbia_2010_e_dtm_35.tif
Size is 10745, 15264
Coordinate System is:
PROJCRS["NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet",
BASEGEOGCRS["GCS_North_American_1983_HARN",
DATUM["North_American_1983_HARN",
ELLIPSOID["GRS_1980",6378137,298.257222101,
LENGTHUNIT["metre",1,
ID["EPSG",9001,
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433,
ID["EPSG",9122,
CONVERSION["Lambert Conic Conformal (2SP)",
METHOD["Lambert Conic Conformal (2SP)",
ID["EPSG",9802]],
PARAMETER["Latitude of false origin",45.3,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8821]],
PARAMETER["Longitude of false origin",-120.5,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8822]],
PARAMETER["Latitude of 1st standard parallel",45.8,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8823]],
PARAMETER["Latitude of 2nd standard parallel",47.3,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8824]],
PARAMETER["Easting at false origin",50,
LENGTHUNIT["metre",1],
ID["EPSG",8826]],
PARAMETER["Northing at false origin",0,
LENGTHUNIT["metre",1],
ID["EPSG",8827]]],
CS[Cartesian,2],
AXIS["easting",east,
ORDER[1],
LENGTHUNIT["US survey foot",0.304800609601219,
ID["EPSG",9003]]],
AXIS["northing",north,
ORDER[2],
LENGTHUNIT["US survey foot",0.304800609601219,
ID["EPSG",9003
Data axis to CRS axis mapping: 1,2
Origin = (1512164.000,152311.000)
Pixel Size = (3.000,-3.000)
Metadata:
  AREA_OR_POINT=Area
  DataType=Generic
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( 1512164.000,  152311.000) (121d 0' 8.57"W, 45d44'59.58"N)
Lower Left  ( 1512164.000,  106519.000) (121d 0' 4.46"W, 45d37'27.52"N)
Upper Right ( 1544399.000,  152311.000) (120d52'34.01"W, 45d45' 1.35"N)
Lower Right ( 1544399.000,  106519.000) (120d52'30.94"W, 45d37'29.29"N)
Center  ( 1528281.500,  129415.000) (120d56'19.49"W, 45d41'14.50"N)
Band 1 Block=512x256 Type=Float32, ColorInterp=Gray
  Min=159.316 Max=1037.520 
  Minimum=159.316, Maximum=1037.520, Mean=262.041, StdDev=157.494
  NoData Value=-3.40282306073709653e+38
  Overviews: 5373x7632, 2687x3816, 1344x1908, 672x954, 336x477, 168x239
  Metadata:
BandName=Band_1
RepresentationType=ATHEMATIC
STATISTICS_COVARIANCES=24804.31297971113
STATISTICS_MAXIMUM=1037.5201416016
STATISTICS_MEAN=262.04051816209
STATISTICS_MINIMUM=159.31565856934
STATISTICS_SKIPFACTORX=1
STATISTICS_SKIPFACTORY=1
STATISTICS_STDDEV=157.49385060919


D:\wd\testgpkg>grass78 -e -c columbia_2010_e_dtm_35.tif D:\grassdata\rastertest
Starting GRASS GIS...
Creating new GRASS GIS location ...
WARNUNG: Sperren gleichzeitiger Zugriffe auf ein Mapset ist unter Windows
 nicht möglich.
Cleaning up temporary files...
Cleaning up temporary files...


g.region -p 
projection: 99 (NAD83(HARN) / Washington South (ftUS))
zone:   0
datum:  ** unknown (default: WGS84) **
ellipsoid:  grs80
north:  152311
south:  106519
west:   1512164
east:   1544399
nsres:  3
ewres:  3
rows:   15264
cols:   10745
cells:  164011680



r.in.gdal input=D:\wd\testgpkg\columbia_2010_e_dtm_35.tif 
output=columbia_2010_e_dtm_35
WARNING: Datum  von GRASS nicht erkannt und keine 
Parameter gefunden.
Importing raster map ...


g.region -p -a raster=columbia_2010_e_dtm_35@data 
align=columbia_2010_e_dtm_35@data
projection: 99 (NAD83(HARN) / Washington South (ftUS))
zone:   0
datum:  ** unknown (default: WGS84) **
ellipsoid:  grs80
north:  152311
south:  106519
west:   1512164
east:   1544399
nsres:  3
ewres:  3
rows:   15264
cols:   10745
cells:  164011680


r.stats -l input=columbia_2010_e_dtm_35@data
159.315659-162.759598 from  to 
162.759598-166.203537 from  to 
166.203537-169.647476 from  to 
169.647476-173.091415 from  to 
173.091415-176.535354 from  to 
176.535354-179.979293 from  to 
179.979293-183.423233 from  to 
183.423233-186.867172 from  to 


r.report map=columbia_2010_e_dtm_35@data
+-+
| RASTER MAP CATEGORY REPORT

Re: [GRASS-user] imported .tif maps lose all data

[Micha Silver]

  
  
Here's what I got using GRASS 7.8

  
grass -e -c
~/Downloads/columbia_2010_e_dtm_35.tif
/tmp/grassdata/columbia/PERMANENT

  
grass /tmp/grassdata/columbia/PERMANENT/
Starting GRASS GIS...


  
r.import
~/Downloads/columbia_2010_e_dtm_35.tif out=dtm_35
WARNING: Datum  not recognised
by GRASS and no
 parameters found
WARNING: Datum  not recognised
by GRASS and no
 parameters found
Importing raster map ...
 100%

  
g.region -ap rast=dtm_35
projection: 99 (NAD83(HARN) / Washington South (ftUS))
zone:   0
datum:  ** unknown (default: WGS84) **
ellipsoid:  grs80
north:  152311
south:  106519
west:   1512164
east:   1544399
nsres:  3
ewres:  3
rows:   15264
cols:   10745
cells:  164011680

  
micha@RMS:GIS$ r.info dtm_35
 ++
 | Map:  dtm_35 Date: Sat Sep 25
21:13:31 2021    |
 | Mapset:   PERMANENT  Login of Creator:
micha   |
 | Location:
columbia
|
 | DataBase:
/tmp/grassdata  
|
 |
Title:
|
 | Timestamp:
none   
|
 ||
 |   
|
 |   Type of Map:  raster   Number of Categories:
0   |
 |   Data Type:   
FCELL  |
 |   Rows:
15264  |
 |   Columns: 
10745  |
 |   Total Cells: 
164011680  |
 |    Projection: NAD83(HARN) / Washington South
(ftUS)   |
 |    N: 152311    S: 106519   Res:
3 |
 |    E:    1544399    W:    1512164   Res:
3 |
 |   Range of data:    min = 159.3157  max =
1037.52  |
 |   
|
 |   Data
Description:   
|
 |    generated by
r.in.gdal  |
 |   
|
 |  
Comments:   
|
 |    r.in.gdal -a -k
input="/home/micha/Downloads/columbia_2010_e_dtm_35.\   |
 |    tif" output="dtm_35" memory=300 offset=0
num_digits=0   |
 |   
|
 ++

  
micha@RMS:GIS$ r.report dtm_35
 100%
+-+
| RASTER MAP CATEGORY
REPORT  |
|LOCATION: columbia   Sat Sep 25
21:14:06 2021|
|-|
|  north: 152311    east:
1544399 |
|REGION    south: 106519    west:
1512164 |
|  res:    3    res:   
3 |
|-|
|MASK:
none  
|
|-|
|MAP: (untitled) (dtm_35 in
PERMANENT)    |
|-|
|    Category
Information |
| 
#|description  |

Re: [GRASS-user] Imported .tif maps lose all data

[Carlos Henrique Grohmann de Carvalho]

Rich

I believe r.in.gdal will require the region to match each of the tifs
you're importing. Try using r.import with the option extent set to "input",
so it won't do region cropping

C



On Sat, Sep 25, 2021 at 1:43 PM Rich Shepard 
wrote:

> On Sat, 25 Sep 2021, Carlos Henrique Grohmann de Carvalho wrote:
>
> > How is your region settings? Do they match the DEMs? Maybe importing with
> > r.import will help, as it can override region settings
>
> Carlos,
>
> Initially it was the default region. But, I changed the region to a test
> map, dtm_35, and re-ran r.report and r.stats. There's still no data in any
> of the cells.
>
> Thanks,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>


-- 
Prof. Carlos Henrique Grohmann
Institute of Energy and Environment - Univ. of São Paulo, Brazil
- Digital Terrain Analysis | GIS | Remote Sensing -

http://carlosgrohmann.com
http://orcid.org/-0001-5073-5572

Can’t stop the signal.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Imported .tif maps lose all data

[Micha Silver]

  
  


On 9/25/21 7:41 PM, Rich Shepard wrote:

On
  Sat, 25 Sep 2021, Micha Silver wrote:
  
  
  Just to check: did you set the current
region to the imported raster

before running r.report?

  
  
  Micha,
  
  
  Just did set the region to dtm_35 and re-ran r.report:
  
  
  The data's still AWOL.
  
  



Can we go back to your suggestion to post the original data
  somewhere?



  
  Thanks,
  
  
  Rich
  
  ___
  
  grass-user mailing list
  
  grass-user@lists.osgeo.org
  
  https://lists.osgeo.org/mailman/listinfo/grass-user
  

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
  

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] imported .tif maps lose all data

[Rich Shepard]

On Sat, 25 Sep 2021, Helmut Kudrnovsky wrote:


The data file sizes are all in the low 100Ks. I could upload an example to
fileconvoy.com if that's helpful.


could you make one of the data files available?


Heelmut,

Certainly. It's avalable from

and will be there for 5 days.

The file that can be retrieved with the above link is: 
columbia_2010_e_dtm_35.tif (138.85 MB)

Regards,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] imported .tif maps lose all data

[Helmut Kudrnovsky]

>The data file sizes are all in the low 100Ks. I could upload an example to
>fileconvoy.com if that's helpful.

could you make one of the data files available?

Heelmut
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Imported .tif maps lose all data

[Rich Shepard]

On Sat, 25 Sep 2021, Carlos Henrique Grohmann de Carvalho wrote:


How is your region settings? Do they match the DEMs? Maybe importing with
r.import will help, as it can override region settings


Carlos,

Initially it was the default region. But, I changed the region to a test
map, dtm_35, and re-ran r.report and r.stats. There's still no data in any
of the cells.

Thanks,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Imported .tif maps lose all data

[Rich Shepard]

On Sat, 25 Sep 2021, Micha Silver wrote:


Just to check: did you set the current region to the imported raster
before running r.report?


Micha,

Just did set the region to dtm_35 and re-ran r.report:
+-+
| RASTER MAP CATEGORY REPORT  |
|LOCATION: new_nevins_dockSat Sep 25 09:35:06 2021|
|-|
|  north: 106729east: 1544180 |
|REGIONsouth:  60934west: 1511876 |
|  res:3res:3 |
|-|
|MASK: none   |
|-|
|MAP: (untitled) (dtm_35 in topography)   |
|-|
|   Category Information | cell|   %  |
|#|description   |count| cover|
|-|
|*|no data. . . . . . . . . . . . . . . . . . . . . . . . . .|164373520|100.00|
|-|
|TOTAL   |164373520|100.00|
+-+

and r.stats:

r.stats -l in=dtm_35 out=stats.txt
* no data

The data's still AWOL.

Also, in your example, you imported to a GRASS raster named dtm_4, but you 
then run r.report on a raster named dtm_35


That's becaue I copied from the input script and forgot to change it to
dtm_35 which is what I used for the examples.

Thanks,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Imported .tif maps lose all data

[Carlos Henrique Grohmann de Carvalho]

How is your region settings? Do they match the DEMs? Maybe importing with
r.import will help, as it can override region settings

Carlos




On Sat, 25 Sep 2021, 11:43 Rich Shepard,  wrote:

> I have 77 LiDAR topo files in .tif format. What gdalinfo tells me about a
> representative file:
> $ gdalinfo columbia_2010_e_dtm_35.tif
> Driver: GTiff/GeoTIFF
> Files: columbia_2010_e_dtm_35.tif
> Size is 10745, 15264
> Coordinate System is:
> PROJCRS["NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet",
>  BASEGEOGCRS["GCS_North_American_1983_HARN",
>  DATUM["North_American_1983_HARN",
>  ELLIPSOID["GRS_1980",6378137,298.257222101,
>  LENGTHUNIT["metre",1,
>  ID["EPSG",9001,
>  PRIMEM["Greenwich",0,
>  ANGLEUNIT["degree",0.0174532925199433,
>  ID["EPSG",9122,
>  CONVERSION["Lambert Conic Conformal (2SP)",
>  METHOD["Lambert Conic Conformal (2SP)",
>  ID["EPSG",9802]],
>  PARAMETER["Latitude of false origin",45.3,
>  ANGLEUNIT["degree",0.0174532925199433],
>  ID["EPSG",8821]],
>  PARAMETER["Longitude of false origin",-120.5,
>  ANGLEUNIT["degree",0.0174532925199433],
>  ID["EPSG",8822]],
>  PARAMETER["Latitude of 1st standard parallel",45.8,
>  ANGLEUNIT["degree",0.0174532925199433],
>  ID["EPSG",8823]],
>  PARAMETER["Latitude of 2nd standard parallel",47.3,
>  ANGLEUNIT["degree",0.0174532925199433],
>  ID["EPSG",8824]],
>  PARAMETER["Easting at false origin",50,
>  LENGTHUNIT["metre",1],
>  ID["EPSG",8826]],
>  PARAMETER["Northing at false origin",0,
>  LENGTHUNIT["metre",1],
>  ID["EPSG",8827]]],
>  CS[Cartesian,2],
>  AXIS["easting",east,
>  ORDER[1],
>  LENGTHUNIT["US survey foot",0.304800609601219,
>  ID["EPSG",9003]]],
>  AXIS["northing",north,
>  ORDER[2],
>  LENGTHUNIT["US survey foot",0.304800609601219,
>  ID["EPSG",9003
> Data axis to CRS axis mapping: 1,2
> Origin = (1512164.000,152311.000)
> Pixel Size = (3.000,-3.000)
> Metadata:
>AREA_OR_POINT=Area
>DataType=Generic
> Image Structure Metadata:
>COMPRESSION=LZW
>INTERLEAVE=BAND
> Corner Coordinates:
> Upper Left  ( 1512164.000,  152311.000) (121d 0' 8.57"W, 45d44'59.58"N)
> Lower Left  ( 1512164.000,  106519.000) (121d 0' 4.46"W, 45d37'27.52"N)
> Upper Right ( 1544399.000,  152311.000) (120d52'34.01"W, 45d45' 1.35"N)
> Lower Right ( 1544399.000,  106519.000) (120d52'30.94"W, 45d37'29.29"N)
> Center  ( 1528281.500,  129415.000) (120d56'19.49"W, 45d41'14.50"N)
> Band 1 Block=512x256 Type=Float32, ColorInterp=Gray
>Min=159.316 Max=1037.520
>Minimum=159.316, Maximum=1037.520, Mean=262.041, StdDev=157.494
>NoData Value=-3.40282306073709653e+38
>Overviews: 5373x7632, 2687x3816, 1344x1908, 672x954, 336x477, 168x239
>Metadata:
>  BandName=Band_1
>  RepresentationType=ATHEMATIC
>  STATISTICS_COVARIANCES=24804.31297971113
>  STATISTICS_MAXIMUM=1037.5201416016
>  STATISTICS_MEAN=262.04051816209
>  STATISTICS_MINIMUM=159.31565856934
>  STATISTICS_SKIPFACTORX=1
>  STATISTICS_SKIPFACTORY=1
>  STATISTICS_STDDEV=157.49385060919
>
> I started GRASS with a new location:
> grass -c /path/to/project/data/topography/columbia_2010_e_dtm_35.tif
> /data/grassdata/columbia_river_dtms/topography
>
> and imported all raw data; e.g.,
>
> r.in.gdal
> in=/path/to/project/data/topography/columbia_2010_e_dtm_35.tif out=dtm_4
> --o
>
> The problem is the imported maps have no elevation data. For example,
> r.report dtm_35
>   100%
>
> +-+
> | RASTER MAP CATEGORY REPORT
> |
> |LOCATION: new_nevins_dockSat Sep 25 07:28:25
> 2021|
>
> |-|
> |  north: 106729east: 1544180
>|
> |REGIONsouth:  60934west: 1511876
>|
> |  res:3res:3
>|
>
> |-|
> |MASK: none
>|
>
> |-|
> |MAP: (untitled) (dtm_35 in topography)
>|
>
> |-|
> |   Category Information | cell|
>  %  |
> |#|description   |count|
> cover|
>
> |-|
> |*|no data. . . . . . . . . . . . . . . . . . . 

Re: [GRASS-user] Imported .tif maps lose all data

[Micha Silver]

Rich:

Just to check: did you set the current region to the imported raster 
before running r.report?


From the man page:

Note that the statistics is always computed in the current geographical 
region.



From the Y coordinates in the gdalinfo output and the region settings 
reported by r.report, it seems that there is almost no overlap. Maybe 
that's the reason the r.report is not showing anything?




On 9/25/21 5:43 PM, Rich Shepard wrote:

I have 77 LiDAR topo files in .tif format. What gdalinfo tells me about a
representative file:
$ gdalinfo columbia_2010_e_dtm_35.tif

Corner Coordinates:
Upper Left  ( 1512164.000,  152311.000) (121d 0' 8.57"W, 45d44'59.58"N)
Lower Left  ( 1512164.000,  106519.000) (121d 0' 4.46"W, 45d37'27.52"N)
Upper Right ( 1544399.000,  152311.000) (120d52'34.01"W, 45d45' 1.35"N)
Lower Right ( 1544399.000,  106519.000) (120d52'30.94"W, 45d37'29.29"N)


r.in.gdal
in=/path/to/project/data/topography/columbia_2010_e_dtm_35.tif 
out=dtm_4 --o





Also, in your example, you imported to a GRASS raster named dtm_4, but 
you then run r.report on a raster named dtm_35


??




The problem is the imported maps have no elevation data. For example,
r.report dtm_35
 100%
+-+ 

| RASTER MAP CATEGORY 
REPORT  |
|LOCATION: new_nevins_dock    Sat Sep 25 
07:28:25 2021|
|-| 

|  north: 106729    east: 
1544180 |
|REGION    south:  60934    west: 
1511876 |

|  res:    3    res: 3 |
|-| 


|MASK: none |
|-| 

|MAP: (untitled) (dtm_35 in 
topography)   |
|-| 

|   Category Information | cell|   
%  |
|#|description   | count| 
cover|
|-| 

|*|no data. . . . . . . . . . . . . . . . . . . . . . . . . 
.|164373520|100.00|
|-| 


|TOTAL |164373520|100.00|
+-+ 



r.stats -l in=dtm_35 out=-
 100%
* no data



r.stats also honors the current region




The data file sizes are all in the low 100Ks. I could upload an 
example to

fileconvoy.com if that's helpful.

What have I done incorrectly that the imported maps have no elevation 
data

while the raw .tif files do?

TIA,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Imported .tif maps lose all data

[Rich Shepard]

I have 77 LiDAR topo files in .tif format. What gdalinfo tells me about a
representative file:
$ gdalinfo columbia_2010_e_dtm_35.tif
Driver: GTiff/GeoTIFF
Files: columbia_2010_e_dtm_35.tif
Size is 10745, 15264
Coordinate System is:
PROJCRS["NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet",
BASEGEOGCRS["GCS_North_American_1983_HARN",
DATUM["North_American_1983_HARN",
ELLIPSOID["GRS_1980",6378137,298.257222101,
LENGTHUNIT["metre",1,
ID["EPSG",9001,
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433,
ID["EPSG",9122,
CONVERSION["Lambert Conic Conformal (2SP)",
METHOD["Lambert Conic Conformal (2SP)",
ID["EPSG",9802]],
PARAMETER["Latitude of false origin",45.3,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8821]],
PARAMETER["Longitude of false origin",-120.5,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8822]],
PARAMETER["Latitude of 1st standard parallel",45.8,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8823]],
PARAMETER["Latitude of 2nd standard parallel",47.3,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8824]],
PARAMETER["Easting at false origin",50,
LENGTHUNIT["metre",1],
ID["EPSG",8826]],
PARAMETER["Northing at false origin",0,
LENGTHUNIT["metre",1],
ID["EPSG",8827]]],
CS[Cartesian,2],
AXIS["easting",east,
ORDER[1],
LENGTHUNIT["US survey foot",0.304800609601219,
ID["EPSG",9003]]],
AXIS["northing",north,
ORDER[2],
LENGTHUNIT["US survey foot",0.304800609601219,
ID["EPSG",9003
Data axis to CRS axis mapping: 1,2
Origin = (1512164.000,152311.000)
Pixel Size = (3.000,-3.000)
Metadata:
  AREA_OR_POINT=Area
  DataType=Generic
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( 1512164.000,  152311.000) (121d 0' 8.57"W, 45d44'59.58"N)
Lower Left  ( 1512164.000,  106519.000) (121d 0' 4.46"W, 45d37'27.52"N)
Upper Right ( 1544399.000,  152311.000) (120d52'34.01"W, 45d45' 1.35"N)
Lower Right ( 1544399.000,  106519.000) (120d52'30.94"W, 45d37'29.29"N)
Center  ( 1528281.500,  129415.000) (120d56'19.49"W, 45d41'14.50"N)
Band 1 Block=512x256 Type=Float32, ColorInterp=Gray
  Min=159.316 Max=1037.520
  Minimum=159.316, Maximum=1037.520, Mean=262.041, StdDev=157.494
  NoData Value=-3.40282306073709653e+38
  Overviews: 5373x7632, 2687x3816, 1344x1908, 672x954, 336x477, 168x239
  Metadata:
BandName=Band_1
RepresentationType=ATHEMATIC
STATISTICS_COVARIANCES=24804.31297971113
STATISTICS_MAXIMUM=1037.5201416016
STATISTICS_MEAN=262.04051816209
STATISTICS_MINIMUM=159.31565856934
STATISTICS_SKIPFACTORX=1
STATISTICS_SKIPFACTORY=1
STATISTICS_STDDEV=157.49385060919

I started GRASS with a new location:
grass -c /path/to/project/data/topography/columbia_2010_e_dtm_35.tif 
/data/grassdata/columbia_river_dtms/topography

and imported all raw data; e.g.,

r.in.gdal
in=/path/to/project/data/topography/columbia_2010_e_dtm_35.tif out=dtm_4 --o

The problem is the imported maps have no elevation data. For example,
r.report dtm_35
 100%
+-+
| RASTER MAP CATEGORY REPORT  |
|LOCATION: new_nevins_dockSat Sep 25 07:28:25 2021|
|-|
|  north: 106729east: 1544180 |
|REGIONsouth:  60934west: 1511876 |
|  res:3res:3 |
|-|
|MASK: none   |
|-|
|MAP: (untitled) (dtm_35 in topography)   |
|-|
|   Category Information | cell|   %  |
|#|description   |count| cover|
|-|
|*|no data. . . . . . . . . . . . . . . . . . . . . . . . . .|164373520|100.00|
|-|
|TOTAL   |164373520|100.00|