[GRASS-user] rshepard@appl-ecosys.com sent you a file

GRASS GRASS user
1

You have a file waiting for you on File Convoy (www.fileconvoy.com). Click on the link below to retrieve your file.

http://www.fileconvoy.com/dfl.php?id=g95f381ad302e3e6a1000089290c30f8b0cc10650bd

The file available is:

bareearth.tar.gz - 10.831 MB

Message of the sender:

At the provided URL is the file, bareearth.tar.gz. I hope this allows proper transfer of the files.

Rich

The file will be available on the server for the next 5 days.

Thanks.

PS: This email has been sent by service@fileconvoy.com on behalf of rshepard@appl-ecosys.com.

Click on this link to opt out of this service

RNID:g95f381ad302e3e6a1000089290c30f8b0cc10650bd:

2

On Sun, 10 Jun 2018, Micha Silver wrote:

Now it works
I created a new LOCATION based on "a georeferenced file" and pointed to the hdr.adf file.
The location projection parameters:

Micha,

   Now to find why it's not working the same way here with 7.5svn release
72793.

   In ~/data/oregon/projects/ I started grass75 and created a new location
for the project name, pointed grass to hdr.adf and get the same info as you:

g.proj -g
name=unnamed
ellps=grs80
proj=lcc
lat_1=43
lat_2=45.5
lat_0=41.75
lon_0=-120.5
x_0=399999.9999999999
y_0=0
no_defs=defined
unit=user-defined
units=user-defineds
meters=0.3048

   I also created a new mapset, topography, and entered the same command
syntax as you used:

r.in.gdal -e --overwrite input="/home/rshepard/projects/oregon/<projname>/data/topography/LDQ-45122C3/2014_OLC_Metro/Bare_Earth/bh45122c3/hdr.adf" output=bare_earth memory=300 offset=0 num_digits=0
WARNING: Raster map <bare_earth> already exists and will be overwritten
WARNING: Datum <Not_specified_based_on_GRS_1980_ellipsoid> not recognised
          by GRASS and no parameters found
Importing raster map <bare_earth>...
  100%
Region for the current mapset updated

   When I load that bare_earth raster map it's the same as before: a
multicolored wedge along the north and a wide purple rectangle along the
west side (see attached).

   Ideas on where I should look for the reason I get different results from
Micah are much appreciated.

Rich

(attachments)

bare_earth.png

3

On Sun, Jun 10, 2018 at 6:41 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:

On Sun, 10 Jun 2018, Micha Silver wrote:

Now it works

.. also here, git the file.

I created a new LOCATION based on "a georeferenced file" and pointed to
the hdr.adf file.
The location projection parameters:

Micha,

  Now to find why it's not working the same way here with 7.5svn release
72793.

When using gdalinfo, it does not recognize the SRS (on my system at least).
[mneteler@oboe Bare_Earth ]$ gdalinfo bh45122c3
Driver: AIG/Arc/Info Binary Grid
Files: bh45122c3
       bh45122c3.ovr
       bh45122c3.aux.xml
       bh45122c3/sta.adf
       bh45122c3/w001001x.adf
       bh45122c3/prj.adf
       bh45122c3/metadata.xml
       bh45122c3/hdr.adf
       bh45122c3/w001001.adf
       bh45122c3/dblbnd.adf
Size is 11052, 15426
Coordinate System is:
PROJCS["unnamed",
    GEOGCS["Unknown datum based upon the GRS 1980 ellipsoid",
        DATUM["Not_specified_based_on_GRS_1980_ellipsoid",
            SPHEROID["GRS 1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            AUTHORITY["EPSG","6019"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4019"]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",43],
    PARAMETER["standard_parallel_2",45.5],
    PARAMETER["latitude_of_origin",41.75],
    PARAMETER["central_meridian",-120.5],
    PARAMETER["false_easting",1312335.958005249],
    PARAMETER["false_northing",0],
    UNIT["user-defined",0.3048]]
Origin = (829504.500000000000000,1326862.500000000000000)
Pixel Size = (3.000000000000000,-3.000000000000000)
Corner Coordinates:
Upper Left ( 829504.500, 1326862.500) (122d22'44.53"W, 45d22'29.77"N)
Lower Left ( 829504.500, 1280584.500) (122d22'29.72"W, 45d14'52.95"N)
Upper Right ( 862660.500, 1326862.500) (122d15' 0.15"W, 45d22'37.00"N)
Lower Right ( 862660.500, 1280584.500) (122d14'46.37"W, 45d15' 0.16"N)
Center ( 846082.500, 1303723.500) (122d18'45.19"W, 45d18'45.04"N)
Band 1 Block=256x16 Type=Float32, ColorInterp=Undefined
  Min=206.380 Max=1157.470
  Minimum=206.380, Maximum=1157.470, Mean=526.722, StdDev=308.445
  NoData Value=-3.4028234663852886e+38
  Overviews: 5526x7713, 2763x3857, 1382x1929, 691x965, 346x483, 173x242
  Metadata:
    STATISTICS_MAXIMUM=1157.4699707031
    STATISTICS_MEAN=526.72212274996
    STATISTICS_MINIMUM=206.38000488281
    STATISTICS_STDDEV=308.44451906832

However, I discovered the SRS in the included XML file:

grep SRS bh45122c3.aux.xml
<SRS>PROJCS["NAD_1983_2011_Oregon_Statewide_Lambert_Feet_Intl",GEOGCS["GCS_NAD_1983_2011",DATUM["D_NAD_1983_2011",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["false_easting",1312335.958005249],PARAMETER["false_northing",0.0],PARAMETER["central_meridian",-120.5],PARAMETER["standard_parallel_1",43.0],PARAMETER["standard_parallel_2",45.5],PARAMETER["latitude_of_origin",41.75],UNIT["Foot",0.3048]]</SRS>

Apparently the SRS lookup mechanism fails in GDAL? GRASS GIS mostly
relies on it.

I have GDAL 2.2.4, released 2018/03/19, does anyone have a more recent
version and could try?

Markus

4

On Mon, 11 Jun 2018, Markus Neteler wrote:

When using gdalinfo, it does not recognize the SRS (on my system at least).

Markus,

   I get the same report with the unknown SRS.

However, I discovered the SRS in the included XML file:

grep SRS bh45122c3.aux.xml
<SRS>PROJCS["NAD_1983_2011_Oregon_Statewide_Lambert_Feet_Intl",GEOGCS["GCS_NAD_1983_2011",DATUM["D_NAD_1983_2011",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["false_easting",1312335.958005249],PARAMETER["false_northing",0.0],PARAMETER["central_meridian",-120.5],PARAMETER["standard_parallel_1",43.0],PARAMETER["standard_parallel_2",45.5],PARAMETER["latitude_of_origin",41.75],UNIT["Foot",0.3048]]</SRS>

   I saw that when I looked at that file but had (still have) no idea what to
do with it.

Apparently the SRS lookup mechanism fails in GDAL? GRASS GIS mostly
relies on it.

I have GDAL 2.2.4, released 2018/03/19, does anyone have a more recent
version and could try?

   Version gdal-2.3.0 is installed here on Slackware-14.2.

   Any suggestions on resolving the problem you and I (at least, but not
Micha) have with this? I'll be more than happy to test any patches.

Best regards,

Rich

5

Dear Grass-users,

I have problems using d.rast.edit. In the archived mails I only found
that there is a problem using NULL values (*). I cannot save my edits
regardless which values I enter.
I tried using the command line, the GUI, having the rasters I edit in
the display and not having it in the display - without any effect. I am
not using aspect maps.
I installed the latest grass version last week (win7,64bit).

Could anyone give me a hint what else I could try?

Heidi

On 2018-06-11 00:35, Rich Shepard wrote:

On Mon, 11 Jun 2018, Markus Neteler wrote:

When using gdalinfo, it does not recognize the SRS (on my system at
least).

Markus,

I get the same report with the unknown SRS.

However, I discovered the SRS in the included XML file:

grep SRS bh45122c3.aux.xml
<SRS>PROJCS["NAD_1983_2011_Oregon_Statewide_Lambert_Feet_Intl",GEOGCS["GCS_NAD_1983_2011",DATUM["D_NAD_1983_2011",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["false_easting",1312335.958005249],PARAMETER["false_northing",0.0],PARAMETER["central_meridian",-120.5],PARAMETER["standard_parallel_1",43.0],PARAMETER["standard_parallel_2",45.5],PARAMETER["latitude_of_origin",41.75],UNIT["Foot",0.3048]]</SRS>

I saw that when I looked at that file but had (still have) no idea
what to
do with it.

Apparently the SRS lookup mechanism fails in GDAL? GRASS GIS mostly
relies on it.

I have GDAL 2.2.4, released 2018/03/19, does anyone have a more recent
version and could try?

Version gdal-2.3.0 is installed here on Slackware-14.2.

Any suggestions on resolving the problem you and I (at least, but not
Micha) have with this? I'll be more than happy to test any patches.

Best regards,

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

--

6

Now to find why it's not working the same way here with 7.5svn release

GRASS 7.4.0 and GRASS trunk seems to behave differently in set up this
incomplete CRS in this case.

GRASS 7.4.0 produces:

g.proj -p
-PROJ_INFO-------------------------------------------------
name : unnamed
ellps : grs80
proj : lcc
lat_1 : 43
lat_2 : 45.5
lat_0 : 41.75
lon_0 : -120.5
x_0 : 399999.9999999999
y_0 : 0
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : user-defined
units : user-defineds
meters : 0.3048

despite the name, the CRS looks ok.

looking at the gdalinfo output of the raster:

>Min=206.380 Max=1157.470
>NoData Value=-3.4028234663852886e+38

loading this raster data into e.g QGIS, it shows the same as in GRASS,

When I load that bare_earth raster map it's the same as before: a
multicolored wedge along the north and a wide purple rectangle along the
west side (see attached).

most of the central part of the raster is NoData; thus it seems to be ok as
it is.

further steps may be:

(1) ask your data provider for data with a complete SRS information
(2) ask on the GDAL ML if it is maybe a GDAL issue about the SRS information
(3) ask your data provider if it is correct that most of the raster is
NoData

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

7

I have GDAL 2.2.4, released 2018/03/19, does anyone have a more recent
version and could try?

here:
gdalinfo --version
GDAL 2.2.4, released 2018/03/19

it seems GRASS 7.4.0 and GRASS trunk behave differently with this data.

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

8

On Mon, Jun 11, 2018 at 10:55 AM, Helmut Kudrnovsky <hellik@web.de> wrote:

Now to find why it’s not working the same way here with 7.5svn release

GRASS 7.4.0 and GRASS trunk seems to behave differently in set up this

incomplete CRS in this case.

I can not confirm, because …

GRASS 7.4.0 produces:

g.proj -p
-PROJ_INFO-------------------------------------------------
name : unnamed
ellps : grs80
proj : lcc
lat_1 : 43
lat_2 : 45.5
lat_0 : 41.75
lon_0 : -120.5
x_0 : 399999.9999999999
y_0 : 0
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : user-defined
units : user-defineds
meters : 0.3048

while trunk produces
-PROJ_INFO-------------------------------------------------
name : unnamed
ellps : grs80
proj : lcc
lat_1 : 43
lat_2 : 45.5
lat_0 : 41.75
lon_0 : -120.5
x_0 : 399999.9999999999
y_0 : 0
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : International Foot
units : International Feet
meters : 0.3048

identical, only that trunk is able to resolve the name of the unit

despite the name, the CRS looks ok.

I agree, projection information is recognized.

Apparently GDAL uses the projection information embedded in the dataset. I guess because GDAL finds some info, it does not look further in the .aux.xml file (no need to do so).

Markus M

looking at the gdalinfo output of the raster:

Min=206.380 Max=1157.470
NoData Value=-3.4028234663852886e+38

loading this raster data into e.g QGIS, it shows the same as in GRASS,

When I load that bare_earth raster map it’s the same as before: a
multicolored wedge along the north and a wide purple rectangle along the
west side (see attached).

most of the central part of the raster is NoData; thus it seems to be ok as
it is.

further steps may be:

(1) ask your data provider for data with a complete SRS information
(2) ask on the GDAL ML if it is maybe a GDAL issue about the SRS information
(3) ask your data provider if it is correct that most of the raster is
NoData

best regards
Helmut

Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

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

9

On Mon, 11 Jun 2018, Helmut Kudrnovsky wrote:

>Min=206.380 Max=1157.470
>NoData Value=-3.4028234663852886e+38

most of the central part of the raster is NoData; thus it seems to be ok
as it is.

Helmut,

   This is a problem. I know from driving a lot of the area covered by this
map that it actually has elevation and is quite variable, as shown by the
range you posted.

further steps may be:

(1) ask your data provider for data with a complete SRS information
(2) ask on the GDAL ML if it is maybe a GDAL issue about the SRS information
(3) ask your data provider if it is correct that most of the raster is
NoData

   I'll do the last suggestion. And, I have two other data sets (from 2009
and 2011) I can try. The one we've examined is from 2014.

Thanks,

Rich

10

I can not confirm, because ...

[...]

identical, only that trunk is able to resolve the name of the unit

what I can observe here with

GRASS version: 7.5.svn
GRASS SVN revision: r72772
Build date: 2018-06-06
Build platform: x86_64-w64-mingw32
GDAL: 2.2.3
PROJ.4: 4.9.3
GEOS: 3.5.0
SQLite: 3.17.0
Python: 2.7.5
wxPython: 2.8.12.1
Platform: Windows-8-6.2.9200 (OSGeo4W)

startup GUI -> new location -> read projection and datum terms from a
georeferenced data file -> then reference to
D:\temp\rich\Bare_Earth\bh45122c3\hdr.adf

no SRS information is reckognized at, new location can't be build. and I
can't import the raster data by r.in.gdal.

whereas both above works in winGRASS 7.4.0

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

11

On Mon, 11 Jun 2018, Helmut Kudrnovsky wrote:

what I can observe here with

   ...

no SRS information is reckognized at, new location can't be build. and I
can't import the raster data by r.in.gdal.

whereas both above works in winGRASS 7.4.0

Helmut,

   It's apparently not the platform but the grass version of r.in.gdal. It's
better to identify issues in 7.5 sooner rather than later. Tripping over
these issues is my contribution to development. :slight_smile:

   I'll try the other two sets of LiDAR data for this area today and report
the results here.

   Thanks for confirming.

Best regards,

Rich

12

On Mon, 11 Jun 2018, Rich Shepard wrote:

I'll try the other two sets of LiDAR data for this area today and report
the results here.

   With a different data set, 2013_OLC_Clackamol, r.in.gdal with gdal-2.3.0
and grass7.5svn still does not properly set the SRS/CRS. The output,
however, is a vertical wedge rather than the horizontal wedge with a wide
retangular band produced by the 2014 data set. New image attached.

Rich

(attachments)

bareearth_2013.png

13

On Mon, Jun 11, 2018 at 3:05 PM, Helmut Kudrnovsky <hellik@web.de> wrote:

I can not confirm, because …
[…]
identical, only that trunk is able to resolve the name of the unit

what I can observe here with

GRASS version: 7.5.svn
GRASS SVN revision: r72772
Build date: 2018-06-06
Build platform: x86_64-w64-mingw32
GDAL: 2.2.3
PROJ.4: 4.9.3
GEOS: 3.5.0
SQLite: 3.17.0
Python: 2.7.5
wxPython: 2.8.12.1
Platform: Windows-8-6.2.9200 (OSGeo4W)

startup GUI → new location → read projection and datum terms from a
georeferenced data file → then reference to
D:\temp\rich\Bare_Earth\bh45122c3\hdr.adf

no SRS information is reckognized at, new location can’t be build. and I
can’t import the raster data by r.in.gdal.

strange, works for me on Linux.

can you provide the winGRASS 7.5 output of
g.proj georef=D:\temp\rich\Bare_Earth\bh45122c3\hdr.adf -p
and
g.proj georef=D:\temp\rich\Bare_Earth\bh45122c3 -p

thanks!

gdalinfo reports as SRS

PROJCS[“unnamed”,
GEOGCS[“Unknown datum based upon the GRS 1980 ellipsoid”,
DATUM[“Not_specified_based_on_GRS_1980_ellipsoid”,
SPHEROID[“GRS 1980”,6378137,298.257222101,
AUTHORITY[“EPSG”,“7019”]],
AUTHORITY[“EPSG”,“6019”]],
PRIMEM[“Greenwich”,0,
AUTHORITY[“EPSG”,“8901”]],
UNIT[“degree”,0.0174532925199433,
AUTHORITY[“EPSG”,“9122”]],
AUTHORITY[“EPSG”,“4019”]],
PROJECTION[“Lambert_Conformal_Conic_2SP”],
PARAMETER[“standard_parallel_1”,43],
PARAMETER[“standard_parallel_2”,45.5],
PARAMETER[“latitude_of_origin”,41.75],
PARAMETER[“central_meridian”,-120.5],
PARAMETER[“false_easting”,1312335.958005249],
PARAMETER[“false_northing”,0],
UNIT[“user-defined”,0.3048]]

which is ok.

I’m using gdal-2.3.0 and proj-5.1.0

Markus M

whereas both above works in winGRASS 7.4.0

best regards
Helmut

Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

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

14

strange, works for me on Linux.

can you provide the winGRASS 7.5 output of
g.proj georef=D:\temp\rich\Bare_Earth\bh45122c3\hdr.adf -p
and
g.proj georef=D:\temp\rich\Bare_Earth\bh45122c3 -p

------------------------------------------------
System Info
GRASS version: 7.4.0
GRASS SVN revision: r72154
Build date: 2018-01-27
Build platform: x86_64-w64-mingw32
GDAL: 2.2.3
PROJ.4: 4.9.3
GEOS: 3.5.0
SQLite: 3.17.0
Python: 2.7.5
wxPython: 2.8.12.1
Platform: Windows-8-6.2.9200 (OSGeo4W)

g.proj -p georef=D:\temp\rich\bareearth\Bare_Earth\bh45122c3
-PROJ_INFO-------------------------------------------------
name : unnamed
ellps : grs80
proj : lcc
lat_1 : 43
lat_2 : 45.5
lat_0 : 41.75
lon_0 : -120.5
x_0 : 399999.9999999999
y_0 : 0
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : user-defined
units : user-defineds
meters : 0.3048
Trying to open with OGR...
Trying to open with GDAL...
...succeeded.
WARNING: Datum <Not_specified_based_on_GRS_1980_ellipsoid> not recognised by
GRASS and no parameters found

----------------

g.proj -p georef=D:\temp\rich\bareearth\Bare_Earth\bh45122c3\hdr.adf
Trying to open with OGR...
Trying to open with GDAL...
...succeeded.
WARNING: Datum <Not_specified_based_on_GRS_1980_ellipsoid> not recognised by
GRASS and no parameters found
-PROJ_INFO-------------------------------------------------
name : unnamed
ellps : grs80
proj : lcc
lat_1 : 43
lat_2 : 45.5
lat_0 : 41.75
lon_0 : -120.5
x_0 : 399999.9999999999
y_0 : 0
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : user-defined
units : user-defineds
meters : 0.3048
------------------------------------------------

GRASS version: 7.5.svn
GRASS SVN revision: r72772
Build date: 2018-06-06
Build platform: x86_64-w64-mingw32
GDAL: 2.2.3
PROJ.4: 4.9.3
GEOS: 3.5.0
SQLite: 3.17.0
Python: 2.7.5
wxPython: 2.8.12.1
Platform: Windows-8-6.2.9200 (OSGeo4W)

----------------

g.proj -p georef=D:\temp\rich\bareearth\Bare_Earth\bh45122c3
(Mon Jun 11 19:39:41 2018) Command finished (2 sec)

----------------

g.proj -p georef=D:\temp\rich\bareearth\Bare_Earth\bh45122c3\hdr.adf
(Mon Jun 11 19:40:49 2018) Command finished (4 sec)

----------------

now DEBUG=3 in 7.5.svn

----------------

g.proj -p georef=D:\temp\rich\bareearth\Bare_Earth\bh45122c3\hdr.adf
D1/3: G_set_program_name(): g.proj
D1/3: Trying to open
<D:\temp\rich\bareearth\Bare_Earth\bh45122c3\hdr.adf> with
OGR...
D1/3: Trying to open with GDAL...
D1/3: ...succeeded.
D3/3: DatumNameMassage: Raw string found
<Not_specified_based_on_GRS_1980_ellipsoid>
D3/3: DatumNameMassage: Search for datum equivalences of
<Not_specified_based_on_GRS_1980_ellipsoid>
D3/3: GPJ_osr_to_grass: pszDatumNameConst:
<Not_specified_based_on_GRS_1980_ellipsoid>
(Mon Jun 11 19:42:53 2018) Command finished (4 sec)

----------------

g.proj -p georef=D:\temp\rich\bareearth\Bare_Earth\bh45122c3
D1/3: G_set_program_name(): g.proj
D1/3: Trying to open
<D:\temp\rich\bareearth\Bare_Earth\bh45122c3> with OGR...
D1/3: Trying to open with GDAL...
D1/3: ...succeeded.
D3/3: DatumNameMassage: Raw string found
<Not_specified_based_on_GRS_1980_ellipsoid>
D3/3: DatumNameMassage: Search for datum equivalences of
<Not_specified_based_on_GRS_1980_ellipsoid>
D3/3: GPJ_osr_to_grass: pszDatumNameConst:
<Not_specified_based_on_GRS_1980_ellipsoid>

----------------

not much information.

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

15

On Mon, Jun 11, 2018 at 3:41 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:

On Mon, 11 Jun 2018, Helmut Kudrnovsky wrote:

what I can observe here with

…

no SRS information is reckognized at, new location can’t be build. and I
can’t import the raster data by r.in.gdal.

whereas both above works in winGRASS 7.4.0

Helmut,

It’s apparently not the platform but the grass version of r.in.gdal. It’s
better to identify issues in 7.5 sooner rather than later. Tripping over

these issues is my contribution to development. :slight_smile:

But you succeeded with importing the data with r.in.gdal. They are not what you expected, though. As Helmut suggested,

(3) ask your data provider if it is correct that most of the raster is
NoData

Markus M

I’ll try the other two sets of LiDAR data for this area today and report
the results here.

Thanks for confirming.

Best regards,

Rich

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

16

On Mon, 11 Jun 2018, Markus Metz wrote:

But you succeeded with importing the data with r.in.gdal. They are not
what you expected, though. As Helmut suggested,

Markus,

   Well, not correctly.

(3) ask your data provider if it is correct that most of the raster is
NoData

   Have you seen a topographic map that has no data in most of its coverage?
On paper it would be mostly blank. No, the correct data are there but not
being correctly imported into grass here.

   As the provider noted in a message to me this morning they use AIG for all
LiDAR data. My response to him was that the data for a different county I
downloaded two years ago were in a .gdb file, not .adf files. No response
yet.

Regards,

Rich

17

On Mon, Jun 11, 2018 at 9:50 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:

On Mon, 11 Jun 2018, Markus Metz wrote:

But you succeeded with importing the data with r.in.gdal. They are not
what you expected, though. As Helmut suggested,

Markus,

Well, not correctly.

(3) ask your data provider if it is correct that most of the raster is
NoData

Have you seen a topographic map that has no data in most of its coverage?

Regarding LiDAR data, yes. LiDAR data are typically recorded in stripes which matches the data you have been provided.

On paper it would be mostly blank. No, the correct data are there but not
being correctly imported into grass here.

As the provider noted in a message to me this morning they use AIG for all
LiDAR data. My response to him was that the data for a different county I
downloaded two years ago were in a .gdb file, not .adf files. No response

yet.

(3) ask your data provider if it is correct that most of the raster is
NoData

Markus M

Regards,

Rich

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

18

On Mon, 11 Jun 2018, Markus Metz wrote:

strange, works for me on Linux.

   To cover all bases, I checked out the most recent 7.4svn code, configured,
built, and installed it. v.in.gdal produces the same partial map as it did
with 7.5svn. On linux.

   Helmut wrote that on his win8 host it built and displayed properly. Since
that's the same set of AIG files as we're all using the issue is not likely
to be empty cells for 80% of the coverage, but something ... somewhere ...
in the code that's blocking proper operation here.

   Tomorrow I'll try both grass versions on a Slackware-14.2/x86_64 host.

Rich

19

Dear Heidi,

On Mon, Jun 11, 2018 at 8:11 AM, Heidi Trimmel <heidelinde.trimmel@boku.ac.at> wrote:

Dear Grass-users,

I have problems using d.rast.edit. In the archived mails I only found
that there is a problem using NULL values (*). I cannot save my edits
regardless which values I enter.
I tried using the command line, the GUI, having the rasters I edit in
the display and not having it in the display - without any effect. I am
not using aspect maps.
I installed the latest grass version last week (win7,64bit).

I have tried it (successfully) using the North Carolina sample data, on Linux:

GRASS 7.4.1svn (nc_spm_08_grass7):~ >

g.region raster=elev_lid792_1m -p
…

open graphical monitor on cmd line, the same should work via g.gui

d.mon wx0
d.rast elev_lid792_1m

pan to area of interest and edit raster cells (I used “102” as value to modifiy cells

Use: File > Save to save

then: File > Exit

d.rast.edit input=elev_lid792_1m output=elev_lid792_1m_modified
/home/mneteler/software/grass74/dist.x86_64-pc-linux-gnu/scripts/d.rast.edit:211: wxPyDeprecationWarning: Call to deprecated item.
self.SetVirtualSizeHints(50, 50)
WARNING: No data base element files found

original stats, note the min value

r.univar -g elev_lid792_1m
n=525000
null_cells=0
cells=525000
min=103.764259338379
max=131.598037719727
range=27.8337783813477
mean=120.768608856928
…

modified map stats, note the min value

r.univar -g elev_lid792_1m_modified
n=525000
null_cells=0
cells=525000
min=103.764259338379
max=131.598037719727
range=27.8337783813477

mean=120.768608856928
…

IMPORTANT: hit “enter” when editing the “New value: ___” field. That’s of course a suboptimal solution, I’ll open a ticket for this.

HTH,

Markus

20

On Sun, Jun 24, 2018 at 11:36 AM, Markus Neteler <neteler@osgeo.org> wrote:

On Mon, Jun 11, 2018 at 8:11 AM, Heidi Trimmel <heidelinde.trimmel@boku.ac.at> wrote:
> Dear Grass-users,
>
> I have problems using d.rast.edit.

I have tried more and opened a ticket:
https://trac.osgeo.org/grass/ticket/3595

Workaround:

IMPORTANT: hit "enter" when editing the "New value: ___" field.

Now also the manual is updated accordingly (lots of old stuff therein
cleanup up + screenshot added).
It will be online in 30 min from now:

https://grass.osgeo.org/grass74/manuals/d.rast.edit.html

Best,
Markus

--
Markus Neteler, PhD
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog