[GRASS-user] Save the Date: GRASS Developer Summit Raleigh 2025

[Vaclav Petras via grass-user]

Dear all,

It is my pleasure to announce that we will meet in 2025 and spend time
together focused on improving GRASS GIS. Please mark your calendars for the
GRASS Developer Summit in Raleigh, May 19-24, 2025. Help us plan better by
filling out an interest form:

https://forms.gle/uzQqgayYC7F4kLCZ8

The event will be the main community meeting for 2025 and will be hosted at
North Carolina State University.

Feel free to ping me if you have any questions,
Vaclav
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] v.dissolve confusion

[Vaclav Petras via grass-user]

Hi Michael,

On Fri, 15 Mar 2024 at 20:00, Michael Barton via grass-dev <
grass-...@lists.osgeo.org> wrote:

> Any suggestions about what is wrong with either of the versions of this
> dissolve command?
>
> v.dissolve --overwrite input=alcala_subsectors@SAA2024 column=ID
> output=alcala_subsectors_dissolved@SAA2024
> aggregate_columns=group_concat(REGION),max(STRATUM),max(SECTOR),avg(SUBSECTOR),group_concat(SECTOR_ID),sum(AREA),group_concat(SURVEYED),avg(IDNUM)
> result_columns="region TEXT,stratum INTEGER,sector INTEGER,subsector
> REAL,sector_ID TEXT,area REAL,surveyed TEXT,IDnum REAL"
>

What I can say based on this command is that the equivalent command from
the manual page for NC SPM sample dataset works both in terminal and GUI
(and a similar one runs through Python in CI). So, a minimal reproducible
example would be needed.


> In both cases, I get the error:
> Option  requires all of 
>

However, perhaps this will help: This message comes from the command line
parser. This means that the parameter validation fails even before this
hits any of the code specific for v.dissolve. This is the parser simply
reading and enforcing the line "requires_all:
result_columns,aggregate_columns" which says if result_columns is provided,
aggregate_columns must be provided too. Given that the parser does not go
beyond checking the presence of parameters here, it is highly unlikely that
specific data would trigger an issue. So, maybe double check your inputs
before creating a minimal reproducible example.

Best,
Vaclav
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Renaming location to project

[Vaclav Petras via grass-user]

Dear users and developers,

We have a new development which will likely touch everyone, so I would like
to make sure that everyone is informed and can prepare for or even help
with the changes.

After years of discussions, we are renaming the "location" concept in GRASS
GIS to "project". While we confirmed we want to keep all the advantages of
the current data hierarchy in GRASS GIS, the term "location" makes
explaining and working with the hierarchy difficult. The new term "project"
was chosen for the concept because it aligns with the place the concept has
in GRASS GIS and how other software packages are using the term. The term
"project" is also already used by many people who are explaining GRASS GIS
data hierarchy in workshops, classes, and papers.

Main transition will happen for 8.4 and is designed to be backward
compatible until the 9.0 release.

Many PRs are already in place:

https://github.com/orgs/OSGeo/projects/2

This text is a summary of a longer text in the related issue:

https://github.com/OSGeo/grass/issues/3121#issuecomment-1866473182

Best,
Vaclav
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Trying to use GRASS with Jupyter note books in Windows

[Vaclav Petras via grass-user]

On Thu, 28 Sept 2023 at 16:09, Vishal Mehta  wrote:

>
> Also, can I use bash within the jupyter notebook? I'm not familiar with
> the gs.script syntax; I'm very comfortable with the old bash ways..
> so any day I would rather
> glist rast than
> gs.list_grouped(type=['raster'])
>

That's really your choice as a user of Jupyter, GRASS GIS just provides the
Python API in addition to the command line interface. The command line
interface is there and you can use it from Bash or whatever else.


> What i'm hoping for is a way to mix and match within a single workflow,
> taking advantage of things like the interactive map via python
> what-have-you's, but sticking to the bash commands for pretty much
> everything else.
>

Use the exclamation mark lines in Jupyter (with IPython kernel). That
passes the line to your operating system. If you simply want general
command line syntax, that's the way to go on any platform. With that, you
can mix and match easily and that's relatively common thing to do. I'm
doing it a lot when experimenting, but for sharing I usually go with one
syntax which then needs to be Python.


> I saw some notebooks with something like
> %%bash
> 
>
> but that didn't work for me..
>

I would have to check, but the I would guess that your Windows does not
have Bash on path? This %%bash creates quite nice experience on Linux
(locally, cloud, etc.), but I don't know if it is the right choice on
Windows, but that's up to you to decide.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Trying to use GRASS with Jupyter note books in Windows

[Vaclav Petras via grass-user]

Hi Vishal,

The executable on Windows is not called "grass" like on Linux but "grass8"
or "grass83" (to avoid a strange Python import error). That should do the
trick. If not, try simply providing a full path yourself including the
extension (C:\...\...bat).

Best,
Vaclav

On Wed, 27 Sept 2023 at 21:20, Vishal Mehta via grass-user <
grass-user@lists.osgeo.org> wrote:

> I'm trying to follow this setup:
>
> https://github.com/ncsu-geoforall-lab/GIS714-assignments/blob/main/GRASS_GIS_Foundations/JupyterOnWindows_Tutorial.ipynb
>
> I have stand-alone GRASS GIS 8.3 installed in Windows in C:\GRASS GIS 8.3
>
> I followed the  7 setup steps (changing set path to reflect that its
> installed in C:\GRASS GIS 8.3
> Then when i run this first part:
>
> import os
> import subprocess
> import sys
>
> # Ask GRASS GIS where its Python packages are.
> sys.path.append(
> subprocess.check_output(["grass", "--config", "python_path"],
> text=True).strip()
> )
>
> # Import GRASS packages
> import grass.script as gs
> import grass.jupyter as gj
> --
> I get the following error:
>
> ---FileNotFoundError
>  Traceback (most recent call last)
> Cell In[1], line 7  3 import sys  5 # Ask GRASS GIS where its Python 
> packages are.  6 sys.path.append(> 7 
> subprocess.check_output(["grass", "--config", "python_path"], 
> text=True).strip()  8 ) 10 # Import GRASS packages 11 import 
> grass.script as gs
>
> File C:\GRASS GIS 8.3\Python39\lib\subprocess.py:424, in 
> check_output(timeout, *popenargs, **kwargs)421 empty = b''422 
> kwargs['input'] = empty--> 424 return run(*popenargs, stdout=PIPE, 
> timeout=timeout, check=True,425**kwargs).stdout
>
> File C:\GRASS GIS 8.3\Python39\lib\subprocess.py:505, in run(input, 
> capture_output, timeout, check, *popenargs, **kwargs)502 
> kwargs['stdout'] = PIPE503 kwargs['stderr'] = PIPE--> 505 with 
> Popen(*popenargs, **kwargs) as process:506 try:507 
> stdout, stderr = process.communicate(input, timeout=timeout)
>
> File C:\GRASS GIS 8.3\Python39\lib\subprocess.py:951, in Popen.__init__(self, 
> args, bufsize, executable, stdin, stdout, stderr, preexec_fn, close_fds, 
> shell, cwd, env, universal_newlines, startupinfo, creationflags, 
> restore_signals, start_new_session, pass_fds, user, group, extra_groups, 
> encoding, errors, text, umask)947 if self.text_mode:948   
>   self.stderr = io.TextIOWrapper(self.stderr,949 
> encoding=encoding, errors=errors)--> 951 self._execute_child(args, 
> executable, preexec_fn, close_fds,952 pass_fds, 
> cwd, env,953 startupinfo, creationflags, shell,   
>  954 p2cread, p2cwrite,955
>  c2pread, c2pwrite,956 errread, errwrite,957  
>restore_signals,958 gid, 
> gids, uid, umask,959 start_new_session)960 
> except:961 # Cleanup if the child failed starting.962 for f 
> in filter(None, (self.stdin, self.stdout, self.stderr)):
>
> File C:\GRASS GIS 8.3\Python39\lib\subprocess.py:1420, in 
> Popen._execute_child(self, args, executable, preexec_fn, close_fds, pass_fds, 
> cwd, env, startupinfo, creationflags, shell, p2cread, p2cwrite, c2pread, 
> c2pwrite, errread, errwrite, unused_restore_signals, unused_gid, unused_gids, 
> unused_uid, unused_umask, unused_start_new_session)   1418 # Start the 
> process   1419 try:-> 1420 hp, ht, pid, tid = 
> _winapi.CreateProcess(executable, args,   1421  # 
> no special security   1422  None, None,   1423
>   int(not close_fds),   1424  
> creationflags,   1425  env,   1426
>   cwd,   1427  startupinfo)   
> 1428 finally:   1429 # Child is launched. Close the parent's copy of 
> those pipe   1430 # handles that only the child should have open.  You 
> need   (...)   1433 # pipe will not close when the child process exits 
> and the   1434 # ReadFile will hang.   1435 
> self._close_pipe_fds(p2cread, p2cwrite,   1436  
> c2pread, c2pwrite,   1437  errread, errwrite)
> FileNotFoundError: [WinError 2] The system cannot find the file specified
>
>
> Can someone help figure out what the issue is?
> Thanks,
> Vishal
> ___
> 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://

Re: [GRASS-user] how to calculate volume of water stored in water storage with r.sim.water?

[Vaclav Petras]

On Tue, 1 Aug 2023 at 10:24, bonushenricus 
wrote:

> Since I have the data in GRASS, I will try using the old geomhydas, hoping
> the modules will work in GRASS8, and then use the Mhydas models in
> OpenFluid.
>

I don't know anything about Geo-MHYDAS, but a lot of effort in GRASS GIS
goes into compatibility, so I would hope you can make it work. Anyway
sometimes breaking changes are needed and Geo-MHYDAS is definitively
written in an older style, namely with long Bash scripts with Perl helpers,
but that doesn't really matter for GRASS version compatibility as long as
you are on Linux.

https://github.com/UMR-LISAH/Geo-MHYDAS-2010
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Running canny edge detection on thinned binary image

[Vaclav Petras]

Hi Venka,

i.edge, or Canny Edge Detector, is definitely built for something else.
Lines are output, not input. However, we created i.edge together with
r.houghtransform which works on the result from i.edge or any other thin
lines. The line segments it extracts might be what you are looking for.
Maybe you are just looking for r.to.vect followed by v.to.db with azimuth,
maybe with v.split in between.

Best,
Vaclav

On Mon, 24 Jul 2023 at 06:18, Venka  wrote:

> Hi Micha,
>
> Thanks for your response.
>
> Is there any other way to generate edge_map and angle_map
> from single pixel width areas?
>
> Venka
>
> On 7/24/2023 6:23 PM, Micha Silver wrote:
> > AFAIK, the Canny algorithm requires large, wide areas of black pixels,
> adjacent
> > to large wide areas of white pixels in order to find the edge. It
> compares the
> > change in value over a wide "strip" to determine the edge.
> >
> > It's a bit counter-intuitive, but the algorithm will not work on single
> pixel
> > width areas.
> >
> >
> > On 24/07/2023 6:28, Venka wrote:
> >> Hi All,
> >>
> >> I have a question about Canny Edge Detection using i.edge
> >>
> >> 1) I produce a thinned binary image as below
> >>
> >> r.thin --overwrite input=line_element output=thinned_line_element
> >>
> >> a) the "line_element" represents valleys that are, at places, few pixel
> >> wide
> >>
> >> b) the output "thinned_line_element" represents valley lines that are
> >> a single pixel wide
> >>
> >> 2) I run the Canny edge detector on "thinned_line_element" as below
> >> i.edge --overwrite input=thin_line_element output=edge_map
> angles_map=angle_map
> >>
> >>
> >> The resultant "edge_map" produces a monotone (no edges) edge map and
> the
> >> "angle_map" outputs the angles
> >> correctly
> >>
> >> 3) Running the Canny edge detector on the un-thinned "line_element"
> >>
> >> i.edge --overwrite input=line_element@PERMANENT output=edge_map1
> >> angles_map=angle_map1
> >>
> >> produces both "edge_map1" and "angles_map1" correctly.
> >>
> >> Any idea why the Canny edge detector does not produce edge map on
> thinned image?
> >>
> >> Kind regards,
> >>
> >> Venka
> >> ___
> >> grass-user mailing list
> >> grass-user@lists.osgeo.org
> >> https://lists.osgeo.org/mailman/listinfo/grass-user
> >
> > --
> > Micha Silver
> > Ben Gurion Univ.
> > Sde Boker, Remote Sensing Lab
> > cell: +972-523-665918
> >
>
> ___
> 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] Active Tropical Cyclone Tracking with GRASS GIS and Jupyter Notebook

[Vaclav Petras]

Hi Kyaw,

I think it is fairly safe to say that GRASS GIS supports that, but someone
would need to create that specific workflow or notebook.

Best,
Vaclav


On Tue, 16 May 2023 at 23:59,  wrote:

> Hi all,
>
> I am just wondering whether GRASS GIS supports tracking active and archive
> cyclones/hurricanes/typhoons as was found in ArcGIS using living atlas and
> ArcGIS online platform.
> I noticed that they are using NOAA and other satellite sensors.
>
> Thank you very much.
>
>
> Kyaw Moe Aung
> Consultant
> PyJuliaR Consulting Firm
> ___
> 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] Map production recommendations

[Vaclav Petras]

For some use cases, you can consider the m.printws addon. It is an
alternative to ps.map (both GUI and the command line) based on the standard
d-commands.

https://grass.osgeo.org/grass-stable/manuals/addons/m.printws.html

Since we are listing options here, GMT experienced quite some revamp. I
would curious if anyone here has tried it lately.


On Fri, 12 May 2023 at 09:01, Rich Shepard  wrote:

> On Fri, 12 May 2023, Massimiliano Alvioli wrote:
>
> > I am not sure what can be done to facilitate the use of ps.map, but I can
> > tell that browsing GRASS mapsets from QGIS to create nice map figures is
> > the easiest thing to do. If you browse your "grassdata" folder from the
> > file explorer in QGIS, you must scroll down until you see GRASS icons for
> > each location. Then you can navigate to your mapset and display your
> > raster/vectors in QGIS, and use the map creator (?) tool to prepare
> > figures.
>
> Massi,
>
> ps.map has always been a low priority for improvements. While it took a lot
> of time to produce high quality output, the presention to non-technical
> decision-makers was highly satisfying. Now I have several projects needing
> such images so I installed qgis and need to learn how to use it for this
> purpose.
>
> Your instructions are really helpful and I'll apply them today to produce
> the 3 maps needed immediately.
>
> Best 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

[GRASS-user] Reminder: Community sprint planning meeting

[Vaclav Petras]

If you want to join the sprint planning meeting in an hour or so, you need
to email me to get the link.

If you already got the link from me or as a PSC member, you can ignore this
email.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Community sprint planning meeting

[Vaclav Petras]

Given the feedback I have already received, let me emphasize that the
community sprint is really for all contributors, not only code
contributors! If you are interested in translations, documentation, event
organizing, or other things, the sprint is a good time to do that.

On Fri, 10 Feb 2023 at 14:03, Vaclav Petras  wrote:

> Dear all,
>
> I'm happy to announce we are planning a community sprint for the 40th
> birthday of GRASS GIS!
>
> If you are interested, we will meet on Friday, February 17 at 15:00 UTC
> [1]. Send me an email and I will send you a Zoom link.
>
> Best,
> Vashek
>
> [1]
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2023&month=2&day=17&hour=15&min=0&sec=0&p1=179&p2=51&p3=48&p4=25&p5=197&p6=37&p7=248&p8=176
>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Community sprint planning meeting

[Vaclav Petras]

Dear all,

I'm happy to announce we are planning a community sprint for the 40th
birthday of GRASS GIS!

If you are interested, we will meet on Friday, February 17 at 15:00 UTC
[1]. Send me an email and I will send you a Zoom link.

Best,
Vashek

[1]
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2023&month=2&day=17&hour=15&min=0&sec=0&p1=179&p2=51&p3=48&p4=25&p5=197&p6=37&p7=248&p8=176
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.terrain.geom

[Vaclav Petras]

Dear Maria Cecilia,

A common procedure would be to open a pull request on GitHub for that repo,
but a much better solution would be to have that in the grass-addons repo
where all of us can help maintain it. In any case, a PR is needed which is
a strange thing when you do it the first time around:

https://github.com/OSGeo/grass-addons/blob/grass8/CONTRIBUTING.md

...but it gets better and people here or on GitHub can help.

Maybe you can contact some of the authors (of the paper or of the code) and
see if you or them can submit that to the grass-addons repo.

There might be further considerations on why this should or should not be
in the grass-addons repo, but putting it there is a good default unless
someone comes up with other suggestions.

Best,
Vaclav

On Thu, 27 Oct 2022 at 18:38, Maria Cecilia Zalazar <
zalazarmariaceci...@gmail.com> wrote:

>  data.zip
> 
> Dear Grass community, there is a very interesting grass add-on
> (r.terrain.geom) that extracts fluvial terrace-like surfaces from digital
> elevation models and also creates a pdf plot with graphs showing the
> terrain characteristics and logic of process (R interface).
> https://github.com/edinaj0zs4/terrace_extraction_grassgis
> (Józsa, E., 2019. Geomorphometric application of quasi-global DEMs for
> semi-automated geomorphological mapping. University of Pécs)
>
> My winGrass version is 8.2 and I had to modify the TERRACE_jozsa
> (R-script) in order to update the interface required package
> (rgrass instead of spgrass6). Also the ggplot2 version was necessary to
> update. I'm sending the new R script.
> Actually, this is not an available add-on script via g.extension in
> oficial repositories. I'm not sure which are the requirements to do this
> (some improvements or check?), or if it is possible to make it accessible
> via a public repository.
> I´m sending data for easy checking.
>
> Thanks very much in advance!
>
> Regards!
> ___
> 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 GIS based developing tools

[Vaclav Petras]

On Tue, 25 Oct 2022 at 03:31, Manuele Pesenti 
wrote:

> ...
>
this should be the link to the complete gist:
> https://gist.github.com/manuelep/e56fe90399c44e02e7cb97d5ef95edbd
>

What is being built by compose? Don't I need a Dockerfile?
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS GIS based developing tools

[Vaclav Petras]

Hi Manuele,

Seeing a setup with JupyterLab is always nice and useful especially if the
focus is developing and distributing GRASS procedures. A standalone
repository with everything needed would be a good starting point for
sharing such a setup and making it ready to go. I don't see a Dockerfile,
but it seems it is needed. You can compare your setup to docker and binder
directories in the main GRASS repo  and
describe how your setup is different.

Best,
Vaclav

On Mon, 24 Oct 2022 at 04:02, Manuele Pesenti 
wrote:

> Hi everyone,
> maybe this is  such an off topic for this list, I just wanted to share
> that  I wrote a docker-compose file
>  for
> building
> up an environment based on GRASS GIS for developing and distributing GRASS
> GIS based procedures.
> The main developing proposed tool in the architecture is Jupyter Lab, I
> don't know if it's such a commont tool between the component of this
> mailing-list.
> I just wanted to have some feedback to understand if it can be considered
> a useful tool.
>
> Unfortunately the readme file at the moment is in italian but the compose
> file and the commands maybe can be understood anyway.
>
> Thanks
> Best regards
>
>
> *Manuele Pesenti*
> *Software Developer and GIS Specialist*
> *Gter srl*
> *Via Jacopo Ruffini 9/1A - 16128 Genova*
> *P.IVA/CF 01998770992*
> *ph: 010-0899150*
> *www.gter.it* 
>
>
> ___
> 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 birthday toast tomorrow, July 29th!

[Vaclav Petras]

To celebrate GRASS birthday, discuss latest developments, and more, join us
in one hour using Zoom at:

https://ncsu.zoom.us/j/92129342971?pwd=Um1DSlhtYWwrL3Vwa0tlc3hzNHBQdz09

Topic: GRASS GIS Birthday 2022
Time: 15:00 UTC
Meeting ID: 921 2934 2971
Passcode: 454117


On Thu, 28 Jul 2022 at 03:33, Veronica Andreo  wrote:

> Hello everyone!!
>
> Tomorrow, the calendar marks 39 years of GRASS development! 🤓 Let's
> celebrate with some beverage and make a toast in an online meeting at 15
> UTC (See local times here:
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2022&month=7&day=29&hour=15&min=0&sec=0&p1=48&p2=25&p3=207&p4=197
> )
>
> Vashek will provide a link before the scheduled time! Keep an eye on the
> mailing list!
>
> See you tomorrow!
> Vero
>
> --
> Dra. Verónica Andreo
> Investigadora Asistente de CONICET
> Instituto Gulich (CONAE - UNC)
> Centro Espacial Teófilo Tabanera (CETT)
> Falda del Cañete - Córdoba, Argentina
> +54 3547 40 int. 1153
> https://veroandreo.gitlab.io/
> ___
> 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] GRASS GIS 8.2.0 Released

[Vaclav Petras]

I'm pleased to announce that GRASS GIS 8.2.0 was released!

The 8.2.0 release of GRASS GIS is now available with results from the GSoC
2021 and many other additions. A new grass.jupyter package is now included
for interacting with Jupyter notebooks. Single window graphical user
interface is available in GUI settings. r.series and three other modules
are newly parallelized. Additionally, the release includes a series of
scripting, packaging, and reproducibility improvements.

For all 220+ changes, see our detailed announcement with the full
contributors and list of features and bugs fixed at GitHub / Releases /
8.2.0 . Special thanks
to GSoC students, their mentors, and first-time contributors!

Packages and installers are now available for Windows, macOS, Debian,
Fedora, and Gentoo with more coming soon.

See more at grass.osgeo.org / News
.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] single window gui in main branch

[Vaclav Petras]

On Tue, Jan 11, 2022 at 7:32 PM Veronica Andreo 
wrote:

>
> ps: Indeed, maybe a tab Single-window would be much more visible and would
> highlight the feature more.
>

I think it will eventually be very visible as the default :-). Now we need
the noise so that everyone can test it in this opt-in phase.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Workaround for temporary table with SQL keywords as column names

[Vaclav Petras]

Hi Luí­s,

On Thu, Nov 4, 2021 at 12:52 PM Luí­s Moreira de Sousa via grass-user <
grass-user@lists.osgeo.org> wrote:

>
> To the question: is there a workaround for this problem? Can GRASS be
> instructed to not use SQL keywords as column names? Or somehow create valid
> SQL queries, for instance using double quotes?
>

Not an overall solution, but v.to.lines module/tool is written Python, so
adding an option which would be a prefix for names for all new columns
would be fairly straightforward.

https://github.com/OSGeo/grass/blob/main/scripts/v.to.lines/v.to.lines.py

The SQL keywords issue is not resolved, but a couple things here and there
could make it less of an issue. You can see part of the discussion in #653:

https://github.com/OSGeo/grass/commit/ff33a47ec7608d3be7116df11de8b0b4b186c654

Best,
Vaclav
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.mon start=cairo multi-layer PDF, PS, SVG output

[Vaclav Petras]

Hi Luigi,

ps.map (or g.gui.psmap/File > Cartographic Composer) is certainly an
option. You can also have a look at m.printws in addons (mentioned in the
ticket you linked), but it suffers from the same issues as the normal
display since it is using d-commands.

https://grass.osgeo.org/grass78/manuals/addons/m.printws.html

I have tried to put individual layers rendered as SVGs together manually.
That was too difficult to match, but perhaps if you clip vectors to a
computational region you can match those.

Just to be clear, are you saying the ps driver (with
GRASS_RENDER_PS_TRAILER etc) didn't work for you?

Best,
Vaclav

On Tue, Nov 9, 2021 at 9:48 AM Luigi Ponti  wrote:

> Dear list,
>
> I am replying to myself just to say that I hit the same issues as shown at:
> https://trac.osgeo.org/grass/ticket/3033
>
> My apologies for not checking that first.
>
> As I keep running into this problem, but there is not a lot of discussion
> on it, probably people have found other ways to deal with it (e.g., ps.map,
> which what I will try next).
>
> Also, I noticed that the Python way was also explored:
> https://discuss.wxpython.org/t/wx-image-postscript/25813
>
> which I was actually about to ask…
>
> Kind regards,
>
> Luigi
>
>
> On Thu, Oct 28, 2021 at 12:34 PM Luigi Ponti  wrote:
>
>> Dear all,
>>
>> I am trying to get output image files in various formats using the Cairo
>> driver, following some very useful Python scripting examples:
>> https://baharmon.github.io/python-in-grass
>>
>> When I try to map vector layers (e.g., point data) on top of raster
>> layers (say a digital elevation model);
>>
>> if I use PNG output file extension, both vector and raster layers show up
>> with points having transparent background,
>>
>> if I use PDF, PS, or SVG output file extension, only the vector layer
>> (drawn last) is shown in the output image with white background.
>>
>> Maybe the PS driver is a better option?
>>
>> Yet, I was reading this old grass-dev post that may be relevant:
>> https://marc.info/?l=grass-dev&m=146346954429631&w=2
>>
>> Kind regards,
>>
>> Luigi
>>
>>
>> Sample test function I am using follows:
>>
>> def make_map(outfile_name,
>> fig_width,
>> fig_height,
>> bg_color: Optional[str] = None,
>> file_types: Optional[list] = None):
>> """ Test ouput map figure.
>> PLEASE CHECK as PDF and PS output does not get vectors displayed on
>> top of rasters. """
>> background_color = bg_color or [NO_BG_COLOR]
>> extensions = [PNG] if file_types is None else file_types
>> for extension in extensions:
>> outfile = pathlib.Path(OUT_DIR).joinpath(f"{outfile_name}.{extension}")
>> grass.run_command("d.mon", overwrite=True,
>> start="cairo",
>> width=fig_width,
>> height=fig_height,
>> bgcolor=background_color,
>> output=outfile)
>> grass.run_command("d.rast",
>> map="raster_layer")
>> grass.run_command("d.vect",
>> map="point_vector_layer",
>> type="point",
>> color="150:0:0",
>> size=20)
>> # all other display commands
>> grass.run_command("d.mon", stop="cairo")
>>
>>
>> Bundled GRASS app for Mac from here:
>> http://grassmac.wikidot.com/downloads
>>
>> System Info:
>>
>> GRASS version: 8.0.dev
>>
>> Code revision: 32930185c
>>
>> Build date: 2021-07-01
>>
>> Build platform: x86_64-apple-darwin20.5.0
>>
>> GDAL: 3.1.4
>>
>> PROJ: 7.1.1
>>
>> GEOS: 3.8.1
>>
>> SQLite: 3.35.4
>>
>> Python: 3.8.8
>>
>> wxPython: 4.1.1
>>
>> Platform: macOS-10.16-x86_64-i386-64bit
>>
>>
>> g.version -b
>> GRASS 8.0.dev (2021)
>>
>>  ./configure
>>  --with-macosx-sdk=/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk
>> --enable-64bit --with-macosx-archs=x86_64 --with-opengl=aqua --with-openmp
>> --prefix=/Applications/GRASS-8.0.app/Contents/Resources --with-freetype
>> --with-freetype-includes=/Applications/GRASS-8.0.app/Contents/Resources/include/freetype2
>> --with-freetype-libs=/Applications/GRASS-8.0.app/Contents/Resources/lib
>> --with-gdal=/Applications/GRASS-8.0.app/Contents/Resources/bin/gdal-config
>> --with-gdal-libs=/Applications/GRASS-8.0.app/Contents/Resources/lib
>> --with-proj=/Applications/GRASS-8.0.app/Contents/Resources/bin/proj
>> --with-proj-includes=/Applications/GRASS-8.0.app/Contents/Resources/include
>> --with-proj-libs=/Applications/GRASS-8.0.app/Contents/Resources/lib
>> --with-proj-share=/Applications/GRASS-8.0.app/Contents/Resources/share/proj
>> --with-geos=/Applications/GRASS-8.0.app/Contents/Resources/bin/geos-config
>> --with-jpeg-includes=/Applications/GRASS-8.0.app/Contents/Resources/include
>> --with-jpeg-libs=//Applications/GRASS-8.0.app/Contents/Resources/lib
>> --with-png-includes=/Applications/GRASS-8.0.app/Contents/Resources/include
>> --with-png-libs=/Applications/GRASS-8.0.app/Contents/Resources/lib
>> --with-tiff-includes=/Applications/GRASS-8.0.app/Contents/Resources/include
>> --with-tiff-libs=/Applications/GRASS-8.0.app/Contents/Resources/lib
>> --with-postgres=yes
>> --with-postgres-includes=/Applications/GRASS-8.0.app/Contents/Resources/include
>> --with-postgres-libs=/Applicatio

Re: [GRASS-user] compiling grass-7.8.5 on conda environment

[Vaclav Petras]

On Fri, Aug 6, 2021 at 1:33 AM Laura Poggio  wrote:

> Hi Vaclav,
> thanks a lot. Your patch worked perfectly. The remaining problems were
> solved by loading the conda environment path into LD_LIBRARY.
>

That's what I do there.


>
> I will look into your repository if there is a better solution.
>

Not a one I know of, but I wouldn't mind using something else. I think the
reason for this being needed during compilation is that the things in GRASS
GIS are actually running during compilation (modules help to generate parts
of documentation).

However, feel free to check my scripts there. It is a fully reproducible
build workflow on our HPC, but maybe just a little adaptation is needed.


> But at least the environment works and grass can be updated to 7.8 and
> python3.
>

The scripts can install multiple versions which is good just for updating
to latest release as need while keeping the old versions around for
reproducibility. We are using it to be able to use also the development
versions and update them often without disturbing people who are using them.

Let me know if anything there needs more explanation.

Vaclav


>
> Thanks a lot again
> Laura
>
> On Tue, 3 Aug 2021 at 17:21, Laura Poggio  wrote:
>
>> Hi Vaclav,
>> thanks a lot!
>> with the patch for the makefile in the repository I managed to solve the
>> previous error. Now I am getting a different error apparently linked to
>> some library conflict (same combination of libraries works in a different
>> environment):
>>
>> /home/user/conda3/envs/sg_py3_geo//lib//libspatialite.so.7: undefined
>> reference to `GEOSFrechetDistance'
>> /home/user/conda3/envs/sg_py3_geo//lib//libspatialite.so.7: undefined
>> reference to `GEOSFrechetDistance_r'
>> /home/user/conda3/envs/sg_py3_geo//lib//libspatialite.so.7: undefined
>> reference to `GEOSFrechetDistanceDensify'
>> /home/user/conda3/envs/sg_py3_geo//lib//libgdal.so.27: undefined
>> reference to `GEOSMakeValid_r'
>> /home/user/conda3/envs/sg_py3_geo//lib//libspatialite.so.7: undefined
>> reference to `GEOSFrechetDistanceDensify_r'
>>
>> Tomorrow I will try again with a clean conda environment implementing all
>> of your scripts.
>> Thanks a lot!
>>
>> Laura
>>
>>
>>
>> On Tue, 3 Aug 2021 at 15:32, Vaclav Petras  wrote:
>>
>>> Hi Laura,
>>>
>>> See whether the following is helpful to you. It uses everything from
>>> conda and has some local fixes for iconv. I didn't test 7.8.5 specifically,
>>> only the 7.8 release branch.
>>>
>>> GRASS GIS on HPC Henry2
>>> https://github.com/ncsu-geoforall-lab/grass-gis-on-hpc-henry2/
>>>
>>> Some more comments:
>>>
>>> On Tue, Aug 3, 2021 at 9:12 AM Laura Poggio 
>>> wrote:
>>>
>>>>
>>>> I am trying to compile grass 7.8.5 in a conda environment (on centos7,
>>>> managed HPC) adapting this instructions here
>>>> <https://github.com/GRASS-GIS/grass-gis-experimental-ci/blob/conda-compile/configure.sh>
>>>> .
>>>>
>>>
>>> Nobody touched that repo for a while, but development happened
>>> elsewhere. We have a CentOS 7 build partially using conda in the main
>>> repo's CI. However, my experience was that the CentOS 7 Docker container in
>>> CI was very different from the CentOS 7 environment on HPC which has many
>>> customizations.
>>>
>>> https://github.com/OSGeo/grass/blob/master/.github/workflows/centos.yml
>>>
>>> There is also a conda-based build for macOS, but that would need to be
>>> adapted
>>>
>>>
>>>> conda create -y -n $conda_env python=3.8.5
>>>> conda activate $conda_env
>>>> conda install -c conda-forge geos gdal==3.3.1 -y
>>>> conda install -c conda-forge pdal fftw -y
>>>> conda install -c biobuilds libxml2
>>>> conda install -c conda-forge libiconv
>>>>
>>>
>>> The GRASS GIS on Henry 2 repo has an environment file you can use.
>>>
>>>
>>>>
>>>> compile works well. make gives a lot of errors. When I run make again
>>>> in one of the folder, I get this errors:
>>>> /home/user/grasspy3/grass-7.8.5/dist.x86_64-pc-linux-gnu/lib/
>>>> libgrass_gis.7.8.so: undefined reference to `libiconv'
>>>> /home/user/grasspy3/grass-7.8.5/dist.x86_64-pc-linux-gnu/lib/
>>>> libgrass_gis.7.8.so: undefined reference to `libiconv_open'
>>>> /home/user/grasspy3/grass-7.8.5/dist.x86_64-

Re: [GRASS-user] compiling grass-7.8.5 on conda environment

[Vaclav Petras]

Hi Laura,

See whether the following is helpful to you. It uses everything from conda
and has some local fixes for iconv. I didn't test 7.8.5 specifically, only
the 7.8 release branch.

GRASS GIS on HPC Henry2
https://github.com/ncsu-geoforall-lab/grass-gis-on-hpc-henry2/

Some more comments:

On Tue, Aug 3, 2021 at 9:12 AM Laura Poggio  wrote:

>
> I am trying to compile grass 7.8.5 in a conda environment (on centos7,
> managed HPC) adapting this instructions here
> 
> .
>

Nobody touched that repo for a while, but development happened elsewhere.
We have a CentOS 7 build partially using conda in the main repo's CI.
However, my experience was that the CentOS 7 Docker container in CI was
very different from the CentOS 7 environment on HPC which has many
customizations.

https://github.com/OSGeo/grass/blob/master/.github/workflows/centos.yml

There is also a conda-based build for macOS, but that would need to be
adapted


> conda create -y -n $conda_env python=3.8.5
> conda activate $conda_env
> conda install -c conda-forge geos gdal==3.3.1 -y
> conda install -c conda-forge pdal fftw -y
> conda install -c biobuilds libxml2
> conda install -c conda-forge libiconv
>

The GRASS GIS on Henry 2 repo has an environment file you can use.


>
> compile works well. make gives a lot of errors. When I run make again in
> one of the folder, I get this errors:
> /home/user/grasspy3/grass-7.8.5/dist.x86_64-pc-linux-gnu/lib/
> libgrass_gis.7.8.so: undefined reference to `libiconv'
> /home/user/grasspy3/grass-7.8.5/dist.x86_64-pc-linux-gnu/lib/
> libgrass_gis.7.8.so: undefined reference to `libiconv_open'
> /home/user/grasspy3/grass-7.8.5/dist.x86_64-pc-linux-gnu/lib/
> libgrass_gis.7.8.so: undefined reference to `libiconv_close'
>

I was not able to create a proper fix for GRASS GIS configuration, but the
repo has a somewhat hacky patch applied locally which injects libiconv into
more places.

Let me know how this goes. With the scripts in GRASS GIS on Henry 2, I can
install new versions easily, but I would like to see it more streamlined
with less local customizations.

Best,
Vaclav


>
> I found this answer
> ,
> but I am not sure how to continue from there.
> Thanks a lot
> Laura
>
> ___
> 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] Restructuring the Addons repository

[Vaclav Petras]

Dear users and developers,

Please review or participate in the discussion about and transition to the
new Addons repository layout for GRASS GIS version 8.

Most detailed plan is laid out in the following grass-addons issue:

https://github.com/OSGeo/grass-addons/issues/528

Thanks for taking your time to review this,
Vaclav
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Code sprint is now (OGC-OSGeo-ASF 2021)

[Vaclav Petras]

Code sprint is now!

Agenda and all:

https://github.com/opengeospatial/joint-ogc-osgeo-asf-sprint-2021/

GRASS GIS page (edit using a PR):

https://github.com/opengeospatial/joint-ogc-osgeo-asf-sprint-2021/blob/master/group/OSGeoGRASS.adoc

List of OSGeo participants (add yourself):

https://wiki.osgeo.org/wiki/Joint_OGC_OSGeo_ASF_Sprint_2021

Post you plan here:

https://github.com/opengeospatial/joint-ogc-osgeo-asf-sprint-2021/issues/2

Working on stuff in the main repo? Add it here:

https://github.com/OSGeo/grass/projects/5

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

[GRASS-user] Statement Vaclav Petras

[Vaclav Petras]

Dear GRASS community,

Thank you for a nomination for a second term at PSC. I've been at PSC since
2016 and a core developer since 2012. I'm working in academia mostly on
developing or helping people to develop code for research. I think I have
touched a lot of files in the GRASS GIS code base, but according to the
command below [1], it is only 16.5%. I presented GRASS GIS at various
conferences and taught it to graduate students and at workshops. My
favorite presentation I did is perhaps *33 Years Of GRASS GIS As An
Innovation Platform* [2, 3].

As a PSC member, I will vote for sponsoring crucial or special project
needs on top of sprints and promotion what we did so far. Additionally, I
would like to see more support and promotion within the project for people
and organizations which provide some kind of GRASS GIS support or services
as part of their business. For example, I think that a developer seeking
crowdfunding should not only be supported by the project, but there should
be an established and ongoing process of doing that. Therefore, I will
support proposals which make promotion, sponsoring, customer-contractor
matching, and contributing and thanking by money more common and present in
our community.

Best,
Vaclav

[1] python -c "print(100 * $(git log --pretty='%H' --author='wenzeslaus' |
while read commit_hash; do git show --oneline --name-only $commit_hash |
tail -n+2; done | sort | uniq | xargs ls -d 2>/dev/null | wc -l) / $(git
ls-tree -r master --name-only | wc -l))"
[2] https://ncsu-geoforall-lab.github.io/grass-as-a-platform/ncgis2017.html
[3] https://youtu.be/Vv5NnPg6MOY
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] New Grass start menu

[Vaclav Petras]

Hi Eric,

On Tue, Nov 24, 2020 at 2:31 PM Eric Patton 
wrote:

>
> I am using the 2020-11-24 weekly generic Linux build, and I can't seem to
> launch
> the start menu using the [--text|--gtext|--gui] flags. When I invoke
> grass79, I
> am taken immediately into the last-used Location and Mapset, without ever
> seeing
> any start menu.


--text always started in the last used location/mapset. No Startup Window
presented. No change there, but...

--gui now behaves the same since #767 [1]. It starts in the last used
mapset. This pairs well with another change which opens the GUI in the Data
tab where you can change the mapset if needed. The Data tab has all
features of the Startup Window and much much more. There is more to be said
about this, but I will just add that we are now evaluating how well it
works.

--gtext: we are now seeking feedback about how this should behave or if it
is even needed.

I checked my grassrc, and there doesn't seem to be anything
> offending in there. I'm running it on Linux Mint 19.3.
>

If there would be anything wrong or the last used mapset is simply already
in use, you should actually get the Startup Window with both --gui and
--gtext at this point.

I hope this clarifies it and I'm now curious about what you think. You can
quickly get some info from Linda's slides [2] and some more details from
development wiki pages [3, 4].

Vaclav

[1] https://github.com/OSGeo/grass/pull/767
[2] https://drive.google.com/file/d/1dMTAKSW43P3lmIdcSIxRASDomIGxTyJL/view
[3]
https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup#NewGUIStartupPresentationandFeedbackAugust312020
[4] https://trac.osgeo.org/grass/wiki/GSoC/2020/StartupWindow
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] The new GRASS start menu

[Vaclav Petras]

Thank you, Hernán. This is great to hear and yes, we are looking for
feedback. A big chunk of work was done by Linda Kladivova during GSoC 2020.
This is still an ongoing process, so you may receive more requests for
feedback from Linda soon.

On Mon, Oct 26, 2020 at 5:46 AM Hernán De Angelis <
variablestarli...@gmail.com> wrote:

> Hi everyone
>
> I just got and installed the latest master and was positively surprised
> by the new GRASS start menu.
>
> This is for me a step forward in making live easier for newcommers to
> GRASS GIS.
>
> Kudos to all who have worked with this.
>
> /Hernán
>
>
> ___
> 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] New GUI Startup Presentation and Feedback

[Vaclav Petras]

Dear users and devs,

If you want to see the main points we discussed during the video call,
please go to the New Startup wiki page on Trac (if you participated in the
call, please feel free to extend):

https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup#NewGUIStartupPresentationandFeedbackAugust312020

If you didn't get a chance to join the call or missed a part of it, you can
also read Linda's final report at the following link where, at the very
bottom, you will also find a link to the slide deck Linda used to give an
overview of the new features.

https://trac.osgeo.org/grass/wiki/GSoC/2020/StartupWindow#FinalReport

If you find a bug or have a wish for the new startup procedure, data
catalog, or location wizard, please open a new issue on GitHub.

Best,
Vaclav


On Fri, Aug 28, 2020 at 4:40 PM Vaclav Petras  wrote:

> Dear users and devs,
>
> I'm delighted to inform you that we completed an important phase in a
> revamp of the GRASS GIS startup workflow using GUI. Special thanks goes to
> Linda Kladivova who worked on this in her GSoC project this summer.
>
> The changes to the startup workflow are significant - probably the biggest
> since the introduction of the Tcl/Tk GUI (!), definitely since GRASS GIS
> 6.4 - so you don't want to miss these news.
>
> Please join us on Monday, August 31, at 18:00 UTC, for a video call where
> Linda and the GSoC mentors will present the updates and everybody will have
> an opportunity to give feedback on what was done and what should be done in
> the future.
>
>
> https://www.timeanddate.com/worldclock/converter.html?iso=20200831T18&p1=1440&p2=204&p3=195&p4=51&p5=179&p6=248&p7=176
>
> You are especially welcome to join us if you did not participate in the
> previous calls as Linda will explain all the recent changes and newly added
> features.
>
> The call is open to anybody on grass-user or grass-dev. Note that we will
> create a private recording of the meeting for the purpose of Linda's master
> thesis.
>
> I will share a Zoom link here right before the call.
>
> Best,
> Vaclav
>
> PS: If you are answering this email, I cross posted it to both user and
> dev mailing lists, so you may want to take care to reply to just one
> mailing list. You can contact me privately too if you have any questions or
> concerns.
>
> Resources:
>
> Notes from the previous calls:
>
> https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup#NewGUIstartupvideocallMay142020
>
> GSoC 2020 Page:
> https://trac.osgeo.org/grass/wiki/GSoC/2020/StartupWindow
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] New GUI Startup Presentation and Feedback

[Vaclav Petras]

See you in one hour.

New GUI Startup Presentation and Feedback: Presentation of and discussion
about the GSoC 2020 results. A private recording for the purpose of Linda's
master thesis will be created.

Aug 31, 2020 18:00 UTC

Join Zoom Meeting
https://ncsu.zoom.us/j/92820641586?pwd=ZzJqUFJmaWFTUTRmREJTRGF5OFF6UT09

Vaclav

On Fri, Aug 28, 2020 at 4:40 PM Vaclav Petras  wrote:

> Dear users and devs,
>
> I'm delighted to inform you that we completed an important phase in a
> revamp of the GRASS GIS startup workflow using GUI. Special thanks goes to
> Linda Kladivova who worked on this in her GSoC project this summer.
>
> The changes to the startup workflow are significant - probably the biggest
> since the introduction of the Tcl/Tk GUI (!), definitely since GRASS GIS
> 6.4 - so you don't want to miss these news.
>
> Please join us on Monday, August 31, at 18:00 UTC, for a video call where
> Linda and the GSoC mentors will present the updates and everybody will have
> an opportunity to give feedback on what was done and what should be done in
> the future.
>
>
> https://www.timeanddate.com/worldclock/converter.html?iso=20200831T18&p1=1440&p2=204&p3=195&p4=51&p5=179&p6=248&p7=176
>
> You are especially welcome to join us if you did not participate in the
> previous calls as Linda will explain all the recent changes and newly added
> features.
>
> The call is open to anybody on grass-user or grass-dev. Note that we will
> create a private recording of the meeting for the purpose of Linda's master
> thesis.
>
> I will share a Zoom link here right before the call.
>
> Best,
> Vaclav
>
> PS: If you are answering this email, I cross posted it to both user and
> dev mailing lists, so you may want to take care to reply to just one
> mailing list. You can contact me privately too if you have any questions or
> concerns.
>
> Resources:
>
> Notes from the previous calls:
>
> https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup#NewGUIstartupvideocallMay142020
>
> GSoC 2020 Page:
> https://trac.osgeo.org/grass/wiki/GSoC/2020/StartupWindow
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] New GUI Startup Presentation and Feedback

[Vaclav Petras]

Dear users and devs,

I'm delighted to inform you that we completed an important phase in a
revamp of the GRASS GIS startup workflow using GUI. Special thanks goes to
Linda Kladivova who worked on this in her GSoC project this summer.

The changes to the startup workflow are significant - probably the biggest
since the introduction of the Tcl/Tk GUI (!), definitely since GRASS GIS
6.4 - so you don't want to miss these news.

Please join us on Monday, August 31, at 18:00 UTC, for a video call where
Linda and the GSoC mentors will present the updates and everybody will have
an opportunity to give feedback on what was done and what should be done in
the future.

https://www.timeanddate.com/worldclock/converter.html?iso=20200831T18&p1=1440&p2=204&p3=195&p4=51&p5=179&p6=248&p7=176

You are especially welcome to join us if you did not participate in the
previous calls as Linda will explain all the recent changes and newly added
features.

The call is open to anybody on grass-user or grass-dev. Note that we will
create a private recording of the meeting for the purpose of Linda's master
thesis.

I will share a Zoom link here right before the call.

Best,
Vaclav

PS: If you are answering this email, I cross posted it to both user and dev
mailing lists, so you may want to take care to reply to just one mailing
list. You can contact me privately too if you have any questions or
concerns.

Resources:

Notes from the previous calls:
https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup#NewGUIstartupvideocallMay142020

GSoC 2020 Page:
https://trac.osgeo.org/grass/wiki/GSoC/2020/StartupWindow
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS GIS Birthday Virtual Celebration

[Vaclav Petras]

See you in one hour. The link is:

https://ncsu.zoom.us/j/92325670198?pwd=QkNrWHpWSk5nNTJCRmlidXNCalJBdz09
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] GRASS GIS Birthday Virtual Celebration

[Vaclav Petras]

Dear GRASS GIS users and developers,

On Wednesday, July 29, we will celebrate GRASS GIS birthday!

Please, join us in a video call at 19:00 UTC. I will send a link to the call
here right before the meeting. We will use Zoom.

https://www.timeanddate.com/worldclock/converter.html?iso=20200729T19&p1=1440&p2=204&p3=195&p4=51&p5=207&p6=671

We will ponder the long history, perhaps question some technological
decisions, discuss some current issues, and think about the future of GRASS
GIS.

If you think this is not enough celebratory, bring your most complicated
GRASS GIS workflow. What would be a better way to celebrate than to explain
an obscure command from 10 years ago?

Best,
Vashek

PS: You can let me know privately if you have any questions or concerns
about joining this video call.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Change color letters from Layer Manager

[Vaclav Petras]

Hi Maurício,

Unfortunately, these can't be customized, but they can be fixed. However, I
don't have that problem on 20.04. Perhaps a different theme? Can you please
open a new issue on GitHub with a screenshot and more details?

Thanks,
Vaclav

On Thu, May 21, 2020 at 11:51 AM Maurício Vancine <
mauricio.vanc...@gmail.com> wrote:

> Dear,
>
> Is there a way to change the color of the layer letters added in the Layer
> Manager?
>
> In Ubuntu 20.04, the color of the layers is white and is a bit confusing
> to see.
>
> If it's a configuration of Ubuntu itself, I apologize for the
> inconvenience, but I couldn't change it here.
>
> Thank you!
> --
> *Maurício Humberto Vancine*
> Ecólogo (ABE n. 2018007), Mestre em Zoologia e Doutorando em Zoologia
> Universidade Estadual Paulista (UNESP), Rio Claro, SP, Brasil
>
> Site  | Lattes
>  | Google Scholar
>  | ORCID
>  | Publons
>  | GitHub
> 
>
>
> ___
> 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] Fwd: Gecomputation web-seminars (GDAL, PKTOOLS, GRASS, HPC)

[Vaclav Petras]

I just wanted to highlight this again because of the dedicated GRASS GIS
seminar:

Intro to advanced GRASS GIS on Wednesday from Yale Center for Research
Computing. Something to share with your colleagues. Registration is still
open (and free).

Introduction to GRASS GIS

may 13, 2020
9:00 - 11:30 AM EDT
(IN ENGLISH, Via Zoom: REGISTER; Via YOUTUBE )
1:00 - 3:30 PM EDT
(En Español, via zoom: REGISTER; Via YOUTUBE )
This workshop introduces students to the powerful GRASS GIS software to
manipulate raster and vector data, and covers using the graphical user
interface and simple Bash scripts to automate many common geo-data
processing tasks such as cropping and re-projecting images, and how to
script processes for complex geo-functions.
REGISTER

[image: Globe with GRASS logo]

On Fri, May 8, 2020 at 1:37 PM Giuseppe Amatulli <
giuseppe.amatu...@gmail.com> wrote:

>
>
> -- Forwarded message -
> From: Giuseppe Amatulli 
> Date: Fri, 8 May 2020 at 13:35
> Subject: Gecomputation web-seminars (GDAL, PKTOOLS, GRASS, HPC)
> To: 
>
>
> Dear Colleagues,
> In reference to the Gecomputation web-seminars starting on Monday, May
> 11th 2020, below you can find the youtube hyperlink for the live streaming.
> After the event, the youtube videos will be linked to my youtube channel
> 
> .
> Please register if you want to follow via zoom and also if you want have
> the instructions to access to the Linux Virtual Machine.
> Please disseminate.
> Best regards
> Giuseppe Amatulli
>
> -- Forwarded message -
> From: Giuseppe Amatulli 
> Date: Thu, 30 Apr 2020 at 11:45
> Subject: Gecomputation web-seminars (GDAL, PKTOOLS, GRASS, HPC)
> To: 
>
>
> Dear Colleagues,
>
> During the second week of May (Eastern Daylight Time), I will be teaching
> 4 web-seminars for enhancing *gecomputation skills to process large
> geographic data*.
> Each of these seminars will be held in both *English* and *Spanish*.
> Participants will be given access to a cloud-based Linux virtual machine
> that can be reached via an SSH tunnel.
> Please distribute the details of these seminars among your colleagues and
> students.
>
> To view this email as a web page, go here.
> 
> [image: Yale Center for Research Computing]
>
> Raster/Vector Processing using GDAL/OGR
> 
> may 11, 2020
> 9:00 - 11:30 AM EDT
> (IN ENGLISH, VIA ZOOM: register; VIA YOUTUBE
> )
> 1:00 - 3:30 PM EDT
> (En Español, via zoom: REGISTER; Via YOUTUBE
> )
>
> The workshop covers geo-data processing tasks: cropping and re-projecting,
> mosaicing, and filtering images, and how to script processes for complex
> geo-functions.
> REGISTER
> 
> [image: Globe with GDAL logo]
> Image Processing using Pktools
> 
> may 12, 2020
> 9:00 - 11:30 AM EDT
> (IN ENGLISH, Via Zoom: REGISTER; Via YOUTUBE
> )
> 1:00 - 3:30 PM EDT
> (En Español, via zoom: REGISTER; Via YOUTUBE
> )
> This workshop will focus on Processing Kernel for geospatial data
> (Pktools) to perform remote sensing image analysis. The workshop will
> include examples of mosaicing, filtering, histogram, masking, and raster
> re-classification.
> REGISTER
> 
> [image: Globe with Pktools logo]
> Introduction to GRASS GIS
> 
> may 13, 2020
> 9:00 - 11:30 AM EDT
> (IN ENGLISH, Via Zoom: REGISTER; Via YOUTUBE
> )
> 1:00 - 3:30 PM EDT
> (En Español, via zoom: REGISTER; Via YOUTUBE
> )
> This workshop introduces students to the 

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

[Vaclav Petras]

On Thu, Apr 30, 2020 at 9:59 PM Vaclav Petras  wrote:

> Dear users and devs,
>
> I though it would be a good idea to video meet next week and talk about
> what would be the best way of releasing GRASS GIS in the future. As always,
> both contributors and users are invited to share ideas and opinions.
>
> ...
>
> PS: If you are answering to this email, I cross posted it to both user and
> dev mailing lists, so you may want to take care to reply to just one
> mailing list.
>

Scenario 2 on the following page is my attempt to capture the main scenario
we talked about during the call. Thanks to all who participated!

https://trac.osgeo.org/grass/wiki/Release/Schedule
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[Vaclav Petras]

New URL (Zoom):

https://ncsu.zoom.us/j/95921808290?pwd=UnVOa0VHN2gvbWJLbDExNEJ4TWU3Zz09
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[Vaclav Petras]

The link to meeting today is below. We are starting in two hours at 18:00
UTC

.

https://meet.jit.si/lets-talk-grass-releases
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[Vaclav Petras]

Dear all,

I closed the poll and picked the most . We will meet 18:00 UTC using Jitsi.
I will post a link to the meeting to this thread (grass-dev and grass-user)
right before the meeting.

https://www.timeanddate.com/worldclock/converter.html?iso=20200505T18&p1=1440&p2=204&p3=195&p4=51&p5=207&p6=671

If you want to read something ahead of time, here are some links:

https://trac.osgeo.org/grass/wiki/Release/Schedule
https://www.qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule
https://grasswiki.osgeo.org/wiki/Talk:GRASS_GIS_Community_Sprint_Prague_2019#Also_discussed

See you soon,
Vaclav


On Thu, Apr 30, 2020 at 9:59 PM Vaclav Petras  wrote:

> Dear users and devs,
>
> I though it would be a good idea to video meet next week and talk about
> what would be the best way of releasing GRASS GIS in the future. As always,
> both contributors and users are invited to share ideas and opinions.
>
> I'm thinking to meet for one hour. Here is a Doodle poll for the date and
> times:
>
> https://doodle.com/poll/bd3g9nfzurtdeg6i
> (Times should show in your local time and are between 17:00-22:00 UTC.)
>
> If this works, and based on the website video discussion it seems it does,
> we could meet in semi-regular fashion in the future.
>
> Best,
> Vaclav
>
> PS: If you are answering to this email, I cross posted it to both user and
> dev mailing lists, so you may want to take care to reply to just one
> mailing list.
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[Vaclav Petras]

On Thu, Apr 30, 2020 at 10:47 PM Rich Shepard 
wrote:

> On Thu, 30 Apr 2020, Vaclav Petras wrote:
>
> > I though it would be a good idea to video meet next week and talk about
> > what would be the best way of releasing GRASS GIS in the future. As
> > always, both contributors and users are invited to share ideas and
> > opinions.
> >
> > I'm thinking to meet for one hour. Here is a Doodle poll for the date and
> > times:
>
> Vaclav,
>
> What would be the agenda? Will you and the other devs present options while
> every participant contributes they opinion? What are the issues with the
> current way of releasing GRASS upgrades? Are you looking for solutions to
> those issues or a choice among a few solutions?
>

There was couple related discussions in the past here and there (see
below), so it's time to discuss this properly.

https://grasswiki.osgeo.org/wiki/Talk:GRASS_GIS_Community_Sprint_Prague_2019#Also_discussed
https://github.com/OSGeo/grass/pull/333#issuecomment-584859963
https://lists.osgeo.org/pipermail/grass-dev/2020-April/094340.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[Vaclav Petras]

Dear users and devs,

I though it would be a good idea to video meet next week and talk about
what would be the best way of releasing GRASS GIS in the future. As always,
both contributors and users are invited to share ideas and opinions.

I'm thinking to meet for one hour. Here is a Doodle poll for the date and
times:

https://doodle.com/poll/bd3g9nfzurtdeg6i
(Times should show in your local time and are between 17:00-22:00 UTC.)

If this works, and based on the website video discussion it seems it does,
we could meet in semi-regular fashion in the future.

Best,
Vaclav

PS: If you are answering to this email, I cross posted it to both user and
dev mailing lists, so you may want to take care to reply to just one
mailing list.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Question with algorithm 'r.mapcalc.simple' from QGIS GUI

[Vaclav Petras]

On Sun, Apr 5, 2020 at 2:51 PM Valter Albino  wrote:

> I can see it [https://grass.osgeo.org/grass78/manuals/r.mapcalc.html].
> Altought for the example that was presented the syntax doesn't work, it's
> a fine solution, thanks Pedro!
>

Hi, I'm getting back to this to ask about the example with syntax which
does not work. What example are you talking about?


>
> Pedro Venâncio  escreveu no dia domingo,
> 5/04/2020 à(s) 19:31:
>
>> Valter logical and in GRASS is &&.
>>
>> Best regards,
>> Pedro
>>
>>
>> A domingo, 5/04/2020, 19:11, Valter Albino 
>> escreveu:
>>
>>> OK, it doesn't support this type of function: "Undefined function
>>> 'logical_and'"
>>> Hey, but GDAL raster calculator in QGIS GUI does!
>>>
>>> Cumprimentos,
>>> *Valter Albino -* Geógrafo Físico, M.Sc.
>>> Modelação H&H / Riscos ambientais / OT&U
>>> www.valteralbino.wixsite.com/hydrodynamics
>>>
>>>
>>> Valter Albino  escreveu no dia domingo,
>>> 5/04/2020 à(s) 18:50:
>>>
 Hi

 Searching for a solution do compute a simple "if else" expression with
 'r.mapcalc.simple' from QGIS GUI.
 Don't understand the following message. Someone have any clue?

 QGIS version: 3.12.1-București

 QGIS code revision: 121cc00ff0

 Qt version: 5.11.2

 GDAL version: 3.0.4

 GEOS version: 3.8.1-CAPI-1.13.3

 PROJ version: Rel. 6.3.1, February 10th, 2020

 Processing algorithm…

 Algorithm 'r.mapcalc.simple' starting…

 Input parameters:

 { 'GRASS_RASTER_FORMAT_META' : '', 'GRASS_RASTER_FORMAT_OPT' : '',
 'GRASS_REGION_CELLSIZE_PARAMETER' : 5, 'GRASS_REGION_PARAMETER' :
 '-59062.1289,-38278.9651,-78283.947,-59308.1937 [EPSG:3763]', 'a' :
 'H:/recLUvalue.tif', 'b' : 'H:/recSoilNu.tif', 'c' : None, 'd' : None, 'e'
 : None, 'expression' : '99*(A==1) + 91*logical_and(A==2, B==1) +
 94*logical_and(A==2, B==2) + 96*logical_and(A==2, B==3) +
 97*logical_and(A==2, B==4) + 93*logical_and(A==3, B==1) +
 95*logical_and(A==3, B==2) + 97*logical_and(A==3, B==3) +
 97*logical_and(A==3, B==4) + 91*logical_and(A==4, B==1) +
 94*logical_and(A==4, B==2) + 96*logical_and(A==4, B==3) +
 97*logical_and(A==4, B==4) + 78*logical_and(A==5, B==1) +
 86*logical_and(A==5, B==2) + 91*logical_and(A==5, B==3) +
 92*logical_and(A==5, B==4) + 100*(A==1) + 79*logical_and(A==8, B==1) +
 87*logical_and(A==8, B==2) + 91*logical_and(A==8, B==3) +
 93*logical_and(A==8, B==4) + 78*logical_and(A==9, B==1) +
 86*logical_and(A==9, B==1) + 91*logical_and(A==9, B==2) +
 93*logical_and(A==9, B==3) + 72*logical_and(A==11, B==1) +
 84*logical_and(A==11, B==2) + 90*logical_and(A==11, B==3) +
 92*logical_and(A==11, B==4) + 45*logical_and(A==12, B==1) +
 71*logical_and(A==12, B==2) + 79*logical_and(A==12, B==3) +
 84*logical_and(A==12, B==4) + 50*logical_and(A==13, B==1) +
 76*logical_and(A==13, B==2) + 85*logical_and(A==13, B==3) +
 89*logical_and(A==13, B==4) + 75*logical_and(A==14, B==1) +
 87*logical_and(A==14, B==2) + 93*logical_and(A==14, B==3) +
 96*logical_and(A==14, B==4)', 'f' : None, 'output' : 'TEMPORARY_OUTPUT' }


 g.proj -c proj4="+proj=tmerc +lat_0=39.668258333
 +lon_0=-8.133108 +k=1 +x_0=0 +y_0=0 +ellps=GRS80
 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs"

 r.in.gdal input="H:\recLUvalue.tif" band=1 output="rast_5e8a18a12ad402"
 --overwrite -o

 r.in.gdal input="H:\recSoilNu.tif" band=1 output="rast_5e8a18a12ad403"
 --overwrite -o

 g.region n=-59308.1937 s=-78283.947 e=-38278.9651 w=-59062.1289 res=5.0

 r.mapcalc.simple a=rast_5e8a18a12ad402 b=rast_5e8a18a12ad403
 expression="99*(A==1) + 91*logical_and(A==2, B==1) + 94*logical_and(A==2,
 B==2) + 96*logical_and(A==2, B==3) + 97*logical_and(A==2, B==4) +
 93*logical_and(A==3, B==1) + 95*logical_and(A==3, B==2) +
 97*logical_and(A==3, B==3) + 97*logical_and(A==3, B==4) +
 91*logical_and(A==4, B==1) + 94*logical_and(A==4, B==2) +
 96*logical_and(A==4, B==3) + 97*logical_and(A==4, B==4) +
 78*logical_and(A==5, B==1) + 86*logical_and(A==5, B==2) +
 91*logical_and(A==5, B==3) + 92*logical_and(A==5, B==4) + 100*(A==1) +
 79*logical_and(A==8, B==1) + 87*logical_and(A==8, B==2) +
 91*logical_and(A==8, B==3) + 93*logical_and(A==8, B==4) +
 78*logical_and(A==9, B==1) + 86*logical_and(A==9, B==1) +
 91*logical_and(A==9, B==2) + 93*logical_and(A==9, B==3) +
 72*logical_and(A==11, B==1) + 84*logical_and(A==11, B==2) +
 90*logical_and(A==11, B==3) + 92*logical_and(A==11, B==4) +
 45*logical_and(A==12, B==1) + 71*logical_and(A==12, B==2) +
 79*logical_and(A==12, B==3) + 84*logical_and(A==12, B==4) +
 50*logical_and(A==13, B==1) + 76*logical_and(A==13, B==2) +
 85*logical_and(A==13, B==3) + 89*logical_and(A==13, B==4) +
 75*logical_and(A==14, B==1) + 87*logical_and(A==14, B==2) +
 93*logical_and(A==14, B==3) + 96*logica

Re: [GRASS-user] d.mon and world file

[Vaclav Petras]

Hi Martin,

On Mon, Apr 6, 2020 at 3:10 PM Martin Landa  wrote:

>
> is there any quick way how to generate also a world file when storing
> graphics into a file using `d.mon`. I just found `d.mon -g`, but it
> needs some hacking.
>

I'm not aware of that, but since I'm not sure what you are doing I need to
ask if d.to.rast+r.out.gdal (or d.out.file) would help you here.

https://grass.osgeo.org/grass78/manuals/d.to.rast.html
https://grass.osgeo.org/grass78/manuals/d.out.file.html

The code you are looking for might be also in the following repo, but not
using d.mon:

https://github.com/ncsu-geoforall-lab/grass-web-publishing


> It would be nice if `d.info` or directly `d.mon` could generate a
> world file if requested.
>

Maybe a Python function to generate worldfile from the current
computational region would be a better fit?

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

Re: [GRASS-user] Problems on MacOS Catalina Installation via Homebrew "Cannot find proj.db"

[Vaclav Petras]

Dear Veronika,

Thank you for awesome analysis. I don't have an answer, but I'm struggling
with the same and I thought it might be a good idea to connect the related
discussions:

[GRASS-dev] Automatic/CI compilation on macOS
https://lists.osgeo.org/pipermail/grass-dev/2020-March/094187.html
https://lists.osgeo.org/pipermail/grass-dev/2020-March/094207.html

[Bug] Update build GRASS as macOS application #457 (linked comment and
below)
https://github.com/OSGeo/grass/issues/457#issuecomment-603575140

Vaclav


On Fri, Mar 27, 2020 at 12:49 PM Veronika Grupp  wrote:

> Dear GRASS GIS users,
>
> After installing GRASS GIS via Homebrew I encountered a problem when I
> tried to create a new location and set the projection. (I also posted this
> question on Stackoverflow:
> https://stackoverflow.com/questions/60871421/grass-gis-installed-with-homebrew-create-new-location-cannot-find-proj-db-err
> )
> Maybe someone of you has encountered the same problem or has any idea what
> might be the issue..
>
> I work on MacOS Catalina and installed the latest stable release of GRASS
> GIS (7.8.2) with Homebrew via the osgeo/osgeo4mac tap using the commands brew
> tap osgeo/osgeo4mac and brew install osgeo-grass (as described on the
> GRASS website
> https://grasswiki.osgeo.org/wiki/Compiling_on_MacOSX_using_homebrew).
>
> To get the GUI working also pip3 install wxpython was necessary. I could
> start GRASS with grass78 on the commandline. When I tried to create a new
> location and to set the projection/crs
>
>1. I could not specify an EPSG code
>2. browsing a georeferenced file to use its projection threw the
>error: "proj_get_authorities_from_database: Cannot find proj.db"
>
> and creation of location was cancelled.
>
> Regarding 1. EPSG codes: the newest proj version does not provide a file
> with epsg codes, seems like this was already an issue in GRASS 7.6 combined
> with proj 6.x (https://trac.osgeo.org/grass/ticket/3863) but still
> couldn't find a way to get it working e.g. with another epsg file copied
> into the directory.
>
> Regarding 2. I tried several things that didn't work:
>
> I installed proj 5 (with brew install osgeo-proj@5) and also proj 6 (with
> a bottle from https://bottle.download.osgeo.org/?C=N&O=A) but it throws
> errors at the same point saying that some library (refering proj) was not
> loaded and image was not found.
>
> I tried to set the environment variable PROJ_LIB in .zshenv to the
> respective path where proj.db is located (for version 6 and 7
> respectively), still it threw the same error(s).
>
> Do I need to set any other environment variables or might it be something
> related to GDAL?
> Thank you very much.
> Veronika
> ___
> 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] Can I turn off compression

[Vaclav Petras]

Hi Ken,

That sounds like a good experiment and I think there would be general
interest in what you find. However, please note that less compression may
not mean faster, because then there is more data to write and read and I/O
is generally a significant bottleneck. Markus Metz may say more about this
as he did tests when he was implementing the new compressions, but you
might be able to find some posts on this on the grass-dev mailing list.

Best,
Vaclav

On Sat, Feb 29, 2020 at 11:40 AM Ken Mankoff  wrote:

>
> Hm. Answer: No
>
> I just did:
>
> export GRASS_COMPRESSOR=none
>
> And then get this error message:
>
> WARNING: No compression is not supported for GRASS raster maps, using
> default ZLIB
>
> Seems like a shame to not have this as an option. I'll try speeding it up
> by tweaking the compression method and amount.
>
>   -k.
>
> On 2020-02-29 at 08:37 -08, Ken Mankoff  wrote...
> > Hi,
> >
> > I'd like to turn off compression for all maps. Is this possible with
> > g.gisenv or environment variables? The g.gisenv manual only shows how
> > to choose among compression methods, not disable it.
> >
> > This does not seem to work:
> >
> > g.gisenv set="GRASS_COMPRESSOR=none" # optimize for speed
> >
> > I can decompress one map with:
> >
> > r.compress -u map=foo
> >
> > But I'm trying to skip the time spent compressing and decompressing
> > altogether. I could use a small speed boost, and this seems like an
> > easy way to speed things up - I can afford the disk space for all the
> > temporary intermediate maps.
> >
> > 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] Example project for a GRASS GIS module on GitHub

[Vaclav Petras]

Zenodo & JOSS in relation to r.example.plus: If you have idea on the text,
please open a PR. I suggest adding it as a subsection of "What is next" and
making the current content of that section a subsection as well.

As for the JOSS and grass-addons repo:

On Tue, Feb 4, 2020 at 8:25 AM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> Hi,
>
> In this context we should probably also keep JOSS in mind and probably
> make devs aware of that possibility, including linking a JOSS paper to the
> repo. See presentation from FOSSDEM [1] for more background.
>
> Question is, if it is possible to have the link on a module basis in
> grass-addons.


What do you mean by a link? Does JOSS require the software to be in a
separate repo?

Best,
Vaclav


> Cause, I also think that getting stuff into grass-addons is important for
> the reasons Vaclav lists in the repo.
>
> Cheers
> Stefan
>
> 1: https://video.fosdem.org/2020/AW1.126/open_research_joss.webm
>
> -Original Message-
> From: "Peter Löwe" 
> Sent: tirsdag 4. februar 2020 11:24
> To: grass-user@lists.osgeo.org
> Cc: Stefan Blumentrath ; wenzesl...@gmail.com
> Subject: [GRASS-user] Example project for a GRASS GIS module on GitHub
>
> Hi Vasek,
>
> thanks for setting up the demo module on GitHub!
>
> To demonstrate how module authors can get credit by scientific citation,
> some kind of reference/howto describing how the integration of the GitHub
> project and the Zenodo data repositiory (https://www.zenodo.org/) can be
> achieved, as explained here:
> https://www.zenodo.org/login/?next=%2Faccount%2Fsettings%2Fgithub%2F
> https://guides.github.com/activities/citable-code/
> By doing so, a persistent identifier (DOI) is assigned to the GRASS module
> codebase. Zenodo also offers a handy tool to provide citation strings for
> the modulde code in hundreds of citation styles.
>
> Best regards,
> Peter
>
> 
>
> > From: grass-user  On Behalf Of
> Vaclav Petras
> > Sent: torsdag 30. januar 2020 02:31
> > To: grass-...@lists.osgeo.org; GRASS user list <
> grass-user@lists.osgeo.org>
> > Subject: [GRASS-user] Example project for a GRASS GIS module on GitHub
> >
> > Dear users and contributors,
> >
> > I've created an example project (repository) on GitHub. It is a GRASS
> GIS module written in Python which simply adds two raster maps together. It
> uses GitHub Actions to build the module and publish its documentation as a
> website (using GitHub Pages).
> >
> > https://github.com/wenzeslaus/r.example.plus
> >
> > This is based on my earlier work on an example project on GitLab [1] and
> includes several improvements and changes:
> >
> > * There is a test suite included with couple of test functions.
> > * It uses Black for code formatting (assuming author runs it manually).
> > * Repository is marked as a template (see the big "Use this template"
> button).
> > * GitHub Actions are used for:
> >   * compiling the module and running tests,
> >   * checking code quality with Flake8 and Pylint, and
> >   * checking code style with Black.
> > * GitHub Actions are now used for publishing documentation (done by
> GitLab CI before).
> > * Option names now follow GRASS GIS standards more.
> > * More documentation in the code and on how to use the code.
> > * Badges are now in the README file (GitLab had those as project
> properties).
> >
> > Otherwise, I hope the project should describe itself and if something is
> missing or is not documented enough, please open an issue or a pull request.
> >
> > Best,
> > Vaclav
> >
> > PS: We can discuss on grass-dev if this should go under some
> organization and how to improve the "what's next" part [2].
> >
> > [1]
> https://lists.osgeo.org/pipermail/grass-dev/2018-November/090438.html
> > [2] https://github.com/wenzeslaus/r.example.plus#what-is-next
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Example project for a GRASS GIS module on GitHub

[Vaclav Petras]

Dear users and contributors,

I've created an example project (repository) on GitHub. It is a GRASS GIS
module written in Python which simply adds two raster maps together. It
uses GitHub Actions to build the module and publish its documentation as a
website (using GitHub Pages).

https://github.com/wenzeslaus/r.example.plus

This is based on my earlier work on an example project on GitLab [1] and
includes several improvements and changes:

* There is a test suite included with couple of test functions.
* It uses Black for code formatting (assuming author runs it manually).
* Repository is marked as a template (see the big "Use this template"
button).
* GitHub Actions are used for:
  * compiling the module and running tests,
  * checking code quality with Flake8 and Pylint, and
  * checking code style with Black.
* GitHub Actions are now used for publishing documentation (done by GitLab
CI before).
* Option names now follow GRASS GIS standards more.
* More documentation in the code and on how to use the code.
* Badges are now in the README file (GitLab had those as project
properties).

Otherwise, I hope the project should describe itself and if something is
missing or is not documented enough, please open an issue or a pull request.

Best,
Vaclav

PS: We can discuss on grass-dev if this should go under some organization
and how to improve the "what's next" part [2].

[1] https://lists.osgeo.org/pipermail/grass-dev/2018-November/090438.html
[2] https://github.com/wenzeslaus/r.example.plus#what-is-next
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] licensing question: calling GRASS GIS modules via the grass.script API in an MIT/Apache licensed script ?

[Vaclav Petras]

On Tue, May 7, 2019 at 4:42 AM Moritz Lennert 
wrote:

> Hi,
>
> We work with a company on a project where we use GRASS GIS to calculate
> accessibility indicators. The main output we provide is a Python script
> which calls GRASS GIS modules via the grass.script API. The company is
> willing to make this script free software, but would like to license it
> with a permissive license such as MIT or Apache.
>
> I would think that calling GRASS GIS modules in a script does not
> automatically imply the script has to be GPL, but what about the use of
> the Python API ?
>
> I would think that this case falls in the grey area described at [1] and
> have tendency to think that MIT/Apache license would be allowed.
>

Hi Moritz,

To make things more complicated: Note that if MIT is allowed, that (would)
mean(s) that proprietary is also allowed, i.e. can you license it under an
arbitrary licensing terms and conditions. So, I think you are basically
asking if you can create proprietary scripts which are using GRASS GIS
modules and also if there is a difference between a script and a software
in this context. Is doing scripting in GRASS GIS mere using of GRASS GIS or
it is making derived programs? There is general agreement that Bash scripts
can be MIT/proprietary, but is calling GRASS GIS modules the same as
calling POSIX defined tools? Depending on the answers, you can be looking
at incorporating GPL-covered software in a proprietary system [2].

But first, I would be asking for reasons for requiring MIT/Apache. Clearly,
it is not *fear* of leaking patent rights with GPLv3 because that would
rule out Apache. If the reason is keeping the option to reuse pieces of the
code in a propriety product by the company, I don't see why that would be
an issue because 1) as a copyright holder, you can decide to change
licensing at any time and 2) even if you keep GPL, you can use modified GPL
code internally without releasing it. Use of GPL software is oviously not
an issue either here. On top of that, the increasing use of SaaS and GPL
behavior there [3] makes me wonder why to even talk about this and not go
with the obviously save choice GPL >=2.

To push back a little, I would say that if somebody has the capacity to
have reasons for MIT/Apache which go beyond what I tried to describe in the
previous paragraph, I would say they have capacity to determine the
licensing options here, i.e. answer my first paragraph. This serves also as
my "I'm not a lawyer statement."

And a more practical note, in case the conclusion of all this is still a
MIT or Apache license, note that Apache 2.0 is not compatible with GPL v2
(it is compatible only with v3), so it would not be possible to include the
code into GRASS GIS (which is >=2) if somebody decides to do so.

Best,
Vaclav

[2] https://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
[3] https://www.fsf.org/licensing/2007-03-29-gplv3-saas


> Does anyone have a more informed opinion ?
>
> Moritz
>
>
> [1] https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
> ___
> 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 python + PyCharm

[Vaclav Petras]

On Wed, Jun 12, 2019 at 5:09 PM Markus Neteler  wrote:

> On Wed, Jun 12, 2019 at 10:49 AM Helmut Kudrnovsky  wrote:
> >
> > Hi,
> >
> > PyCharm is a nice python IDE.
> >
> > anyone some experiences to share how to integrate GRASS python (pygrass
> and
> > grass script) into the PyCharm IDE environment?
>
> Please add your notes also here then:
>
> https://grasswiki.osgeo.org/wiki/Tools_for_Python_programming#PyCharm_IDE


Or, if PyCharm allows you to supply custom executable and parameters script
execution, you can try to set it up with `grass ... --exec`. The drawback
is that debugger may not support that.

Alternatively, as a combination of both, you can set up a shortcut for
"PyCharm with GRASS GIS" using `grass --tmp-location XY --exec pycharm`. In
that case, as in case with running it inside, some Python version/packages
issues may arise more likely.

Best,
Vaclav

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

Re: [GRASS-user] Example project on GitLab: Access / discoverablity

[Vaclav Petras]

On Mon, Nov 19, 2018 at 10:01 AM "Peter Löwe"  wrote:

>
>> Can you give recomendations what keywords/metadata should be attached to
>> such external GRASS repos so users will find them ?
>
>
> I think that's a challenge and that's one of the reasons, the official
> GRASS GIS Addons repository is still the best option.
>
> The search on GitLab as well as GitHub (and pretty much everywhere) does
> not distinguish keywords from names or descriptions, so as long as "GRASS
> GIS" and "module" is somewhere, it's good. However, this can also give a
> lot of results which are not GRASS GIS modules. The ultimate test is of
> course examining the content, e.g. the couple lines in the Makefile. Adding
> "g.extension" as a keyword and/or expecting in a README file might be a
> way, but still only approximate and it is an odd keyword to have.
>
>
> -> Maybe at this point the Citation File Format, as already introduced
> through the g.citation module, could be a step forward: IF a repo contains
> the keyword "GRASS GIS" AND there is a CFF file, this could be mined for
> structured information about the code.
>

A CFF might end up being a recommend part of a GRASS GIS module source code
(well, I can recommend it even now), but that still would not be enough to
identify a module because you can have e.g. a code using GRASS GIS
externally or a project analyzing GRASS GIS source code which would include
CFF file and GRASS GIS as a keyword.


>
> -> Currently, Zenodo (as a DOI generator) can only be linked to GitHub,
> but IMHO it's just a matter of time until they also support GitLab. Once
> that happens we should brace ourselves for a diaspora of GRASS mini-repos
> as the academia-based developers will go after scientific credit / citation
> by DOI. In such a situation finding/discovering useful add-ons will become
> a challenge (unless the code is placed in the canoncal GRASS project repos
> :-) ).
>

We already have a lot of modules floating around on personal websites or
servers. In these cases, GitHub and others made the discovery and perhaps
even the preservation actually easier because now things are at least in
couple of predictable and searchable places. But obviously, this is a worse
state than GRASS GIS Addons with its central registry, code maintained by
community, linked online documentation, compiled binaries for MS Windows
(!), compilation log, ...
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Example project on GitLab: Access / discoverablity

[Vaclav Petras]

He Peter,

On Wed, Nov 14, 2018 at 10:16 AM "Peter Löwe"  wrote:

>
> thanks for setting up the r.example.plus example GitLab project. This is
> an interesting reference case.
>

Thanks!


>
> Is it already possible to integrate this code into a local GRASS
> installation via g.extension (
> https://grass.osgeo.org/grass74/manuals/g.extension.html) ?
>

Yes, it is, but only on Linux, macOS and other unix-like systems.


>
> Can you give recomendations what keywords/metadata should be attached to
> such external GRASS repos so users will find them ?
>

I think that's a challenge and that's one of the reasons, the official
GRASS GIS Addons repository is still the best option.

The search on GitLab as well as GitHub (and pretty much everywhere) does
not distinguish keywords from names or descriptions, so as long as "GRASS
GIS" and "module" is somewhere, it's good. However, this can also give a
lot of results which are not GRASS GIS modules. The ultimate test is of
course examining the content, e.g. the couple lines in the Makefile. Adding
"g.extension" as a keyword and/or expecting in a README file might be a
way, but still only approximate and it is an odd keyword to have.

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

Re: [GRASS-user] Example project on GitLab

[Vaclav Petras]

On Wed, Nov 7, 2018 at 8:47 AM Bernardo Santos <
bernardo_brand...@yahoo.com.br> wrote:

>
> thanks for that, it'll be very useful. I think a similar approach can be
> used to build repositories for addons within GitHub, right?
>

Yes, when you involve Travis CI.


> Do you see clear advantages of using GitLab instead of GitHub for this
> purposes?
>

One other reason besides the private repos mentioned by KenM, the CI is
much better integrated then GitHub and Travis CI, so for example, you don't
have to pass any tokens to connect them bidirectionally in order to publish
web pages build by CI. The built web pages on GitLab don't need to be part
of the repository which may have some drawbacks but it is mostly an
advantage I would say. This is all kind of related to the GitLab approach
to the project - it is a primary a project and Git repo is just part of it
(GitHub interface is built around a repo).

Another thing is that you can download all the data and upload it to your
own GitLab instance if you don't want to use gitlab.com anymore (at least
that's what they claim). This relates to the fact that (most of) GitLab
itself is actually open source (!).

I'm not sure if it is an advantage for real work, but I personally enjoyed
working with the GitLab WebIDE and I created the whole example just using
that although at this point is misses spell check and you need to commit in
order to run the code.

One disadvantage of GitLab is that the CI is Linux only while GitHub has
macOS and recently they added Windows too.

Best,
Vaclav
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Example project on GitLab

[Vaclav Petras]

On Mon, Nov 5, 2018 at 2:43 PM Ken Mankoff  wrote:

> I think I will find it useful in helping some of my custom scripts to
> official plugins.
>

Glad to hear that! Thanks for sharing your code!



> On Fri, Nov 2, 2018 at 7:08 PM Vaclav Petras  wrote:
>
>> Dear users and devs,
>>
>> I've created an example project at GitLab. It is a GRASS GIS module
>> written in Python. It uses GitLab CI to build the module and publish its
>> documentation as a website.
>>
>> https://gitlab.com/vpetras/r.example.plus
>>
>> If you are familiar with GitHub, GitLab will feel familiar as well (we
>> can discuss the differences later), but the following terminology
>> comparison may come useful:
>>
>>
>> https://about.gitlab.com/2017/09/11/comparing-confusing-terms-in-github-bitbucket-and-gitlab/
>>
>> Otherwise, I hope the project should describe itself and if something is
>> missing or is not documented enough, your can submit an issue or a merge
>> request.
>>
>> Best,
>> Vaclav
>>
>> PS: We can create a GitLab group for GRASS GIS and move this project
>> there.
>>
>> ___
>> 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] Example project on GitLab

[Vaclav Petras]

Dear users and devs,

I've created an example project at GitLab. It is a GRASS GIS module written
in Python. It uses GitLab CI to build the module and publish its
documentation as a website.

https://gitlab.com/vpetras/r.example.plus

If you are familiar with GitHub, GitLab will feel familiar as well (we can
discuss the differences later), but the following terminology comparison
may come useful:

https://about.gitlab.com/2017/09/11/comparing-confusing-terms-in-github-bitbucket-and-gitlab/

Otherwise, I hope the project should describe itself and if something is
missing or is not documented enough, your can submit an issue or a merge
request.

Best,
Vaclav

PS: We can create a GitLab group for GRASS GIS and move this project there.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Using grass.script in Jupyter (Azure)

[Vaclav Petras]

On Sat, Oct 13, 2018 at 9:09 PM Mehrdad Varedi  wrote:
>
> ImportError   Traceback (most recent call
last)
>  in ()
> > 1 import grass.script as gs
>   2 import grass.script.setup as gsetup
>
>
f:\PROGRA~1\QGIS2~1.18\apps\grass\grass-7.4.1\etc\python\grass\script\__init__.py
in ()
>   3 from __future__ import absolute_import
>   4
> > 5 from .core   import *
>   6 from .db import *
>   7 from .raster import *
>
>
f:\PROGRA~1\QGIS2~1.18\apps\grass\grass-7.4.1\etc\python\grass\script\core.py
in ()
>  42 # python3
>  43 import builtins as __builtin__
> ---> 44 from os import environb as environ
>  45 unicode = str
>  46 __builtin__.__dict__['_'] =
__builtin__.__dict__['_'].__self__.lgettext
>
> ImportError: cannot import name 'environb' from 'os'
(f:\ProgramData\Anaconda3\lib\os.py)

You are trying to run it in Python 3 which is the first part of the
traceback (that is actually fine if you want to run it in Python 3 - but
note that the support is experimental).

As for the error itself, environb is a part of os in Python 3, so I don't
understand why that would be missing in your Anaconda Python. You can check
the files manually and confirm that all is an expected Python version.

https://docs.python.org/3/library/os.html#os.environb
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Category

[Vaclav Petras]

On Wed, Oct 10, 2018 at 8:40 PM Francois Chartier 
wrote:

> Hi,
>
> Apologize for my dumb question, but to import a csv file (xyz attribute),
> I have been setting the attribute (property which i would like to view,
> interpolate) as the category when i define the columns (x,y,z, cat). I
> think I am doing this incorrectly
>

An attribute in an attribute table is probably more appropriate here than a
category. See the example in v.in.ascii manual:

https://grass.osgeo.org/grass77/manuals/v.in.ascii.html#example-4---point-format-mode---csv-table
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Merging Raster Files in GRASS

[Vaclav Petras]

Just to clarify functionality for some of the modules.

On Wed, Oct 10, 2018 at 7:09 AM Mehrdad Varedi  wrote:

>
> *r.buildvrt *in version (7.4.0 and 7.4.1)generated the following error:
> 'r.buildvrt' is not recognized as an internal or external
> command, operable program or batch file.
>

Available only in 7.6 (future release) and above.


> I have tried *r.patch *which doesn't generate any error, although the
> created result is empty with no errors.
>

Likely the computation region as Vero says.


> *r.out.gdal* and using the grouping option to group the layers and export
> them to a new Tiff, although that had a similar output as r.patch.
>

The group r.out.gdal support is GRASS GIS imagery group created by i.group.
That's a GRASS GIS way of handling multiband images, or more precisely, a
way to organize fully overlapping rasters together as a collection of
spectral bands or related image processing outputs.


>
> A virtual raster file in QGIS was created using the 4 Tiff files and
> importing to grass using r.import, didn't work and I got errors.
>

 This should work. (Files and error messages would be needed to understand
what's wrong, but if r.patch works for you that's good).
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] 3D unstructured Grid

[Vaclav Petras]

On Wed, Oct 10, 2018 at 8:34 PM Francois Chartier 
wrote:

> Hi Vaclav,
>
> Question:
> 1-can the value remain constant until the next underlying data point?
>

v.vol.rst is for interpolation, but a constant value can be achieved with
r.to.rast3elev or r.to.rast3, but I think in your case you will likely need
some prereprocessing to get the right rasters from your irregular points.

https://grass.osgeo.org/grass74/manuals/r.to.rast3elev.html
https://grass.osgeo.org/grass74/manuals/r.to.rast3.html

I think there was some addon or script for working with soil types (which
is how your case sounds). Perhaps somebody knows more about it.


> 2-by "the output is a regular grid"  does that mean that the points
> (vector) can be unstructured, but in the end the raster or mesh is a
> regular grid?
>

Yes, 3D points (XYZ tuples) and (regular) 3D raster (grid).


>   if that is the case, how does the value in the raster determined?
>

v.vol.rst is interpolating the value using "regularized spline with
tension" aka RST, i.e. it is applicable to properties which are a real
number, but it is not suitable for categorical data.


> Is it an interpolated value between the points that fall with in the
> raster cell footprint?
>

The interpolation happens for the raster cells (or you can think of them as
grid locations in the middle of the raster cell). Usually, there would be
much more raster cells than vector points, but the RST interpolation works
the same way in all cases.



>
> thanks,
> Francois
>
> Le jeu. 4 oct. 2018 à 22:48, Vaclav Petras  a
> écrit :
>
>>
>>
>> On Tue, Oct 2, 2018 at 9:38 PM Francois Chartier 
>> wrote:
>>
>>> For example, in the example on the webpage, there is a 3D raster for
>>> soil moisture; if the soil moisture is measured only for the top of a
>>> cylinder along your vertical hole, the next moisture measurement is taken
>>> at a lower depth, and the intervals (cylinder length) are not the same
>>> along that vertical axis?
>>>
>>
>>
>> Yes, all are (can be) different. The values are interpolated in between.
>> The input are arbitrary places points. The output is a regular grid. Note,
>> you may need to explore zscale parameter of v.vol.rst because of the how
>> your data looks like.
>>
>>
>>
>>>
>>> Le lun. 1 oct. 2018 à 22:01, Vaclav Petras  a
>>> écrit :
>>>
>>>> On Sat, Sep 29, 2018 at 4:45 PM Francois Chartier <
>>>> fra.chart...@gmail.com> wrote:
>>>>
>>>>> Can Grass GIS create a 3D unstructured grid based on a 3D point data
>>>>> set ?
>>>>>
>>>>
>>>> All data and visualizations at the following website were created in
>>>> GRASS GIS including a 3D regular grid (3D raster in GRASS GIS) interpolated
>>>> from a set of 3D points (vector which is 3D, i.e. with z, in GRASS GIS).
>>>> Points were soil properties measurement at different depths, 3D raster is
>>>> then continuous representation of a selected property.
>>>>
>>>> https://geospatial.ncsu.edu/geoforall/multidim-geovis.html
>>>>
>>>> Module used for interpolation was v.vol.rst:
>>>>
>>>> https://grass.osgeo.org/grass74/manuals/v.vol.rst.html
>>>>
>>>> Vaclav
>>>>
>>>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Using grass.script in Jupyter (Azure)

[Vaclav Petras]

On Tue, Oct 9, 2018 at 9:25 PM Mehrdad Varedi  wrote:

> Hi Everyone,
>
> I want to develop a program using GRASS python libraries in Jupyter(on
> Azure). All codes begin with:
>
>
> *import* *grass.script* *as* *gscript*
>
>
> of course the grass.script is not available in Jupyter. I tried to install
> GRASS
>
> I used: !pip install GRASS
>
> and it worked like a charm, although I can't have access to grass.script.
>
> Sorry if it is a silly question, although I apreciate any idea to begin
> programming GRASS on Azure.
>


Hi Mehrdad,

the package you installed is not GRASS GIS. Install GRASS GIS using
whatever is appropriate for your platform (e.g. using apt install grass on
Ubuntu, but ideally after connecting PPA in this case). Then there is
couple of approaches how to use GRASS GIS with Jupyter. The one I prefer is
starting Jupyter Notebook and than starting GRASS GIS from there:

https://github.com/wenzeslaus/geospatial-modeling-course-jupyter/blob/master/notebooks/buffers_cost_python.ipynb

See also:

[GRASS-dev] Package grass installed by pip is not GRASS GIS
https://lists.osgeo.org/pipermail/grass-dev/2018-October/090191.html

Best,
Vaclav


> I appreciate any help you can provide,
>
>
>
> Mehrdad
>
> --
>
> Mehrdad Varedi
> ᐧ
> ___
> 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] floodplain creation

[Vaclav Petras]

Based on what we have discussed (including some off-list), the best shot
seems to be using directions based on r.watershed on the carved DEM
together with the given (not computed) streams for HAND (streams are also
used for the carving and r.lake steps).

An alternative is using streams from r.watershed, but only those which fall
into a buffer around the given streams (for more context, see some of my
previous emails when I already mentioned this).

Getting the directions for a stream, as I suggested, is of course useless
except for using it for updating the direction raster which may or may not
bring a minor improvement (probably not worth complicating the workflow).

Vaclav


On Wed, Oct 3, 2018 at 5:46 PM Shane Carey  wrote:
>
> Hi Vaclav,
>
> I have checked the output from r.watershed with what you have calculated
and I do see differences in the value obtained by both. Could it be a
rounding issue perhaps? The only other difference I see is that the output
from r.watershed is a complete raster as opposed to just the river network.
See image attached to explain what I mean. Does that make any difference?
>
>
> Le gach dea ghui,
> Shane Carey
> GIS and Data Solutions Consultant
>
>
> On Tue, Oct 2, 2018 at 12:07 PM Shane Carey  wrote:
>>
>> Ok cool. When I I try to run the r.stream.distance with this new new
stream direction layer (that I calculated with  r.mapcalc
"streams_direction_8 = int((streams_direction + 45) / 45)" ),
>>
>> it just hangs on the part that says: "caclulating downstream
parameters". So I am not sure what is going on here - have you any ideas on
this?
>>
>> Also, could you explain a little about what this expression is doing:
(streams_direction + 45) / 45)
>>
>> Thanks Vaclav
>>
>>
>> Le gach dea ghui,
>> Shane Carey
>> GIS and Data Solutions Consultant
>>
>>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] 3D unstructured Grid

[Vaclav Petras]

On Tue, Oct 2, 2018 at 9:38 PM Francois Chartier 
wrote:

> For example, in the example on the webpage, there is a 3D raster for soil
> moisture; if the soil moisture is measured only for the top of a cylinder
> along your vertical hole, the next moisture measurement is taken at a lower
> depth, and the intervals (cylinder length) are not the same along that
> vertical axis?
>


Yes, all are (can be) different. The values are interpolated in between.
The input are arbitrary places points. The output is a regular grid. Note,
you may need to explore zscale parameter of v.vol.rst because of the how
your data looks like.



>
> Le lun. 1 oct. 2018 à 22:01, Vaclav Petras  a
> écrit :
>
>> On Sat, Sep 29, 2018 at 4:45 PM Francois Chartier 
>> wrote:
>>
>>> Can Grass GIS create a 3D unstructured grid based on a 3D point data set
>>> ?
>>>
>>
>> All data and visualizations at the following website were created in
>> GRASS GIS including a 3D regular grid (3D raster in GRASS GIS) interpolated
>> from a set of 3D points (vector which is 3D, i.e. with z, in GRASS GIS).
>> Points were soil properties measurement at different depths, 3D raster is
>> then continuous representation of a selected property.
>>
>> https://geospatial.ncsu.edu/geoforall/multidim-geovis.html
>>
>> Module used for interpolation was v.vol.rst:
>>
>> https://grass.osgeo.org/grass74/manuals/v.vol.rst.html
>>
>> Vaclav
>>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] 3D unstructured Grid

[Vaclav Petras]

On Sat, Sep 29, 2018 at 4:45 PM Francois Chartier 
wrote:

> Can Grass GIS create a 3D unstructured grid based on a 3D point data set ?
>

All data and visualizations at the following website were created in GRASS
GIS including a 3D regular grid (3D raster in GRASS GIS) interpolated from
a set of 3D points (vector which is 3D, i.e. with z, in GRASS GIS). Points
were soil properties measurement at different depths, 3D raster is then
continuous representation of a selected property.

https://geospatial.ncsu.edu/geoforall/multidim-geovis.html

Module used for interpolation was v.vol.rst:

https://grass.osgeo.org/grass74/manuals/v.vol.rst.html

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

Re: [GRASS-user] floodplain creation

[Vaclav Petras]

On Sat, Sep 29, 2018 at 1:55 PM Shane Carey  wrote:

> My last bit of the puzzle is to create the flow direction raster. How do I
> reclassify in order to get the stream direction using r.mapcalc?
>

Hi Shane,

You are welcome. What you need to do are 2 steps: 1) vector to raster
conversion with direction to be used for raster values:

v.to.rast input=streams output=streams_direction use=dir

The v.to.rast manual says: "line direction in degrees CCW from east" [1].
However, the r.stream.distance manual specifies the drainage direction to
be: "...zero and negative values are valid direction data only if they vary
from -8 to 8 (CCW from East in steps of 45 degrees). Flow direction map
shall be of integer type (CELL)." So you need to reclassify.

[1] https://grass.osgeo.org/grass74/manuals/v.to.rast.html
[2] https://grass.osgeo.org/grass74/manuals/addons/r.stream.distance.html

The reclassification with r.mapcalc would be something like the following,
but I didn't really check and it may be wrong. Alternative would be to use
r.recode.

r.mapcalc "streams_direction_8 = int((streams_direction + 45) / 45)"

So please double check the output from the above and compare it with what
you get from r.watershed.

For completeness, here is what I wrote before:

"""
Yes, just convert your streams to raster (presence-absence) and a raster
for flow direction as I mentioned here:

https://lists.osgeo.org/pipermail/grass-user/2018-September/079135.html

Since you already have the streams and you want to use them, you need to
convert them to raster and then also get stream direction for r.stream.
distance by reclassifying, e.g. with r.mapcalc, output from something like
this:

v.to.rast in=streams output=streams_dir use=dir

which you can see in context here (different hydrology tool):

http://ncsu-geoforall-lab.github.io/geospatial-modeling-course/grass/simwe.html
"""


> I am just coping in what you said from your last email Vaclav so that you
> know which part I am stuck on. This is really super - thanks again
>
> [Since you already have the streams and you want to use them, you need to
> convert them to raster and then also get stream direction for
> r.stream.distance by reclassifying, e.g. with r.mapcalc]
>
> Le gach dea ghui,
> *Shane Carey*
> *GIS and Data Solutions Consultant*
>
>
> On Fri, Sep 28, 2018 at 3:02 PM Vaclav Petras 
> wrote:
>
>>
>> On Thu, Sep 27, 2018 at 12:10 PM Shane Carey  wrote:
>>
>>>
>>> Is there anyway of the algorithm just being able to create a floodlain
>>> for actual real rivers as opposed to the derived river dataset?
>>>
>>
>> Yes, just convert your streams to raster (presence-absence) and a raster
>> for flow direction as I mentioned here:
>>
>> https://lists.osgeo.org/pipermail/grass-user/2018-September/079135.html
>>
>> However, you need to be cautious about fit between the existing streams
>> and the DEM. Definitively check how your existing streams align with the
>> derived ones (where there are both streams).
>>
>>
>>>
>>> On Máirt 25 MFómh 2018 at 15:49, Shane Carey 
>>> wrote:
>>>
>>>> Image attached shows rivers (black line) and floodplain of where it
>>>> thinks there are rivers and in some cases where there may not be rivers.
>>>>
>>>
>> To use the derived streams and get rid of parts you don't want, you could
>> buffer the existing streams and preserve only the derived streams which are
>> in that buffer.
>>
>> However, you should really look at why they are different and
>> specifically what is closer to reality.
>>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] floodplain creation

[Vaclav Petras]

On Thu, Sep 27, 2018 at 12:10 PM Shane Carey  wrote:

>
> Is there anyway of the algorithm just being able to create a floodlain for
> actual real rivers as opposed to the derived river dataset?
>

Yes, just convert your streams to raster (presence-absence) and a raster
for flow direction as I mentioned here:

https://lists.osgeo.org/pipermail/grass-user/2018-September/079135.html

However, you need to be cautious about fit between the existing streams and
the DEM. Definitively check how your existing streams align with the
derived ones (where there are both streams).


>
> On Máirt 25 MFómh 2018 at 15:49, Shane Carey  wrote:
>
>> Image attached shows rivers (black line) and floodplain of where it
>> thinks there are rivers and in some cases where there may not be rivers.
>>
>
To use the derived streams and get rid of parts you don't want, you could
buffer the existing streams and preserve only the derived streams which are
in that buffer.

However, you should really look at why they are different and specifically
what is closer to reality.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] floodplain creation

[Vaclav Petras]

On Mon, Sep 24, 2018 at 6:33 PM Shane Carey  wrote:

>
> This works well, but doesn't capture every river - is it a case of making
> the threshold value smaller or making a deeper carve in the rivers???
>


It's probably the threshold. How your rivers compare to the ones derived on
carved DEM?



>
> Thanks in advance - I think this method would will work well, if it were
> able to "flood" all rivers.
>
> On Sun, Sep 23, 2018 at 12:55 PM, Shane Carey  wrote:
>
>> Thanks, I will compare them and let you  know the differences.
>> Thanks
>>
>> On Domh 23 MFómh 2018 at 02:09, Vaclav Petras 
>> wrote:
>>
>>> These are steps based on:
>>>
>>>
>>> https://grasswiki.osgeo.org/wiki/From_GRASS_GIS_novice_to_power_user_(workshop_at_FOSS4G_Boston_2017)#Hydrology:_Estimating_inundation_extent_using_HAND_methodology
>>>
>>> You need r.stream.distance module from Addons:
>>>
>>> g.extension r.stream.distance
>>>
>>> Get drainage and streams from your DEM (your carved DEM):
>>>
>>> r.watershed elevation=dem accumulation=flowacc drainage=drainage
>>> stream=streams threshold=10
>>>
>>> Compute height above nearest drainage/stream (HAND):
>>>
>>> r.stream.distance stream_rast=streams direction=drainage
>>> elevation=elevation method=downstream difference=hand
>>>
>>> Use r.lake not on the original DEM, but on the HAND and start flooding
>>> ("lake") from the streams:
>>>
>>> r.lake elevation=hand water_level=3 lake=flood_3m seed=streams
>>>
>>> Convert to vector if desired:
>>>
>>> r.to.vect -s input=flood_3m output=flood_3m type=area
>>>
>>> The difference to the r.grow+r.mapcalc method [1] is that this uses an
>>> addon module (there should be no problem installing it) and that r.grow
>>> uses euclidean distance for what is later used for height difference while
>>> r.steam.distance follows drainage and further that r.lake floods only the
>>> cells accessible to water unlike the r.mapcalc expression which just looks
>>> at height. The two methodological differences can be summarized as "not
>>> respecting the surrounding terrain enough." Anyway, the r.grow+r.mapcalc
>>> method can get you quite far and I would be interested in the comparison
>>> (will differ for different terrains).
>>>
>>> Best,
>>> Vaclav
>>>
>>> [1]
>>> https://lists.osgeo.org/pipermail/grass-user/2018-September/079134.html
>>>
>>> On Fri, Sep 21, 2018 at 11:39 AM Shane Carey 
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I have used r.carve to carve out the rivers of a DTM - a really super
>>>> job. I now need to pour 3meters of water into every cell in the river and
>>>> see how for this water extends out - onto the floodplain.
>>>>
>>>> I was trying to use r.lake to do this, but unsure as to how r.lake will
>>>> work to pour 3 meters of water in every cell along the river network.
>>>>
>>>> Any advice on this would be great. It is for the creation of a
>>>> floodplain.
>>>>
>>>> Thanks
>>>>
>>>>
>>>> Le gach dea ghui,
>>>> *Shane Carey*
>>>>
>>>> ___
>>>> grass-user mailing list
>>>> grass-user@lists.osgeo.org
>>>> https://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>>> --
>> Le gach dea ghui,
>> *Shane Carey*
>> *GIS and Data Solutions Consultant*
>>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] floodplain creation

[Vaclav Petras]

These are steps based on:

https://grasswiki.osgeo.org/wiki/From_GRASS_GIS_novice_to_power_user_(workshop_at_FOSS4G_Boston_2017)#Hydrology:_Estimating_inundation_extent_using_HAND_methodology

You need r.stream.distance module from Addons:

g.extension r.stream.distance

Get drainage and streams from your DEM (your carved DEM):

r.watershed elevation=dem accumulation=flowacc drainage=drainage
stream=streams threshold=10

Compute height above nearest drainage/stream (HAND):

r.stream.distance stream_rast=streams direction=drainage
elevation=elevation method=downstream difference=hand

Use r.lake not on the original DEM, but on the HAND and start flooding
("lake") from the streams:

r.lake elevation=hand water_level=3 lake=flood_3m seed=streams

Convert to vector if desired:

r.to.vect -s input=flood_3m output=flood_3m type=area

The difference to the r.grow+r.mapcalc method [1] is that this uses an
addon module (there should be no problem installing it) and that r.grow
uses euclidean distance for what is later used for height difference while
r.steam.distance follows drainage and further that r.lake floods only the
cells accessible to water unlike the r.mapcalc expression which just looks
at height. The two methodological differences can be summarized as "not
respecting the surrounding terrain enough." Anyway, the r.grow+r.mapcalc
method can get you quite far and I would be interested in the comparison
(will differ for different terrains).

Best,
Vaclav

[1] https://lists.osgeo.org/pipermail/grass-user/2018-September/079134.html

On Fri, Sep 21, 2018 at 11:39 AM Shane Carey  wrote:

> Hi All,
>
> I have used r.carve to carve out the rivers of a DTM - a really super job.
> I now need to pour 3meters of water into every cell in the river and see
> how for this water extends out - onto the floodplain.
>
> I was trying to use r.lake to do this, but unsure as to how r.lake will
> work to pour 3 meters of water in every cell along the river network.
>
> Any advice on this would be great. It is for the creation of a floodplain.
>
> Thanks
>
>
> Le gach dea ghui,
> *Shane Carey*
>
> ___
> 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 above a river

[Vaclav Petras]

Hi Shane,

On Fri, Sep 14, 2018 at 5:03 PM Shane Carey  wrote:

>
> Does anyone know is it possible to calculate the elevation above a river
> channel (actual river network that was digitised as opposed to being
> extracted from a DTM) from a DTM and create a polygon from it.
>
> I need to calculate heights of 1m and 3m above a river channel on both
> sides of the channel and create a polygon from it.
>

Maybe Height Above Nearest Drainage (HAND) is what you are looking for. It
is basically done using:

r.stream.distance stream_rast=streams direction=drainage
elevation=elevation method=downstream difference=above_stream

See full workflow here:

https://grasswiki.osgeo.org/wiki/From_GRASS_GIS_novice_to_power_user_(workshop_at_FOSS4G_Boston_2017)#Hydrology:_Estimating_inundation_extent_using_HAND_methodology

You will need to do some post processing with r.lake or r.mapcalc and
r.to.vect to get the polygons.

Since you already have the streams and you want to use them, you need to
convert them to raster and then also get stream direction for
r.stream.distance by reclassifying, e.g. with r.mapcalc, output from
something like this:

v.to.rast in=streams output=streams_dir use=dir

which you can see in context here (different hydrology tool):

http://ncsu-geoforall-lab.github.io/geospatial-modeling-course/grass/simwe.html

However, I would be careful about how the streams fit with the terrain you
are using to be sure results make sense.

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

Re: [GRASS-user] Issue with r.mapcalc module

[Vaclav Petras]

On Thu, Sep 6, 2018 at 7:55 AM Micha Silver  wrote:

> You need quotes around the expression:
>
> On 06/09/2018 13:47, Vidura Dantanarayana wrote:
>
> Hi all,
> I need to create a raster file with the
> if(fuel_class==4,3,if(fuel_class==8,15)) expression. I used the following
> command but it result a parse error.
>
> r.mapcalc --overwrite expression=1hr_moisture =
> if(fuel_class==4,3,if(fuel_class==8,15))
>
> r.mapcalc --overwrite expression="1hr_moisture =
> if(fuel_class==4,3,if(fuel_class==8,15))"
>
> Also, what happens if feul_class is not 4 and not 8??
>


Good point.


>
> What could be the reason for the error?
>
>
Not sure, perhaps more info would be in the whole error message, but here
are some tips:

1. Check if the input raster map exists.
2. Do not start the raster map name with a number.
3. Use space after comma and around operators (best practice).

Here is the same expression but with the suggestions and null() for the
case Mica mentioned (note that I didn't actually tested that):

r.mapcalc --overwrite expression="moisture_1hr = if(fuel_class == 4, 3,
if(fuel_class == 8, 15, null()))"

Vaclav


> BR,
> Vidura Dantanarayana.
>
>
>
> ___
> grass-user mailing 
> listgrass-user@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/grass-user
>
>
> --
> Micha Silver
> Ben Gurion Univ.
> Sde Boker, Remote Sensing Lab
> +972-523-665918
>
> ___
> 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] experimental Python 3 support in trunk

[Vaclav Petras]

On Thu, Sep 6, 2018 at 4:41 PM Markus Metz 
wrote:

>
> That means that trunk will continue to use python2 by default, and it also
> requires that the link python is installed, which will, if installed, refer
> to the same target as python2.
>
> If we want to get python3 support tested in trunk, we must make it clear
> to testers that python must refer to python3, contrary to PEP394, i.e. "the
> user deliberately overrides this".
>
> IMHO, we would get more feedback on python3 support if we change the
> shebang to python3 in trunk.
>


Makes sense, but I don't think we should do that right now. We already know
many things don't work with Python 3 at all - I'm thinking about all things
dependent on ctypes - so we would seriously reduced the functionality for
the people who are using trunk for real work (so far we always had people
doing it and supported that AFAICT). We are now getting some testing done
and in some time, when Python 3 support is more complete and/or we are not
getting enough testing, we can change the shebang.

So far it seems to be that the Python virtual env works and, alternatively,
changing PATH (perhaps together with creating a symlink) should work too.
Also those who needed to workaround that they distro has python -> python3
symlink don't need to do the workaround anymore. Finally, we could include
patch, or perhaps a sed/awk/python script, to change the shebangs in the
local copy of the code. Mac OS and MS Windows might be little different,
but the virtual env approach should be applicable everywhere.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] experimental Python 3 support in trunk

[Vaclav Petras]

On Wed, Sep 5, 2018 at 3:57 PM Markus Metz 
wrote:

>
>
> On Wed, Sep 5, 2018 at 9:41 PM Martin Landa 
> wrote:
> >
> > Hi,
> >
> > st 5. 9. 2018 v 21:38 odesílatel Markus Metz
> >  napsal:
> > > alternatively, the shebang in GRASS *.py files can be changed to
> python3 (should be changed to python3 according to Python developer's Guide
> PEP394)
> >
> > we are going to support both Python2 and 3, at least for 7.6/7.8, right?
> Ma
>
> the symbolic link python is deprecated and will disappear soon from
> current distros: GRASS does not work if python does not exist, while
> python2 and/or python3 might exist. Current distros are already replacing
> the shebang in GRASS *.py files with python2. IMHO, if we want to support
> python3 we need to change the shebang accordingly: no more support for
> python2 in trunk.
>
> - python as a link to python2 is no longer available on modern distros
> - python3 is older than GRASS7
> - all currently supported distros provide a full python3 environment
>

Hi Markus and Martin,

That being said, GRASS GIS does not fully support Python 3 yet and, with
exception of few contributions, there was no major work done on the Python
3 support up until recently, i.e. we are not ready to switch to 3 for 7.6.
I think we can have something like "technical preview" in 7.8 (e.g. with
warning "use 3 only if you have to"). 8.0 should fully support 3.

Another thing is that Python 3 means using wxPython 4 to get the GUI (other
wxPythons don't support Python 3). That was hard to do for quite some time
(4.0.0 released in January), but now it is included, e.g., in Ubuntu 18.04
(released April).

As for the shebang, PEP394 says: "for the time being, all distributions
*should* ensure that python, if installed, refers to the same target as
python2, unless the user deliberately overrides this or a virtual
environment is active" and that "python should be used in the shebang line
only for scripts that are source compatible with both Python 2 and 3" which
is what we aim for. So that tells me we should keep there `python` and if a
distro decides to patch it to 2 (because their `python` does not point to
`python2` as PEP394 suggests) or perhaps later to 3 (because they want to
ensure `python3`), they are free to do that. We are not planning to drop
support for 2, so keeping `python` in shebang is appropriate in the long
term according to PEP394.

Best,
Vaclav


Links:
https://wxpython.org/news/wxpython-4.0.0-release/index.html
https://wxpython.org/news/wxpython-4.0.0a1-release/index.html
https://launchpad.net/ubuntu/+source/wxpython4.0
https://www.python.org/dev/peps/pep-0394/


>
> Markus M
>
> ___
> 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

Re: [GRASS-user] d.rast.edit increase the dimension of cell

[Vaclav Petras]

It may be helpful if you describe what you are doing, but my guess is that
d.rast.edit is not what you want. You may want to look either at some
resampling modules (e.g. r.resamp.stats) or it actually sounds more like
you want r.region which is good in case you actually want to preserve the
number of cells but just change the resolution (and extent). To get the
(cell) values to what you want, use r.mapcalc, something like:

r.mapcalc expression="new = 1000 * old"

Let us know how that goes.

Vaclav

On Thu, Aug 23, 2018 at 9:42 AM jaindamini 
wrote:

> I had to know that whether d.rast.edit allows us to increase the dimension
> of
> each cell?
> For example, if a cell is currently 0.001 x 0.001 m, is it possible to
> multiply these dimensions and the z value for each cell by 1000, resulting
> in a raster that preserves the morphology of the DEM but is at 1 m
> resolution?
>
>
>
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] Fwd: [Projects] OSGeo Annual General Meeting - projects please join and report (August 30 2018)

[Vaclav Petras]

On Sat, Aug 25, 2018 at 4:40 AM Luca Delucchi  wrote:

> On Thu, 23 Aug 2018 at 15:06, Markus Neteler  wrote:
> >
> > Does anyone volunteer to update accordingly
> >
> >
> https://docs.google.com/presentation/d/1imiG7x09ry7lGvmS15FCVq2Z7yaICY00fcpXBK27TXY/edit?usp=sharing
> > ?
> >
>
> I asked edit access, I will do it in the next days if none will modify
> it before...
>


I've already started the slide. Feel free to improve.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] New CLI option --tmp-location in 7.5 to enhance --exec

[Vaclav Petras]

On Thu, Aug 16, 2018 at 4:06 AM, Pierre Roudier 
wrote:
>
> Thanks Vaclav,


You are welcome. I hope it will be helpful.


> Looks like a great enhancement. It should make it easy to wrap it into
> a R package for example.


Yes, the idea for this is that it also should make easy to wrap GRASS GIS
in whatever you want.


> One question -- is that possible to refer to the input dataset in the
> script called
> by --exec? Something like:
>
> grass --tmp-location ~/data/elevation.tiff --exec "r.param.scale
> in=myinput out=myoutput param=slope size=9"


This makes sense since the GUI Startup (and/or Location Wizard) have this
functionality (also importing the file after using its SRS). However, this
is effectively an API and needs more considerations. How would you suggest
to deal with the output when `--tmp-location ~/data/elevation.tiff` creates
location with `elevation` raster but than myoutput is deleted with the rest
of the location? What about multiple inputs?

At this point, I'm hoping we can move forward through individual issues and
use cases (rather than revamping CLI altogether), so you remarks fall into
that well. Please, feel to submit an enhancement ticket ideally with a use
case, so we can discuss it there.

Please see also a little write-up I did for GSoC idea some time ago:

https://trac.osgeo.org/grass/wiki/GSoC/2018#Neweasy-to-useCLIandAPIforGRASSGIS

Best,
Vaclav

> Cheers,
>
> P
>
> On 15 August 2018 at 15:20, Vaclav Petras  wrote:
> > Dear user list,
> >
> > The (main) GRASS GIS executable, usually available as simply `grass` on
most
> > systems has now a new option (flag/parameter) in trunk (aka 7.5). The
option
> > is called --tmp-location.
> >
> > When specified, GRASS GIS automatically creates an new (and empty)
location
> > based on provided EPSG code or georeferenced file (similarly to what -c
flag
> > does). Newly it is also possible to provide string "XY" instead of EPSG
to
> > create XY (non-georeferenced) location.
> >
> > This temporary location has only PERMANENT mapset and the whole
location is
> > removed. The location is created in a temporary directory (which is also
> > deleted at the end).
> >
> > The flag --tmp-location is meant to be used together with --exec and it
is a
> > part of a lager endeavor to make the CLI easier for use from outside of
the
> > GRASS GIS session.
> >
> > If you are interested, please, test this new functionality. It is an
> > opportunity to provide feedback before this feature lands in the 7.6
> > release.
> >
> > Here are some things to try:
> >
> > * Execute a module in a location created based on EPSG:
> >
> >   grass --tmp-location EPSG:3358 --exec g.region -p
> >
> > * Execute Python script in a location created based on EPSG:
> >
> >   grass --tmp-location EPSG:3358 --exec script.py
> >
> > * Examine the created location using a Bash command:
> >
> >   grass --tmp-location EPSG:3358 --exec bash -c "g.proj -p && g.region
-p &&
> > g.mapset -p && g.gisenv GISDBASE,LOCATION_NAME sep=/"
> >
> > * Get SRS/CRS for a file:
> >
> >   grass --tmp-location ~/data/elevation.tiff --exec g.proj -p
> >
> > * Get help text for a module:
> >
> >   grass --tmp-location XY --exec r.neighbors --help
> >
> > See the documentation and `grass --help` for more hints (and let me
know how
> > these can be enhanced).
> >
> > Best regards,
> > Vaclav
> >
> >
> > https://trac.osgeo.org/grass/ticket/3537
> > https://trac.osgeo.org/grass/ticket/3585
> > https://trac.osgeo.org/grass/ticket/3586
> > https://trac.osgeo.org/grass/changeset/72790
> > https://trac.osgeo.org/grass/changeset/73096
> > https://trac.osgeo.org/grass/changeset/73098
> > https://trac.osgeo.org/grass/changeset/73099
> >
> >
> >
> > ___
> > 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] New CLI option --tmp-location in 7.5 to enhance --exec

[Vaclav Petras]

On Thu, Aug 16, 2018 at 6:39 AM, Nikos Alexandris 
wrote:
>
> * Vaclav Petras  [2018-08-14 23:20:16 -0400]:
>
> ..
>
>> If you are interested, please, test this new functionality. It is an
>> opportunity to provide feedback before this feature lands in the 7.6
>> release.
>>
>> Here are some things to try:
>>
>> * Execute a module in a location created based on EPSG:
>>
>>  grass --tmp-location EPSG:3358 --exec g.region -p
>>
>> * Execute Python script in a location created based on EPSG:
>>
>>  grass --tmp-location EPSG:3358 --exec script.py
>>
>> * Examine the created location using a Bash command:
>>
>>  grass --tmp-location EPSG:3358 --exec bash -c "g.proj -p && g.region -p
>> && g.mapset -p && g.gisenv GISDBASE,LOCATION_NAME sep=/"
>>
>> * Get SRS/CRS for a file:
>>
>>  grass --tmp-location ~/data/elevation.tiff --exec g.proj -p
>
>
> Perhaps test if the file exists and, if not, exit with an informative
error
> message?
>
> In Python:
>
> import os.path
> os.path.isfile(fname)
> ?

Hi Nikos,

sounds good to me. Do you want to submit an issue and suggest a patch?

Vashek

> Currently, if the file does not exist, the process hangs:
>
> ```
> Cleaning up temporary files...
> Starting GRASS GIS...
> ```
>>
>> * Get help text for a module:
>>
>>  grass --tmp-location XY --exec r.neighbors --help
>>
>> See the documentation and `grass --help` for more hints (and let me know
>> how these can be enhanced).
>>
>> Best regards,
>> Vaclav
>>
>>
>> https://trac.osgeo.org/grass/ticket/3537
>> https://trac.osgeo.org/grass/ticket/3585
>> https://trac.osgeo.org/grass/ticket/3586
>> https://trac.osgeo.org/grass/changeset/72790
>> https://trac.osgeo.org/grass/changeset/73096
>> https://trac.osgeo.org/grass/changeset/73098
>> https://trac.osgeo.org/grass/changeset/73099
>
>
> All works.
> Fantastic work!
>
> Kudos Radek and Vaclav,
> Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.region question

[Vaclav Petras]

Hi Rich,

On Wed, Aug 15, 2018 at 5:21 PM, Rich Shepard 
wrote:
>
> Does applying r.region to a portion of a large raster map functionally
> reduce the size of the map,

No, r.region changes the "region" of the raster map itself, i.e. changes
its extent and resolution. The data stays the same. Its changes the
metadata. The effect is stretching, shrinking, or moving the raster map.
Any suggestions for improvement of the manual page?

https://grass.osgeo.org/grass74/manuals/r.region

> equivalent to v.clip applied to vector maps?

See r.clip module in addons for equivalent of v.clip:

https://grass.osgeo.org/grass74/manuals/addons/r.clip.html

Best,
Vaclav
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] New CLI option --tmp-location in 7.5 to enhance --exec

[Vaclav Petras]

Dear user list,

The (main) GRASS GIS executable, usually available as simply `grass` on
most systems has now a new option (flag/parameter) in trunk (aka 7.5). The
option is called --tmp-location.

When specified, GRASS GIS automatically creates an new (and empty) location
based on provided EPSG code or georeferenced file (similarly to what -c
flag does). Newly it is also possible to provide string "XY" instead of
EPSG to create XY (non-georeferenced) location.

This temporary location has only PERMANENT mapset and the whole location is
removed. The location is created in a temporary directory (which is also
deleted at the end).

The flag --tmp-location is meant to be used together with --exec and it is
a part of a lager endeavor to make the CLI easier for use from outside of
the GRASS GIS session.

If you are interested, please, test this new functionality. It is an
opportunity to provide feedback before this feature lands in the 7.6
release.

Here are some things to try:

* Execute a module in a location created based on EPSG:

  grass --tmp-location EPSG:3358 --exec g.region -p

* Execute Python script in a location created based on EPSG:

  grass --tmp-location EPSG:3358 --exec script.py

* Examine the created location using a Bash command:

  grass --tmp-location EPSG:3358 --exec bash -c "g.proj -p && g.region -p
&& g.mapset -p && g.gisenv GISDBASE,LOCATION_NAME sep=/"

* Get SRS/CRS for a file:

  grass --tmp-location ~/data/elevation.tiff --exec g.proj -p

* Get help text for a module:

  grass --tmp-location XY --exec r.neighbors --help

See the documentation and `grass --help` for more hints (and let me know
how these can be enhanced).

Best regards,
Vaclav


https://trac.osgeo.org/grass/ticket/3537
https://trac.osgeo.org/grass/ticket/3585
https://trac.osgeo.org/grass/ticket/3586
https://trac.osgeo.org/grass/changeset/72790
https://trac.osgeo.org/grass/changeset/73096
https://trac.osgeo.org/grass/changeset/73098
https://trac.osgeo.org/grass/changeset/73099
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS GIS 7.4 in Ubuntu 18.04 LTS

[Vaclav Petras]

On Fri, Aug 10, 2018 at 3:45 PM, Markus Neteler  wrote:

> Hi Pablo,
>
> On Tue, Aug 7, 2018 at 6:22 AM, Pablo J. Zader 
> wrote:> Hi list
> ...
> > What is the best combination of grass with ubuntu (16.04 LTS,  18.04 LTS)
> > today?
>
> While I am mostly on Fedora, we also have GRASS GIS running on Ubuntu
> 18.04.
>
> Newer distro = newer packages (e.g. if you want ZSTD compression for G75
> etc.).
>

Also PDAL is packaged for 18.04, so you can compile GRASS with it.

https://launchpad.net/ubuntu/bionic/+source/pdal
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] Fwd: [Projects] OSGeo Annual General Meeting - projects please join and report (August 30 2018)

[Vaclav Petras]

I have created a page for 2017 based on the two slides from AGM 2017:

https://trac.osgeo.org/grass/wiki/AnnualReport/2017

The page for 2018 is here (please, contribute):

https://trac.osgeo.org/grass/wiki/AnnualReport/2018

On Fri, Aug 3, 2018 at 10:16 PM, Vaclav Petras  wrote:

> Items for the presentation can be collected (and preserved!) at the
> following wiki page which I created based on the description for the slides.
>
> https://trac.osgeo.org/grass/wiki/AnnualReports/2018
>
> Here is what we showed in 2017 (slides 33 & 34):
>
> https://docs.google.com/presentation/d/1T9QRcCdyd8PLQnXB2VfZ2k3ReX-
> 9CH_YXRg0VKqtgeQ/edit?usp=sharing
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] Fwd: [Projects] OSGeo Annual General Meeting - projects please join and report (August 30 2018)

[Vaclav Petras]

Items for the presentation can be collected (and preserved!) at the
following wiki page which I created based on the description for the slides.

https://trac.osgeo.org/grass/wiki/AnnualReports/2018

Here is what we showed in 2017 (slides 33 & 34):

https://docs.google.com/presentation/d/1T9QRcCdyd8PLQnXB2VfZ2k3ReX-9CH_YXRg0VKqtgeQ/edit?usp=sharing
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r3.in.xyz

[Vaclav Petras]

Hi, I'm not following this discussion fully, but don't you need just
r.to.rast3elev followed by some raster algebra with ifs (r3.mapcalc)?

https://grass.osgeo.org/grass74/manuals/r.to.rast3elev.html
https://grass.osgeo.org/grass74/manuals/r3.mapcalc.html

Best,
Vaclav

On Thu, Jun 28, 2018 at 12:18 PM, Francois Chartier 
wrote:

> Is it possible to define a horizontal constraints so that more weight is
> given on the interpolation of the property horizontally rather than
> vertically.
> Similarly in kriging we can define a semi variogram with an orientation in
> 2d, and i would like to know if it can be done in 3d.
> Also what about the question regarding the elevations between the top and
> bottom of the soil formation.  Is there a possibilty for v vol rst to
> consider data points in between top and bottom.
>
> On Jun 28, 2018 03:40, "Moritz Lennert" 
> wrote:
>
> On 27/06/18 16:32, Francois Chartier wrote:
> > So therefore, my approach of generating a soil property at each
> > elevation and interpolating is a correct approach.
> > Is there a way that i can constrain the interpolation horizontally.
>
> Not sure what you mean by constraining the interpolation horizontally.
>
> You can create a 2D elevation map by interpolating all your height
> information of layer 1 (for example using v.surf.rst). Then you create a
> second elevation map interpolating the layer 2 height information, etc.
>
> Moritz
>
>
>
> > I.
> > Cant remember the module name i am using but i am generating the 3d
> > raster from the 3d data points directly.
> >
> >
> > On Tue, Jun 26, 2018, 23:38 Moritz Lennert,
> > mailto:mlenn...@club.worldonline.be>>
> wrote:
> >
> > On 27/06/18 03:59, Francois Chartier wrote:
> >  > Hi,
> >  >
> >  > I am working with a data set that consists of borehole logs with
> > a Top
> >  > of a layer (layer 1) and the top of the underlying layer (layer 2)
> >  > (which is also the bottom of the overlying layer 1).  Everything
> in
> >  > between the elevation of top of layer 1 and top of layer 2
> > correspond to
> >  > a Layer 1 property.
> >  >
> >  > The thickness of Layer 1 varies and this layer may not exist
> > everywhere
> >  > (pinches out).  Above the Layer the property is different; in
> other
> >  > words the property only starts below the Top of layer 1 until the
> >  > underlying Top of the next layer.
> >  > Not sure of the capabilities of the interpolation in Grass and
> > working
> >  > with a very large data set (i cannot link every top of layers
> > together),
> >  > my first approach was to create a each Layer property for every
> >  > elevation slice along each Borehole axis, interpolating soil
> > properties
> >  > at every elevation between Boreholes.
> >  >
> >  > I read on another forum that r3.in.xyz 
> >  can
> >  > interpolate in 3D without a Property at every elevation slice,
> >  >
> >  >   * while respecting the condition that above the Top of the
> layer 2,
> >  > the property corresponds to the Overlying top layer 1, and
> >  >   * that the property is continuous until the next underlying
> > layer 3 -
> >  > can someone confirm this?
> >  >
> >  > To provide a bit of background, borehole data bases, identify the
> > top of
> >  > layer as encountered when drilling downwards, and provide the
> > elevation
> >  > of the next layer (pick); in between the soil property is the
> same,
> >  > however there is no data points.  When interpolating, while there
> > is no
> >  > data point in between the two geological picks, the property
> should
> >  > still have weight in the interpolation process.
> >  >
> >
> > I don't think r3.in.xyz  is what you need. This
>
> > module aggregates 3D
> > point data into voxels.
> >
> > You probably want to use something like r.to.rast3. This would mean
> > interpolating each layer separately into 2D elevation maps and then
> > assemble them into 3D using r.to.rast3.
> >
> > Moritz
> >
>
>
>
>
> ___
> 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] Re-organizing database locations

[Vaclav Petras]

On Fri, Jun 22, 2018 at 2:52 PM, Rich Shepard 
wrote:
>
> On Fri, 22 Jun 2018, Rich Shepard wrote:
>
>>  I need to re-organize locations within ~/data/grassdata and transform
all
>> projections to a single one. Locations now are by the states in which I
have
>> (or had) projects, but there are other locations within them that I want
to
>> collect into a single PERMANENT mapset.
>
>
>   Never mind. I'll create a new location using EPSG 2838, then transform
all
> other data to its PERMANENT mapset by reprojecting it.

g.proj.all might be helpful in that.

https://grass.osgeo.org/grass74/manuals/addons/g.proj.all.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Wildfire Modeling Using GRASS GIS

[Vaclav Petras]

Hi,

This result actually looks pretty good, unlike what you have sent me before
(off list). What exactly you don't like. Try to change some parameters like
wind direction to see how the model behaves.

Best,
Vaclav

On Mon, Jun 18, 2018, 1:30 AM Vidura Dantanarayana 
wrote:

> Hi all,
> I'm a student from University of Colombo School of Computing, Sri Lanka.
> Currently, I'm doing my research on wildfire behavior model optimization
> and I'm planning to use GRASS GIS wildfire modeling module for
> visualization of spread. I downloaded the sample data from grass.osgeo.org
> and execute the wildfire modeling. I think I was failed to get intended
> results. I will attach the result I got. It will be a great support if you
> can help me to get the correct result. And another question is how to
> prepare the data to be fed for the module. Anyways Thank You in advance,
> have a super wonderful day.
>
> Best Regards,
> Vidura Dantanarayana
> ___
> 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.decimate

[Vaclav Petras]

On Wed, Mar 21, 2018 at 12:00 PM, Anika Bettge  wrote:
>
> I have a question to the function v.decimate.
> Has the output normally (without using flag:-x) an attribute table?

No, unfortunately, it doesn't preserve attribute table, but it is a
reasonable enhancement proposal, please open an issue for it.

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

Best,
Vaclav
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] New AddOns for downloading and importing Sentinel products

[Vaclav Petras]

On Tue, Feb 20, 2018 at 5:12 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 20/02/18 01:24, Vaclav Petras wrote:
>
>>
>>
>> On Mon, Feb 19, 2018 at 4:49 PM, Moritz Lennert <
>> mlenn...@club.worldonline.be <mailto:mlenn...@club.worldonline.be>>
>> wrote:
>>
>>
>> and the module would only use it if it is chmod 600, i.e. only
>> readable
>> by the owner.
>>
>>
>> ...and the code to test that (user behaves safely) should be somewhere in
>> g.cloud and/or g.remote:
>>
>> https://trac.osgeo.org/grass/browser/grass-addons/grass7/general/g.cloud
>> https://github.com/wenzeslaus/g.remote
>>
>
>
> I suppose you mean should _also_ be ?



I mean that you can copy it from there, or from r.modis. Luca probably
knows best.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] New AddOns for downloading and importing Sentinel products

[Vaclav Petras]

On Mon, Feb 19, 2018 at 4:49 PM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

>
> and the module would only use it if it is chmod 600, i.e. only readable
> by the owner.
>

...and the code to test that (user behaves safely) should be somewhere in
g.cloud and/or g.remote:

https://trac.osgeo.org/grass/browser/grass-addons/grass7/general/g.cloud
https://github.com/wenzeslaus/g.remote
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.los problem when installing in GRASS 7.0.2

[Vaclav Petras]

On Thu, Feb 1, 2018 at 3:26 PM, Miguel Carrero <
miguel.carrero.pa...@gmail.com> wrote:

>
> I am trying to install r.los from g.extension, but returns me this error:
>
> ...
>
Does anyone know what's happening? The same happens when I try to install
> r.viewshed.cva
>

Another thing is, if you just need viewshed, you can use r.viewshed [1]
which replaced r.los [2].

Vaclav

[1] https://grass.osgeo.org/grass74/manuals/r.viewshed.html
[2]
https://ncsu-geoforall-lab.github.io/grass-as-a-platform/ncgis2017.html#/20
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Level LiDAR data to gps points

[Vaclav Petras]

[following on a private email:]

On Wed, Dec 27, 2017 at 6:14 PM, Vaclav Petras  wrote:

>
> Here, the assumption is that you can interpolate in between the points,
> i.e. that the interpolated values are meaningful. This assumption might be
> broken e.g. when some abrupt surface change influenced the vertical shift
> of the lidar points in a specific area/around certain GPS point (unlikely
> case).
>

Another assumption/limitation is that for interpolation to make sense, you
need to have area covered with GPS points and what is outside the GPS
points (i.e. not in between the GPS points) is not correctly interpolated
(interpolation vs extrapolation). There will be edge cases where it may or
may not work and in any case you should try different methods with
different settings and see the results. If you have just couple of points
(e.g. not enough to take one out and test the interpolation), average (one
value for all) may be the most robust option.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Level LiDAR data to gps points

[Vaclav Petras]

[cc'ing the list]

One way to do the spatially variable shift is to do what I suggested
earlier, but instead of the last step (computing average), interpolate a
surface from the differences at each point using, e.g., v.surf.rst with
zcolumn option set to the difference column computed earlier. For the
average, the assumption was that the shift is everywhere the same. Here,
the assumption is that you can interpolate in between the points, i.e. that
the interpolated values are meaningful. This assumption might be broken
e.g. when some abrupt surface change influenced the vertical shift of the
lidar points in a specific area/around certain GPS point (unlikely case).

To actually shift the data, you need to either do the calculation in the
attribute table (using the aforementioned modules such as v.db.update) or
more simply, and likely more efficiently, apply the shift to a raster with
binned elevations from r.in.lidar using r.mapcalc (same expression as
before, just with a raster map name instead of a constant).

On Wed, Dec 27, 2017 at 5:22 PM, Shane Carey  wrote:

> Oh super Vaclav, is there a way of doing a spatially variable shift or can
> you only do a block shift?
>
> Thanks for your help :-)
>
> On Wed, Dec 27, 2017 at 4:42 PM, Vaclav Petras 
> wrote:
>
>> On Tue, Dec 19, 2017 at 3:29 AM, Shane Carey  wrote:
>>
>>>
>>> I have some LiDAR data that was not levelled properly and I was
>>> wondering does anybody know of a way of levelling the las files to gps
>>> points?
>>>
>>>
>> Hi,
>>
>> if the issue is really just vertical (which is usually the case), you can
>> use v.transform zshift to shift by the given value. For rasters, e.g. DEM
>> based on binning the lidar points with r.in.lidar, you can use r.mapcalc to
>> shift it (e.g. expression "new = old + 2").
>>
>> The shift can be determined by binning (or even interpolating) the
>> points, followed by querying raster using the GPS points as a vector using
>> v.what.rast, and then by computing the difference using v.db.addcolumn and
>> v.db.update. Finally, you can average the difference using v.db.univar. One
>> (average) values will be usually good enough for lidar point cloud, for UAV
>> point cloud, spatially variable shift might be needed.
>>
>> Vaclav
>>
>>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Level LiDAR data to gps points

[Vaclav Petras]

On Tue, Dec 19, 2017 at 3:29 AM, Shane Carey  wrote:

>
> I have some LiDAR data that was not levelled properly and I was wondering
> does anybody know of a way of levelling the las files to gps points?
>
>
Hi,

if the issue is really just vertical (which is usually the case), you can
use v.transform zshift to shift by the given value. For rasters, e.g. DEM
based on binning the lidar points with r.in.lidar, you can use r.mapcalc to
shift it (e.g. expression "new = old + 2").

The shift can be determined by binning (or even interpolating) the points,
followed by querying raster using the GPS points as a vector using
v.what.rast, and then by computing the difference using v.db.addcolumn and
v.db.update. Finally, you can average the difference using v.db.univar. One
(average) values will be usually good enough for lidar point cloud, for UAV
point cloud, spatially variable shift might be needed.

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

Re: [GRASS-user] Cropping maps

[Vaclav Petras]

On Fri, Dec 1, 2017 at 10:39 AM, Markus Metz 
wrote:

>
>
> On Fri, Dec 1, 2017 at 4:26 PM, Vaclav Petras 
> wrote:
> >
> > For cropping, see also a new addon module called r.clip which clips
> according the computational region while respecting mask and the *original*
> raster resolution:
> >
> > https://grass.osgeo.org/grass72/manuals/addons/r.clip.html
> >
> > Testing and feedback welcome.
>
> About https://trac.osgeo.org/grass/browser/grass-addons/grass7/
> raster/r.clip/r.clip.py#L42
>
> g.region align=original
>
> is sufficient. You don't need to specify nsres or ewres when aligning to a
> raster map because nsres and ewres of the raster map are used anyway for
> alignment.
>
>

Fixed. Thanks MarkusM for the tip.

https://trac.osgeo.org/grass/changeset/71982

r.clip and v.clip are now missing in the Cropping maps wiki page if
somebody wants to contribute some text...

https://grasswiki.osgeo.org/wiki/Cropping_maps

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

Re: [GRASS-user] Cropping maps

[Vaclav Petras]

For cropping, see also a new addon module called r.clip which clips
according the computational region while respecting mask and the *original*
raster resolution:

https://grass.osgeo.org/grass72/manuals/addons/r.clip.html

Testing and feedback welcome.

Vaclav

On Tue, Sep 26, 2017 at 10:35 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 26/09/17 16:17, Moritz Lennert wrote:
>
>> On 26/09/17 15:57, Marco Alicera wrote:
>>
>>> Dear list,
>>> I am trying to crop a raster map into a smaller area, but I am failing.
>>>
>>> This wiki page link  is
>>> quite clear:
>>> "Make boundary into mask using r.mask
>>>  then copy raster
>>> source to new map (g.copy
>>> ). All cells
>>> outside of the mask will be omitted from the new copy."
>>>
>>> r.mask vector=myarea
>>> g.copy --overwrite raster=OldRasterWithBigArea,NewRasterWithSmallArea
>>> r.mask -r
>>>
>>> I expected all cell outside were not going to be omitted, but replaced
>>> by NULL.
>>>
>>
>> I'm not sure I understand your last sentence, but AFAIK, the wiki info
>> is wrong. g.copy works directly on the files and ignores mask and region
>> settings. In your example, OldRasterWithBigArea and
>> NewRasterWithSmallArea should be strictly identical.
>>
>> You need to use r.mapcalc "new = old" while the mask is set to get a
>> raster with everything outside the mask set to NULL.
>>
>
> I've rewritten the wiki page to try to make things clearer.
>
>
> Moritz
> ___
> 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] Talks and tutorials at ICC2017, Washington, DC, July

[Vaclav Petras]

Dear users and developers,

I would like to inform you about couple of talks and tutorials related to
GRASS GIS which will happen at the International Cartographic Conference
2017 in Washington, DC, July 1 to 7, 2017. Here are the details:

https://grasswiki.osgeo.org/wiki/GRASS_GIS_at_ICC_2017
http://icc2017.org/attendee-registration-form/

The tutorials will be mostly introductory. Feel free to spread the word,
Vaclav


PS: As always, please write here or extend the wiki if you are presenting
or know about more talks related to GRASS GIS.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Fwd: [OSGeo-Discuss] FOSS4G 2017 Boston Code Sprint

[Vaclav Petras]

[forwarded from osgeo-discuss]

Code Sprint in Boston, August 19th:

https://wiki.osgeo.org/wiki/FOSS4G_2017_Code_Sprint

Add yourself and topics if you are coming.

Best,
Vaclav

-- Forwarded message --
From: Regina Obe 
Date: Sun, May 21, 2017 at 3:23 AM
Subject: [OSGeo-Discuss] FOSS4G 2017 Boston Code Sprint
To: [...]


As with all FOSS4G conferences, we'll be having a code sprint the day after
the conference.

The code sprint is free of charge, though you will need to arrange your own
accommodations.

The code sprint will be held Saturday August 19th 2017 right after the 2017
FOSS4G Boston Conference.

If you'd like to attend, please add your name to the list below so we can
plan accordingly.  Also feel free to spread the word.


https://wiki.osgeo.org/wiki/FOSS4G_2017_Code_Sprint#Code_Sprint


Thanks,
Regina Obe
Boston LOC Committee member







___
Discuss mailing list
disc...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/discuss
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Vector attribute 'algebra' - calculating difference between areas of polygons

[Vaclav Petras]

On Wed, May 17, 2017 at 11:32 AM, James Duffy 
wrote:

> Is there some sort of vector algebra available in GRASS.



Speaking just about the vector algebra, some basic experimental
functionality is available in an experimental addon module v.mapcalc.

https://grass.osgeo.org/grass72/manuals/addons/v.mapcalc.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.to.vect stats

[Vaclav Petras]

On Mon, May 1, 2017 at 11:43 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>>
>> I have separated the binning code in r.in.lidar [3] so that it can be
>> used in r.in.xyz
>
>
> Is it different from the binning code in r.in.xyz ?


Not really. r.in.lidar was based on r.in.xyz, now they are different but of
course the idea is to make them again as similar as possible.

>
>
>
>> and the missing module which would do
>> the binning of a vector map into a raster map. There is actually a large
>> overlap with code for grid-based decimation of a point cloud (2D with
>> gridded or averaged X and Y). I already committed the code to r.in.lidar
>> [4], but we had a discussion on mailing list and decided that this
>> functionality should not be part of r.in.lidar, so it is disabled [5]
>> but the code is still there.
>
>
> So what you are saying is that the code should go into a library and be
used by all relevant modules ?


Yes. That would be ideal. Now it is in separate files in r.in.lidar and it
can be copied and synced, but I think the library would not be less general
than other libraries, so there is probably no reason to not include it. The
only reason I didn't do it is that I wanted to do the refactoring in
r.in.xyz first (which I never finished) and then work on the library.

>
>
>>
>> Anyway, a new module needs to be implemented for this. The name can be
>> something like r.binning, r.vect.stats, r.point.stats, or
>> r.points.stats. It might good project for beginners.
>
>
> I like the idea. But do you really think this would be much faster than
v.out.ascii | r.in.xyz ?


I don't know if much faster, but it will be at least little faster. Another
issue is that "v.out.ascii | r.in.xyz" is little hard to do on MS Windows
and from GUI in general. Yes, there should have been a wrapper module for
this already, but the a module to do the task directly is seems to me as a
better solution esp. if there is the library. But the wrapper module may be
a good way to start and to decide about the name and interface.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.to.vect stats

[Vaclav Petras]

On Mon, May 1, 2017 at 6:54 AM, Moritz Lennert  wrote:

> On 01/05/17 12:43, Martin Landa wrote:
>
>> I need a tool which converts vector features (points) to raster map
>> using statistical method like min,max,mean (something like
>> `r.in.lidar` does - if more points are found within one cell, raster
>> value is computed by given method).
>>
>> I started with module `r.to.vect`, but it takes only one attribute
>> value if more features found, `v.kernel` does not support attributes.
>> There is probably such tool, I must overlook something...
>>
>
> I generally use v.to.db op=coor && v.db.select | r.in.xyz for such a
> task. I don't know if a dedicated module would be much faster than a script
> that wraps around these modules. I guess avoiding the v.to.db part could
> gain you some time when dealing with lots of points.


Hi, this is certainly a missing feature. Even the v.to.rast documentation
[1] says:

v.out.ascii input=myschools_wake output=- column=value | r.in.xyz input=-

For certain cases, you may be able to use v.out.lidar instead of
v.out.ascii, but it is probably less efficient (although it uses LAS
instead of ASCII, you can't use pipes). You could also use v.mkgrid with
rectangular grid and v.vect.stats [2] followed by v.to.rast (which avoids
export, but for large grids it is likely very slow).

I have separated the binning code in r.in.lidar [3] so that it can be used
in r.in.xyz and the missing module which would do the binning of a vector
map into a raster map. There is actually a large overlap with code for
grid-based decimation of a point cloud (2D with gridded or averaged X and
Y). I already committed the code to r.in.lidar [4], but we had a discussion
on mailing list and decided that this functionality should not be part of
r.in.lidar, so it is disabled [5] but the code is still there.

Anyway, a new module needs to be implemented for this. The name can be
something like r.binning, r.vect.stats, r.point.stats, or r.points.stats.
It might good project for beginners.

Vaclav

[1]
https://grass.osgeo.org/grass72/manuals/v.to.rast.html#convert-vector-points-to-raster-with-raster-cell-binning
[2]
https://grass.osgeo.org/grass72/manuals/v.vect.stats.html#point-statistics-in-a-hexagonal-grid
[3] https://trac.osgeo.org/grass/changeset/66595
[4] https://trac.osgeo.org/grass/changeset/67210
[5] https://trac.osgeo.org/grass/changeset/68418
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] creating high-resolution DMT

[Vaclav Petras]

On Tue, Mar 21, 2017 at 10:01 AM, Markus Neteler  wrote:
>
> > Another drawback is that it was written
> > for GRASS 6 (but converting it to GRASS 7 should not
> > be hard, since it uses only the basic raster API).
>
> FWIW New names can be looked up here:
> https://trac.osgeo.org/grass/wiki/Grass7/RasterLib/ListOfFunctions

For those interested in what was required for the port from 6 to 7:

https://trac.osgeo.org/grass/changeset/70880
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] creating high-resolution DMT

[Vaclav Petras]

Back to filling holes in lidar data, I also think that the "fill in the
gaps" approach is quite promising, so I ported the r.fill.gaps module to G7:

https://grass.osgeo.org/grass72/manuals/addons/r.fill.gaps.html

I didn't review the code, but the documentation is very nice and detailed.
I did some mostly formatting updates for the current submitting guidelines
and added complete example with lidar data.

On Tue, Mar 21, 2017 at 7:29 AM, Benjamin Ducke 
wrote:

>
> I just realized that I have never committed "r.fill.gaps"
> to the add-ins repo.
>
>
Really nice module, please, find more of these in your shelf :-)

Thanks!
Vaclav



> I have just done that now:
>
> http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#r.fill.gaps
>
> Its purpose is filling small gaps in otherwise dense
> data using IDW with a pre-computed weights matrix.
> It works on rasterized data, so you simply use v.to.rast
> on your vector points first. Make sure to set the
> cell size small enough so that you don't get many
> vector points falling into the same cell. The result
> will be an oversampled raster with a lot of small
> "no data" cells. That's exactly the intended input for
> r.fill.gaps!
>
> This is not multi-core code, (parallelizing
> interpolation algorithms is hard, because you need to
> segment the data and then you need to deal with the
> seams between the segments), but it is very, very fast,
> as long as you keep the IDW radius small.
>
> The code is optimized to death, which makes it very
> hard to read. Another drawback is that it was written
> for GRASS 6 (but converting it to GRASS 7 should not
> be hard, since it uses only the basic raster API).
>
> r.fill.gaps is not useful for filling large gaps, both
> in terms of performance (for large IDW radii) and
> interpolation quality (it's IDW -- enough said).
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Workshops at FOSS4G 2017 in Boston and voting for presentations

[Vaclav Petras]

Dear users and developers,

I'm pleased to announce these two following GRASS GIS workshops which will
happen at FOSS4G 2017 in Boston:

* From GRASS GIS novice to power user
* Processing lidar and UAV point clouds in GRASS GIS

See the full descriptions here:

https://grasswiki.osgeo.org/wiki/GRASS_GIS_at_FOSS4G_Boston_2017

Also consider voting for GRASS GIS related talks at (closes Apr 10, vote
soon):

http://community-review.foss4g.org

Conference dates:

Workshops: Aug 14-15
Presentations: Aug 16-18
Sprint: Aug 19

Register here (early bird ends May 16):

http://2017.foss4g.org/

Hope to see you there,
Vaclav
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.mapcalc: compare two maps [RESOLVED]

[Vaclav Petras]

On Wed, Mar 29, 2017 at 8:46 PM, Rich Shepard 
wrote:

> n=140652
> null_cells=71271
> cells=211923
>

Relatively hight number of null cells.


> min=-1.89342188835144
> max=0.00093058729544282
> range=1.89435247564688
>

Probably small differences, but there is at least one outlier.


> mean=-5.03205256742558e-05
> mean_of_abs=5.24979771199771e-05
> sum=-7.07768257713542
> median=0
>

The overall differences are small or cancel out as they are distributed
around zero.

Looking at histogram may also help you interpret these statistics.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.mapcalc: compare two maps [RESOLVED]

[Vaclav Petras]

On Tue, Mar 28, 2017 at 4:30 PM, Rich Shepard 
wrote:

> Now I have the difference map which is a solid color...
> ...Ergo, no differences.
>

As Soeren mentioned in the other part of the thread, use r.univar to get
the statistics. Don't rely on just looking at the resulting raster map.
There can be things like outliers which may throw the visualization off.

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