Re: [GRASS-user] v.surf.idw Not Working
I tried with your shapefile, and got no errors. Here are the steps... First I created a new GRASS location matching the CRS of the shapefile: grass -c Coal-Test-Shapefile-main/coal_test.shp /home/micha/GIS/grass/michaela Check the projection: g.proj -p -PROJ_INFO- name : RD/83 / 3-degree Gauss-Kruger zone 5 ellps : bessel proj : tmerc lat_0 : 0 lon_0 : 15 k : 1 x_0: 550 y_0: 0 no_defs: defined -PROJ_EPSG- epsg : 3399 -PROJ_UNITS unit : meter units : meters meters : 1 Then I imported your shapefile, and *set the computational region*: v.import Coal-Test-Shapefile-main/coal_test.shp output=coal_test g.region -ap vect=coal_test # Resolution is 1 meter, 1500x1500 pixels Now run the IDW module v.surf.idw input=coal colu=dbl_1 out=coal_idw_1 81 points loaded Interpolating raster map (1500 rows, 1500 columns)... 100% v.surf.idw complete. Resulting image is attached. You can try other options to v.surf.idw to get a smoother interpolation, if necessary. HTH On Fri, Feb 12, 2021 at 8:35 PM Michaela Lobato wrote: > Hi Markus, > > Here is the information: > > v.info -c map=coal_test@PERMANENT > > INTEGER|cat > INTEGER|cat_ > INTEGER|int_1 > INTEGER|int_2 > DOUBLE PRECISION|dbl_1 > DOUBLE PRECISION|dbl_2 > DOUBLE PRECISION|dbl_3 > DOUBLE PRECISION|dbl_4 > DOUBLE PRECISION|dbl_5 > Displaying column types/names for database connection of layer <1>: > > > v.info -t map=coal_test@PERMANENT > > nodes=0 > points=96 > lines=0 > boundaries=0 > centroids=0 > areas=0 > islands=0 > primitives=96 > map3d=0 > > You can also find the file here > https://github.com/amlobat2/Coal-Test-Shapefile. Let me know if you need > any additional information. > > Best, > Michaela > > > On Fri, Feb 12, 2021 at 3:29 AM Markus Neteler wrote: > >> Hi Michaela, >> >> On Thu, Feb 11, 2021 at 11:47 PM Michaela Lobato >> wrote: >> > >> > Hello, >> > >> > I have recently been struggling with an issue in GRASS. I am a new >> GRASS user and recently downloaded version 7.8.5 for my MacBook (macOS >> Catalina). I converted this sample dataset to a shapefile. >> >> Could you make this shapefile available? Or post the data structure? >> >> # attribute table structure >> v.info -c coal_test >> >> # vector types >> v.info -t coal_test >> >> ? >> >> Best, >> Markus >> > > > -- > A. Michaela Lobato > BS Systems Engineering and Design | Autonomous Systems and Robotics | > December 2019 > MS Systems and Entrepreneurial Engineering | Decision and Control | In > Progress > Email: amlob...@illinois.edu | Cell: (815) 494- > > ___ > 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 (52) 3665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Creating a png file with multiple vector maps
Would this addon be useful?
https://grass.osgeo.org/grass78/manuals/addons/m.printws.html
On February 11, 2021 6:55:24 PM Chris Bartolomei via grass-user
wrote:
Good morning Anna,
It took quite a while of trial and error but I worked out a method that
kindof works:
First off - unless someone says otherwise, you can't use the PNG driver
(d.mon) method to overlay more than one polygon vector. Sorry - it just
doesn't work. You CAN use the ps.map method - that works really well
generating the image however it by default assumes you are printing on an
A4 piece of paper so there's all sorts of white space. The image is
centered at the top of this fictional piece of paper. In your postscript
rules file you can use the "maploc" command to position the image elsewhere
on the page. This is necessary because the next trick changes the paper
dimensions but it assumes the origin is the lower left corner and therefore
clips anything that is above the new dimensions. Back to postscript
commands in the rules file first though ... the ps.map maploc command uses
inches (why?? it should be points) so an A4 page is 8.27" x 11.69" points
are 1/72 of an inch thus 595p x 842p - it also has a default 36p margin
(0.5 inch). You'll need those numbers later. maploc also lets you set the
size of your image box: maploc {x offset from left edge} {y offset from
top} {width of box} {height of box} Note: this is all done via a BASH
script with GRASS 7.4 on Linux (RHEL 7), not python. This is my postscript
rules file:
maploc 0.1 6.815 6.5 4.875 #468p x 351p map box moved down towards the
bottom of the page
# note that if you push it too far down to where the box would run off the
bottom, the image is
# resized to fit on the page so do some testing to come up with the correct
values
# also I found the computational region controls the aspect ratio so
although I say
# 6.5 x 4.875 with the above maploc command, I got a 6.5 x 3.8 inch box.
border y # add a border to the map frame (box)
color 81:81:81 # shade of gray
end # end the border controls
vareas admin_area # top vector layer to display
layer 1 # attribute table to use
rgbcolumn area_color # name of column holding R:G:B values to fill the polygons
color 153:153:153 #boundary color
end # end the admin_area controls
vareas Country # this is the bottom vectors to display
color 210:210:210 #boundary color
fcolor 153:153:153 #fill color for all polygons
end # end the Country controls
Here's the command to run to generate the postscript file:
ps.map input=$HOME/ps_rules.txt out=$HOME/color_admin.ps --overwrite
To convert the postscript to PNG I had to use ghostscript - there are other
tools you can use though.
gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -r300 -dTextAlphaBits=4
-dGraphicsAlphaBits=4 -dDEVICEWIDTHPOINTS=473 -dDEVICEHEIGHTPOINTS=276
-dFIXEDMEDIA -dPSFitPage -sOutputFile=$HOME/color_admin.png -c
"<> setpagedevice" -f $HOME/color_admin.ps
So the above line needs some explaining
(http://www.ghostscript.com/doc/9.27/Use.htm) but in a nutshell, the
parameters to play with are first the Pageoffset [x y] values. They are in
points not inches ... 1/72 inch = 1 point ... remember the 1/2" margins?
the -34 gives me 2 points of white space to the left edge of the map frame,
the 78 I had to play with to push the map frame down to the right spot.
Next is the DEVICEWIDTHPOINTS and DEVICEHEIGHTPOINTS ... again in points
... this "trims" the paper to height and width ... set something then run
it and view the results. Adjust and run again until you get it correct.
It's a royal pain but it seems to work this way. It would sure be nice to
create a GRASS workspace file and just say "convert this workspace to an
image" with everything all laid out nicely - like Arc does exporting their
mxd map files...
I hope this helps someone !
:)
Chris
On Wednesday, February 10, 2021, 11:08:00 PM EST, Anna Petrášová
wrote:
On Tue, Feb 9, 2021 at 4:41 PM Chris Bartolomei wrote:
Hi Anna - thank you for the suggestion - I tried it but alas, still it only
outputs a single vector map (layer). I can get either the Country vector or
the admin_areas vector, but not both overlaid.
:(
Chris
I realized you are using both environmental variables and d.mon, that might
cause some issues, you use one or the other. So try to remove the lines
starting with d.mon.
Hope that helps,
Anna
On Tuesday, February 9, 2021, 1:20:52 PM EST, Anna Petrášová
wrote:
Hi,
On Tue, Feb 9, 2021 at 10:25 AM Chris Bartolomei via grass-user
wrote:
Good morning :)
I'm using GRASS 7.4.1 on a Linux cluster so I only have command-line
capability. I have two vector layers (a country boundary polygon and part
of an administrative area map - also polygons). I am trying to automate
creating a PNG file of the admin areas overlaying the country boundary
therefore all work has to be command-line (in a bash script). I've tried
this two ways - using the d.mon
Re: [GRASS-user] v.surf.idw Not Working
Hi Markus, Here is the information: v.info -c map=coal_test@PERMANENT INTEGER|cat INTEGER|cat_ INTEGER|int_1 INTEGER|int_2 DOUBLE PRECISION|dbl_1 DOUBLE PRECISION|dbl_2 DOUBLE PRECISION|dbl_3 DOUBLE PRECISION|dbl_4 DOUBLE PRECISION|dbl_5 Displaying column types/names for database connection of layer <1>: v.info -t map=coal_test@PERMANENT nodes=0 points=96 lines=0 boundaries=0 centroids=0 areas=0 islands=0 primitives=96 map3d=0 You can also find the file here https://github.com/amlobat2/Coal-Test-Shapefile. Let me know if you need any additional information. Best, Michaela On Fri, Feb 12, 2021 at 3:29 AM Markus Neteler wrote: > Hi Michaela, > > On Thu, Feb 11, 2021 at 11:47 PM Michaela Lobato > wrote: > > > > Hello, > > > > I have recently been struggling with an issue in GRASS. I am a new GRASS > user and recently downloaded version 7.8.5 for my MacBook (macOS > Catalina). I converted this sample dataset to a shapefile. > > Could you make this shapefile available? Or post the data structure? > > # attribute table structure > v.info -c coal_test > > # vector types > v.info -t coal_test > > ? > > Best, > Markus > -- A. Michaela Lobato BS Systems Engineering and Design | Autonomous Systems and Robotics | December 2019 MS Systems and Entrepreneurial Engineering | Decision and Control | In Progress Email: amlob...@illinois.edu | Cell: (815) 494- ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.surf.idw Not Working
Hi Michaela, On Thu, Feb 11, 2021 at 11:47 PM Michaela Lobato wrote: > > Hello, > > I have recently been struggling with an issue in GRASS. I am a new GRASS user > and recently downloaded version 7.8.5 for my MacBook (macOS Catalina). I > converted this sample dataset to a shapefile. Could you make this shapefile available? Or post the data structure? # attribute table structure v.info -c coal_test # vector types v.info -t coal_test ? Best, Markus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.contour
Maris, 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. Dave On Fri, 12 Feb 2021 at 05:25, Maris Nartiss wrote: > 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 <43carn...@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 > > 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. > > > > Any help or advice will be much appreciated, > > > > Dave Marshall > > > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
