Bug report #21925

GRASS r.in.lidar fails in QGIS but works in native GRASS

Added by Andreas Olsson over 5 years ago. Updated over 5 years ago.

Status:Open
Priority:Normal
Assignee:-
Category:Processing/GRASS
Affected QGIS version:3.6.2 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:29740

Description

File info pulled from LAS-file, using GRASS because that function doesn’t work in QGIS!

The data is in "SWEREF 99 18 00", a Swedish coordinatesystem.

Using LAS Library Version 'libLAS 1.8.0 with GeoTIFF 1.4.0 GDAL 1.11.3 LASzip 2.2.0'
LAS File Version: 1.2
System ID: 'Trimble'
Generating Software: 'TRW 2.21.0 2.2 r0 (130917)'
File Creation Day/Year: 234/2018
Point Data Format: 2
Number of Point Records: 126410605
Number of Points by Return: 126410605 0 0 0 0
Scale Factor X Y Z: 0.0001 0.0001 0.0001
Offset X Y Z: 149520 6.56859e+006 20
Min X Y Z: 148852 6.56773e+006 5.0197
Max X Y Z: 149927 6.56905e+006 80.8466
Spatial Reference: None
Data Fields:
'X'
'Y'
'Z'
'Intensity'
'Return Number'
'Number of Returns'
'Scan Direction'
'Flighline Edge'
'Classification'
'Scan Angle Rank'
'User Data'
'Point Source ID'
'Red'
'Green'
'Blue'

History

#1 Updated by Giovanni Manghi over 5 years ago

  • Status changed from Open to Feedback

Can you attach sample data?

#2 Updated by Andreas Olsson over 5 years ago

Giovanni Manghi wrote:

Can you attach sample data?

I got one file and it’s to big.

I think the problem can be that there’s no coordinate system info in the file and it works in GRASS because you set up a predefined file and coordinate system that GRASS can assume is the same system as the file. If it was possible to tell QGIS what coordinate system to assume is right then it might work.

#3 Updated by Andreas Olsson over 5 years ago

So I guess the problem is the lack of spatial reference in the file.

#4 Updated by Giovanni Manghi over 5 years ago

I got one file and it’s to big.

link?

#5 Updated by Andreas Olsson over 5 years ago

Giovanni Manghi wrote:

I got one file and it’s to big.

link?

https://sprend.com/download?C=e892a43de33f49b79b63c421e4a03ab8

#6 Updated by Giovanni Manghi over 5 years ago

What CRS do you use to create your GRASS mapset/location where this data import correctly?

#7 Updated by Andreas Olsson over 5 years ago

Giovanni Manghi wrote:

What CRS do you use to create your GRASS mapset/location where this data import correctly?

CRS
EPSG:3011 - SWEREF99 18 00 - Projected

I sett GRASS not to assume any CRS of the data.

#8 Updated by Giovanni Manghi over 5 years ago

I sett GRASS not to assume any CRS of the data.

that is not how Processing works when using GRASS tools: as far as I remember a temporary location/mapset is created on the fly while importing the data, and the CRS used is derived from the data itself. Is this the rule for any lidar data, they do not have an intrinsic CRS?

#9 Updated by Olivier ATHIMON over 5 years ago

Is it the same problem than i have ? => #21905

Before we could use functions of GRASS in Processing/GRASS by using the shortcut "QGIS Desktop"? But now, functions of Processing/GRASS only work by using the shortcut "QGIS Desktop with GRASS"...

#10 Updated by Andreas Olsson over 5 years ago

Giovanni Manghi wrote:

I sett GRASS not to assume any CRS of the data.

that is not how Processing works when using GRASS tools: as far as I remember a temporary location/mapset is created on the fly while importing the data, and the CRS used is derived from the data itself. Is this the rule for any lidar data, they do not have an intrinsic CRS?

I think the problem can be that Grass att least needs to know the project CRS to convert the LASfile. Do QGIS create a temporary database/project when processing?

#11 Updated by Giovanni Manghi over 5 years ago

Olivier ATHIMON wrote:

Is it the same problem than i have ? => #21905

no, I think the above ticket was already given and answer.

#12 Updated by Giovanni Manghi over 5 years ago

Do QGIS create a temporary database/project when processing?

yes, it creates on the fly a mapset/location where it (on the fly) imports the input data, then it process it and export out from the location/mapset. I think it uses the CRS of the input to define the projection for the mapset/location.

#13 Updated by Andreas Olsson over 5 years ago

Giovanni Manghi wrote:

Do QGIS create a temporary database/project when processing?

yes, it creates on the fly a mapset/location where it (on the fly) imports the input data, then it process it and export out from the location/mapset. I think it uses the CRS of the input to define the projection for the mapset/location.

Maybe you could have a optional setting for overriding the files crs?

#14 Updated by Giovanni Manghi over 5 years ago

Maybe you could have a optional setting for overriding the files crs?

that would be a feature request.

#15 Updated by Andreas Olsson over 5 years ago

Giovanni Manghi wrote:

Maybe you could have a optional setting for overriding the files crs?

that would be a feature request.

Or a solution to the bug.

#16 Updated by Giovanni Manghi over 5 years ago

  • Subject changed from GRASS r.in.lidar fail i QGIS but works in plain GRASS to GRASS r.in.lidar fails in QGIS but works in native GRASS
  • Status changed from Feedback to Open
  • Operating System deleted (Win 10)

#17 Updated by Andreas Olsson over 5 years ago

“
-o
Override projection check (use current location's projection)
Assume that the dataset has same projection as the current location
“
This option is also in QGIS for r.in.lidar but it needs to know the project crs to actually work.

#18 Updated by Giovanni Manghi over 5 years ago

This option is also in QGIS for r.in.lidar but it needs to know the project crs to actually work.

That GRASS options assumes that the data CRS is the same as the mapset/location (that aleady exist). In QGIS the CRS for mapset/location (that does not exist yet) is derived from the data being used as input (again, I think bit not 100% sure).

Also available in: Atom PDF