Re: [GRASS-user] unable to open database sqlite

[Maris Nartiss via grass-user]

Hello Sibylle,
I have bad news for you – you'll have to change your name (or at least
move GRASS DB to a folder without non-ascii characters in its path).
Thanks to Windows quirks (up to three different encodings for a single
session!), non-ascii chars are a frequent source of problems and there
is nothing much we can do to fix the issue. If you wonder how I know,
just check my name ;-)

TLDR: move grassdata to a folder without "ö" in its path. There is a
really high chance it will instantly solve your problem. Or – even
better – just use Linux.

Good luck,
Māris.

trešd., 2024. g. 17. apr., plkst. 11:36 — lietotājs sibylle via
grass-user () rakstīja:
>
> Dear community
>
>
>
> I am new to GRASS GIS and I got the following error:
>
>
>
> r.boxplot -o input=Bombus_test@PERMANENT
>
>
>
> > Note, you need to close the figure to finish the script
>
>
>
> Reducing number of bins from 100 to 132480
>
> Computing histogram
>
> Computing bins
>
> Binning data
>
> Sorting bins
>
> Computing quantiles
>
> WARNING: Unable to open database  Stöckli\grassdata\Switzerland2\PERMANENT\sqlite\sqlite.db> by driver 
>
> ERROR: Unable to open database 
> <$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db> by driver 
>
> WARNING: Unable to open database  Stöckli\grassdata\Switzerland2\PERMANENT\sqlite\sqlite.db> by driver 
>
> WARNING: Unable open database  Stöckli\grassdata\Switzerland2\PERMANENT\sqlite\sqlite.db> by driver 
>
> WARNING: Unable to find table  
> linked to vector map 
>
> Traceback (most recent call last):
>
>
>
> However, when going to that directory, the location produced before 
> (Switzerland2) is there:
>
>
>
> C:\Users\Sibylle Stöckli\grassdata\Switzerland2\PERMANENT
>
>
>
>
>
> Kind regards
>
> Sibylle
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Integer division with r.mapcalc

[Maris Nartiss via grass-user]

And that WIKI is wrong. gis.h defines CELL as int thus only thing
guaranteed is that CELL will be able to store values in range from
-32767 to +32767. But by magic of C standard on my system CELL can
store values in range from -2147483647 to +2147483647 (as long as my
compiler uses /usr/include/limits.h). One running GRASS on an ARM CPU
system most likely will see different numbers.

I do agree that it is a good idea to note integer overflow in
r.mapcalc, but I would be careful with "largest number" as it has to
be tied-up to arch/compiler combo.

Māris.

ceturtd., 2024. g. 11. apr., plkst. 12:16 — lietotājs Luí­s Moreira de
Sousa via grass-user () rakstīja:
>
> Thanks Ondrej, that makes sense.
>
> I just found the details in the Wiki [0], perhaps those should be in the 
> manual.
>
> Regards.
>
> [0] https://grasswiki.osgeo.org/wiki/GRASS_raster_semantics
>
> --
> Luís
>
>
> Sent with Proton Mail secure email.
>
> On Thursday, April 11th, 2024 at 9:49 AM, Ondřej Pešek 
>  wrote:
>
> > Hi Luís,
> >
> > čt 11. 4. 2024 v 8:26 odesílatel Luí­s Moreira de Sousa via grass-user
> > grass-user@lists.osgeo.org napsal:
> >
> > > I am working with a raster with very large integers. That are stored as 
> > > 64 bit floats (imported from a GTiff). I wish to extract part of these 
> > > values with an integer division. The first approach was:
> > >
> > > r.mapcalc 'short_ints = int(long_ints)/100'
> > >
> > > However, this results in something that is not an integer division. In 
> > > fact I have no idea what the result is. Eventually, I succeeded with the 
> > > following formulation:
> > >
> > > r.mapcalc 'psu_ids = int(ssu_ids/100)'
> > >
> > > I have been going through the manual back and forth and can't understand 
> > > why these two expressions produce different results. Any insights?
> >
> >
> > This is probably due to the 32-bit size of `int()`. If your values are
> > higher than `2 ** 31 -1` (i.e. 214783467; `31` because half of the
> > numbers go to the negatives; `-1` because there is also NULL), the
> > counter starts to rotate. It means that `2 ** 31` will be NULL and `2 ** 31 
> > + 1` will be `- (2 ** 31 - 1)`. You can encounter this behaviour
> > also in other software, such as in `numpy`.
> >
> > Indeed, there is no mention of that in the docs. I will update it
> > today to include this information. It is true that it's easy to break
> > your teeth on this.
> >
> > Cheers,
> > Ondra
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] How to replace some vector & DB features, keep attributes

[Maris Nartiss via grass-user]

Hi Ken,
GRASS has a loose coupling between geometry and attributes. Use v.edit
to get your geometries correct and set a CAT value of your liking to
the new geometry. Then just make a database entry for that CAT. Note –
geometries are identified by IDs (single CAT can point to 0, 1 or n
geometries and single geometry can have multiple CATs), attributes are
always identified by CAT.

As for the SQL, try something like this (cat_value replace with CAT
set by v.edit tool=addcat):
db.execute sql="INSERT INTO new_vector (cat, attr1, attr2) SELECT
cat_value, attr1, attr2 FROM old_vector WHERE cat = old_cat"

M.

pirmd., 2024. g. 15. janv., plkst. 16:48 — lietotājs Ken Mankoff
() rakstīja:
>
> Hi Maris,
>
> On 2024-01-15 at 02:10 -08, Maris Nartiss  wrote...
> > v.edit tool=catadd/catdel is the thing you are looking for. Delete old
> > geometry, delete category of new geometry (if there is one), set old
> > cat value to the new geometry.
>
> Thank you for the suggestion. I don't need cat to be the same. I'm deleting 
> ~100 cats (old vector lines) and replacing with only one new one anyway.
>
> More importantly, in my simplified example I neglected to mention that 
> although I want to keep some attributes, I don't want to keep all. There are 
> several old attributes that are no longer relevant for this one manually 
> created line.
>
> I was going to create the new line (as below) and then in a for loop:
>
> for a in attr1 attr2 attr3 attr4; do # attrs I want to keep or copy
> # db.select statement to get attr1 value from $old_cat
> # db.execute sql='UPDATE test set a = $att where cat=$new_cat
> done
>
> Alternatively, if I follow your advice, then I'd need to:
>
> for a in attr1 attr2 attr3 attr4; do # attrs I want to delete
> # db.execute sql='UPDATE test set $attr = NULL where cat=$new_cat
> done
>
> So... is this looping method correct, or is there some SQL statement that 
> will copy attr1,attr2,attrn from row x (defined by an ID or cat) to row y?
>
> Thanks,
>
>   -k.
>
>
> >> I'd like to replace multiple vector lines with ID == 42 with one new
> >> one, and keep the attributes (date, year, name) from one of the
> >> replaced/removed lines.
> >>
> >> I'm able to create my one new line with:
> >>
> >>
> >> I'm not sure how to copy over the relevant attributes from one of the
> >> lines (first, last, doesn't matter) that has the relevant ID.
> >>
> >> Once I do that, I think I know how to delete the lines I don't want,
> >> but I'm not sure I'm doing it correct. It seems I have to run two
> >> commands to delete the lines from both the vectors (when displaying)
> >> and the database (when querying). I'm doing this:
> >>
> >> v.edit map=test tool=delete where="ID == 42" db.execute sql="DELETE
> >> FROM test WHERE ID == 42"
> >>
> >> Can anyone help with the middle step?
> >>
> >> Thanks,
> >>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] How to replace some vector & DB features, keep attributes

[Maris Nartiss via grass-user]

Hi Ken,
v.edit tool=catadd/catdel is the thing you are looking for. Delete old
geometry, delete category of new geometry (if there is one), set old
cat value to the new geometry.

Good luck,
M.

pirmd., 2024. g. 15. janv., plkst. 04:56 — lietotājs Ken Mankoff via
grass-user () rakstīja:
>
> Hi,
>
> I'd like to replace multiple vector lines with ID == 42 with one new one, and 
> keep the attributes (date, year, name) from one of the replaced/removed lines.
>
> I'm able to create my one new line with:
>
> echo "L 2 1
>  -273157 -994455
>  -255458 -989423
>  1 10" | v.edit -n tool=add map=test input=-
>
> I'm not sure how to copy over the relevant attributes from one of the lines 
> (first, last, doesn't matter) that has the relevant ID.
>
> Once I do that, I think I know how to delete the lines I don't want, but I'm 
> not sure I'm doing it correct. It seems I have to run two commands to delete 
> the lines from both the vectors (when displaying) and the database (when 
> querying). I'm doing this:
>
> v.edit map=test tool=delete where="ID == 42"
> db.execute sql="DELETE FROM test WHERE ID == 42"
>
> Can anyone help with the middle step?
>
> Thanks,
>
>   -k.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Pipe character in text field

[Maris Nartiss via grass-user]

If you are executing this command from a shell (e.g. bash), you must
escape or enclose in single quotes the pipe character.
Try:
v.db.update map=mymap column=xkey value='|'

Māris.

pirmd., 2023. g. 4. dec., plkst. 10:51 — lietotājs gisfisch--- via
grass-user () rakstīja:
>
> Hello list,
>
>
>
> I have to insert a pipe character in a text field. I use:
>
> v.db.update map=mymap column=xkey value=|
>
>
>
> but that will result in ^| instead of just the pipe |
>
>
>
> How do I get rid of that little hook? Using a backslash to escape did not 
> help.
>
>
>
> Mit freundlichen Grüßen,
>
> Uwe Fischer
>
>
>
> Ingenieurbüro Fischer
>
> Esbecker Str. 8
>
> 31036 Eime
>
> T. 05182/8325
>
> T. 0172/8876934
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] PDAL version issue

[Maris Nartiss via grass-user]

Check that you also have -dev packages (if they are separate on your
Linux distro). Exact error message will be in the config.log file.
Without it it is hard to tell what went wrong as I have PDAL 2.3.0 and
it compiles fine.

Māris.

piektd., 2023. g. 24. nov., plkst. 17:21 — lietotājs Rich Shepard via
grass-user () rakstīja:
>
> Installed here is pdal-2.2.0. When I configure the updated source code it
> fails at this point:
> checking whether to use PDAL... yes
> configure: error: *** Unable to locate suitable (>=1.7.1) PDAL library.
>
> The configuration file ends with
> --with-pdal=/usr/bin/pdal
>
> and pdal is found in /usr/bin/pdal
>
> Please suggest how I let configure know the installed pdal is >=1.7.1.
>
> TIA,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Cannot pull from dev master branch

[Maris Nartiss via grass-user]

If there are no changes you want to keep, just git reset --hard HEAD.

Māris.

piektd., 2023. g. 24. nov., plkst. 16:13 — lietotājs Rich Shepard via
grass-user () rakstīja:
>
> I've not used grass in a long time and want to update my source code to the
> current dev status as I've done before. But, there's a merge issue I need to
> learn how to resolve. My attempt:
> $ git pull
> error: Your local changes to the following files would be overwritten by 
> merge:
> Dockerfile
> contributors.csv
> display/d.legend.vect/draw.c
> doc/development/submitting/python.md
> doc/development/submitting/submitting.md
> doc/development/submitting/submitting_c.md
> doc/gui/wxpython/example/frame.py
> doc/infrastructure.md
> doc/python/raster_example_ctypes.py
> docker/alpine/Dockerfile
> docker/alpine/Dockerfile_alpine_latest
> docker/debian/Dockerfile
> docker/ubuntu/Dockerfile
> docker/ubuntu_wxgui/Dockerfile
> gui/wxpython/animation/nviztask.py
> gui/wxpython/animation/temporal_manager.py
> gui/wxpython/core/gconsole.py
> gui/wxpython/core/globalvar.py
> gui/wxpython/core/menutree.py
> gui/wxpython/core/settings.py
> gui/wxpython/core/toolboxes.py
> gui/wxpython/core/utils.py
> gui/wxpython/core/workspace.py
> gui/wxpython/core/ws.py
> gui/wxpython/datacatalog/tree.py
> gui/wxpython/dbmgr/base.py
> gui/wxpython/dbmgr/dialogs.py
> gui/wxpython/dbmgr/sqlbuilder.py
> gui/wxpython/gcp/manager.py
> gui/wxpython/gmodeler/frame.py
> gui/wxpython/gmodeler/model.py
> gui/wxpython/gui_core/dialogs.py
> gui/wxpython/gui_core/forms.py
> gui/wxpython/gui_core/gselect.py
> gui/wxpython/gui_core/mapdisp.py
> gui/wxpython/gui_core/preferences.py
> gui/wxpython/gui_core/prompt.py
> gui/wxpython/gui_core/pyedit.py
> gui/wxpython/gui_core/treeview.py
> gui/wxpython/gui_core/vselect.py
> gui/wxpython/gui_core/widgets.py
> gui/wxpython/iclass/dialogs.py
> gui/wxpython/iclass/frame.py
> gui/wxpython/iclass/statistics.py
> gui/wxpython/iclass/toolbars.py
> gui/wxpython/icons/icon.py
> gui/wxpython/image2target/ii2t_manager.py
> gui/wxpython/iscatt/controllers.py
> gui/wxpython/iscatt/core_c.py
> gui/wxpython/iscatt/dialogs.py
> gui/wxpython/iscatt/frame.py
> gui/wxpython/iscatt/iscatt_core.py
> gui/wxpython/iscatt/plots.py
> gui/wxpython/iscatt/toolbars.py
> gui/wxpython/lmgr/frame.py
> gui/wxpython/lmgr/giface.py
> gui/wxpython/lmgr/layertree.py
> gui/wxpython/lmgr/statusbar.py
> gui/wxpython/lmgr/workspace.py
> gui/wxpython/location_wizard/wizard.py
> gui/wxpython/main_window/frame.py
> gui/wxpython/mapdisp/frame.py
> gui/wxpython/mapdisp/main.py
> gui/wxpython/mapswipe/frame.py
> gui/wxpython/mapwin/base.py
> gui/wxpython/mapwin/buffered.py
> gui/wxpython/modules/colorrules.py
> gui/wxpython/nviz/mapwindow.py
> gui/wxpython/nviz/tools.py
> gui/wxpython/nviz/wxnviz.py
> gui/wxpython/photo2image/ip2i_manager.py
> gui/wxpython/psmap/dialogs.py
> gui/wxpython/psmap/frame.py
> gui/wxpython/psmap/instructions.py
> gui/wxpython/startup/guiutils.py
> gui/wxpython/tools/build_modules_xml.py
> gui/wxpython/vdigit/mapwindow.py
> gui/wxpython/vdigit/toolbars.py
> gui/wxpython/vdigit/wxdigit.py
> gui/wxpython/vdigit/wxdisplay.py
> gui/wxpython/vnet/dialogs.py
> gui/wxpython/vnet/vnet_core.py
> gui/wxpython/vnet/vnet_data.py
> gui/wxpython/vnet/widgets.py
> gui/wxpython/web_services/dialogs.py
> gui/wxpython/web_services/widgets.py
> gui/wxpython/wxgui.py
> gui/wxpython/wxplot/base.py
> imagery/i.atcorr/geomcond.cpp
> imagery/i.atcorr/i.atcorr.html
> lib/bitmap/bitmap.c
> lib/init/grass.py
> lib/vector/Vlib/area.c
> lib/vector/Vlib/buffer2.c
> lib/vector/Vlib/build.c
> lib/vector/Vlib/build_sfa.c
> lib/vector/Vlib/close.c
> lib/vector/Vlib/copy.c
> lib/vector/Vlib/field.c
> lib/vector/Vlib/header.c
> lib/vector/Vlib/level_two.c
> lib/vector/Vlib/line.c
> lib/vector/Vlib/net_analyze.c
> lib/vector/Vlib/open.c
> lib/vector/Vlib/poly.c
> lib/vector/Vlib/read.c
> lib/vector/Vlib/read_ogr.c
> lib/vector/Vlib/simple_features.c
> lib/vector/Vlib/write.c
> lib/vector/Vlib/write_nat.c
> lib/vector/Vlib/write_pg.c
> locale/grass_po_stats.py
> locale/po/grasslibs_ar.po
>  

Re: [GRASS-user] Instructions for Linux Unbuntu install

[Maris Nartiss]

Hello Philip,
the key message is inability to locate libgdal.so.30. My guess – along
with installing some programs your IT department also upgraded other
software. Just run `locate libgdal.so` in a terminal to get a list of
all GDAL versions installed on your system. If 3.0 is missing, then
you'll have to recompile GRASS (or install an update from repository
it came from).

Māris.

piektd., 2023. g. 18. aug., plkst. 22:28 — lietotājs Moffatt, Philip
via grass-user () rakstīja:
>
> Hi there - I have a linux box with the following version of Unbuntu:
>
> Distributor ID: Ubuntu
> Description: Ubuntu 22.04.2 LTS
> Release: 22.04
> Codename: jammy
>
> A few weeks ago grass would start from the terminal and then my IT dept 
> installed a program called "admin by request" and now the gui will not start. 
> I get this error:
>
> petbuser@PETB:~$ grass
> Starting GRASS GIS...
> Cleaning up temporary files...
>
>   __  ___   _____
>  / / __ \/   | / ___/ ___/   / /  _/ ___/
> / / __/ /_/ / /| | \__ \\_  \   / / __ / / \__ \
>/ /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ /
>\/_/ |_/_/  |_///   \/___///
>
> Welcome to GRASS GIS 8.2.2dev (3d37ee165c)
> GRASS GIS homepage:  https://grass.osgeo.org
> This version running through:Bash Shell (/bin/bash)
> Help is available with the command:  g.manual -i
> See the licence terms with:  g.version -c
> See citation options with:   g.version -x
> If required, restart the GUI with:   g.gui wxpython
> When ready to quit enter:exit
>
> Launching  GUI in the background, please wait...
> To run a command as administrator (user "root"), use "sudo ".
> See "man sudo_root" for details.
>
> GRASS smrMFC/philip:~ > wxdigit.py: Could not load grass_vector.8.2.
> wxdigit.py: Could not load grass_vector.8.2.
> wxnviz.py: Could not load grass_g3d.8.2.
> g.findfile: error while loading shared libraries: libgdal.so.30: cannot open 
> shared object file: No such file or directory
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/wx/core.py", line 3282, in 
> lambda event: event.callable(*event.args, **event.kw) )
>   File "/usr/local/grass82/gui/wxpython/wxgui.py", line 95, in show_main_gui
> mainframe = GMFrame(parent=None, id=wx.ID_ANY, 
> workspace=self.workspaceFile)
>   File "/usr/local/grass82/gui/wxpython/lmgr/frame.py", line 156, in __init__
> self.statusbar = SbMain(parent=self, giface=self._giface)
>   File "/usr/local/grass82/gui/wxpython/lmgr/statusbar.py", line 38, in 
> __init__
> self.mask = SbMask(self.widget, self.giface)
>   File "/usr/local/grass82/gui/wxpython/lmgr/statusbar.py", line 87, in 
> __init__
> self.Refresh()
>   File "/usr/local/grass82/gui/wxpython/lmgr/statusbar.py", line 120, in 
> Refresh
> if gs.find_file(
> KeyError: 'name'
>
> GRASS smrMFC/philip:~ >
>
> The IT department has now uninstalled the admin by request program by my 
> issue persists. I wanted to try and reinstall grass, but I have not been able 
> to get passed the PPA steps listed online. I do not know what to do next.
>
> Thank you,
>
> plm
> 
> From: grass-user  on behalf of 
> grass-user-requ...@lists.osgeo.org 
> Sent: Wednesday, August 16, 2023 12:00 PM
> To: grass-user@lists.osgeo.org 
> Subject: grass-user Digest, Vol 208, Issue 16
>
> [EXTERNAL EMAIL]
>
> Send grass-user mailing list submissions to
> grass-user@lists.osgeo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fgrass-user__%3B!!JmPEgBY0HMszNaDT!pCOWNoUQztOHaiZEShGF2j8bqYxIW165dmf0v1mk36PlyrguZuVgkBvFT1KRtYD2mIW9Adki4s9VraI4iEVGD4nC0HoNlrAkjZk7KQ%24&data=05%7C01%7Cphilip.moffatt%40wsu.edu%7Ca372c25d2f0d49f4164b08db9e8b0b48%7Cb52be471f7f147b4a8790c799bb53db5%7C0%7C0%7C638278092265285702%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7%2F7mqfEWOFR1G1ATL1ulfLL7n5NKjs%2F3Cm95bgD9%2FT4%3D&reserved=0
> or, via email, send a message with subject or body 'help' to
> grass-user-requ...@lists.osgeo.org
>
> You can reach the person managing the list at
> grass-user-ow...@lists.osgeo.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of grass-user digest..."
>
>
> Today's Topics:
>
>1. Re: Mouse coordinates in Map Window not following GUI
>   settings projection (Eric Patton)
>
>
> --
>
> Message: 1
> Date: Wed, 16 Aug 2023 16:17:04 +
> From: Eric Patton 
> To: Veronica Andreo 
> Cc: Anna Petr??ov? , grass-user@lists.osgeo.org
> Subject: Re: [GRASS-user] Mouse coordinates in Map Window not
>  

Re: [GRASS-user] v.to.rast -d segmentation fault Re: Surfaces with faults

[Maris Nartiss]

Thanks for the data. I was able to reproduce the segfault. I opened a
bug report so it doesn't get lost.
https://github.com/OSGeo/grass/issues/3105

Māris.

otrd., 2023. g. 25. jūl., plkst. 08:41 — lietotājs bonushenricus
() rakstīja:
>
> Thank you.
> the CRS is EPSG:32632
> fosso.dat I attached
> > separator=comma
> > g.region vector=fosso_linea res=0.2
> > v.split input=fosso_linea output=fosso_linea_split length=0.1
> > v.to.points -i input=fosso_linea_split output=fosso_punti
> > v.to.rast -d input=fosso_punti type=point output=fosso_dem
> use=z
>
> Il giorno mar, 25/07/2023 alle 08.33 +0300, Maris Nartiss ha scritto:
> > Please provide your input data and computational region settings. I
> > was not able to reproduce the issue with my data.
> >
> > Māris.
> >
> > otrd., 2023. g. 25. jūl., plkst. 07:17 — lietotājs bonushenricus
> > () rakstīja:
> > >
> > > Hello
> > > the problem isn't in my ASCII file or in v.in.lines
> > > but a bug in v.to.rast, with the -d parameter.
> > > I used gdb
> > > > Thread 1 "v.to.rast" received signal SIGSEGV, Segmentation fault.
> > > > (gdb) bt
> > > > #0  0x in ?? ()
> > > > #1  0x77ef7091 in G_plot_point ()
> > >from /usr/local/grass83/lib/libgrass_gis.8.3.so
> > > > #2  0x8d46 in do_lines ()
> > > > #3  0xabc6 in vect_to_rast ()
> > > > #4  0x7ad6 in main ()
> > > > (gdb)
> > >
> > >
> > >
> > > Il giorno lun, 24/07/2023 alle 17.59 +0200, bonushenricus ha
> > > scritto:
> > > > Hello
> > > > I've just tried with the solution of this thread
> > > > https://www.mail-archive.com/grass-user@lists.osgeo.org/msg40640.html
> > > > so
> > > > > v.in.lines -z --overwrite input=fosso.dat output=fosso_linea /
> > > > > separator=comma
> > > > > g.region vector=fosso_linea res=0.2
> > > > > v.split input=fosso_linea output=fosso_linea_split length=0.2
> > > > > v.to.points -i input=fosso_linea_split output=fosso_punti
> > > > > v.to.rast -d input=fosso_punti type=point output=fosso_dem
> > > > > use=z
> > > > but the result is
> > > > > Command ended with non-zero return code -11 (0 sec)
> > > >
> > > > I believe there was something wrong in v.in.lines or in my ASCII
> > > > file:
> > > > the vector line hasn't attribute
> > > >
> > > > Il giorno lun, 24/07/2023 alle 16.44 +0200, bonushenricus ha
> > > > scritto:
> > > > > Hello
> > > > > I would like to use the procedure described in "Open Source
> > > > > GIS: A
> > > > > GRASS GIS Approach" second edition page 191 "7.3.5 Surfaces
> > > > > with
> > > > > faults".
> > > > > I have a survey of points. Some points are two ditches. I have
> > > > > run
> > > > > a
> > > > > v.surf.rst with the survey points without the ditch.
> > > > > Attached is the ascii file of the ditch points (EPSG:32632)
> > > > > I have therefore operated as follows:
> > > > > > v.in.lines -z --overwrite input=fosso.dat output=fosso_linea
> > > > > > /
> > > > > > separator=comma
> > > > > > g.region vector=fosso_linea res=0.2
> > > > > > v.to.rast -d --overwrite input=fosso_linea type=line
> > > > > > output=fosso
> > > > > > /
> > > > > > use=z
> > > > > > v.surf.rst --overwrite segmax=60 npmin=100 dmin=1 dmax=6 /
> > > > > > input=fosso_linea elevation=fosso_dem mask=fosso
> > > > > the result is with no_data
> > > > >
> > > > > Some suggestions?
> > > > > --
> > > ___
> > > grass-user mailing list
> > > grass-user@lists.osgeo.org
> > > https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.to.rast -d segmentation fault Re: Surfaces with faults

[Maris Nartiss]

Please provide your input data and computational region settings. I
was not able to reproduce the issue with my data.

Māris.

otrd., 2023. g. 25. jūl., plkst. 07:17 — lietotājs bonushenricus
() rakstīja:
>
> Hello
> the problem isn't in my ASCII file or in v.in.lines
> but a bug in v.to.rast, with the -d parameter.
> I used gdb
> > Thread 1 "v.to.rast" received signal SIGSEGV, Segmentation fault.
> > (gdb) bt
> > #0  0x in ?? ()
> > #1  0x77ef7091 in G_plot_point ()
>from /usr/local/grass83/lib/libgrass_gis.8.3.so
> > #2  0x8d46 in do_lines ()
> > #3  0xabc6 in vect_to_rast ()
> > #4  0x7ad6 in main ()
> > (gdb)
>
>
>
> Il giorno lun, 24/07/2023 alle 17.59 +0200, bonushenricus ha scritto:
> > Hello
> > I've just tried with the solution of this thread
> > https://www.mail-archive.com/grass-user@lists.osgeo.org/msg40640.html
> > so
> > > v.in.lines -z --overwrite input=fosso.dat output=fosso_linea /
> > > separator=comma
> > > g.region vector=fosso_linea res=0.2
> > > v.split input=fosso_linea output=fosso_linea_split length=0.2
> > > v.to.points -i input=fosso_linea_split output=fosso_punti
> > > v.to.rast -d input=fosso_punti type=point output=fosso_dem use=z
> > but the result is
> > > Command ended with non-zero return code -11 (0 sec)
> >
> > I believe there was something wrong in v.in.lines or in my ASCII
> > file:
> > the vector line hasn't attribute
> >
> > Il giorno lun, 24/07/2023 alle 16.44 +0200, bonushenricus ha scritto:
> > > Hello
> > > I would like to use the procedure described in "Open Source GIS: A
> > > GRASS GIS Approach" second edition page 191 "7.3.5 Surfaces with
> > > faults".
> > > I have a survey of points. Some points are two ditches. I have run
> > > a
> > > v.surf.rst with the survey points without the ditch.
> > > Attached is the ascii file of the ditch points (EPSG:32632)
> > > I have therefore operated as follows:
> > > > v.in.lines -z --overwrite input=fosso.dat output=fosso_linea /
> > > > separator=comma
> > > > g.region vector=fosso_linea res=0.2
> > > > v.to.rast -d --overwrite input=fosso_linea type=line output=fosso
> > > > /
> > > > use=z
> > > > v.surf.rst --overwrite segmax=60 npmin=100 dmin=1 dmax=6 /
> > > > input=fosso_linea elevation=fosso_dem mask=fosso
> > > the result is with no_data
> > >
> > > Some suggestions?
> > > --
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] grass82 with_opencl in Debian 12

[Maris Nartiss]

There are two options for PDAL – either disable completely (no import
tools for LAS files then) or provide paths for include and lib
directories. See ./configure --help for correct syntax of all
parameters. I have no idea if one can mix conda and native libs in a
single program.

Good luck,
Māris.

otrd., 2023. g. 27. jūn., plkst. 08:21 — lietotājs bonushenricus
() rakstīja:
>
> Hi and thanks
> Yes QGIS runs the 3D rendering very well
> For GRASS-GIS with the most simple
> > CFLAGS=-O2 ./configure
> i have at the end a problem in DEBIAN 12 because the pdal library
> doesn't exist in the stable repository
> so the configuration done:
> > Package pdal was not found in the pkg-config search path.
> > Perhaps you should add the directory containing `pdal.pc'
> > to the PKG_CONFIG_PATH environment variable
> > Package 'pdal', required by 'virtual:world', not found
> > Package pdal was not found in the pkg-config search path.
> > Perhaps you should add the directory containing `pdal.pc'
> > to the PKG_CONFIG_PATH environment variable
> > Package 'pdal', required by 'virtual:world', not found
> > configure: error: *** Unable to locate suitable (>=1.7.1) PDAL
> > library
> The formal installation (from the website of PDAL) with conda doesn't
> change anything.
>
> Bye
>
>
> Il giorno lun, 26/06/2023 alle 21.29 +0200, Richard Duivenvoorde ha
> scritto:
> > Wel there IS an openCL too :-) In QGIS:
> >
> > https://www.itopen.it/opencl-acceleration-now-available-in-qgis/
> >
> > 'naming is important' :-)
> >
> > Regards,
> >
> > Richard Duivenvoorde
> >
> > On 6/26/23 16:04, Markus Neteler wrote:
> > > Hi Enrico,
> > >
> > > On Mon, Jun 26, 2023 at 3:59 PM bonushenricus
> > >  wrote:
> > > >
> > > > Hello everyone
> > > > I installed Debian 12.
> > > > I found grass-gis 8.2.1
> > > > But it's not configured to work in opencl, and 3d rendering is
> > > > very
> > > > slow.
> > >
> > > It is actually "openGL" to be installed, see
> > >
> > > https://github.com/OSGeo/grass/blob/main/REQUIREMENTS.md#optional-packages
> > >
> > > HTH,
> > > Markus
> > >
> > >
> >
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.to.rast: advice needed

[Maris Nartiss]

I think you need to interpolate and not simply convert vector lines to
raster lines. Make sure lines have an attribute with elevation (or z
coordinate) and use e.g. v.surf.rst module.

Māris.

trešd., 2023. g. 10. maijs, plkst. 17:29 — lietotājs Rich Shepard
() rakstīja:
>
> I need to convert a vector contour map to a raster so I can apply the
> hydrologic models modules.
>
> Reading the v.to.rast manual page I learned that I needed to add categories
> to the input contour map. Running v.category added no categories: "0
> features added."
>
> v.info does not tell me anything about the elevation values of the contour
> lines. Looking at the v.* modules, and trying v.univar, didn't help. I could
> try v.to.3d, but I need information about the vector map's contents.
>
> Which v.db* should I use to find the elevation colum associated with each
> contour line?
>
> TIA,
>
> Rich
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.in.ascii syntax help needed

[Maris Nartiss]

On the first row you have specified a line with 5 coordinates and one
category (L 5 1).
You have not provided the last line containing that one category. Just
add „1 1“ (layer 1, cat 1) as a last row and you should be fine.

Māris.

pirmd., 2023. g. 8. maijs, plkst. 23:59 — lietotājs Rich Shepard
() rakstīja:
>
> The v.in.ascii manual has an exmple of a standard input file with
> elevations. I want to import a rectangle defining the analysis area mask. My
> input file has a syntax error and I don't see what it is when I examine the
> manual page.
>
> Input file:
> L 5 1
> 2306066.31 224201.00
> 2307121.58 224201.00
> 2307121.58 223165.80
> 2306066.31 223165.80
> 2306066.31 224401.00
>
> Grass error message:
> GRASS Oregon/analysis_area:analyses > v.in.ascii -zn 
> in=$HOME/projects/oregon/northside-rock/data/analysis-area.txt out=anal_mask 
> format=standard columns='x double precision, y double precision,' x=1 y=2 
> cat=0 --o
> WARNING: End of ASCII file reached before end of categories
> ERROR: Import failed
>
> If I remove the cat=0 option I trigger the same error.
>
> TIA,
>
> Rich
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Importing LiDAR data

[Maris Nartiss]

Peaking at the file list you provided, you are dealing with already
processed LiDAR data in raster (and shapefile) format. Thus r.in.gdal
is the way to go.

r.in.las (obsolete) and r.in.pdal (the new way to go) deal with raw
point clouds in LAS format. They perform point binning according to
chosen criteria to generate a raster.

Māris.

ceturtd., 2023. g. 27. apr., plkst. 19:46 — lietotājs Rich Shepard
() rakstīja:
>
> On Thu, 27 Apr 2023, Rich Shepard wrote:
>
> > There are raster LiDAR modules (r.in.gdal, r.in.lidar, r.in.pdal) and the
> > latter two work with .las files, so I assume that my data use r.in.gdal.
> > It's been a long time since I've build LiDAR maps and I ask for the proper
> > command lines to 1) set the location for import and 2) import the data. An
> > example file tree is 10,008 lines long and downloadable (for 5 days) from:
> > .
>
> For now, I'm interested in only the bare earth data; learning which files to
> use for the other data is still valuable.
>
> Regards,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] LiDAR files information commands

[Maris Nartiss]

Do you mean `pdal info file.las`?

Māris.

ceturtd., 2023. g. 27. apr., plkst. 01:35 — lietotājs Rich Shepard
() rakstīja:
>
> A long time ago I learned here the commands to summarize the pertinent
> content of LiDAR data files. I can't find it in my mail records. Please
> point me to a source of gdal file information.
>
> TIA,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Development build not finding PDAL version installed

[Maris Nartiss]

Could you check the config.log file for an exact error message?

There was a fix for PDAL as pdal-config enforces C++11 although it
requires C++17:
https://github.com/OSGeo/grass/commit/cb8293e8d40c02857b3a15bac441f703339ba5fd

Māris.

svētd., 2023. g. 12. febr., plkst. 00:39 — lietotājs Rich Shepard
() rakstīja:
>
> On Sat, 11 Feb 2023, Markus Neteler wrote:
>
> > Did you install pdal-dev(el)? (the name depends on your Linux distro)
>
> Markus,
>
> Slackware doesn't distribute partial packages. The unmodified kernel and the
> complete upstream packages are what we use.
>
> Regards,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Probabilistic neighborhood analysis

[Maris Nartiss]

Hello Bernardo,
although a solution with r.mapcalc random could be made to work, I'd
say creating a new dedicated module is the way to go. Just an idea –
create neighbour count raster (how many cells with centre class are in
a sliding window), in second pass unroll classes based on their count
and then choose random class from obtained list.

I don't think it is so common to infill (inpaint) categorical values
in classification results of remote sensing.
Māris.

pirmd., 2023. g. 9. janv., plkst. 13:18 — lietotājs Bernardo Santos
via grass-user () rakstīja:
>
> Hi Ken,
>
> The fuzzy logic tools seem interesting! But I am new to the concept so I did 
> not really think about how could I set functions/rules that increase with the 
> frequency of a land cover class...
> Do you know any example in this context?
>
> I thought that people working with satellite imagery classification and cloud 
> cover would have experience with that, since sometimes it is necessary to 
> somehow interpolate and fill values cover by clouds...
>
> Best
> B
>
> Em segunda-feira, 26 de dezembro de 2022 16:50:42 GMT+1, Ken Mankoff 
>  escreveu:
>
>
> What about using the fuzzy logic modules?
>
>   -k.
>
> Please excuse brevity. Sent from tiny pocket computer with non-haptic 
> feedback keyboard.
>
> On Wed, Dec 14, 2022, 13:38 Bernardo Santos via grass-user 
>  wrote:
>
> Hi,
>
> I am trying to produce scenarios of past land cover, before hydropower 
> reservoirs were built. To do so, I need to fill empty pixels from a raster in 
> the locations where the reservoirs are currently present, using as input the 
> actual land cover map. I tried doing that with r.neighbors (taking 
> method=mode) with neighborhoods of increasing size, to replace null pixels 
> with the most common land cover class in the neighborhood. I also tried that 
> with r.fill.stats which is basically the same thing.
> However, the results gets very homogeneous, since the interpolated null cells 
> always get the value of the most common land cover class.
>
> Do anyway know of a method in GRASS to perform a "probabilistic" 
> neirighborhood analysis, where cells in a neighborhood are given weights 
> (possibly related to the distance to the central cell and to their frequency) 
> and these weights are used to stocastically sample a value to fill the 
> central cell?
> If not in GRASS, does anyway know of such a method in a different platform, 
> i.e. R?
>
> Thanks!
> Best
> Bernardo
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.smap can't find signature file

[Maris Nartiss]

It worked? Strange, as i.smap requires signature generated by
i.gensigset and should not work with one generated by i.gensig (this
fact is even present in the documentation).

i.maxlik can work with signature file from i.gensig or i.cluster as
both programs generate signature file with same structure.

Māris.

P.S. GRASS 8.2 is much better as a lot of bugs have been fixed.

ceturtd., 2022. g. 22. sept., plkst. 15:55 — lietotājs Klaus Mithöfer
() rakstīja:
>
> Hello,
>
> it seems it is a problem of the module GUI. I was able to run the
> process in the terminal.
> I use GRASS GIS 7.2.9 uon Ubuntu 20.04..5 LTS.
>
> Cheers, Klaus
> > Dear all,
> >
> > I have created a group and subgroup for an image and created a signature
> > file with i.gensig. I can use the group, subgroup and signature file in
> > i.maxlik to get a result. But in i.smap the signature file cannot be
> > found. What might be the problem?
> >
> > Kind regards, Klaus
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Change gisdbase in GRASS 8.x

[Maris Nartiss]

otrd., 2022. g. 30. aug., plkst. 07:10 — lietotājs Wolf Bergenheim
() rakstīja:
>
> Hi Tom,
>
> 1) To point GRASS to the GISDBASE on the external drive, simply start GRASS 
> once with
>
> grass /external_ntfs_mount/some_location/mapset
>
> Meaning that you give as argument the path to a mapset that you want to use 
> in the GISDBASE on the external btfs drive. GRASS will remember this then is 
> subsequent runs so you only will need to do it once.

It is possible to switch GISDBASE from GUI after starting GRASS in
different GISDBASE.

> 2) For the external NTFS drive and permissions. How do you mount it? It does 
> seem to me that the user mapping is incorrect if everything is mapped to the 
> root user. Either you can use the options to mount it as your user (at which 
> point it will work on linux, but I don't know what windows user they will be 
> mapped to (probably the administrator). Alternatively you can provide a 
> mapping file which maps your linux username to a windows user id as shown for 
> example here:
> https://linux.die.net/man/8/mount.ntfs-3g

NTFS is a tricky beast as mount on Linux will just set a single owner
for all files. If nothing is specified, it will be the user mounting
disk (=root). To get NTFS permissions right, you should pass -o
uid=XX,gid=XX parameters to the mount command where XX is your UID and
GID. If disk is automounted, you should look into automounter
documentation how to get things right (fstab entry or enabling user
mount, ...).

Good luck,
Māris.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Export raster to PostGIS

[Maris Nartiss]

As r.out.gdal uses GDAL library, it is bound to GDAL limitations.
According to the GDAL PG documentation, PG rasters are read-only:
https://gdal.org/drivers/raster/postgisraster.html#raster-postgisraster
Thus you can read but can not write PG rasters with GDAL.

Māris.

piektd., 2022. g. 26. aug., plkst. 10:48 — lietotājs Asim via
grass-user () rakstīja:
>
> Hello
>
> Is it possible to export a raster map created using r.water.outlet to PostGIS 
> in GRASS 78?  The documentation indicates using r.out.gdal with PostGISRaster 
> as format.  The command I'm trying is the following:
>
>r.out.gdal input=mywatershed format=PostGISRaster output=mywatershed 
> createopt="PG:dbname='mydb'"
>
> The postgresql server is running with locally and the database "mydb" can be 
> accessed without having to enter a password using psql client.  However, this 
> command fails with the error:
>
>ERROR 6: PostGISRasterDataset::CreateCopy() only works on source datasets 
> that are PostGISRaster
>
> Is something wrong in the command?  The error message seems to suggest that 
> it is impossible to export the raster map created with r.water.outlet to 
> PostGIS because it is not sourced from PostGIS.  Can someone please confirm?
>
> Asim
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] multiple

[Maris Nartiss]

Hello Frank,
Sorry for being so late. The problem with v.profile is fixed in git
main [1]. It will be released as a part of 8.4.0. In the mean time you
can try to compile GRASS from git yourself to get the fix.

Māris.
 1. 
https://github.com/OSGeo/grass/commit/20331ef5ee9f9b34ae692b42daa9d49006f4e28e

ceturtd., 2022. g. 28. apr., plkst. 20:14 — lietotājs Maris Nartiss
() rakstīja:
>
> Thank you, Frank.
> It is a bug in v.profile. I'll try to take a look into it. In the mean
> time you can track the issue here:
> https://github.com/OSGeo/grass/issues/2344
>
> Sorry for your inconvenience,
> Māris.
>
> otrd., 2022. g. 26. apr., plkst. 21:08 — lietotājs Frank David
> () rakstīja:
> >
> > Hello,
> >
> > I need to identify vector lines (like roads, rivers) crossed by a
> > transect and get distance from the beginning of the transect. For the
> > moment I'm using v.profile but it returns only the first item. Is there
> > any way to get all crossed lines ?
> >
> > Thank for your help,
> >
> > Frank
> >
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] multiple

[Maris Nartiss]

Thank you, Frank.
It is a bug in v.profile. I'll try to take a look into it. In the mean
time you can track the issue here:
https://github.com/OSGeo/grass/issues/2344

Sorry for your inconvenience,
Māris.

otrd., 2022. g. 26. apr., plkst. 21:08 — lietotājs Frank David
() rakstīja:
>
> Hello,
>
> I need to identify vector lines (like roads, rivers) crossed by a
> transect and get distance from the beginning of the transect. For the
> moment I'm using v.profile but it returns only the first item. Is there
> any way to get all crossed lines ?
>
> Thank for your help,
>
> Frank
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] multiple

[Maris Nartiss]

Hello Frank,
Could you elaborate on „first item“ as I just digitized a vector map
with three lines and crossed them with a profile and got back three
distances.
Things to check – do all lines have a CAT value in specified layer?
If you have a problem with a specific data set, you can send me it
off-list so I can take a look.

Māris.

otrd., 2022. g. 26. apr., plkst. 21:08 — lietotājs Frank David
() rakstīja:
>
> Hello,
>
> I need to identify vector lines (like roads, rivers) crossed by a
> transect and get distance from the beginning of the transect. For the
> moment I'm using v.profile but it returns only the first item. Is there
> any way to get all crossed lines ?
>
> Thank for your help,
>
> Frank
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] NULL values as output of i.atcorr

[Maris Nartiss]

One thing to always check – does your computational region contain
data you are analysing? Try to run `g.region rast=immagine` before
running i.atcorr.

Māris.

trešd., 2022. g. 26. janv., plkst. 18:13 — lietotājs
 rakstīja:
>
> Dear all,
>
> I am having troubles in processing a Sentinel-2 image with i.atcorr.
>
> The command I use is the following:
>
> i.atcorr -r -input=immagine@mapset range=0,1 
> parameters=C:\...\22giugno2020_b4.txt output=immagine_atcorr rescale=0,1
>
> and I obtain this output:
>
> wavelength less than 0.25 micron:
>
> let's take s(l)=s(0.25)
>
> Atmospheric correction...
>
> Atmospheric correction complete.
>
>
>
> The map I obtain is constituted by pixels with 6.669033e-34 values.
>
> Can anyone explain the meaning of the output and why I obtain a NULL value 
> corrected map?
>
> Thank you for your support.
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] "double free or corruption" when calling e.g. g.version, g.list, g.region

[Maris Nartiss]

This looks like a version mismatch between library GRASS was compiled
with and library used when running. If you are on a Gentoo system, run
revdep-rebuild. If you are not using Gentoo, ask your package provider
to do a full recompile. I would put my money on GDAL (and a smaller
bet on PROJ).

Māris.

piektd., 2022. g. 21. janv., plkst. 13:03 — lietotājs Maximilian
Stahlberg () rakstīja:
>
> Hello,
>
> I'm using GRASS 7.8.6 on openSUSE Leap 15.2 and experience the
> following crashes:
>
> > Welcome to GRASS GIS 7.8.6
> > GRASS GIS homepage:  https://grass.osgeo.org
> > This version running through:Z Shell (/bin/zsh)
> >   [...]
> > GRASS 7.8.6 : ~ > g.version
> > GRASS 7.8.6 (2021)
> > *** Error in `g.version': double free or corruption (out): 
> > 0x55866fc655b0 ***
> > [1]9995 abort (core dumped)  g.version
> > GRASS 7.8.6 : ~ > g.list
> > Lists available GRASS data base files of the user-specified data type 
> > optionally using the search pattern.
> >   [...]
> > *** Error in `g.list': double free or corruption (out): 0x55a24a9f75b0 
> > ***
> > [1]1 abort (core dumped)  g.list
>
> Some other tools like g.gisenv work and GRASS used to work fully in the
> past (using, potentially, older versions of GRASS and SUSE).
>
> Even though these crashes occur at the end of execution (after output
> was produced), they are problematic as they stop e.g. the GUI from
> fully working, i.e. grass --gui brings up the launcher but crashes when
> I press "Start GRASS session" with the following output (note that
> there is additionally an assertion failure at the end):
>
> > Launching  GUI in the background, please wait...
> > GRASS 7.8.6 : ~ > /usr/lib64/python3.6/site-packages/wx/py/buffer.py:6: 
> > DeprecationWarning: the imp module is deprecated in favour of importlib; 
> > see the module's documentation for alternative uses
> >   import imp
> > *** Error in `g.version': double free or corruption (out): 
> > 0x5588157c15b0 ***
> > Unable to get GRASS version
> > *** Error in `g.version': double free or corruption (out): 
> > 0x55ddbe4825b0 ***
> > Traceback (most recent call last):
> >   File "/usr/lib64/grass78/scripts/g.extension", line 2592, in 
> > version = grass_version["version"].split(".")
> > KeyError: 'version'
> > *** Error in `g.list': double free or corruption (out): 0x56167e0485b0 
> > ***
> > Traceback (most recent call last):
> >   File "/usr/lib64/grass78/gui/wxpython/wxgui.py", line 106, in OnInit
> > workspace=self.workspaceFile)
> >   File "/usr/lib64/grass78/gui/wxpython/lmgr/frame.py", line 143, in 
> > __init__
> > self.notebook = self._createNoteBook()
> >   File "/usr/lib64/grass78/gui/wxpython/lmgr/frame.py", line 330, in 
> > _createNoteBook
> > gcstyle=GC_PROMPT)
> >   File "/usr/lib64/grass78/gui/wxpython/gui_core/goutput.py", line 118, in 
> > __init__
> > self.cmdPrompt = GPromptSTC(parent=self, menuModel=self._menuModel)
> >   File "/usr/lib64/grass78/gui/wxpython/gui_core/prompt.py", line 138, in 
> > __init__
> > GPrompt.__init__(self, parent=parent, menuModel=menuModel)
> >   File "/usr/lib64/grass78/gui/wxpython/gui_core/prompt.py", line 56, in 
> > __init__
> > self.mapList = self._getListOfMaps()
> >   File "/usr/lib64/grass78/gui/wxpython/gui_core/prompt.py", line 100, in 
> > _getListOfMaps
> > result['raster'] = grass.list_strings('raster')
> >   File "/usr/lib64/grass78/etc/python/grass/script/core.py", line 1288, in 
> > list_strings
> > mapset=mapset).splitlines():
> >   File "/usr/lib64/grass78/etc/python/grass/script/core.py", line 503, in 
> > read_command
> > return handle_errors(returncode, stdout, args, kwargs)
> >   File "/usr/lib64/grass78/etc/python/grass/script/core.py", line 343, in 
> > handle_errors
> > returncode=returncode)
> > grass.exceptions.CalledModuleError: Module run None g.list --q -m 
> > type=raster ended with error
> > Process ended with non-zero return code -6. See errors in the (error) 
> > output.
> > OnInit returned false, exiting...
> > Error in atexit._run_exitfuncs:
> > wx._core.wxAssertionError: C++ assertion "GetEventHandler() == this" failed 
> > at 
> > /home/abuild/rpmbuild/BUILD/wxPython-4.0.1/ext/wxWidgets/src/common/wincmn.cpp(478)
> >  in ~wxWindowBase(): any pushed event handlers must have been removed
> > *** Error in `python3': double free or corruption (!prev): 
> > 0x5647498368e0 ***
>
> Python versions used are 3.9.4 (local) for --text and 3.6.12 (system
> wide, has wx) for --gui.
>
> Any idea what could cause this?
>
> Kind regards,
> Maximilian
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.fillnulls hang on one computer, not on another

[Maris Nartiss]

At the back r.fillnulls is calling other interpolation modules. Some
of them can run in parallel but they are using implicit approach in
selection of threads to run by detecting number of CPUs. My guess –
for some reason this magick code gets CPU count wrong and thus does
not utilize all CPUs available.

Māris.

otrd., 2022. g. 18. janv., plkst. 23:20 — lietotājs Ken Mankoff
() rakstīja:
>
> Hi Markus,
>
> > I'm out of my depth here. It seems like a similar issue elsewhere may
> > point to SSL library issues or that this is a parent thread waiting on
> > another thread. From
> > https://meenakshi02.wordpress.com/2011/02/02/strace-hanging-at-futex/
> > and 'ps -efL | grep filln', there is only one other PID. If I strace
> > that, all I see is
> >
> > read(3,
>
> It grows!!
>
> After a while I'm now seeing
>
>
> read(3, "  10%\10\10\10\10\10", 6410)   = 10
> read(3, "  20%\10\10\10\10\10", 6400)   = 10
> read(3, "  30%\10\10\10\10\10", 6390)   = 10
> read(3, "  40%\10\10\10\10\10", 6380)   = 10
>
>
> So maybe it'll finish... eventually?
>
>   -k.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] how to derive polygons from text strings

[Maris Nartiss]

pirmd., 2021. g. 20. dec., plkst. 11:29 — lietotājs Uwe Fischer
() rakstīja:
>
> Hello Māris,
>
> thanks a lot. That is hard tobacco for a user like me. What do you mean 'ask 
> the same rendering engine'?

This depends on how you are planning to use those frames around text.
If as a background for a text, it might not fit well as the exact
width and height of text will depend on the rendering engine used to
draw text. Frames around text in ArcGIS work only as long as text
itself is rendered by ArcGIS. Try to draw text in frames made by
ArcGIS with QGIS and most likely you will not see a perfect fit even
if the same font is in use.

> Is there a chance to get such boxes for a normal user or is it a case for a 
> c++ programmer?

You can always go back to scripting. If selected font is monospace,
calculations are easy, if not monospace, it will be hard to get it
right. Thus digging into C code seems to be the best bet.

> Mit freundlichen Grüßen,
> UWE FISCHER

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

Re: [GRASS-user] how to derive polygons from text strings

[Maris Nartiss]

AFIAK no*

It is more tricky than it might seem as exact dimensions depend not
only on font size but also on selected font (see monospace vs
condensed fonts), kerning, styling (bold, italics). Thus final size of
bonding box of a string is a product of all of its properties. Thus
the best option to get the size right is to ask the same rendering
engine to calculate exact dimensions as it will know the size it will
use.


* apart from one used for vector labelling in d.* modules, but that is
not exposed to the enduser. See D_get_text_box from display library.

Māris.

sestd., 2021. g. 18. dec., plkst. 18:50 — lietotājs Uwe Fischer
() rakstīja:
>
> Hello list,
>
> I have a point feature layer with attributes for a text string (call it 
> 'label') and the fontsize in map units (which are meters in my case). Is 
> there a way in Grass to derive polygons from this input information which 
> enclose the label strings  when those are used to label the points? For those 
> who know ArcMap: what I mean is exactly what happens when you save 
> Annotations as Shapes in ArcCatalog: you get a polygon layer in which each 
> text string has a polygon hull which fits the height and width, respectively.
>
> best regards,
>
> Uwe
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.neighbors vs r.resamp.filter

[Maris Nartiss]

If the computational region is set to match input map, r.neighbours
will produce output in the same resolution. r.resamp.* will work if
the computational region differs from the input map.
Do not use r.neighbours with a different computational region, as
GRASS internally is using nearest neighbour method for resampling –
the result might not be what you expect to have.

TL;DR:
for same resolution output – r.neighbours
for different resolution (e.g. count per km²) – r.resamp.*

Māris.

trešd., 2021. g. 3. nov., plkst. 15:26 — lietotājs Bernardo Santos via
grass-user () rakstīja:
>
> Dear all,
>
> I am working with human infrastructure data (houses, trails, roads and 
> railways, dams, etc) and I need to create maps of density (in space) of each 
> type of infrastructure, for different spatial extents (i.e. considering 
> different neighborhood sizes). So far I've been using r.neighbors to do this, 
> but some colleagues and collaborators are using r.resamp.filter instead. I 
> took a good look at each and made some tests to compare, but I am not sure 
> what are the real differences between each. Has this been developed or 
> discussed somewhere?
>
> My inputs are rasterized versions of points, lines, or polygon features.
>
> If it is better, I can bring a reprex here to discuss it more deeply.
>
> Best regards,
> Bernardo Niebuhr
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Create location fails in docker

[Maris Nartiss]

2021-09-30 10:46 GMT+03:00, Margherita Di Leo :
>> What does this error message mean? Why is it trying to write in the
> /.grass7 folder ? And what does the name '_' refer to?

It means that you need to fix your environment before starting GRASS.
Check your $HOME setting.

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

Re: [GRASS-user] GRASS 8.0.dev not reading .shp file

[Maris Nartiss]

Check the file with ogr: ogrinfo -ro -so path/to/file_name.shp file_name

Māris.


2021-09-29 22:32 GMT+03:00, Rich Shepard :
> I created a new location using the .prj file for cross-section contour
> lines
> and successfully input CL_33_LDYX_20210712_CS_contour_lines.shp. When I
> tried to input the sounding points file
> (CL_33_LDYX_20210712_CS_sounding_points.shp)
> GRASS responded:
> ERROR: Unable to open data source
> 
>
> The sounding points .shp file is an ESRI Shapefile version 1000 length 19168
> type
> PointZ and 38336 bytes in lengh.
>
> What might cause GRASS to read one .shp file in a directory but not another
> .shp file in the same directory?
>
> I am seeing this 'unable to read file' error frequently these past few
> days.
>
> TIA,
>
> Rich
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Elevation/bathymetry raster maps

[Maris Nartiss]

One option always is to set colours manually.

Māris.


2021-09-29 19:12 GMT+03:00, Rich Shepard :
> Looking at the raster and raster addon modules I don't see one that will
> allow more elevation/depth 'slices' for a given range. r.resample appears
> to
> reduce the 'slices'; can it be used to also increase the number?
>
> A related question is how GRASS sets the 'slice' range for assignment to a
> color in the spectrum (elevation and water in these cases).
>
> Specifically, I have a raster map with a range of depth/elevation altitudes
> from -32.55505 to 595.1976 feet. Can I determine the number of 'slices'
> within that range and use the water colors from minimum to zero and the
> elevation colors from 1 to maximum? I want to display higher resolution in
> the depths and the adjacent terrestrial elevations with a greater range of
> colors to better communicate the channel and immediate river bank topology.
>
> TIA,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] What color style for bathymetric raster map?

[Maris Nartiss]

pirmd., 2021. g. 20. sept., plkst. 19:58 — lietotājs Rich Shepard
() rakstīja:
> I've used r.colors only for terrestrial DEMs before and elevation was
> suitable for the projects, so today's look at the manual page was too
> superficial. I missed water, etopo2 and the options.

Feel free to create a pull request with enhancements for
documentation. Keep in mind – it is hard for us, developers and
pro-users to write documentation as we know clunks of GRASS too well.

> Rich

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

Re: [GRASS-user] v.in.ogr ESRI fileGDB

[Maris Nartiss]

Strange. I just tested and it works just as I described:
v.in.ogr input=/home/maris/path/to/dataset.gdb/ layer=mylayer output=mylayer

I was testing on the main branch compiled at the end of August running
with GDAL 3.0.4.

Rich, you should see in the output of ogrinfo -ro -so a list of layers
in the FGDB. If you do not see them, then you will not be able to
import as GRASS is using OGR for reading FGDB.
Here's an example of output on my system:
ogrinfo -ro -so path/to.gdb/
INFO: Open of `to.gdb/'
  using driver `OpenFileGDB' successful.
1: first_layer (Multi Line String)
2: second_layer (Multi Polygon)

Māris.

piektd., 2021. g. 17. sept., plkst. 18:30 — lietotājs Rich Shepard
() rakstīja:
>
> On Fri, 17 Sep 2021, Maris Nartiss wrote:
>
> > I don't have File GDB at hand to test it but it should be as simple as
> > pointing "input" to the folder of FGDB and setting "layer" to the name of
> > dataset in FGDB. You can get names of all layers in CLI with "ogrinfo -ro
> > -so /path/to/FGDB".
>
> Māris,
>
> Something's wrong here. Using 'ogrinfo -ro -so Tile_E.gdb' from the
> directory where that's located produces this message:
> INFO: Open of `Tile_E.gdb/'
>using driver `OpenFileGDB' successful.
>
> Same result using -al rather than -ro.
>
> Using the GUI:
> Fri Sep 17 08:20:46 2021)
> v.in.ogr -r 
> input=~/projects/washington/nevins-dock/data/bathymetry/Tile_E.gdb 
> output=bathy_terrain
> ERROR: Unable to open data source <[path_to_/Tile_E.gdb>
>
> Is it me or v.in.ogr in the 8.0dev source?
>
> A couple of years ago I had no problems importing ESRI FileGDB maps.
>
> Regards,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.in.ogr ESRI fileGDB

[Maris Nartiss]

Hello Rich,
I don't have File GDB at hand to test it but it should be as simple as
pointing "input" to the folder of FGDB and setting "layer" to the name
of dataset in FGDB. You can get names of all layers in CLI with
"ogrinfo -ro -so /path/to/FGDB".

Good luck & let us know if you succeed.
Māris.

ceturtd., 2021. g. 16. sept., plkst. 20:08 — lietotājs Rich Shepard
() rakstīja:
>
> I have an ESRI GDB directory of bathymetric and topographic coverage. I've
> not before imported this type of file from the command line.
>
> Looking at the v.in.ogr manual page I'm not sure how to write the command;
> there's not an example for a GDB.
>
> Please point me to a reference that will teach me how to import this file
> type.
>
> TIA,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] GRASS 7.8.5 compile errors

[Maris Nartiss]

Don't forget to run make distclean before reconfiguring and
recompiling GRASS. If you would be on a Gentoo, I would suggest to run
revdep-rebuild that would rebuild all packages linking to proj. On
Ubuntu you just have to look for a PPA with GIS packages compiled with
the right proj version.

Māris.

2021-08-12 20:00 GMT+03:00, Thomas Adams :
>
> It's a mystery where libproj.so.15 references are coming from. I have never
> had this kind of problem before.
>
> Tom
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] GRASS 7.8.5 compile errors

[Maris Nartiss]

Hello Thomas,
I gave you a wrong path. Try this one:
ldd /home/teaiii/grass-7.8.5/dist.x86_64-pc-linux-gnu/lib/libgrass_gproj.so

The problem still boils down to having different incompatible system
libraries during compilation and runtime. You can also search for
libproj.so files in /usr/lib(64) or just dpkg -l | grep proj and if
you see multiple proj versions, remove one.

Māris.

2021-08-12 13:11 GMT+03:00, Thomas Adams :
> Hi Māris,
>
> When I run the command ldd /home/teaiii/grass-7.8.5/lib/libgrass_gproj.so |
> grep proj , I get:
>
> ldd: /home/teaiii/grass-7.8.5/lib/libgrass_gproj.so: No such file or
> directory
>
> There is no libgrass_gproj.so file in /home/teaiii/grass-7.8.5/lib/l in
> fact just subdirectories along with Makefile and README
>
> Tom
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] GRASS 7.8.5 compile errors

[Maris Nartiss]

This is a know issue. Most likely you have two versions of PROJ
library installed. Make sure to have only one llibproj.so file
present.
Here's a check for it (one line – good, more than one – bad):
ldd /home/teaiii/grass-7.8.5/lib/libgrass_gproj.so | grep proj

Here's a old bug report:
https://github.com/OSGeo/grass/issues/435#issuecomment-688807074

Good luck,
Māris.


2021-08-11 22:06 GMT+03:00, Thomas Adams :
> Hi Anna,
>
> Thank you for your help sorting this out... Not surprisingly, I get the
> same errors in grass-7.8.6RC2
>
> *Error in /home/teaiii/grass-7.8.5/lib/python/ctypes:*
>
> Error: /usr/include/stdio.h:246: Syntax error at '__filename'
> Error: /usr/include/stdio.h:247: Syntax error at '__modes'
> Error: /usr/include/stdio.h:252: Syntax error at '__filename'
> Error: /usr/include/stdio.h:253: Syntax error at '__modes'
> Error: /usr/include/stdio.h:254: Syntax error at '__stream'
> Error: /usr/include/stdio.h:304: Syntax error at '__stream'
> Error: /usr/include/stdio.h:304: Syntax error at '__buf'
> Error: /usr/include/stdio.h:308: Syntax error at '__stream'
> Error: /usr/include/stdio.h:308: Syntax error at '__buf'
> Error: /usr/include/stdio.h:309: Syntax error at 'size_t'
> Error: /usr/include/stdio.h:314: Syntax error at '__stream'
> Error: /usr/include/stdio.h:314: Syntax error at '__buf'
> Error: /usr/include/stdio.h:326: Syntax error at '__stream'
> Error: /usr/include/stdio.h:327: Syntax error at '__format'
> Error: /usr/include/stdio.h:332: Syntax error at '__format'
> Error: /usr/include/stdio.h:334: Syntax error at '__s'
> Error: /usr/include/stdio.h:335: Syntax error at '__format'
> Error: /usr/include/stdio.h:341: Syntax error at '__s'
> Error: /usr/include/stdio.h:341: Syntax error at '__format'
> Error: /usr/include/stdio.h:347: Syntax error at '__format'
> Error: /usr/include/stdio.h:349: Syntax error at '__s'
> Error: /usr/include/stdio.h:349: Syntax error at '__format'
> Error: /usr/include/stdio.h:354: Syntax error at '__s'
> Error: /usr/include/stdio.h:355: Syntax error at 'const'
> Error: /usr/include/stdio.h:355: Syntax error at '__format'
> Error: /usr/include/stdio.h:358: Syntax error at '__s'
> Error: /usr/include/stdio.h:359: Syntax error at 'const'
> Error: /usr/include/stdio.h:359: Syntax error at '__format'
> Error: /usr/include/stdio.h:379: Syntax error at '__fmt'
> Error: /usr/include/stdio.h:382: Syntax error at '__fmt'
> Error: /usr/include/stdio.h:391: Syntax error at '__stream'
> Error: /usr/include/stdio.h:392: Syntax error at '__format'
> Error: /usr/include/stdio.h:397: Syntax error at '__format'
> Error: /usr/include/stdio.h:399: Syntax error at '__s'
> Error: /usr/include/stdio.h:400: Syntax error at '__format'
> Error: /usr/include/stdio.h:416: Syntax error at '__stream'
> Error: /usr/include/stdio.h:417: Syntax error at '__format'
> Error: /usr/include/stdio.h:418: Syntax error at '__format'
> Error: /usr/include/stdio.h:419: Syntax error at '__s'
> Error: /usr/include/stdio.h:420: Syntax error at '__format'
> Error: /usr/include/stdio.h:432: Syntax error at '__s'
> Error: /usr/include/stdio.h:432: Syntax error at '__format'
> Error: /usr/include/stdio.h:440: Syntax error at '__format'
> Error: /usr/include/stdio.h:444: Syntax error at '__s'
> Error: /usr/include/stdio.h:445: Syntax error at '__format'
> Error: /usr/include/stdio.h:465: Syntax error at '__s'
> Error: /usr/include/stdio.h:466: Syntax error at '__format'
> Error: /usr/include/stdio.h:468: Syntax error at '__format'
> Error: /usr/include/stdio.h:470: Syntax error at '__s'
> Error: /usr/include/stdio.h:471: Syntax error at '__format'
> Error: /usr/include/stdio.h:564: Syntax error at '__s'
> Error: /usr/include/stdio.h:564: Syntax error at 'FILE'
> Error: /usr/include/stdio.h:603: Syntax error at '__lineptr'
> Error: /usr/include/stdio.h:604: Syntax error at '__n'
> Error: /usr/include/stdio.h:605: Syntax error at 'FILE'
> Error: /usr/include/stdio.h:606: Syntax error at '__lineptr'
> Error: /usr/include/stdio.h:607: Syntax error at '__n'
> Error: /usr/include/stdio.h:608: Syntax error at 'FILE'
> Error: /usr/include/stdio.h:616: Syntax error at '__lineptr'
> Error: /usr/include/stdio.h:617: Syntax error at '__n'
> Error: /usr/include/stdio.h:618: Syntax error at '__stream'
> Error: /usr/include/stdio.h:626: Syntax error at '__s'
> Error: /usr/include/stdio.h:626: Syntax error at '__stream'
> Error: /usr/include/stdio.h:646: Syntax error at '__ptr'
> Error: /usr/include/stdio.h:647: Syntax error at 'size_t'
> Error: /usr/include/stdio.h:647: Syntax error at '__stream'
> Error: /usr/include/stdio.h:652: Syntax error at '__ptr'
> Error: /usr/include/stdio.h:653: Syntax error at 'size_t'
> Error: /usr/include/stdio.h:653: Syntax error at '__s'
> Error: /usr/include/stdio.h:673: Syntax error at '__ptr'
> Error: /usr/include/stdio.h:674: Syntax error at 'size_t'
> Error: /usr/include/stdio.h:674: Syntax error at '__stream'
> Error: /usr/include/stdio.h:675: Syntax error at '__ptr'
> Error: /

Re: [GRASS-user] Topography shading in irradiance

[Maris Nartiss]

Hello Robson,
although I did not completely understood your problem, here are a few
points for a start.
1. Import WRF data in into a new location/mapset with its coordinate
system matching WRF one;
2. Set computational region resolution to 1km (g.region res=1000 -a -p);
3. Run one of r.resamp.* tools (e.g. r.resamp.interp) to obtain smooth
version of WRF in the new resolution set in the step #2.
4. ???
5. Profit!

To fill ???, take a look at r.sun and r.sunmask. You will need a DEM
to calculate the influence of topography.

https://grass.osgeo.org/grass78/manuals/r.resamp.interp.html
https://grass.osgeo.org/grass78/manuals/r.sun.html
https://grass.osgeo.org/grass78/manuals/r.sunmask.html

Don't hesitate to ask follow up questions after taking a look at r.sun
and r.sunmask.
Good luck,
Māris.


2021-08-12 5:04 GMT+03:00, Robson Passos :
> Dear,
>
> I have irradiance data from the WRF meteorological model, the data is with
> 3 km resolution, first I need to refine it to 1 km resolution and then
> calculate the irradiance loss due to the shading of the terrain.
>
> Is there a tool that does this in GRASS? I would like to use an irradiance
> raster as input and know the influence of topography on shading, similar to
> what is presented in the solar potential atlases.
>
> If you can clarify this for me I would appreciate it.
>
> Thank you very much in advance,
> Robson
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] wxpython and wxgtk c++ abi mismatch error - how to fix?

[Maris Nartiss]

As a former Gentoo user, I feel your pain. Unfortunately there is
nothing we can do, you must rebuild wxgtk and then rebuild wxpython as
building one and not other with the same g++ version is a path to hard
to predict random failures. And pray the mighty toolchain goods that
you have only one version of wxgtk installed as otherwise build
process might compile wxpython against a different wxgtk version than
one used during runtime (= leading to a fail).

Good luck & wait for winter when recompiling will pay off by reduce
your heating bills ;-)
Māris.

2021-08-02 23:23 GMT+03:00, Donovan Cameron :
> My system info:
>
> OS: Arch Linux
> GRASS: 7.8.5
> wxgtk3: 3.0.5.1
> python-wxpython: 1:4.0.7.2
>
> To compile GRASS I have python-wxpython set as a dependency and it
> builds fine but I always get this warning on startup of GRASS:
>
> % grass78 --gui
> Starting GRASS GIS...
> 12:54:21: Warning: Mismatch between the program and library build
> versions detected.
> The library used 3.0 (wchar_t,compiler with C++ ABI 1014,wx
> containers,compatible with 2.8),
> and wxPython used 3.0 (wchar_t,compiler with C++ ABI 1016,wx
> containers,compatible with 2.8).
>
> Recently, the GUI started to crash without any error or warning. It
> launches a location/project and as soon as the two windows load (map and
> layer windows) they just crash after a few seconds. No output in
> terminal to indicate the cause. Can still execute command line GRASS no
> problem though, so it doesn't crash the entire program just the GUI.
>
> I've never really understood what causes the warning and now this crash
> - do I need to re-compile wxgtk3[1] and python-wxpython[2] to fix it?
> They do take a little bit of time to compile so curious if anyone has
> encountered this as well and has some insight before I dive in!
>
> I'm thinking the error is because the compiler used has some differences
> to it as seen from C++ ABI 1014 and 1016.
>
> The wxgtk package in Arch Linux has a 6 year old patch[3] applied that
> has that exact warning in it and the comment for the patch in the
> PKGBUILD is:
>
> # C++ ABI check is too strict and breaks with GCC 5.1
> # https://bugzilla.redhat.com/show_bug.cgi?id=1200611
>
>
>
> Thanks,
>
> Donovan (saultdon)
>
>
> [1]
> https://github.com/archlinux/svntogit-packages/blob/packages/wxgtk/trunk/PKGBUILD
> [2]
> https://github.com/archlinux/svntogit-community/blob/packages/python-wxpython/trunk/PKGBUILD
> [3]
> https://github.com/archlinux/svntogit-packages/blob/packages/wxgtk/trunk/make-abicheck-non-fatal.patch
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] 7.9.dev fails to find pdal

[Maris Nartiss]

You'll have to recompile PDAL after GDAL upgrade.

Good luck,
Māris.

2021-04-25 21:15 GMT+03:00, Rich Shepard :
> The error is "libgdal.so.26, needed by /usr/lib64/libpdal_base.so, not
> found". That's because Slackware upgraded gdal so libgdal.so.28 is
> installed.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] 7.9.dev fails to find pdal

[Maris Nartiss]

As there is no problem with pdal 2.1.0, it could be that something has
changed in pdal. Please take a look into config.log file to see the
actual error. If there isn't something that looks like a problem
specific to your machine, open a bug report and attach failing part of
config.log.

Māris.


2021-04-25 19:21 GMT+03:00, Rich Shepard :
> A couple of weeks ago I pulled changed files from the 7.9.dev github repo
> and the new source configured, built, and installed with no errors.
>
> Today it cannot find pdal-config (which is in /usr/bin/pdal-config along
> with /usr/bin/pdal and /usr/include/pdal/ because pdal-2.2.0 is installed
> here:
>
> checking whether to use PDAL... yes
> checking for pdal-config... /usr/bin/pdal-config
> configure: error: *** Unable to locate PDAL library.
>
> I'd like suggestions where to look for the problem.
>
> TIA,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Some new issues since installing some Python tools

[Maris Nartiss]

Hello Tom,
please in a few words describe the issue and the solution you found.
This will help others facing same error message to find solution by
simple googling.

Good to hear that you are back on a horse,
Māris.


2021-04-16 13:57 GMT+03:00, Thomas Adams :
> Hi Māris!
>
> I found the issue -- life is good again! Thank you so much!
>
> Best regards,
> Tom
>
> On Fri, Apr 16, 2021 at 2:00 AM Maris Nartiss  wrote:
>
>> Recompiling GRASS will not help. Look at your environment settings. In
>> terminal examine output of env – most likely it contains some extra
>> python paths that should not be there.
>>
>> Usual suspects of not playing nice are any python modules directly
>> (ctypes, SWIG, ...) utilizing code from external compiled libraries
>> (GDAL, wxWidgets, PROJ, ...). Make sure you are using only one python
>> and its modules linking to other shared libraries are compiled with
>> the same version of shared library. On Ubuntu package manager takes
>> care of those aspects, in a virtual or mixed environment you are on
>> your own.
>>
>> Good luck,
>> Māris.
>>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Some new issues since installing some Python tools

[Maris Nartiss]

Recompiling GRASS will not help. Look at your environment settings. In
terminal examine output of env – most likely it contains some extra
python paths that should not be there.

Usual suspects of not playing nice are any python modules directly
(ctypes, SWIG, ...) utilizing code from external compiled libraries
(GDAL, wxWidgets, PROJ, ...). Make sure you are using only one python
and its modules linking to other shared libraries are compiled with
the same version of shared library. On Ubuntu package manager takes
care of those aspects, in a virtual or mixed environment you are on
your own.

Good luck,
Māris.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Importing LiDAR data - tools missing

[Maris Nartiss]

Hello Frank,
old LAS reading tools were based on libLAS. Nowadays libLAS is not
included in most of modern distributions and thus any GRASS tools
depending on libLAS are disabled at compilation time.

There is a work in progress to move LAS reading to PDAL for GRASS 8.
v.in.pdal is already in the master branch, but r.in.pdal still needs
some work (mainly just LAS info printing).

If you are comfortable with compiling GRASS from source and need
r.in.pdal, you can get it from this PR:
https://github.com/OSGeo/grass/pull/1200

If you are comfortable with C++, you are welcome to contribute missing
bits to speed up inclusion of r.in.pdal into upcoming GRASS version.

All best,
Māris.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Loading LPC data in GRASS

[Maris Nartiss]

The r.in.pdal from the PR is totally different beast than one located
in add-ons.

It is quite common for LAS files to lack coordinate system
information. In a such case it is your responsibility to handle its
correctness. If your location is in the same coordinate system as LAS
files, just use -o flag to ignore this error. If coordinate system of
your location and LAS files does not match, specify it with input_srs
parameter.

Good luck,
Māris.


2021-03-24 22:23 GMT+02:00, Andreas Yankopolus :
> Maris,
>
>> r.in.pdal still lacks metadata printing functionality and thus has not
>> been merged into the main branch yet. You can get the code from this PR:
>> https://github.com/OSGeo/grass/pull/1200
>
> I switched to that PR with "git-pr 1200”, and the resulting binary has
> r.in.pdal.
>
> Trying the tutorial in
> https://grass.osgeo.org/grass78/manuals/addons/r.in.pdal.html
> , I get the
> following error message when trying to read a .laz file with r.in.pdal:
>
>   ERROR: The input dataset has undefined projection
>
> I have pdal installed locally and am not using a Docker container for it.
> What should I be doing differently to load LPC data?
>
> Thanks,
>
> Andreas
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Loading LPC data in GRASS

[Maris Nartiss]

Hello Andreas,
r.in.pdal still lacks metadata printing functionality and thus has not
been merged into the main branch yet. You can get the code from this
PR: https://github.com/OSGeo/grass/pull/1200

Let us know if there are any problems with r.in.pdal.
Best,
Māris.


2021-03-24 0:11 GMT+02:00, Andreas Yankopolus :
> I’m starting to work with LiDAR point cloud (LPC) data with the goal of
> creating multi-band rasters that list terrain height, surface height, and
> surface type. GRASS looks like the ticket for visualizing LPC data and
> processing it into GeoTIFFs using Python scripting.
>
> I’m on Ubuntu 20.04, and it appears that LPC support requires compiling your
> own binary, which I did from the GitHub repo following these instructions:
>
> https://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu
> 
>
> The resulting 7.9.dev binary has v.in.pdal but not r.in.pdal. Is there a way
> to get the latter working? All the tutorials I’m finding refer to
> r.in.lidar, which appears similar to r.in.pdal but relies on deprecated
> liblas instead of pdal.
>
> Looks like d.vect will get me from a vector layer to a raster layer but
> haven’t figured it out yet. Should I import using v.in.pdal then convert to
> raster with d.vect?
>
> Thanks,
>
> Andreas
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Problem with r. mapcalc

[Maris Nartiss]

Markus, output of r.univar and r.info both can have scientific
notation in their range outputs.

Giuseppe, at least on my system r.mapcalc for floating point
expressions (if one of operands is floating point) defaults to double
(stored as DCELL). Still to be safe you can convert one of operands
(e.g. input map with ints) to double with double() as Markus already
pointed out.

Good luck,
Māris.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Problem with r. mapcalc

[Maris Nartiss]

Hello Giuseppe,
I am too lazy to calculate binary representation of your numbers, but
your suspicion of insufficient precision of float seems to be spot-on.

If output is set to DCELL, then the result is exactly as you would
expect. Try yourself:
r.mapcalc  expression="output=basin - 241981407231.0"
Range of data:min = 1  max = 3024784769025

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

Re: [GRASS-user] r.contour

[Maris Nartiss]

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 <43carn...@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  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
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.contour

[Maris Nartiss]

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
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.contour

[Maris Nartiss]

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

Re: [GRASS-user] raster reclassification or map calculator to simulate past sea-level change

[Maris Nartiss]

Hello Erik,
try this in r.mapcalc:
new_dem = if(old_dem < 25, null(), old_dem)

old_dem – name of map with input DEM;
null() – value to assign to cells below 25 (could be 0 too).

Keep in mind – your approach will put under water everything below a
specified level even if there is a natural or artificial dam
preventing water from intruding into the area. Use r.lake to perform
floodfill instead of simple water level rise (be ware – could be
memory hungry on large coputational regions).
Second thing – AFAIK Norway is experiencing intensive GIA. Thus simply
playing around with water level on dem is really primitive way how to
reconstruct palaeoenvironment or predict long term future.

Good luck,
Māris.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.rast.stats error: "Unable to seek"

[Maris Nartiss]

Don't want to bring bad news, but it looks more like an offset
overflow. You will not catch it with valgrind. Although it might catch
a bug leading to offset value explosion, most likely the main cause is
just code written for handling of small/medium datasets and not
large/huge ones (=imperfect logic => can't catch that with valgrind).

My suggestion: recompile GRASS with -ftrapv. If it is an integer
overflow, at least it will become clearly obvious.
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

The bad thing is G_fseek calling G_fatal_error without knowing actual
file name (lets put pipes aside) and thus it is impossible to tell
where exactly the error originated from the error message alone.
Better would be to bubble up error to main program and let it deal
with it in a clean way. Of course, as GRASS is designed around current
idioms (handling failure is responsibility of a library making module
development really easy), this will not happen in a foreseeable
future.

One thing you could do – drasticly reduce size of computational region.
Māris.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Using Python in GRASS GIS for analysis

[Maris Nartiss]

Hello Omkar,
if you want to get any answer, include errors as a text in the body of
your email instead of images. Just select the error in your console
and paste into email.

Good luck,
Māris.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.clump/ Concurent mapset locking is not supported on Windows

[Maris Nartiss]

Lack of mapset locking feature is not a fatal error but just a
warning. GRASS should work just fine even after issuing this warning.
If GRASS fails to start on your system, the actual error must be a
different one. Either you manage to get the real error message or just
have to wait for an update in hope it will magically fix the problem.

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

Re: [GRASS-user] GRASS won’t open after locking up

[Maris Nartiss]

1) Clean up ".tmp" directory located inside the last used mapset;
2) Remove the "~/.grass7/rc" file to force a clean start for GRASS. It
is safe as GRASS will generate a new one if rc file is missing.

Hope this helps,
Māris.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Error in compilation of GRASS GIS

[Maris Nartiss]

Hello Ashutosh.

Compilation and development issues are better to ask in dev mailing list.

Also – do not send errors as images. I have no idea what the error
message you got was and I assume I am not the only one. MS Windows
does support copying text from terminal.

Māris.

2021-01-19 20:41 GMT+02:00, Ashutosh Mitra :
> Dear community members
> While compiling GRASS on windows, I am getting an error.
> [image: Screenshot 2021-01-18 145457.png]
> I did the same as written in the error log that move to the directory where
> there is an error and run 'make'
> [image: Screenshot 2021-01-18 151800.png]
>
> It says that :
>
> error while loading shared libraries: libgrass_raster.7.9.dll: cannot open
> shared object file: No such file or directory
> --
>
> Thanks and Regards,
>
> *Ashutosh Mitra*
>
> (Teaching Assistant)
>
> Geoinformatics (CSRE)
>
> IIT Bombay, India.
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Statement Māris Nartišs

[Maris Nartiss]

Dear GRASS GIS community,
I am honoured to be nominated for the PSC.

I am a geographer (Dr.geog.) and self-taught programmer. My first
introduction to GRASS was around autumn of 2004 (5.x time). I remember
being fascinated by its 3D visualisation capabilities. I decided to
get to know GRASS better although the learning curve at that time was
really steep. Within recent years there has been a lot of work done to
make GRASS user friendly, especially for inexperienced users. This is
great as now getting started with GRASS requires little effort in
comparison to "good ol' days".

As a member of PSC I plan to keep an eye on meeting power user
requirements. We can not compete with QGIS (or a well known
proprietary GIS) in terms of man and financial power and thus main
focus of GRASS should be on its strengths – being a powerful and
versatile geospatial data analysis toolset. Any user-friendliness
improvements should not take away power from its power users.

As a native speaker of large language (Latvian with ~1M native
speakers), I am proud to have GRASS GIS in Latvian. As long as I will
be involved with GRASS, I plan to keep an eye on GRASS being any
language friendly.

Māris Nartišs.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] unstable results with r.param.scale ?

[Maris Nartiss]

Thank you Vincent & Vincent.
I managed to reproduce an issue with curvature tool – output result
differs significantly by each run.

You can track progress in GitHub issue tracker:
https://github.com/OSGeo/grass/issues/1168

In the mean time just disable OpenMP before running r.param.scale:
export OMP_NUM_THREADS=1

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

Re: [GRASS-user] unstable results with r.param.scale ?

[Maris Nartiss]

Please state your computation region settings. This seems like a
overflow / memory corruption and region settings might play a role
here.

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

Re: [GRASS-user] [GRASS-dev] grass python problem

[Maris Nartiss]

Please provide more information:
GRASS version
Python version
exact error message

I did not observe any errors while running command you provided (of
course I used different map names to match map names I had on my
system).
Māris.

otrd., 2020. g. 17. nov., plkst. 06:04 — lietotājs ming han
() rakstīja:
>
> Hi Everyone
>
> Hope this email finds you well.
> I can run r.cross in console with following command:
> "r.cross -z --overwrite --quiet 
> input=Connect_Lake@PERMANENT,str_grass_r@PERMANENT output=test"
>
> But I got error by run r.cross in python with following command:
> grass.run_command('r.cross', input = 
> ['str_grass_r@PERMANENT','Connect_Lake@PERMANENT'],output = 'test', quiet = 
> True)
>
>  What is the correct format to use r.cross function in Python? and how to 
> obtain the output table generated by r.cross?
>
> Thanks
> Ming
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.random segfault

[Maris Nartiss]

Hello Eric,
it is hard to say if I hit your bug or another one, but I managed to
reproduce crash and already reported it to the bug tracker:
https://github.com/OSGeo/grass/issues/1024

The problem seems to be with specifying parameter "restrict". If you
really need it, just wait for a fix as it should be quite fast (famous
last words).

Māris.

ceturtd., 2020. g. 15. okt., plkst. 22:11 — lietotājs Eric Patton
() rakstīja:
>
> Hi guys,
>
> I have encountered an error using v.random. It segfaults whenever I try to
> create some random points.
>
> > gdb v.random
> (gdb) run output=test_points npoints=6 restrict=test column=Depth --v --o
> Starting program: /usr/local/grass78/bin/v.random output=test_points 
> npoints=6 restrict=test column=Depth --v --o
> warning: the debug information found in "/lib64/ld-2.27.so" does not match 
> "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).
>
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> WARNING: Vector map  already exists and will be overwritten
> WARNING: Table  linked to vector map  does not
>  exist
> Using native format
> Generating points...
>0%
> Program received signal SIGSEGV, Segmentation fault.
> 0x8c21 in main ()
> (gdb) bt
> #0  0x8c21 in main ()
>
> Is there anything else I can try? І'm not sure what's going on with the
> debugging symbols, but it shouldn't be causing the program to crash, right?
>
> My system:
> > g.version -re
> GRASS 7.8.4 (2020)
> libgis revision: 2020-10-13T18:27:00+00:00
> libgis date: 2020-10-12T13:00:00-03:00
> PROJ: 7.0.0
> GDAL/OGR: 3.0.4
> GEOS: 3.8.0
> SQLite: 3.22.0
> > uname -a
> Linux L-102377 5.4.0-51-generic #56~18.04.1-Ubuntu SMP Tue Oct 6 09:47:18 UTC 
> 2020 x86_64 x86_64 x86_64 GNU/Linux
>
> Thanks,
>
> --
> Eric Patton
> Marine Geoscience Technologist
> Geological Survey of Canada (Atlantic)
> Natural Resources Canada
> Bedford Institute of Oceanography
> 1 Challenger Drive, Dartmouth NS, Canada
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.param.scale issue

[Maris Nartiss]

Valgrind leak check is needed only for developers as it tracks memory
consumption not its errors (although in this case it allowed to notice
OpenMP presence by shear luck). As your valgrind run is clean, this is
a dead end.

On my system I also have a OpenMP and pthreads configuration.
Unfortunately tracking OpenMP issues is really hard as it might need
precise thread/process count and timing to reproduce the bug :-(
Besides it could also be not our bug.

Please do test carefully your hardware to rule out bad thermal
management / faulty RAM as your hardware is brand new and thus
manufacturing defects can not be ruled out yet.

Also state your CPU and GCC.

I did not see any problems with Intel(R) Xeon(R) CPU E3-1241 v3 and
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04).

Māris.

ceturtd., 2020. g. 15. okt., plkst. 11:13 — lietotājs Vincent Bain
() rakstīja:
>
> Thanks Māris for your advice,
>
> it sounds dreadful to me to have to deal with these hardware issues...
> I installed valgrind and ran r.param.scale.
>
> Attached are the outputs of the command, first run without any
> argument, then with --leak-check=full option. Of course it's nearly
> "doubledutch" to me!
>
> Vincent.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.param.scale issue

[Maris Nartiss]

Hello Vincent,
start with running stress tests on your hardware. I always run at
least 24h memtest followed by several rounds of compiling kernel on
any new hardware. Allowed to catch a misbehaving motherboard of laptop
before I started to use it for my daily needs.

You could try to run process under valgrind to see if anything
suspicious comes up. There should be a warning of use of uninitialized
variable in quant_parse_file function, but it shouldn't affect outcome
in this case (I'll try to commit fix tomorrow).

Happy hunting,
Māris.

ceturtd., 2020. g. 15. okt., plkst. 09:18 — lietotājs Vincent Bain
() rakstīja:
>
> Hi Markus,
> thank you for your reply and investigation!
>
> my setup:
> a freshly built GRASS GIS 7.9.dev (64 bit), code revision: 8c2c33b4f
> Debian GNU/Linux 10.5 (buster)
> the whole hardware is 4 months old...
>
> I had the same issue with several raster source maps.
>
> Well, for now I go back to r.slope.aspect...
>
> V.
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] adaptive gaussian filter

[Maris Nartiss]

Something like anisotropic diffusion described by Perona P. and Malik
J. 1990? https://en.wikipedia.org/wiki/Anisotropic_diffusion
I do have a working C module performing aforementioned noise reduction
(with optional Tukey's conductance function according to Black et al.
1998) but I haven't found time (and need) to clean it up + write
documentation to make it production ready. If you are working on a
publication where it would be useful, I'm in.

Māris.

Perona P. and Malik J. 1990. Scale-space and edge detection using
anisotropic diffusion. IEEE transactions on pattern analysis and
machine intelligence, 12(7).
Black M.J., Sapiro G., Marimont D.H. and Heeger D. 1998. Robust
anisotropic diffusion. IEEE transactions on image processing, 7(3).

trešd., 2020. g. 29. jūl., plkst. 14:22 — lietotājs Jachym Cepicky
() rakstīja:
>
> Hi all,
>
> I would like to ask, whether there is a code or extension, which would
> apply gaussian filtering on raster data, but with varying sigma value
> according to one of input raster maps?
>
> I would like to blur raster but differently on different regions (e.g.
> based on texture characteristics)
>
> Thank you
>
> Jachym
>
> --
> Jachym Cepicky
> e-mail: jachym.cepicky gmail com
> URL: http://les-ejk.cz
> GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] .gislock

[Maris Nartiss]

pirmd., 2020. g. 27. jūl., plkst. 05:52 — lietotājs Janet Choate
() rakstīja:
>
> I tried changing permissions on .gislock, i.e.
> -rwxrwxrwx+ 1 jchoate  staff  4 Nov 15  2013 .gislock

Check permissions of folder containing .gislock file. Are you the
owner of that folder? Does it have rwx for your user?

If it doesn't help, please provide tested GRASS 7 version and install
method (self compiled, packages, ...).

Good luck,
Māris.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Raster map - unsupported compressor error

[Maris Nartiss]

ceturtd., 2020. g. 23. jūl., plkst. 16:01 — lietotājs Micha Silver
() rakstīja:
> So to make rasters in 7.8 and have them available in 7.2 you will need to set 
> the GRASS_COMPRESSOR environment variable in advance to "ZLIB" before 
> creating the rasters in version 7.8. THen those should be readable in older 
> versions.

You can also use r.compress in 7.8 to recompress existing maps with
different compression algorithm (ZLIB). A good idea to save some disk
space taken by old maps.
https://grass.osgeo.org/grass78/manuals/r.compress.html

Māris.

P.S. Why do you want to use 7.2 if 7.8 is working fine on your system?
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] 7.9.dev: which wxPython versions supprted?

[Maris Nartiss]

tl;dr Only master branch (7.9) has some wxPython-4.1 related fixes.
Unless you are ready to provide fixes, do not mix GRASS with wxPython
>4.0.

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

Re: [GRASS-user] Status of pdal-2.1 support? [UPDATE]

[Maris Nartiss]

otrd., 2020. g. 26. maijs, plkst. 01:00 — lietotājs Rich Shepard
() rakstīja:
>
> When I run 'make' it eventually fails because,
> v.in.pdal: error while loading shared libraries: libproj.so.15: cannot open
> shared object file: No such file or directory
>
> That's because proj-7.0.1 provides libproj.so.19.
>
> Please help me understand.

After upgrading to proj-7 you forgot to recompile all libraries
linking to proj. If you are running a system with pre-built packages,
go bark on your GIS package maintainer.
Be ware — mixing proj 6 and 7 in a single system is a road to failure.

> Regards,
>
> Rich

Good luck,
Māris.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] Calling all imagery (especially i.maxlik and i.smap) users

[Maris Nartiss]

Hello Brad.
piektd., 2020. g. 8. maijs, plkst. 05:36 — lietotājs Brad ReDacted
() rakstīja:
>
> Hello,
>
> IIRC, signatures cannot be handled as colors without significant modification 
> to api.
>
> Is there a particular reason for not improving the API to be map portable and 
> remove subgroups from modules that do not explicitly require it?

Thanks also to Veronica and Sajid for feedback :-)
Yes, that's the whole point of this thread — to find out more how
people use GRASS image groups so they can be changed (requiring
breaking API, GRASS database structure).

Last night I couldn't sleep and came up with a sound idea of replacing
subgroups with semantically sounder alternative that would allow to
make group independent signature files. Concept still needs some
thinking over and writing/drawing. If anyone is willing to help in
changing imagery support for GRASS 8, let me know.

Māris.

PS. More user stories are still welcome :-)
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] Let's talk about releases - 7.8.3, 7.10, 8.0

[Maris Nartiss]

Thanks, Vaclav, for taking initiative into your hands. Please send us
approximate time of the new startup screen discussion meeting.

All best,
Māris.

otrd., 2020. g. 5. maijs, plkst. 21:10 — lietotājs Vaclav Petras
() rakstīja:
>
> New URL (Zoom):
>
> https://ncsu.zoom.us/j/95921808290?pwd=UnVOa0VHN2gvbWJLbDExNEJ4TWU3Zz09
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Calling all imagery (especially i.maxlik and i.smap) users

[Maris Nartiss]

Hello lists (sorry for cross-posting),
as GRASS 8 starts to look less Duke Nukem Forever (a.k.a. never), it
is a chance to change some things in imagery part. Thus if you heavy
relay on imagery part of GRASS GIS, please find some time to give
small feedback.

GRASS 7.8.0 imagery groups gained functionality of fully qualified
maps and thus could be used from other mapsets, still some issues
popped up.

#1 Should there be subgroups at all?
There has been a call to completely eliminate subgroups [1] and stick
only with groups. If you are using subgroups, this is the right moment
to share your user story (and not hypothetical one!).

#2 Should i.maxlik add its output to the group?
Current implementation of i.maxlik adds classification result to the
input group [2]. This prevents use of i.maxlik with imagery group from
other mapset. I would vote to remove such feature. If you have a use
case where such functionality is needed, speak now, or forever hold
your peace.

#3 Should signature files be handled similarly to raster colors?
i.cluster, i.gensig and i.gensigset write signature files to imagery
subrgoup. This is not possible if group is located in other mapset. My
proposal — handle signatures as raster colours — signatures are always
saved in current mapset. Thus signatures created for a group in other
mapset would be not visible in other mapsets.

Thank you in advance for your feedback,
Māris.

1. https://trac.osgeo.org/grass/ticket/3440
2. https://trac.osgeo.org/grass/ticket/3525
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] bug with projection systems?

[Maris Nartiss]

JFYI
http://trac.osgeo.org/grass/ticket/1905

Seems that GRASS fails to notice difference between "north" and "south" at all.

Maris.

2013/3/14 Shaun Langley :
> Here is the projection for my input file:
>
> Driver: GTiff/GeoTIFF
> Files: MOD112_2004_001.LST_Day_1km.tif
> Size is 2495, 2504
> Coordinate System is:
> PROJCS["WGS 84 / UTM zone 36N",
> GEOGCS["WGS 84",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433],
> AUTHORITY["EPSG","4326"]],
> PROJECTION["Transverse_Mercator"],
> PARAMETER["latitude_of_origin",0],
> PARAMETER["central_meridian",33],
> PARAMETER["scale_factor",0.9996],
> PARAMETER["false_easting",50],
> PARAMETER["false_northing",0],
> UNIT["metre",1,
> AUTHORITY["EPSG","9001"]],
> AUTHORITY["EPSG","32636"]]
>
> Here is the projection on which I initialized my GRASS location:
>
> Driver: GTiff/GeoTIFF
> Files: Mode_LULC_T1_500m.tif
> Size is 1792, 2082
> Coordinate System is:
> PROJCS["WGS_1984_UTM_Zone_36S",
> GEOGCS["WGS 84",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433],
> AUTHORITY["EPSG","4326"]],
> PROJECTION["Transverse_Mercator"],
> PARAMETER["latitude_of_origin",0],
> PARAMETER["central_meridian",33],
> PARAMETER["scale_factor",0.9996],
> PARAMETER["false_easting",50],
> PARAMETER["false_northing",1000],
> UNIT["metre",1,
> AUTHORITY["EPSG","9001"]],
> AUTHORITY["EPSG","32736"]]
>
> Here is the projection info from GRASS for my location:
>
> +proj=utm
> +south
> +no_defs
> +zone=36
> +a=6378137
> +rf=298.257223563
> +towgs84=0.000,0.000,0.000
> +to_meter=1
>
> Without reprojecting the MODIS image, I can import it into GRASS even though
> the projection systems don't match with:
>
> GRASS 6.4.2 (kenya):~/PullDir/0302568977ukjJXB/001 > r.in.gdal
> input=MOD112_2004_001.LST_Night_1km.tif output=foo.testing
> Projection of input dataset and current location appear to match
>  100%
> r.in.gdal complete. Raster map  created.
>
> version: GRASS 6.4.2
> OS: MacOS X ML (10.8.2)
>
> Regards,
> Shaun
>
> (sorry for any duplicates, I sent it to the wrong users list)
>
> --
> Shaun Langley
> Doctoral Candidate
> Department of Geography
> Michigan State University
> (562) 281-7847
>
>
> On Thu, Mar 14, 2013 at 3:09 AM, Markus Neteler  wrote:
>>
>> On Thu, Mar 14, 2013 at 2:57 AM, Shaun Langley 
>> wrote:
>> > I'm wondering if I've stumbled on a bug…
>> >
>> > I'm working with a bunch of MODIS data that I've converted to UTM (Zone
>> > 36, WGS84) using the Modis Reprojection Tool.  Using gdal I can see that
>> > these maps have projections of EPSG:32636; however my GRASS location is
>> > defined with EPSG:32736.  When importing into grass with r.in.gdal, GRASS
>> > identifies the two projections as the same and allows me to proceed to
>> > import without error.  When displaying the maps though, it's obvious that
>> > the projections were wrong.  It too me a long time to figure this problem
>> > out and I'm just wondering if maybe it's a bug?
>>
>> Please post whch GRASS version on which OS you use and
>> ideally also the command lines + messages to give better help.
>>
>> (We do similar things and did not meet such problems)
>>
>> Markus
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Importing ESRI Shapefile might cause attribute data corruption

[Maris Nartiss]

JFYI
GRASS is also hit hard by recent GDAL/OGR ESRI Shapefile encoding
saga. Importing ESRI Shapefile with non-latin text most likely will
corrupt Your text.
Symptoms - even when setting correct encoding for wxgui in
preferences, non-latin letters are shown grabbled and doubled (two
garbage symbols instead of a single letter).
Solution - create a .cpg file and pray or downgrade GDAL/OGR on
pre-1.9.0 version (not an option for WinGRASS users).

Note - if Your data are corrupted during import with v.in.ogr, there's
no easy way how to correct it.*
* find/replace in LO Calc might do the trick for DBF file.

Have a nice day.
Maris.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Join points and contours

[Maris Nartiss]

You are looking for v.patch

As I know Your next questions, here are answers for them:
You must set up region before interpolating with g.region. Use vect
option to limit boundaries and res to set desired resolution.
Don't forget to use -e option for v.patch to join attribute tables
too. They must have identical structure.
Interpolation tool You want to use is v.surf.rst.

Please, take Your time to read that *fine* manual. And don't skip
"introduction to ..." parts!
Here is link: http://grass.osgeo.org/grass64/manuals/index.html

Maris.

2013/1/14 Brian Sanjeewa Rupasinghe :
> Hi,
>
> I have two 2D vector layers; spot heights and contours. Both represent
> elevation with an attribute field (say: level).
> Now i need to combine both vectors into one vector so that i can use
> combined vector to generate elevation raster.
> What is the best method to do that?
>
> Cheers, Brian.
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Raster DEM generation

[Maris Nartiss]

As it says. You have mistyped column name. Check column name and then try again.

Still in Your case I would try to interpolate with v.surf.rst first
and then use result for analysis.

Maris.

2013/1/13 Brian Sanjeewa Rupasinghe :
> Hi Maris,
>
> Many thanks for the advice. Further, i am going to use r.surf.contour to
> generate a raster elevation DEM for viewshed analysis. The grass vector
> contour layer that i have needs to be converted to raster contour. For this
> i tried using v.to.rast function. Elevation field of contour layer is;
> EL_Elevati which is a double precision data type. Following are the
> parameters i used:
>
> v.to.rast input = terrain@topo1K type = line output = rasterCont use=attr
> attrcolumn = EL_Elevati labelcolumn = cat
>
> However, when i run this it gives following error:
>
> dbmi: protocol error
> ERROR: Column  not found
>
> Any suggestion on this is appreciated.
>
> Cheers, Brian.
>
>
> On Sun, Jan 13, 2013 at 2:10 PM, Maris Nartiss  wrote:
>>
>> Hello,
>> there are two options:
>> 1st - join both datasets into single one (GRASS vectors can contain
>> different geometries in single vector dataset) and use v.surf.rst (it
>> will use both line and point data)
>> 2nd - convert lines to points with v.to.points and then join into
>> single point dataset. Interpolate with any tool.
>>
>> Good luck,
>> Maris.
>>
>> 2013/1/12 Brian Sanjeewa Rupasinghe :
>> > Hi all,
>> >
>> > have two shape files containing height information of a certain area.
>> > One
>> > file consists of height information in contours (isolines) and the
>> > othesr
>> > file consists of height information with spot heights. In order to
>> > create a
>> > complete DEM i need heights of both layers. I need to create a raster
>> > DEM
>> > with winGRASS 7 using these information. What would be the best
>> > technique to
>> > generate raster DEM with these two types of data? Do i need to generate
>> > some
>> > spot heights from contours and then integerate with existing spot
>> > heights
>> > for DEM generation or any other method?
>> >
>> > Cheers, Brian
>> >
>> > ___
>> > grass-user mailing list
>> > grass-user@lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/grass-user
>> >
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Exporting GRASS vector to ShapeFile

[Maris Nartiss]

According to v.build output, when exporting areas, You should get 64
closed area features with some holes. Please double check Your
v.out.ogr parameters and output of v.category.

Maris.

2013/1/12 Brian Sanjeewa Rupasinghe :
> Hi Maris, Thanks. Please see following the build info of the Grass Vector
> file that i need to convert to a shapefile.
>
> Cheers, Brian.
>
> (Sat Jan 12 14:25:02 2013)
> v.build map=MaskVector@user1
> Building topology for vector map ...
> Registering primitives...
> 184 primitives registered
> 4948 vertices registered
> Building areas...
> 110 areas built
> 91 isles built
> Attaching islands...
> Attaching centroids...
> Number of nodes: 101
> Number of primitives: 184
> Number of points: 0
> Number of lines: 0
> Number of boundaries: 120
> Number of centroids: 64
> Number of areas: 110
> Number of isles: 91
> (Sat Jan 12 14:25:02 2013) Command finished (0 sec)
>
> On Sat, Jan 12, 2013 at 12:52 PM, Maris Nartiss  wrote:
>>
>> Please, post output of v.build
>>
>> 2013/1/12 Brian Sanjeewa Rupasinghe :
>> > Hi,
>> >
>> > I used v.category. But it too keeps on running failing to add
>> > categories.
>> >
>> >
>> > On Fri, Jan 11, 2013 at 11:28 PM, Maris Nartiss 
>> > wrote:
>> >>
>> >> Try to run on Your vector dataset:
>> >> v.category option=add type=centroid
>> >> Then export with v.out.ogr.
>> >>
>> >> Reason - v.out.ogr is working correctly and Your centroids have no
>> >> CATs and thus are not exported. That would explain "not correctly
>> >> created" - an empty shapefile.
>> >>
>> >> Hope it helps,
>> >> Maris.
>> >>
>> >> 2013/1/11 Brian Sanjeewa Rupasinghe :
>> >> > Hi,
>> >> >
>> >> > I am using GRASS 7svn in windows. Using v.out.ogr function in GRASS i
>> >> > converted a set of polygons (some of which have holes as well) into a
>> >> > shape
>> >> > file.
>> >> > However, when i do not tick the box in Selection pane: ‘Also export
>> >> > features
>> >> > without category (not labelled) otherwise only features with category
>> >> > are
>> >> > exported,
>> >> > the function keeps on executing and shapefile is not correctly
>> >> > created.
>> >> > When
>> >> > i tick this, the shapefile is created but filling all holes as
>> >> > separate
>> >> > polygons. Any comment on this behaviour?
>> >> >
>> >> > Cheers, Brian.
>> >> >
>> >> > ___
>> >> > grass-user mailing list
>> >> > grass-user@lists.osgeo.org
>> >> > http://lists.osgeo.org/mailman/listinfo/grass-user
>> >> >
>> >
>> >
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Raster DEM generation

[Maris Nartiss]

Hello,
there are two options:
1st - join both datasets into single one (GRASS vectors can contain
different geometries in single vector dataset) and use v.surf.rst (it
will use both line and point data)
2nd - convert lines to points with v.to.points and then join into
single point dataset. Interpolate with any tool.

Good luck,
Maris.

2013/1/12 Brian Sanjeewa Rupasinghe :
> Hi all,
>
> have two shape files containing height information of a certain area. One
> file consists of height information in contours (isolines) and the othesr
> file consists of height information with spot heights. In order to create a
> complete DEM i need heights of both layers. I need to create a raster DEM
> with winGRASS 7 using these information. What would be the best technique to
> generate raster DEM with these two types of data? Do i need to generate some
> spot heights from contours and then integerate with existing spot heights
> for DEM generation or any other method?
>
> Cheers, Brian
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Exporting GRASS vector to ShapeFile

[Maris Nartiss]

Please, post output of v.build

2013/1/12 Brian Sanjeewa Rupasinghe :
> Hi,
>
> I used v.category. But it too keeps on running failing to add categories.
>
>
> On Fri, Jan 11, 2013 at 11:28 PM, Maris Nartiss  wrote:
>>
>> Try to run on Your vector dataset:
>> v.category option=add type=centroid
>> Then export with v.out.ogr.
>>
>> Reason - v.out.ogr is working correctly and Your centroids have no
>> CATs and thus are not exported. That would explain "not correctly
>> created" - an empty shapefile.
>>
>> Hope it helps,
>> Maris.
>>
>> 2013/1/11 Brian Sanjeewa Rupasinghe :
>> > Hi,
>> >
>> > I am using GRASS 7svn in windows. Using v.out.ogr function in GRASS i
>> > converted a set of polygons (some of which have holes as well) into a
>> > shape
>> > file.
>> > However, when i do not tick the box in Selection pane: ‘Also export
>> > features
>> > without category (not labelled) otherwise only features with category
>> > are
>> > exported,
>> > the function keeps on executing and shapefile is not correctly created.
>> > When
>> > i tick this, the shapefile is created but filling all holes as separate
>> > polygons. Any comment on this behaviour?
>> >
>> > Cheers, Brian.
>> >
>> > ___
>> > grass-user mailing list
>> > grass-user@lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/grass-user
>> >
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Exporting GRASS vector to ShapeFile

[Maris Nartiss]

Try to run on Your vector dataset:
v.category option=add type=centroid
Then export with v.out.ogr.

Reason - v.out.ogr is working correctly and Your centroids have no
CATs and thus are not exported. That would explain "not correctly
created" - an empty shapefile.

Hope it helps,
Maris.

2013/1/11 Brian Sanjeewa Rupasinghe :
> Hi,
>
> I am using GRASS 7svn in windows. Using v.out.ogr function in GRASS i
> converted a set of polygons (some of which have holes as well) into a shape
> file.
> However, when i do not tick the box in Selection pane: ‘Also export features
> without category (not labelled) otherwise only features with category are
> exported,
> the function keeps on executing and shapefile is not correctly created. When
> i tick this, the shapefile is created but filling all holes as separate
> polygons. Any comment on this behaviour?
>
> Cheers, Brian.
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] to move or not move ? grass64 <- ? -> 7.0

[Maris Nartiss]

Hello,
as a (not so active) GRASS developer, I also use 7 for almost all my
daily needs. I agree about all nice things of using 7 previously
stated, still I also must give a fat warning - some code in 7 is not
yet tested enough. There are new bugs present in 7 only too.

Here is (infamous) example of it - output result is shifted by n
cells.[1] Issue was present only in 7 in not so well tested new code.
Bugs do happen and GRASS 7 contains new bugs yet unknown. Anyone is
welcome to use GRASS 7, but remember to check outputs and be ready to
report back issues.

Maris.

1. https://trac.osgeo.org/grass/changeset/53889

2013/1/10 Markus Metz :
> On Thu, Jan 10, 2013 at 8:33 PM, Patrice Dumas  wrote:
>> On Thu, Jan 10, 2013 at 03:59:49PM -0200, Milton Cezar Ribeiro wrote:
>>> Thanks Rashad,
>>>
>>> I understand that grass 7 have a lot of new features (or
>>> improved/fixed ones), including the powerful contribution of python.
>>> But I would like to hear from grass7 users about how stable are this
>>> version. Anyone survive using only  grass7 our we need to switch
>>> between them?
>>
>> I have seen quite a bit of bugs in grass 7, but the GRASS developpers
>> are very quick to fix a correctly reported bug.
>
> Some of the bugs reported by you were really helpful to improve new
> functionality in GRASS 7. GRASS developers actually depend on this
> kind of feedback, and the more power-users use GRASS 7 and report any
> bugs, the better. In general, I estimate that GRASS 7 (on the command
> line) is as robust, but if in doubt faster and less resource intensive
> than GRASS 6.
>
> Some of the bugs reported by you apply to GRASS 6 only, are fixed in
> GRASS 7 and can not be backported to GRASS 6 because the required
> changes would break GRASS 6 compatibility.
>
> Other bugs that were present in GRASS 6 + 7 are only fixed in GRASS 7
> and may or may not be backported to GRASS 6.
>
> Obviously I am advocating the use of GRASS 7, but for production work
> I would, like Paolo, recommend to have GRASS 6 on the side.
>
> As a GRASS developer, I personally use only GRASS 7 for production work.
>
> Markus M
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.to.rast not working?

[Maris Nartiss]

Output raster map will have bounds and resolution of current
computational region. It doesn't matter if You have any data there or
not. I'm not familiar with v.to.rast code, still it might try to hold
raster in RAM and thus explain Your observed behaviour.

Maris.

2012/12/7 Martin Album Ytre-Eide :
> Thanks, why did I not try that.. Why do region actually matter? I 
> mean, I get the resolution part, but for me it helped just reducing the 
> computational region.  Why should that matter - it is the same features that 
> are converting or do you also get a lot of NULL values in the produced raster?
>
> Martin
>
>
>
> ________
> Fra: Maris Nartiss [maris@gmail.com]
> Sendt: 7. desember 2012 10:19
> To: Martin Album Ytre-Eide
> Emne: Re: [GRASS-user] v.to.rast not working?
>
> Check the size of computational region. Just decrease resolution and
> You will be fine.
>
> 2012/12/7 Martin Album Ytre-Eide :
>> Hi all.
>>
>> When V.to.rast starts - my computer hangs. It takes most of memory  and I
>> have to kill the process to get my laptop back. I first encountered this
>> whil trying to run v.rast.stats. Later I just tried to run v.to.rast whith
>> the same error. It seems to run (taking all memory and much time) Loading
>> data...
>> Pass 1 of 58:
>> Reading features...
>>  100%
>> Writing raster map...
>> Killed
>> GRASS 6.4.2
>>
>> I tried waiting for a while after "Writing raster map"  but no luck.
>>
>> Any help or suggestions for diagnostic is welcome..
>>
>>
>> Martin
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Improved version of r.fillnulls - needs quality check

[Maris Nartiss]

Hello all,
I just have commited to trunk (GRASS 7) a new version of r.fillnulls
that is filling each hole separately. On my test dataset it is giving
significantly better results than old one and provides ~2x speed up in
comparison with previous version (with a cost of increased disk use).

To see, if there aren't some corner cases where results got worse, I
kindly ask frequent r.fillnulls users to test most recent version
(after r54044) and report back any issues found. Differences should be
most visible if large NULL areas are present or input dataset is large
with NULLs located in different parts.


Thanks for helping to make GRASS the best GIS,
Maris.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] mysql error on compiling grass70 source code

[Maris Nartiss]

Hello,
it isn't unless You plan to use those obscure tools who's names I even
can't remember (xganim, ximgview).

Maris.

2012/11/14 王德辉 :
> Hi Markus!
> MOTIF is not existing in GRASS 7, but compiling grass6 needed.
> Cheers,
>
> dehui
>
>
>
>> -原始邮件-
>> 发件人: "Markus Neteler" 
>> 发送时间: 2012年11月14日 星期三
>> 收件人: "王德辉" 
>> 抄送: "Nikos Alexandris" ,
>> grass-user@lists.osgeo.org
>
>> 主题: Re: [GRASS-user] mysql error on compiling grass70 source code
>>
>> On Wed, Nov 14, 2012 at 10:38 AM, 王德辉  wrote:
>> > Hi Nikos!
>> >
>> > # I use ubuntu12.10.After deleting  libpngwriter-dev  and adding below,
>> > the
>> > compilation works.
>>
>> excellent!
>>
>> > sudo apt-get install mysql-server mysql-client libmysqlclient-dev
>> > libiodbc2
>> > libiodbc2-dev  libblas3 libblas-dev  lilblapack3 liblapacke
>> > liblapack-devmotif-clients libmotif-dev
>> > #However, libiodbc2 and libiodbc2-dev conflict with my kubuntu-desktop.
>>
>> Just my 0.02 cent: I am not sure that BLAS and LAPACK are used at all,
>> so perhaps no need to add them unless you plan to do numerical
>> programming with the GMATH etc libs.
>> Also MOTIF: still existing in GRASS 7?
>>
>> Markus
>
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] use of grass 6.4 and 7 on the same location/mapsets

[Maris Nartiss]

If they are not accessed at a same time, then only problem will be
with vector data. GRASS 7 uses a bit different vector data storage
format and thus vector data can be used (displayed) only after a
v.build run. It's a bit annoying and I don't know if it can introduce
any problems (I mean when going G7->G6 vectors), still I haven't
observed any.

In conclusion - for raster - doesn't matter; vectors - better stick to
one version.

Maris.

2012/10/28 Laura Poggio :
> Dear list,
> are any problems in having mapsets accessed from different version of GRASS
> (6.4.2. and 7)?
>
> Thank you
>
> Laura
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] FW: r.lake issues

[Maris Nartiss]

Hello,
please check following things:
1) water level at seed point/area is above terrain (provided DEM);
2) seed point/area is located within current computational region
(just run g.region rast=my_dem before r.lake);
3) seed point/area has values > 0 (quirk of current implementation).

Good luck!
Maris.

PS. 3rd check probably could be eliminated by slight alteration of
r.lake code. Just a note to myself ;)

2012/8/28 ambrish dhaka :
>
>
> 
> From: ambi...@hotmail.com
> To: qgis-u...@lists.osgeo.org
> Subject: r.lake issues
> Date: Tue, 28 Aug 2012 04:55:59 +
>
> HI! ALL
> I have been trying to generate a lake feature from dem and seed raster files
> using r.lake, this is information below.
>
> The areas are not created as values can be seen below.
>
> r.lake dem=e15234@user1 seed=seed@user1 wl=50 lake=seed50
>
>
> Lake depth from 0.00 to 0.00
>
>
> Lake area 0.00 square meters
>
>
> Lake volume 0.00 cubic meters
>
>
> Volume is correct only if lake depth (terrain raster map) is in meters
>
> Successfully finished
>
>
> What could be the reason.
>
>
> AMBRISH DHAKA
>
>
> THANKS! IN ADVANCE
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] creating two new maps from one existing raster

[Maris Nartiss]

Hello Alexander,
if You are not willing to make it into GRASS addon, then, please,
submit it to issue tracking system so it doesn't get lost in ML.


Thanks!
Maris.

2012/8/22 Alexander Muriy :
> Hi, Janet and all.
>
>>
>> can anyone tell me how to make 2 rasters out of my 1 along a user
>> specified
>> line, or how to successfully digitize this?
>> thank you,
>>
>
> I wrote a small shell script  for splitting the raster map
> into parts with the line(s). Hope it will be useful.
>
> --
> ./r.split.line -help
>
> Description:
>  Split raster into parts with vector line(s). Lines MUST intersect the whole
> raster map.
>
> Keywords:
>  raster,vector
>
> Usage:
>  r.split.line raster=name line=name [--verbose] [--quiet]
>
> Flags:
>  --v   Verbose module output
>  --q   Quiet module output
>
> Parameters:
>   raster   Name of input raster map
> line   Name of vector map with line(s)
> ---
>
> The script is attached.
>
> Spearfish example (raster ) with animation in GIF:
> http://img708.imageshack.us/img708/7835/rsplitline.gif
>
> ---
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS error

[Maris Nartiss]

Hello,
You have to run r.example from within GRASS work session. It wouldn't
work outside of GRASS work session unless You set up necessary
environmental variables so it would be more easy for You just to start
GRASS work session.


Maris.

2012/7/17 Albert Saribekyan :
>
>
>
>
>
> Albert Saribekyan.
>>
>>
> Hi all
>
> I have error related to GRASS GIS make and to r.example executable file
> this is my makefile:
>
> # fix this relative to include/
> # or use absolute path to the GRASS source code
> MODULE_TOPDIR = /localuser/soft/grass-6.4.2RC2
>
> PGM = r.example
>
> LIBES = $(GISLIB)
> DEPENDENCIES = $(GISDEP)
>
> include $(MODULE_TOPDIR)/include/Make/Module.make
>
> default: cmd
>
> and when I run my executable file I am getting this error :
>
> ./r.example: error while loading shared libraries: libgrass_gis.6.4.2RC2.so:
> cannot open shared object file: No such file or directory
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] makefile

[Maris Nartiss]

Hello,
r.example should compile with provided Make file just fine. Most of
"std*" things are handled by main Make file and You have to provide
specific things, still I don't see anything specific in Your provided
example. Main Make file is made when You run ./configure in main GRASS
source directory.

http://trac.osgeo.org/grass/browser/grass/trunk/doc/raster/r.example/Makefile

Maris.

2012/7/13 Albert Saribekyan :
>
>
>
>
>
> Albert Saribekyan.
>>
>>
> Dear all
>
> I would like to create a Makefile for r.example анд do not know how to deal
> with these
>
> #include 
> #include 
> #include 
> #include 
> #include 
> include files
>
> Reagards,
>
> Albert
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Grass 6.4.2 download

[Maris Nartiss]

Hello Chad,
I assume You are trying to run it on MS Windows.

Please check following - does Your home folder path contains any
non-latin letters? If yes, try to create a new Windows user i.e.
"grass" and run GRASS from there.

Also worth to check if Your antivirus program / malware defence system
doesn't block GRASS installation (disable antivirus and any Defence+
type system and reinstall GRASS). I have had various strange issues
caused by Comodo AV when installing GRASS or QGIS. Best way - disable
for a moment Comodo AV and Defence+, run install as Administrator,
enable AV back.

Report more information if none of this helps.
Maris.

2012/7/5 Chad Oliver :
> Hi,
>
> My name is Chad, and I'm completely new to Grass.  I'm not sure if this is
> the forum to ask beginner's questions, but I'll give it a go.
>
> I'm having trouble downloading Grass 6.4.2 on my home computer.  I've
> downloaded it on all of our work computers without any problems (including
> Windows Vista, XP), but it's not working on my home computer.
>
> When I double click on the desktop icon, or try to open it directly from
> program files, a window flashes up for a split second and disappears.
>
> When I go to 'Grass 6.4.2 Command Line' I get the following:
> 'g.dirseps' is not recognized as an internal or external command, operable
> program or batch file.
> 'C:\GRASS\etc\winlocale' is not recognized as an internal or external
> command, operable program or batch file.
> 'g.gisenv' is not recognized as an internal or external command, operable
> program or batch file.
> 'C:\GRASS\etc\set_data' is not recognized as an internal or external
> command, operable program or batch file.
> 'C:\GRASS\etc\echo' is not recognized as an internal or external command,
> operable program or batch file.
>
> Can anybody help?
>
> Chad
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Importing ASCII file

[Maris Nartiss]

sed FTW!
# Untested but should work.
for i in *.asc; do
sed 's/cellsize  0.008337679505/cellsize  0.00833/' -i $i;
done;

:)
Maris.

2012/6/28 Hamish :
>
> Edit the cell size back to 0.00833 (no small feat with a
> 3.7gb file, even for vi) and it'll work.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Smoothing contours

[Maris Nartiss]

Hello,
but do original, unsmoothed vector also contains two lines?
Where those lines generated in GRASS or some other (not so
intelligent) software?

If manual splitting and deleting unnecessary parts  is not an option,
I would suggest to play around with v.clean. Don't forget to make a
backup, as it might take lots of experiments to find the right
combination.


Maris.

2012/6/21 Dmitriy Tyugaev :
> Hi list,
>
> Help me please! I have a set of contours, which are created from raster
> cropped by the mask.
> After smoothing the contours with "v.generalize method=boyle look_ahead=5",
> I get the following result.
>
> http://www.image-share.com/ipng-1014-170.html
> http://www.image-share.com/ipng-1014-171.html
>
> It looks like as a two lines, but this is a one feature.
>
> How can I fix it?
> --
> Best regards, Dmitriy
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] wms import fail

[Maris Nartiss]

Hello,
the problem is that some layer names have non-latin (Estonian) letters
and current code is not ready to handle such cases. I can try to look
at the code later (have to test changes) (as soon as I will recover
from Jaanipaev).

Still Maaamet watermarks their WMS service, what could interfere with
any automatic analysis. Example here:
http://kaart.maaamet.ee/wms/alus?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&BBOX=658960.012556,6474081.356986,659242.751929,6474249.416589&SRS=EPSG:3301&WIDTH=1152&HEIGHT=685&LAYERS=of1&STYLES=&FORMAT=image/png&DPI=109&TRANSPARENT=TRUE

Maris.

PS. As I spend some time in Tartu, I would like to know if there are
any other GRASSers in Tartu too as it would be fun to have a beer :)

2012/6/22 Andres Kuusk :
>
>
> Hi,
>
> I have also trouble with r.in.wms.
>
> Estonian Land Board has a WMS server http://kaart.maaamet.ee/wms/alus,
> projection of maps EPSG:3301.
>
> I am using GRASS-7.0.svn, r52182, openSUSE-11.4, linux 2.6.37.6-0.11-pae.
>
> In the graphical user interface wxGUI the connect to server returns error
> message:
>
> Traceback (most recent call last):
>  File "/usr/local/grass-7.0.svn/scripts/r.in.wms", line 284, in 
>    sys.exit(main())
>  File "/usr/local/grass-7.0.svn/scripts/r.in.wms", line 228, in main
>    list_layers()
>  File "/usr/local/grass-7.0.svn/scripts/r.in.wms", line 223, in list_layers
>    cap_xml.getLayers()
>  File "/usr/local/grass-7.0.svn/etc/r.in.wms/wms_parse.py", line 78, in
> getLayers
>    print "  Title: " + ly['title']
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xf5' in position
> 10: ordinal not in range(128)
>
> However, I got the list of layers - two items. Now, if I select a layer
> (of1 - ortofoto) and connect, I got the same error message again, and
> nothing happens.
>
>
> In the commandline in the xterm window where I started GRASS the results are
> different.
>
> % env
> TERM=xterm
> SHELL=/bin/tcsh
> LANG=en_US.utf8
> PYTHONSTARTUP=/etc/pythonstart
> HOME=/home/grass/CHRIS_LE/CHRIS
> MACHTYPE=i586
> GISBASE=/usr/local/grass-7.0.svn
> GRASS_VERSION=7.0.svn
> PYTHONPATH=/usr/local/grass-7.0.svn/etc/python
> GRASS_PAGER=more
> GRASS_WISH=wish
> GRASS_PYTHON=python
> GRASS_GNUPLOT=gnuplot -persist
> GRASS_PROJSHARE=/usr/local/share/proj
> GRASS_HTML_BROWSER=xdg-open
> GISDBASE=/home/grass
>
> % g.region -p
> projection: 99 (Lambert Conformal Conic)
> zone:       0
> datum:      wgs84
> ellipsoid:  a=6378137 es=0.006694380022900787
> north:      6468300
> south:      6468050
> west:       693060
> east:       693315
> nsres:      1
> ewres:      1
> rows:       250
> cols:       255
> cells:      63750
>
> % r.in.wms mapserver=http://kaart.maaamet.ee/wms/alus -l
> returns the long list of map layers, there is a layer
>
> LAYER: of1
>  Title: ORTOFOTO
>  SRS: EPSG:3301
>
>
> I have tried all possible combinations of r.in.wms options.
>
> % r.in.wms output=p_orto mapserver=http://kaart.maaamet.ee/wms/alus
> layers=of1 srs=EPSG:3301 format=tiff maxcols=255 maxrows=250 method=near
> --overwrite
> Calculating tiles...
> ERROR: r.tileset failed
>
> In the directory /home/grass/wms_download/ an empty directory p_orto was
> created.
>
> Adding the option -p results in a different error message:
>
> % r.in.wms -p output=p_orto mapserver=http://kaart.maaamet.ee/wms/alus
> layers=of1 srs=EPSG:3301 format=tiff maxcols=255 maxrows=250 method=near
> --overwrite
> Traceback (most recent call last):
>  File "/usr/local/grass-7.0.svn/scripts/r.in.wms", line 284, in 
> sys.exit(main())
>  File "/usr/local/grass-7.0.svn/scripts/r.in.wms", line 245, in main
>    request = wms_request.WMSRequest(flags, options)
>  File "/usr/local/grass-7.0.svn/etc/r.in.wms/wms_request.py", line 28, in
> __init__
>    self.__set_options()
>  File "/usr/local/grass-7.0.svn/etc/r.in.wms/wms_request.py", line 40, in
> __set_options
>    self.srs_scale = int(grass.parse_key_val(proj_srs['+to_meter']))
> NameError: global name 'proj_srs' is not defined
>
>
> The same error messages I get using r.in.wms options -c, -g, -a.
>
>
> Do I something wrong or is there some error in the r.in.wms ?
>
> The native reolution of the ortophoto at WMS server is 0.25 m, I guess.
> I tried the region resolution of 0.25, and missed maxcols and maxrows values
> in the commandline as well but no success.
> In February 2010 using some GRASS-6 version I could download small pices of
> ortophoto from this WMS server.
>
> Thanks for any assistance.
>
>
> Andres Kuusk
> Tartu Observatory, Estonia
> and...@aai.ee
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Perpendicular projection of points onto line

[Maris Nartiss]

v.profile is designed to do exactly what You are looking for.

http://grass.osgeo.org/wiki/GRASS_AddOns#v.profile

Maris.

2012/5/10 Carlos Grohmann :
> Hi all
> I'm thinking if  there is a way to project a series of points into a line,
> but this projection must be in a direction perpendicular to the line.
>
> Tks
>
> --
> Carlos Grohmann
> Sent with Sparrow
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] wms trouble

[Maris Nartiss]

Just a small correction - every WMS service provider must support
EXCEPTION=XML as a request parameter and return a XML document in case
of an error (see i.e. WMS 1.3.0 7.3.3.11). Every WMS client
implementation just playing with parameters without parsing XML is
doomed to fail (sooner or later).

Just my 0.02,
Maris.

2012. gada 25. aprīlis 14:49 Hamish  rakstīja:
> Martin Album Ytre-Eide wrote:
>> akl_srtm__0.geotiff' not recognised as a supported file format.
>>
>> ERROR: r.in.gdalwarp: gdalwarp failure.
>> ERROR: r.in.gdalwarp failed
>
> find the akl_srtm__0.geotiff file in you filesystem (probably
> in $LOCATION/wms_download/ or so) and look inside it. It probably
> contains the text of an error message instead of a tiff image.
>
> I have not yet figured a reliable cross platform way for it to
> detect that, unfortunately each wms server handles errors in their
> own way, so it is not that easy to test for. (sometimes it is
> even a graphics image which says "error" on the tile)
>
> if the "akl" you seek is in the south pacific, I may be able
> to help with alternate sources of the data. (guessing from
> airport codes)
>
>
> Hamish
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Re: Grid Mismatch while importing with 6.4.1 and 6.4.2

[Maris Nartiss]

If Your GRASS version has changed, most likely also GDAL version has
changed. Just look into GDAL changelog for any "cell is point vs cell
is area" type changes for Your raster format.
Also - for the next time don't forget to add info about raster format
You where trying to import.

Maris.

2012. gada 28. marts 16:02   rakstīja:
> Hello Markus
> So, if the same image imported in different GRASS versions to the same
> Location/Mapset, but it has a displacement of half pixel, it means that it
> was a problem in earlier version of GRASS?
> Thanks
> Antonio
>
>
> On Wed, 28 Mar 2012 14:49:42 +0200, Markus Metz
>  wrote:
>>
>> On Wed, Mar 28, 2012 at 2:06 PM,   wrote:
>>>
>>> Greetings
>>>
>>>
>>>
>>> Daniel lee suggested me that the problem might be the defined region.
>>> But,
>>> as far as I know, Defined region has no impact over importing data. This
>>> is
>>> true right?
>>
>>
>> Yes, r.in.gdal ignores the current region. The extents and resolution
>> as reported by gdalinfo for the original raster and r.info for the
>> imported raster must be identical.
>>
>> Markus M
>>>
>>>
>>> Thanks
>>>
>>> Antonio
>>>
>>>
>>>
>>> Am 27. März 2012 11:52 schrieb António
>>> Rocha :
>>>
>>>
 Greetings
 I have imported a Raster image in GRASS 6.4.1 with r.in.gdal and now,
 when
 I import the same raster (with 6.4.2) there is a grid mistmatch (more or
 less a quarter pixel) from previous import to the current import. The
 image
 is the same, the Location/Mapset also the only difference is the update
 of
 GRASS. Is this expected?
 Thanks
 Antonio
>>>
>>>
>>>
>>> ___
>>> grass-user mailing list
>>> grass-user@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] intersection between two lines vector to obtain points

[Maris Nartiss]

For the record: I created a ticket with a request to create a separate
tool with requested functionality.

http://trac.osgeo.org/grass/ticket/1627

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

Re: [GRASS-user] How to extract multiple raster values to points

[Maris Nartiss]

Hello,
I would suggest to use v.what.rast with multiple runs - one for each
of the raster maps. It's more simple than passing around coordinate
pairs.
Or if other sampling strategies are required (i.e. with bilinear
interpolation), the v.sample is the right tool.

Maris.

http://grass.osgeo.org/grass64/manuals/html64_user/v.what.rast.html
http://grass.osgeo.org/grass64/manuals/html64_user/v.sample.html

2012. gada 23. marts 18:39 Margherita Di Leo  rakstīja:
> Hi,
>
> On Fri, Mar 23, 2012 at 5:06 PM,  wrote:
>>
>> Hello,
>> I wonder if there is a way to extract/sample (eg using nearest neighbour)
>> the values from multiple rasters that correspond to a set of to vector
>> points into a table.
>> I could find a way to do this for one raster, but not for multiple
>> rasters. Has anyone done this in GRASS?
>
>
> Not sure if i got what you mean to do. With r.what you can extract the
> characteristics from multiple rasters, given the coordinates of the points
> you are interested in. If you have multiple points, you can apply r.what
> iteratively using a simple script, i.e.:
>
> #! /usr/bin/python
>
> import os, sys
> from glob import glob
> import grass.script as grass
>
> topidx = sys.argv[1]
> accMFD = sys.argv[2]
>
> fpath = 'your/path/to/coordinates/file'
>
> # coordinates is a txt file in which coordinates are stored
> coord = open( os.path.join(fpath, 'coordinates'), 'r').readlines()
> pairs = []
>
> for line in coord:
>     line = line.strip()
>     x, y = line.split('\t')
>     pairs.append( x + "," + y )
>
> r_what = grass.read_command('r.what', input = 'topidx,accMFD', east_north =
> pairs)
>
> # create a new file output
> fout = open( os.path.join(fpath, 'output'), 'w')
> fout.write(r_what)
> fout.close()
>
> Hope this helps,
> madi
>
> --
> Ing. Margherita Di Leo, Ph.D.
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] NVIZ Seg Faults

[Maris Nartiss]

Hello Rich,
with Your provided data it's not possible to tell if You can do something.
Things to check:
1) the size of Your computational region. On 32bit system You might
hit a memory limits.
2) check Your OpenGL system. Does glxinfo and glxgears work fine?
3) run nviz under gdb and generate backtrace. Still You might need to
recompile GRASS with --enable-debug to get also debug symbols for all
GRASS parts. --enable-debug is harmless and wouldn't interfere with
normal working with GRASS, it will only help to track down bugs.

Here are some notes I have made for myself on running nviz under gdb
and valgrind:
gdb $GISBASE/etc/nviz2.2/nviz
run -f "$GISBASE/etc/nviz2.2/scripts/nviz2.2_script"
elevation=elevation.dem@PERMANENT

valgrind $GISBASE/etc/nviz2.2/nviz -f
"$GISBASE/etc/nviz2.2/scripts/nviz2.2_script"
elevation=elevation.dem@PERMANENT

Maris.

2012. gada 23. marts 02:10 Rich Shepard  rakstīja:
>  The raster map directory holds 2.4G of data. Trying to run nviz causes a
> seg fault after processing ~3%:
>
> GRASS 6.5.svn (Washington):~/grassdata > nviz elev=dem_basin
> Loading raster map ...
> Segmentation fault
>
>  Anything I can do to prevent this?
>
> Rich
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user