I do a lot of work with UK LIDAR data and one of the most frequently used, and useful, GRASS routines for my work is r.contour. I am currently using GRASS through QGIS 3.4.12 and the associated version of GRASS is 7.6.1. I have made a couple of attempts to upgrade my QGIS version to a more recent one but this always results in a different version of GRASS which does not allow r.contour to work with the LIDAR files.
QGIS 3.4 opens LIDAR tif files directly using EPSG:27700 as the CRS. Later versions of QGIS seem to require, or at least suggest, a transformation to an alternative CRS. Whether I use one of these transformations or not, the initial error I receive when running r.contour is “WARNING: Datum <Unknown_based_on_Airy_1830_ellipsoid> not recognised by GRASS and no parameters found”. Other errors follow and finally there is a message to say that the routine has failed. I think that all the versions of GRASS which have generated this error are 7.8.
I would like to upgrade my version of QGIS to a later version but am stuck with 3.4 because of my need for a functioning r.contour. QGIS contains a similar contour-drawing option but it does not allow the specification of upper and lower height limits and so can take a very long time to run on large files.
Hello Dave,
r.contour should be working just fine. Your posted Warning is
harmless. Please try to run it in a pure GRASS session and not through
QGIS – in case of failure, it will be possible to get a reasonable
error message.
As for upgrading of GRASS – be ware – LiDAR tools depend on libLAS
that has been deprecated and is not shipped in most of recent Linux
distributions. Thus working with LAS files might be impossible at all.
There are planned new LiDAR tools based on PDAL in GRASS 8.
Māris.
2021-02-11 23:38 GMT+02:00, Dave Marshall <43carnaby@gmail.com>:
Hello,
I do a lot of work with UK LIDAR data and one of the most frequently used,
and useful, GRASS routines for my work is r.contour. I am currently using
GRASS through QGIS 3.4.12 and the associated version of GRASS is 7.6.1. I
have made a couple of attempts to upgrade my QGIS version to a more recent
one but this always results in a different version of GRASS which does not
allow r.contour to work with the LIDAR files.
QGIS 3.4 opens LIDAR tif files directly using EPSG:27700 as the CRS. Later
versions of QGIS seem to require, or at least suggest, a transformation to
an alternative CRS. Whether I use one of these transformations or not, the
initial error I receive when running r.contour is "WARNING: Datum
<Unknown_based_on_Airy_1830_ellipsoid> not recognised by GRASS and no
parameters found". Other errors follow and finally there is a message to
say that the routine has failed. I think that all the versions of GRASS
which have generated this error are 7.8.
I would like to upgrade my version of QGIS to a later version but am stuck
with 3.4 because of my need for a functioning r.contour. QGIS contains a
similar contour-drawing option but it does not allow the specification of
upper and lower height limits and so can take a very long time to run on
large files.
Thanks for the advice. Note that I am running QGIS in Windows, not Linux. I managed to open GRASS 7.8.5 directly, load a LIDAR file and run r.contour but I’m not at all familiar with running the programme this way. The LIDAR didn’t load with the correct CRS and although r.contour seemed to run properly according to the command output, no lines appeared on the image as they do in QGIS. I suspect that I need some of the functionality in QGIS than I can’t get from GRASS alone so this may not be a way forward for me.
Hello Dave,
r.contour should be working just fine. Your posted Warning is
harmless. Please try to run it in a pure GRASS session and not through
QGIS – in case of failure, it will be possible to get a reasonable
error message.
As for upgrading of GRASS – be ware – LiDAR tools depend on libLAS
that has been deprecated and is not shipped in most of recent Linux
distributions. Thus working with LAS files might be impossible at all.
There are planned new LiDAR tools based on PDAL in GRASS 8.
I do a lot of work with UK LIDAR data and one of the most frequently used,
and useful, GRASS routines for my work is r.contour. I am currently using
GRASS through QGIS 3.4.12 and the associated version of GRASS is 7.6.1. I
have made a couple of attempts to upgrade my QGIS version to a more recent
one but this always results in a different version of GRASS which does not
allow r.contour to work with the LIDAR files.
QGIS 3.4 opens LIDAR tif files directly using EPSG:27700 as the CRS. Later
versions of QGIS seem to require, or at least suggest, a transformation to
an alternative CRS. Whether I use one of these transformations or not, the
initial error I receive when running r.contour is “WARNING: Datum
<Unknown_based_on_Airy_1830_ellipsoid> not recognised by GRASS and no
parameters found”. Other errors follow and finally there is a message to
say that the routine has failed. I think that all the versions of GRASS
which have generated this error are 7.8.
I would like to upgrade my version of QGIS to a later version but am stuck
with 3.4 because of my need for a functioning r.contour. QGIS contains a
similar contour-drawing option but it does not allow the specification of
upper and lower height limits and so can take a very long time to run on
large files.
Hello Dave,
QGIS hides a bit of GRASS complexity by making a guess for various
parameters. As with any guess – sometimes it works, sometimes it is a
miss (and user has no idea which is the case).
To get contours out of LAS files:
1) create a location with coordinate system matching one used by LAS
files (be ware – you might need to know it in advance from metadata as
LAS files quite often lack this information);
2) create a mapset for the area of interest (could be whole region or
a single file in case of parallel processing);
3) start GRASS in newly created mapset;
4) set up your computational region (this is most important part!)
with g.region. Don't forget to choose appropriate resolution.
a) if you know the extent in advance (e.g. from a map sheet grid) use that;
b) if you don't know the extent in advance, use actual extent from the
LAS file. I would advocate to use r.in.lidar -s and set the extent
manually with g.region – you can “snap“ your raster to coordinates.
5) import data with r.in.lidar;
6) run r.contour on the map;
7) export with v.out.ogr to Shapefile (#teamshapefile).
Good luck,
Māris.
P.S. When you wander into area of 66000 LAS files occupying nice 14T
on your disk, only a few adjustments need to be done + a bit of Python
coding + a bit of cluster management
Many thanks for your detailed reply. My LIDAR files are not in LAS format - they are a mixture of ASC and TIF.
I spent a long time learning how to use QGIS and don’t want to have to repeat the process with GRASS unless I have to. If there isn’t a simple way to get r.contour to work from within the later versions of QGIS, then I’ll keep on using the old version as the solution requiring the least effort. From your comments, it would seem that it is how QGIS imports the LIDAR data which has changed and this is why I see the problem I reported. I also realise that QGIS is a global application whereas my work is restricted to the UK using the Ordnance Survey grid so I can’t expect a huge resource to look at a narrow application.
Hello Dave,
QGIS hides a bit of GRASS complexity by making a guess for various
parameters. As with any guess – sometimes it works, sometimes it is a
miss (and user has no idea which is the case).
To get contours out of LAS files:
create a location with coordinate system matching one used by LAS
files (be ware – you might need to know it in advance from metadata as
LAS files quite often lack this information);
create a mapset for the area of interest (could be whole region or
a single file in case of parallel processing);
start GRASS in newly created mapset;
set up your computational region (this is most important part!)
with g.region. Don’t forget to choose appropriate resolution.
a) if you know the extent in advance (e.g. from a map sheet grid) use that;
b) if you don’t know the extent in advance, use actual extent from the
LAS file. I would advocate to use r.in.lidar -s and set the extent
manually with g.region – you can “snap“ your raster to coordinates.
import data with r.in.lidar;
run r.contour on the map;
export with v.out.ogr to Shapefile (#teamshapefile).
Good luck,
Māris.
P.S. When you wander into area of 66000 LAS files occupying nice 14T
on your disk, only a few adjustments need to be done + a bit of Python
coding + a bit of cluster management
Hello Dave,
your case is even easier – TIFF and ASC both are raster formats and
thus it is a simple task: import -> contour -> export (skipping all
point cloud related tweaking).
Create a new location. Either select coordinate system directly or use
one from TIFF file. Import data with r.in.gdal – don't forget to
specify "-e" parameter – it will align the computational region with
the imported raster. Then proceed to use r.contour followed by
v.out.ogr.
In future – do not ask for help with LiDAR but ask for help with
raster data. Otherwise you'll get advices like you got from me – how
to work with point clouds although you are looking for how to work
with ordinary rasters.
Māris.
2021-02-15 22:58 GMT+02:00, Dave Marshall <43carnaby@gmail.com>:
Maris,
Many thanks for your detailed reply. My LIDAR files are not in LAS format -
they are a mixture of ASC and TIF.
I spent a long time learning how to use QGIS and don't want to have to
repeat the process with GRASS unless I have to. If there isn't a simple way
to get r.contour to work from within the later versions of QGIS, then I'll
keep on using the old version as the solution requiring the least effort.
From your comments, it would seem that it is how QGIS imports the LIDAR
data which has changed and this is why I see the problem I reported. I also
realise that QGIS is a global application whereas my work is restricted to
the UK using the Ordnance Survey grid so I can't expect a huge resource to
look at a narrow application.
Cheers,
Dave
On Mon, 15 Feb 2021 at 10:08, Maris Nartiss <maris.gis@gmail.com> wrote:
Hello Dave,
QGIS hides a bit of GRASS complexity by making a guess for various
parameters. As with any guess – sometimes it works, sometimes it is a
miss (and user has no idea which is the case).
To get contours out of LAS files:
1) create a location with coordinate system matching one used by LAS
files (be ware – you might need to know it in advance from metadata as
LAS files quite often lack this information);
2) create a mapset for the area of interest (could be whole region or
a single file in case of parallel processing);
3) start GRASS in newly created mapset;
4) set up your computational region (this is most important part!)
with g.region. Don't forget to choose appropriate resolution.
a) if you know the extent in advance (e.g. from a map sheet grid) use
that;
b) if you don't know the extent in advance, use actual extent from the
LAS file. I would advocate to use r.in.lidar -s and set the extent
manually with g.region – you can “snap“ your raster to coordinates.
5) import data with r.in.lidar;
6) run r.contour on the map;
7) export with v.out.ogr to Shapefile (#teamshapefile).
Good luck,
Māris.
P.S. When you wander into area of 66000 LAS files occupying nice 14T
on your disk, only a few adjustments need to be done + a bit of Python
coding + a bit of cluster management
Hello Dave,
your case is even easier – TIFF and ASC both are raster formats and
thus it is a simple task: import -> contour -> export (skipping all
point cloud related tweaking).
I’d like to just back what Maris already suggested: Try working directly in GRASS. It does have a somewhat steep learning curve at the beginning, but if you stick with it, you’ll find in the long run that it pays (“with interest”). You’ll be able to perform complex analyses on multiple maps relatively easily.
For example, if you post the name of the Lidar based elevation raster that you have, someone on the list will probably help to format the commands that Maris listed above into a detailed recipe to get elevation contours.
Create a new location. Either select coordinate system directly or use
one from TIFF file. Import data with r.in.gdal – don't forget to
specify "-e" parameter – it will align the computational region with
the imported raster. Then proceed to use r.contour followed by
v.out.ogr.
In future – do not ask for help with LiDAR but ask for help with
raster data. Otherwise you'll get advices like you got from me – how
to work with point clouds although you are looking for how to work
with ordinary rasters.
Māris.
2021-02-15 22:58 GMT+02:00, Dave Marshall [<43carnaby@gmail.com>](mailto:43carnaby@gmail.com):
Maris,
Many thanks for your detailed reply. My LIDAR files are not in LAS format -
they are a mixture of ASC and TIF.
I spent a long time learning how to use QGIS and don't want to have to
repeat the process with GRASS unless I have to. If there isn't a simple way
to get r.contour to work from within the later versions of QGIS, then I'll
keep on using the old version as the solution requiring the least effort.
>From your comments, it would seem that it is how QGIS imports the LIDAR
data which has changed and this is why I see the problem I reported. I also
realise that QGIS is a global application whereas my work is restricted to
the UK using the Ordnance Survey grid so I can't expect a huge resource to
look at a narrow application.
Cheers,
Dave
On Mon, 15 Feb 2021 at 10:08, Maris Nartiss [<maris.gis@gmail.com>](mailto:maris.gis@gmail.com) wrote:
Hello Dave,
QGIS hides a bit of GRASS complexity by making a guess for various
parameters. As with any guess – sometimes it works, sometimes it is a
miss (and user has no idea which is the case).
To get contours out of LAS files:
1) create a location with coordinate system matching one used by LAS
files (be ware – you might need to know it in advance from metadata as
LAS files quite often lack this information);
2) create a mapset for the area of interest (could be whole region or
a single file in case of parallel processing);
3) start GRASS in newly created mapset;
4) set up your computational region (this is most important part!)
with g.region. Don't forget to choose appropriate resolution.
a) if you know the extent in advance (e.g. from a map sheet grid) use
that;
b) if you don't know the extent in advance, use actual extent from the
LAS file. I would advocate to use r.in.lidar -s and set the extent
manually with g.region – you can “snap“ your raster to coordinates.
5) import data with r.in.lidar;
6) run r.contour on the map;
7) export with v.out.ogr to Shapefile (#teamshapefile).
Good luck,
Māris.
P.S. When you wander into area of 66000 LAS files occupying nice 14T
on your disk, only a few adjustments need to be done + a bit of Python
coding + a bit of cluster management :D
_______________________________________________
grass-user mailing list
[grass-user@lists.osgeo.org](mailto:grass-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/grass-user](https://lists.osgeo.org/mailman/listinfo/grass-user)
Thanks to both of you for your help and suggestions. I had a go with GRASS this evening and managed to load a LIDAR tif file (NT02SW_50CM_DTM_PHASE3.tif) and run r.contour although I couldn’t get the output to appear on the raster image. Some of the key tasks I need to be able to do are to add grid lines, colour the images based on height in a flexible way, subtract one raster image from another and to be able to overlay the contours generated on a satellite image such as Google Earth. I suspect that all this can be done using GRASS directly but assuming it can be, I’m no further forward than I am at the moment using r.contour via QGIS so I’m not sure that taking the time to learn GRASS will be worthwhile having spent several months learning QGIS. The only really useful feature for my work which QGIS doesn’t provide is the ability to display the height values on the image on a square by square basis, as can be done if the file is loaded into Excel.
Cheers,
Dave
On Tue, 16 Feb 2021 at 09:58, Micha Silver <tsvibar@gmail.com> wrote:
On 2/16/21 10:30 AM, Maris Nartiss wrote:
Hello Dave,
your case is even easier – TIFF and ASC both are raster formats and
thus it is a simple task: import -> contour -> export (skipping all
point cloud related tweaking).
I’d like to just back what Maris already suggested: Try working directly in GRASS. It does have a somewhat steep learning curve at the beginning, but if you stick with it, you’ll find in the long run that it pays (“with interest”). You’ll be able to perform complex analyses on multiple maps relatively easily.
For example, if you post the name of the Lidar based elevation raster that you have, someone on the list will probably help to format the commands that Maris listed above into a detailed recipe to get elevation contours.
Create a new location. Either select coordinate system directly or use
one from TIFF file. Import data with r.in.gdal – don't forget to
specify "-e" parameter – it will align the computational region with
the imported raster. Then proceed to use r.contour followed by
v.out.ogr.
In future – do not ask for help with LiDAR but ask for help with
raster data. Otherwise you'll get advices like you got from me – how
to work with point clouds although you are looking for how to work
with ordinary rasters.
Māris.
2021-02-15 22:58 GMT+02:00, Dave Marshall [<43carnaby@gmail.com>](mailto:43carnaby@gmail.com):
Maris,
Many thanks for your detailed reply. My LIDAR files are not in LAS format -
they are a mixture of ASC and TIF.
I spent a long time learning how to use QGIS and don't want to have to
repeat the process with GRASS unless I have to. If there isn't a simple way
to get r.contour to work from within the later versions of QGIS, then I'll
keep on using the old version as the solution requiring the least effort.
>From your comments, it would seem that it is how QGIS imports the LIDAR
data which has changed and this is why I see the problem I reported. I also
realise that QGIS is a global application whereas my work is restricted to
the UK using the Ordnance Survey grid so I can't expect a huge resource to
look at a narrow application.
Cheers,
Dave
On Mon, 15 Feb 2021 at 10:08, Maris Nartiss [<maris.gis@gmail.com>](mailto:maris.gis@gmail.com) wrote:
Hello Dave,
QGIS hides a bit of GRASS complexity by making a guess for various
parameters. As with any guess – sometimes it works, sometimes it is a
miss (and user has no idea which is the case).
To get contours out of LAS files:
1) create a location with coordinate system matching one used by LAS
files (be ware – you might need to know it in advance from metadata as
LAS files quite often lack this information);
2) create a mapset for the area of interest (could be whole region or
a single file in case of parallel processing);
3) start GRASS in newly created mapset;
4) set up your computational region (this is most important part!)
with g.region. Don't forget to choose appropriate resolution.
a) if you know the extent in advance (e.g. from a map sheet grid) use
that;
b) if you don't know the extent in advance, use actual extent from the
LAS file. I would advocate to use r.in.lidar -s and set the extent
manually with g.region – you can “snap“ your raster to coordinates.
5) import data with r.in.lidar;
6) run r.contour on the map;
7) export with v.out.ogr to Shapefile (#teamshapefile).
Good luck,
Māris.
P.S. When you wander into area of 66000 LAS files occupying nice 14T
on your disk, only a few adjustments need to be done + a bit of Python
coding + a bit of cluster management :D
_______________________________________________
grass-user mailing list
[grass-user@lists.osgeo.org](mailto:grass-user@lists.osgeo.org)
[https://lists.osgeo.org/mailman/listinfo/grass-user](https://lists.osgeo.org/mailman/listinfo/grass-user)
