Re: [GRASS-dev] GRASS flyer for the new osgeo branding

[Vaclav Petras]

Thank you for working on the flyer, Luca. Please see my comments below.

On Mon, Jul 24, 2017 at 6:55 PM, Luca Delucchi  wrote:

> I worked for the GRASS flyer [0] with the new osgeo branding, the
> content is really similar to the GRASS flyer, just different layout.
>
> Comments?
>

One of the triangles at the bottom is white (the overall background is
transparent). Is that an intention?

A long term endeavor: the whole paragraph shows bold for me.

Interoperability: I would remove gstat since AFAIU it is retired. There may
be better candidates for that place. For example, we are successfully using
GRASS with Blender (although the heavy lifting is mostly done on the
Blender part thanks to Blender GIS plugin & GDAL). ParaView may be a better
candidate.

G Logo: You have there logo without text with GRASS GIS next to it, so it
looks like a logo. We need to be careful with that and keep the brand. I
agree that we need a more horizontal logo and that we can have a logo in
OSGeo colors (as an alternative). I'm attaching Vincent's version with text
but in OSGeo colors (or close to them - there was still some confusion when
I was grabbing those).

OSGeo logo: It is not there, should be?

URL: Does it need to be a full URL with http://?

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

Re: [GRASS-dev] Adding hexagonal rasters to GRASS

[Vaclav Petras]

Dear Luís,

On Sun, Jul 23, 2017 at 11:50 AM, Luí­s Moreira de Sousa <
luis.de.so...@protonmail.ch> wrote:

>
> I presented hex-utils at the GISTAM conference in April, here is the video:
> https://www.youtube.com/watch?v=uLO4HDCVBp0
>
>
thank you, this is very informative and exiting!


>
> But as Luca said during the Q/A, it is probably better to start outright
> within GRASS. This will require the abstraction of the raster concept,
> together with operations like neighbourhood, number of neighbours, distance
> to neighbours, etc. With that done most of the raster modules would
> function the same way for squared and hexagonal rasters. Still, this would
> require a complete revision of all the raster modules.
>

Sounds good. I think there is a way in GRASS GIS to make it revolutionary
and at the same time keeping everything in place. See below.


>
> For a programmer, the main difference between hexagonal and squared
> rasters is the cell addressing system: with hexagons the axis are not
> orthogonal.
>

If there would be a way, like the abstraction you mentioned, which would,
e.g. make the current rectangle-only code work with hexagonal data (e.g. by
presenting converting hexagons as rectangles on the fly), that would be
helpful, but on the other side, I don't think it is necessarily the first
step if there is an other way how to connect with rectangular rasters (even
if it involves converting back and forth or less precision).


> However, it is possible to store an hexagonal raster in a bi-dimensional
> array like you would store a squared raster.
>

That would help the implementation and hopefully also the integration and
adoption, again see below.


> I wrote an article last year with full details on the HexASCII file format
> and how to deal with hexagonal cell adressing, but it is still under
> review. I can not send it to the list, please send me a personal message if
> you wish to read it.
>

If you can share it, I would like to see it.


>
> It would be great if we can take this forward. I imagine it is a load of
> work, but it will make GRASS an even more awesome system ;)
>
>
Load of work and resulting code to maintain should be part of the
consideration. Using existing functionality (algorithms, formats) and
integrating with it will be crucial for both users and developers alike.

Can you implement it this as a layer on top of existing functionality in
GRASS GIS? There is several examples and concepts in GRASS GIS of this. For
example, the temporal (t.*) modules work with series of rasters and vectors
registered as spatio-temporal datasets and the image processing (i.*)
modules work with series of rasters registered as imagery groups and
subgroups ("multiband image"). In both cases standard storage of rasters
(or vectors) is used, so there is no new backend format in GRASS database
except for the additional data (metadata) needed for these tools. What is
important is that you can work with the existing tools on the data handled
by temporal or imagery modules, i.e. you can use the existing tools to
implement the new tools (e.g. average of spatio-temporal raster dataset can
be implemented through a tool for average of multiple rasters) and if the
imagery or temporal modules miss specific functionality you need, you can
fallback to the standard modules (e.g. loop over members of imagery group).

I was thinking that the hexagonal rasters can be implemented in GRASS GIS
using two rasters which would be shifted against each other, but aligned
with the hexagonal cells, i.e. two rectangular rasters making up one
hexagonal raster/grid (but I didn't test that or examined that more). After
seeing your video with slightly rotated hexagonal grid, I'm thinking if it
is possible to fit only one raster but with different resolution to the
hexagons. The idea is that 1) you don't need another storage format and 2)
you can use the raw data without the hexagon-aware algorithms. Of course we
can settle just with re-using the storage format (1).

Another approach is to threat hexagonal rasters/grids as another basic data
type next to raster maps, vector maps, and 3D raster maps (in GRASS GIS
there are also the aforementioned spatio-temporal datasets and imagery
groups). They would be connected to the rest where it makes sense. For
example, (2D) rasters and 3D rasters are independent, but there is also
several connections: there are modules for conversion in between the two
types, a lot of code for handling colors is the same, and computational
region applies to both and is handled from the same module.

If I may ask, what would you need to create a prototype and what do you
envision as a final goal?

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

Re: [GRASS-dev] git repo for new Web site created

[Vaclav Petras]

On Sat, Jul 22, 2017 at 2:04 PM, Markus Neteler  wrote:

>
> Then we can enable you for the repo.
>

Please add me. My account is wenzeslaus

https://git.osgeo.org/gogs/wenzeslaus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: [mapserver-users] new official twitter account

[Vaclav Petras]

Hi Luca,

On Sat, Jul 22, 2017 at 5:24 AM, Luca Delucchi  wrote:

>
> For social people do we want/have a twitter channel too?
>

years ago, Jorge Cornejo (CC'ed) created and used this account. However,
recently the automatic settings associated with the account was only
reposting some RSS reader with inappropriate content (from point of view of
GRASS and open source) - Jorge already solved that. Last week or so, he
gave access to it through TweetDeck and he can give it to you as well. With
TweetDeck, I can now tweet and also delete old tweets. However, I don't
have a full access to the account and can't change name, banner, add people
to TweetDeck, etc. (Jorge has).

https://twitter.com/GRASSGIS

Vaclav



>
>
> -- Forwarded message --
> From: Jeff McKenna 
> Date: 22 July 2017 at 10:49
> Subject: [mapserver-users] new official twitter account
> To: MapServer 
>
>
> Hello from the OSGeo code sprint at FOSS4G paris!
>
> The MapServer team here has created a new twitter account for updates
> from the MapServer project: please share!
> https://twitter.com/mapserver_osgeo
>
> (this is from overwhelming feedback at FOSS4G this week from the
> community, for more public updates from the project)
>
> Thanks!
>
> -jeff
>
>
> --
> Jeff McKenna
> MapServer Consulting and Training Services
> http://www.gatewaygeomatics.com/
>
>
>
>
> ___
> mapserver-users mailing list
> mapserver-us...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>
>
> --
> ciao
> Luca
>
> www.lucadelu.org
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New attempt to update GRASS for Mac

[Vaclav Petras]

On Thu, Jul 20, 2017 at 3:34 AM, Rainer Krug <rainer_k...@icloud.com> wrote:

> On 19 Jul 2017, at 21:54, Vaclav Petras <wenzesl...@gmail.com> wrote:
>
> On Wed, Jul 19, 2017 at 12:42 PM, Michael Barton <michael.bar...@asu.edu>
> wrote:
>
>>
>> My group (CoMSES Net) is looking into Docker as a means of more
>> reproducible research in modeling science. Initial tests have gone OK, but
>> show that doing software with a GUI is considerably more complicated than
>> doing code that just runs from the command line. It might ultimately be
>> worthwhile to package GRASS as a Docker image.
>>
>
> We don't have an official GRASS Docker image. Maybe it wouldn't be even
> that advantageous for open science purposes.
>
>
> I disagree here - it would be quite an advantage. See for example the
> suite of rocker R images which are available and also used quite a bit (I
> assume). There is even a spatial one (https://hub.docker.com/r/rock
> er/geospatial/) which was added recentlyI, and I am still planning to
> build on that bundle an image which includes GRASS so that you have one
> Docker image for all your basic spatial GIS needs.
>
> Anyway - I think a  Docker image which is “officially” supported (which
> does not contain the GUI, only the command line) would be a very good
> starting point for further very useful Docker container. At least, there is
> another readable recipe for building GRASS from source (in addition to the
> TravisCI test).
>

I agree. There are two or three different cases. 1) Scientific images like
the R one you mentioned which won't be dedicated GRASS GIS images but
rather bundles where GRASS GIS is only one of the components. 2) Testing
image for build and running tests. The Dockerfile for some basic case can
be directly in the GRASS repository. 3) Dedicated Dockerfile/images for
specific projects, e.g. in the forestfrag3d repository there is a certain
development version with a custom patch (because of a bug). In this case
official image would not work because an that would be a stable release and
binary.

You can look at it also from a perspective of the GRASS code source. 1)
Dockerfile in the GRASS repository should use the code it lives in. 2) Some
software bundle may prefer to use some binary distribution (e.g. Ubuntu
PPAs). 3) Specific projects may need to use specific version of the code
and will download it from the repository.


> Anyway, we have already many Dockerfiles. See for example one from me
> which I created for reproducibility of my recent paper:
>
> https://github.com/wenzeslaus/forestfrag3d/blob/master/Dockerfile
>
> In the case of that repository, the idea is that user can (but does not
> have to) run GRASS GIS or QGIS (with GRASS GIS) natively on the data
> created in the Docker image, but the main outputs are PNG images, so no
> special software is necessary.
>
>
> So you have a GRASS Docker image, data is stored in /data in the native
> system, you run the Docker GRASS to generate data, and you than can use a
> native GRASS to do further work with the data - is this correct?
>

Yes. I provide people with Dockerfile through ZIP from paper or Git/GitHub
(as opposed to image from DockerHub). When running the container (`docker
run`) you specify what local/native directory should be linked to the
/data. All the intermediate and final outputs are stored there and
accessible when the `docker run` is done.

Creating and publishing a Docker image would probably add more stability to
the published work as it is a frozen state with all things included. (And
the repository with Dockerfile providing just the code for cases when
somebody wants to modify it.)


>
>
> In past, I had success in using Docker with SSH (all local). However, for
> future it seems that things like Jupyter Notebook (with its widgets) or a
> general web interface to GRASS GIS are a way how to get a GUI while using a
> Docker image.
>
>
> Yes - a web GUI would be perfect - either as a standalone app which
> connects to a GRASS session via e.g. ssh (which could be a local GRASS
> Docker image) our local GRASS, or via a server which is in the  Docker
> image installed (as is with the RStudio images at
> https://hub.docker.com/r/rocker/rstudio/.
>

What is the web GUI, i.e. how to get it to the web browser seems to be the
critical part here. But SSH may be a sufficient solution for now (e.g.
MobaXterm seem to work well for MS Win users - although I didn't see it
with Docker).


>
> A Jupyter Notebook (never used it, but using RStudio Notebooks - I assume
> very similar?) would be like literal programming - correct? And the results
> (e.g. results) would be embedded in the resulting document?
>

Yes, they are similar. Code, text, results - all in one document. Jupyter
Notebook can a

Re: [GRASS-dev] move everything from /lib/init/grass.py to /lib/python/init

[Vaclav Petras]

On Wed, Jul 19, 2017 at 1:42 AM, Pietro <peter.z...@gmail.com> wrote:

> On Mon, Jul 17, 2017 at 5:36 PM, Vaclav Petras <wenzesl...@gmail.com>
> wrote:
>
>>
>> On Mon, Jul 17, 2017 at 12:36 AM, Pietro <peter.z...@gmail.com> wrote:
>>
>>>
>>> On Fri, Jul 14, 2017 at 6:00 PM, Vaclav Petras <wenzesl...@gmail.com>
>>> wrote:
>>>
>>>> This is exactly what I had in my mind when doing the last major changes
>>>> in the grass.py file.
>>>>
>>> I generally like the layout you suggested. It seems to me that choosing
>>>> a good name for the whole module will be a bit tricky.
>>>>
>>>
>>> This is intended as a proof of concept to see the feasibility.
>>> I've try to found a better name but didn't come up to my mind...
>>> Perhaps: session instead of init?
>>>
>>> My final objective is to be able to do something like:
>>>
>>
>> That makes sense. In fact, that's very similar to a file I drafted some
>> time ago splitting the data initialization and runtime in
>> grass.script.setup and adding Session (see the attached file). Another
>> example, for a different case, is here:
>>
>> https://github.com/wenzeslaus/g.remote/blob/master/grasssession.py
>>
>
> Nice module, I was not aware of it!
> However I think that the purpose is slightly different. The grassession
> aims is to generate the session remotely, here I would like to setup a
> local session. It is true that I should be able to just connect through ssh
> to the localhost... but it seems to me not the right way.
>

Sure, the code is for use remote session on another computer, although by
switching the backend you can use the API for local session (without any
ssh to localhost):

https://github.com/wenzeslaus/g.remote/blob/master/localsession.py

What I'm bring up here is the idea of a Session API which works the same
for local session, remote session, or multiple sessions (in one script).


> So I've sketch a possible implementation just to see how it could work,
> see:
>
> https://git.osgeo.org/gogs/zarch/grass/commit/
> b9cb69a1d7381924b0c2229ba43f21b1b7473c72
>
>
Looks nice and clean. The difference to the above is that it does not
contain API for actually executing anything which removes the dependency
problems I mentioned earlier. This is probably much more fitting to the
current session as opposed to the remote (or generally "other") session as
used in g.remote. In other words, we have two different concepts for a
Session object (API): SessionA which sets the global state and thus sets up
a current session and SessionB which sets up a session which is remote or
local (but does touch the global state, i.e. the current session). SessionA
does not have any extra functions and all is executed through standard
(current) APIs while SessionB needs to provide all (or at least some)
functions for execution of modules or code (e.g. g.remote executes scripts).

Besides the fact that SessionA and SessionB have very different APIs and
behavior, my concern is that I think we should consider (and possibly
cover) the use case of parallel processing in different mapsets or parallel
rendering. SessionA is not good for this. SessionB is.

Another concern is the usage of context manager. It makes sense. It is a
resource, you connect, you open. But the state which is changes is global.
Is that expected from context manager? I don't know, I need to read the PEP.


> from grass.init import Session
>>>
>>> # with statement
>>> with Session('mygisdbase/location/mapset') as session:
>>> # do my stuff here
>>> ```
>>>
>>>
>>
>> Unfortunately, here is where the trouble begins. The above leads to the
>> following:
>>
>> with Session as session:
>> session.run_command(...)
>>
>> which fits with API which already exists for Ruby:
>>
>> https://github.com/jgoizueta/grassgis/
>>
>> GrassGis.session configuration do+
>> r.info 'slope'
>> g.region '-p'
>> end
>> The trouble is that session (at least in Python) needs to depend on the
>> rest of the library because it is the interface for the rest (on demand
>> imports may help here).
>>
>
> Sorry I'm not sure that I get your point here, what do you mean?
> The following code is running at the moment on my machine:
>
> ```python
> import os
> import sys
>
> MAPSET = '/home/pietro/docdat/gis/nc_basic_spm_grass7/user1/'
> GISBASE = '/home/pietro/docdat/src/gis/ggrass/dist.x86_64-pc-linux-gnu/'
>
> # set the path
> sys.path.append(os.path.join(os.environ.get('GISBASE', GISBASE),
>  

Re: [GRASS-dev] [pdal] [SoC] Week 07: Integration Of PDAL into GRASS GIS

[Vaclav Petras]

On Mon, Jul 17, 2017 at 11:57 AM, Paul Schrum <paul.sch...@gmail.com> wrote:

> I have set up the repository now on github:
>
> https://github.com/PaulSchrum/r.in.pdal
>

The error is:

cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but
not for C
cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but
not for C
In file included from .../pdal/StageFactory.hpp:38:0,
 from main.c:34:
.../pdal/Stage.hpp:37:16: fatal error: list: No such file or directory

You are trying to compile C++ code (specifically the Stage.cpp headers) as
C which results in header `list` not being found (line 37 -> #include
 -> list: No such file or directory).

Rename main.c to main.cpp.


>
> - Paul
>
>
> On Sun, Jul 16, 2017 at 5:31 PM, Vaclav Petras <wenzesl...@gmail.com>
> wrote:
>
>>
>>
>> On Sat, Jul 15, 2017 at 3:47 PM, Paul Schrum <paul.sch...@gmail.com>
>> wrote:
>>
>>>
>>> *3. Are you blocked on anything?*
>>> Yes.  After setting up r.in.pdal and adding the #include files for Pdal,
>>> make can't find them.  I have a request in with my mentor to help me
>>> troubleshoot this as soon as possible.
>>>
>>>
>> Hi Paul, a link to a repository with code would help.
>>
>>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] move everything from /lib/init/grass.py to /lib/python/init

[Vaclav Petras]

On Mon, Jul 17, 2017 at 12:36 AM, Pietro <peter.z...@gmail.com> wrote:

>
> On Fri, Jul 14, 2017 at 6:00 PM, Vaclav Petras <wenzesl...@gmail.com>
> wrote:
>
>> This is exactly what I had in my mind when doing the last major changes
>> in the grass.py file.
>>
> I generally like the layout you suggested. It seems to me that choosing a
>> good name for the whole module will be a bit tricky.
>>
>
> This is intended as a proof of concept to see the feasibility.
> I've try to found a better name but didn't come up to my mind...
> Perhaps: session instead of init?
>
> My final objective is to be able to do something like:
>

That makes sense. In fact, that's very similar to a file I drafted some
time ago splitting the data initialization and runtime in
grass.script.setup and adding Session (see the attached file). Another
example, for a different case, is here:

https://github.com/wenzeslaus/g.remote/blob/master/grasssession.py

*# Perhaps in GRASS8 we will be able to skip this! ;-)*
> sys.append(os.environ.get('GISBASE', '/home/pietro/my/gisbase'))
>

Added to the list, but how to do it remains unclear (many different
discussions in Trac and ML):

https://trac.osgeo.org/grass/wiki/Grass8Planning


>
> from grass.init import Session
>
> # open - close mode
> session = Session('mygisdbase/location/mapset')
> session.open()
> # do my stuff here...
> session.close()
>
> # with statement
> with Session('mygisdbase/location/mapset') as session:
> # do my stuff here
> ```
>
>

Unfortunately, here is where the trouble begins. The above leads to the
following:

with Session as session:
session.run_command(...)

which fits with API which already exists for Ruby:

https://github.com/jgoizueta/grassgis/

GrassGis.session configuration do+
r.info 'slope'
g.region '-p'
end
The trouble is that session (at least in Python) needs to depend on the
rest of the library because it is the interface for the rest (on demand
imports may help here).

So perhaps having grass.init or grass.setup with the low level functions
and then a separate grass.session with a nice interface which may depend on
all other modules may be a better way. (Although having each function from
the library as a method of Session calls for more thinking about
grass.session.Session.

Just to be clear: I definitively think this should be done. I'm just not
sure what is the right way.

Vaclav
"""Setup and initialization functions

Function can be used in Python scripts to setup a GRASS environment
without starting an actual GRASS session.

Usage::


On Linux when GRASS GIS executable on path, use::

export LD_LIBRARY_PATH=$(grass --config path)/lib
export PYTHONPATH=$(grass --config path)/etc/python

When GRASS GIS executable is not on path, you have spaces in paths
and you want to preserve the context of the variables, use::

export GRASS_EXECUTABLE="/path/to/grass"
export LD_LIBRARY_PATH="$($GRASS_EXECUTABLE --config path)/lib:$LD_LIBRARY_PATH"
export PYTHONPATH="$($GRASS_EXECUTABLE --config path)/etc/python:$PYTHONPATH"

On MS Windows, use::

set GRASS_EXECUTABLE="C:\path\to\grass\grass70.bat"
set PATH="C:\path\to\grass\lib;%PATH%"
set PYTHONPATH="C:\path\to\grass\etc\python;%PYTHONPATH%"

On Mac OS X, use instruction for Linux and use ``DYLD_LIBRARY_PATH``
instead of ``LD_LIBRARY_PATH``. For other systems, use instructions
for Linux and replace ``LD_LIBRARY_PATH`` and colon by their
equivalent if needed.



(C) 2010-2012 by the GRASS Development Team
This program is free software under the GNU General Public
License (>=v2). Read the file COPYING that comes with GRASS
for details.

@author Martin Landa 
@author Vaclav Petras 
"""

# TODO: this should share code from lib/init/grass.py
# perhaps grass.py can import without much trouble once GISBASE
# is known, this would allow moving things from there, here
# then this could even do locking

import os
import sys
import subprocess
import tempfile as tmpfile

# this file does not depend on anything in script and we should
# keep it this way, except for creating location and this should be done
# by lazy import
# TODO: move this file from grass.script.setup to grass.setup

def write_gisrc(dbase, location, mapset):
"""Write the ``gisrc`` file and return its path."""
gisrc = tmpfile.mktemp()
with open(gisrc, 'w') as rc:
rc.write("GISDBASE: %s\n" % dbase)
rc.write("LOCATION_NAME: %s\n" % location)
rc.write("MAPSET: %s\n" % mapset)
return gisrc


def set_gui_path():
"""Insert wxPython GRASS path to sys.path."""
gui_path = os.path.join(os.environ['GISBA

Re: [GRASS-dev] [pdal] [SoC] Week 07: Integration Of PDAL into GRASS GIS

[Vaclav Petras]

On Sat, Jul 15, 2017 at 3:47 PM, Paul Schrum  wrote:

>
> *3. Are you blocked on anything?*
> Yes.  After setting up r.in.pdal and adding the #include files for Pdal,
> make can't find them.  I have a request in with my mentor to help me
> troubleshoot this as soon as possible.
>
>
Hi Paul, a link to a repository with code would help.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] move everything from /lib/init/grass.py to /lib/python/init

[Vaclav Petras]

Hi, Pietro. Just a short answer for now. This is exactly what I had in my
mind when doing the last major changes in the grass.py file. I generally
like the layout you suggested. It seems to me that choosing a good name for
the whole module will be a bit tricky. Also I think one reason for having
them there was that grass.py works without a he G Python lib found. Vaclav

On Jul 14, 2017 10:00 AM, "Pietro"  wrote:

> Dear devs,
>
> What do you think if we move all the function that at the moment are
> contained in `/lib/init/grass.py` into a new subfolder under `/lib/python`
> ?
>
> The main advantages that I see are:
>
> - start a python script in GRASS just setting the the python path and then
> I can use the same functions that are defined for the normal GRASS start
> up, without duplicate code;
> - We can add unittest for the start up functions
> - We can remove code duplication between grass.init and grass.script.core
>
>
> What do you think?
>
> I did the changes and at least on my computer GRASS is working, all the
> changes are available at this link:
>
> https://git.osgeo.org/gogs/zarch/grass/commit/
> 27c8351423da645d938fb6c2e54781ee24e6f074
>
>
> I've split the functions that were contained in the grass.py in the
> following files, any comments?
>
>
> ```
> $ rg -e "^def\s[a-z_]+\(|^class\s[A-Z][a-z]*|^[A-Za-z_]+\s*="
>
> *gettext.py*
> 11:_ = gettext.gettext
>
> *message.py*
> 7:_DEBUG = None
> 10:def warning(text):
> 14:def fatal(msg):
> 19:def message(msg):
> 24:def is_debug():
> 41:def debug(msg):
>
> *utils.py*
> 13:def grep(pattern, lines):
> 23:def print_params():
> 62:def get_username():
> 85:def make_fontcap():
> 93:def ensure_db_connected(mapset):
> 102:def get_shell():
>
> *gui.py*
> 20:def read_gui(gisrc, default_gui):
> 53:def check_gui(expected_gui):
> 94:def save_gui(gisrc, grass_gui):
> 102:def gui_startup(grass_gui):
> 135:def start_gui(grass_gui):
> 148:def close_gui():
> 165:def clear_screen():
> 176:def show_banner():
> 188:def say_hello():
> 203:def show_info(shellname, grass_gui, default_gui):
> 229:def csh_startup(location, location_name, mapset, grass_env_file):
> 280:def bash_startup(location, location_name, grass_env_file):
> 313:PROMPT_COMMAND=grass_prompt\n""" % (_("2D and 3D raster MASKs
> present"),
> 338:def default_startup(location, location_name):
> 353:def done_message():
>
> *subprocess.py*
> 10:def call(cmd, **kwargs):
>
> *info.py*
> 5:BUILD_GISBASE = "@GISBASE@"
> 6:BUILD_PROJSHARE = "@CONFIG_PROJSHARE@"
> 7:CMD_NAME = "@START_UP@"
> 8:GRASS_VERSION = "@GRASS_VERSION_NUMBER@"
> 9:LD_LIBRARY_PATH = '@LD_LIBRARY_PATH_VAR@'
> 12:GISBASE = os.path.normpath(os.environ.get("GISBASE", BUILD_GISBASE))
> 13:GRASS_PROJSHARE = os.environ.get("GRASS_PROJSHARE", BUILD_PROJSHARE)
>
> *data.py*
> 13:def create_location(gisdbase, location, geostring):
> 47:def is_mapset_valid(full_mapset):
> 56:def is_location_valid(gisdbase, location):
> 72:def get_mapset_invalid_reason(gisdbase, location, mapset):
> 106:def set_mapset(gisrc, arg, geofile=None, create_new=False):
> 191:def set_mapset_interactive(grass_gui):
> 218:def lock_mapset(mapset_path, force_gislock_removal, user, grass_gui):
> 270:class MapsetSettings(object):
> 301:def load_gisrc(gisrc, gisrcrc):
>
> *clean.py*
> 8:def try_remove(path):
> 15:def try_rmdir(path):
> 22:def cleanup_dir(path):
> 33:class Cleaner(object):  # pylint: disable=R0903
>
> *env.py*
> 22:def path_prepend(directory, var):
> 31:def path_append(directory, var):
> 40:def set_paths(grass_config_dir):
> 97:def set_defaults():
> 126:def set_display_defaults():
> 134:def set_browser():
> 173:def ensure_home():
> 180:def clean_env(gisrc):
> 192:def load_env(grass_env_file):
> 218:def set_language(grass_config_dir):
>
> *compatibility.py*
> 5:ENCODING = locale.getdefaultlocale()[1]
> 11:def to_text_string(obj, encoding=ENCODING):
>
> *path.py*
> 11:_WXPYTHON_BASE = None
> 14:def readfile(path):
> 21:def writefile(path, s):
> 27:def gpath(*args):
> 35:def wxpath(*args):
> 50:def get_grass_config_dir():
> 78:def create_tmp(user, gis_lock):
> 125:def clean_temp():
> 132:def get_gisrc_from_config_dir(grass_config_dir, batch_job):
> 143:def get_grass_env_file(sh, grass_config_dir):
> 160:def find_exe(pgm):
>
> *system.py*
> 4:windows = sys.platform == 'win32'
> 5:cygwin = "cygwin" in sys.platform
> 6:macosx = "darwin" in sys.platform
>
> *gisrc.py*
> 13:def create_gisrc(tmpdir, gisrcrc):
> 33:def read_gisrc(filename):
> 54:def read_env_file(path):
> 64:def write_gisrc(kv, filename):
> 71:def create_initial_gisrc(filename):
>
> *batch.py*
> 9:def get_batch_job_from_env_variable():
> 32:def run_batch_job(batch_job):
>
> *parser.py*
> 29:help_text = r"""GRASS GIS $VERSION_NUMBER
> 114:def help_message(default_gui):
> 121:class Parameters(object):
> 135:def parse_cmdline(argv, default_gui):
> 183:def main(argv):
> ```
>
> I wish you all a nice week-end.
>
> Pietro
>
> ___
> grass-dev mailing list
> 

Re: [GRASS-dev] GRASS GIS 7.2 talk at FOSS4G-E next week: highlights wanted

[Vaclav Petras]

Hi Markus,

On Thu, Jul 13, 2017 at 4:47 PM, Markus Neteler  wrote:

>
> I'd be glad to receive some suggestions and ideas what to highlight
> there beyond contents from
>

You can have a look at slides 43-56 from my presentation at NCGIS 2017.
Cloud, superpixels, command line (cool again!), Tangible Landscape and
urban modeling with FUTURES (both our lab's work if that's ok), Itzi,
resources for learning and couple of other things included in the release
notes.

https://ncsu-geoforall-lab.github.io/grass-as-a-platform/ncgis2017.html#/43

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

Re: [GRASS-dev] [SoC] Week 05: Integration Of PDAL into GRASS GIS

[Vaclav Petras]

Hi Paul,

On Fri, Jun 30, 2017 at 4:42 PM, Paul Schrum  wrote:

>
>
>
> 3. Are you blocked on anything?
>
>
>
> I have added a new .cpp file and .hpp file for generating pipelines from
> GRASS inputs.  They compile, but I can’t get them to link.  I think I
> will need help figuring this out.
>

it compiles for me. Try using the Makefile and adding it to the repository.


>
>
> Repo: https://github.ncsu.edu/ptschrum/v_in_pdal
>

...but before that, move the repository (see the open issue there).

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

Re: [GRASS-dev] [SoC] Week 01 Report - Integration Of PDAL into GRASS GIS

[Vaclav Petras]

This is actually a question for PDAL ML, not grass-dev, and Paul was
discussing it there, hence Adam's email.

But anyway, I told Paul not to worry about it for now, because the issue
(linking LAZ libraries to PDAL) is more or less orthogonal to Paul's
project (using PDAL in GRASS).

Thanks all for all the support,
Vaclav

On Wed, Jun 7, 2017 at 3:16 AM, Margherita Di Leo 
wrote:

> Hi Paul,
>
> in grass-dev ML you can likely find guidance, putting it in cc. Thanks.
>
> On Tue, Jun 6, 2017 at 9:51 PM, Paul Schrum  wrote:
>
>> Thank you Adam.
>>
>> I was able to build PDAL from source following instructions at Unix
>> Compilation .  I
>> then ran all of the unit tests based on Testing
>> .
>>
>> Later I realized that I am not able to read .laz files.  Doing so will be
>> essential to my project's success.  The way I know it can't read laz is,
>> from the command line, I enter:
>>
>> pdal info autzen.laz
>>
>> and it responds:
>>
>> PDAL: readers.las: Can't read compressed file without LASzip or LAZperf
>> decompression library.
>>
>> Do I need to download LASzip source and build that, then rebuild pdal?
>>
>> - Paul
>>
>>
>> On Mon, Jun 5, 2017 at 4:53 PM, Adam Steer  wrote:
>>
>>> Hi Paul
>>>
>>> What issues are you having with PDAL and LAZ compression? I don’t know
>>> if I can help for your use case, but I do have a working
>>> PDAL/laszip/laz-perf system natively installed on Linux without docker.
>>>
>>> Also I’m not officially a mentor of your or any project, but happy to
>>> help - and happy to discuss with your mentor(s) also if need be.
>>>
>>> Cheers
>>>
>>> Adam
>>>
>>> --
>>> Dr. Adam Steer
>>> Earth systems data service specialist
>>> National Computational Infrastructure
>>> Leonard Huxley Building, Mills Road
>>> The Australian National University
>>> Acton ACT 2600 Australia
>>>
>>> adam.st...@anu.edu.au
>>> +61 2 6125 1413
>>> http://nci.org.au
>>>
>>>
>>>
>>>
>>> > On 5 Jun 2017, at 11:13 am, Paul Schrum  wrote:
>>> >
>>> > Submitted by Paul Schrum
>>> > Also available at Integration Of PDAL into GRASS GIS
>>> >
>>> >   • What did you get done this week?
>>> >   • Built GRASS73 from source from my local repo directoy.
>>> >   • Stepped into a module (v.in.ascii) using the debugger to watch
>>> it work at the source code level. This was only proving the concept of
>>> stepping into the code – just getting it to work.
>>> >   • Talked with my mentor about the nature of the existing
>>> v.in.pdal module and what are some of the things which must be changed,
>>> fixed, or improved.
>>> >   • What do you plan on doing next week?
>>> >   • Continue stepping through v.in.ascii to see how it works at
>>> the source level in order to understand how to write points to a vectormap.
>>> >   • Get GRASS 73 to link to current version of PDAL.
>>> >   • Fix broken references to PDAL data structures in the GRASS
>>> source
>>> >   • Refactor existing v.in.pdal so that operations which r.in.pdal
>>> and r3.in.pdal will need are in a separate module and available as
>>> functions to be called from all three of them.
>>> >   • Learn the process of calling PDAL and how to get it to do the
>>> basic operation of reading a lidar file and handing over the data to the
>>> caller.
>>> >   • Set up a basic set of test data for PDAL, open it from pdal
>>> without GRASS, then open it using pdal through GRASS with only the most
>>> basic options in operation.
>>> >   • Get PDAL to be able to read .laz (compressed) files. For some
>>> reason it can’t do that after build-from-source.
>>> >   • Are you blocked on anything?
>>> > I had two listed on the Wiki when I originally posted it, but my
>>> mentor helped me work through those before the end of the reporting period
>>> for Week 1. So there are currently no issues blocking me.
>>> >
>>> > ___
>>> > SoC mailing list
>>> > s...@lists.osgeo.org
>>> > https://lists.osgeo.org/mailman/listinfo/soc
>>>
>>>
>>
>> ___
>> SoC mailing list
>> s...@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/soc
>>
>
>
>
> --
> Margherita Di Leo
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] 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-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.colors.matplotlib

[Vaclav Petras]

Hi Steve,

On Tue, May 30, 2017 at 3:10 PM, Steven Pawley 
wrote:

>
> Thanks for writing the r.colors.matplotlib tools because I use the
> matplotlib colorramps very frequently both in GRASS and in python more
> generally.
>

Glad to hear that.


>
> I seem to be having a problem of using the perceptually uniform ramps in
> the r.colors.matplotlib add on, receiving the error: ERROR: Matplotlib
> 2.0.2 does not contain color table 
>
> I'm on linux and matplotlib 2.0.2 has the perceptually uniform ramps, and
> I can use them if I display data in python within a GRASS session directly
> (i.e. plt.imshow(numpyraster, cmap='plasma').
>
> Is there a reason why r.colors.matplotlib can't see these ramps? It still
> works with all of the traditional matplotlib ramps.


The module does not check for specific color maps in mpl, but it uses
general code to check the presence of a requested color map. It imports
matplotlib.cm.datad dictionary. Perhaps, this dictionary does not contain
the new color maps. The checking is not ideal, it should based on
cm.get_map() function. I think the reason why I "ask for permission" here
instead is that I was not able to figure out what is the error state from
get_map() or how to transfer it to the user. But perhaps you will be more
successful or 2.0 behaves differently. The relevant code is here:

https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.colors.matplotlib/r.colors.matplotlib.py#L164

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

Re: [GRASS-dev] G7 helptext: replace Fig. 1: GRASS GIS 7 location structure with new figure

[Vaclav Petras]

On Thu, May 25, 2017 at 1:15 AM, Markus Neteler  wrote:

> IMHO "Fig. 1: GRASS GIS 7 location structure" in
> https://grass.osgeo.org/grass72/manuals/help_loc_struct.png
> https://grass.osgeo.org/grass72/manuals/helptext.html
>
> (master: doc/help_loc_structure.odg)
>
> often confuses users while
> https://grasswiki.osgeo.org/wiki/File:Grass_database.png
>
> is so much better! Could we exchange that somehow?
>
> The help_loc_struct.png is fine for the dev manual but not for the user
> manual.
>
> Since you are the author of File:Grass_database.png I thought to ask here.
>


Yes, but it is more complicated. The reason to create the new figure was
that the old one is developer and file structure focused. The new one is
hight level and user focused.

However, the important part is that the figure is for a new page which is
supposed to be the new page about the database which would separate a
detailed explanation of the database from the intro to GRASS. The
helptext.html is now used (as link or button) for both explanation of the
database structure and into to using GRASS. The database page is here:

https://grass.osgeo.org/grass73/manuals/grass_database.html

The into page is still missing. There is of course an overlap in between
these two. It could look like one of those:

http://ncsu-geoforall-lab.github.io/grass-intro-workshop/intro.html
http://www4.ncsu.edu/~akratoc/GRASS_intro/
http://fatra.cnr.ncsu.edu/temporal-grass-workshop/GRASS_intro.pdf

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

[GRASS-dev] 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-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Having trouble building GRASS from source and asking for help

[Vaclav Petras]

On Mon, May 15, 2017 at 4:14 PM, Paul Schrum  wrote:

> I should get this to succeed before moving on to other steps.



You don't actually need to do the "install" step to run it. Just run it
using ./bin.../grass73.

Generally speaking, it would be good to get this resolved.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Introduction for GSoC 2017

[Vaclav Petras]

On Fri, May 12, 2017 at 9:51 AM, Martin Landa 
wrote:

> since the tools is experimental we should not include in G7.4 I would
> say.
>

Or just say they are experimental.


> If you agree we have two options:
>
> * move it to Addons
> * after creating relbr_74 to remove the tools
>

Then I would just remove them from 74, because we want them in trunk. I
don't like it that much, but copy in addons may be good for users.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Broken: GRASS-GIS/grass-ci#2145 (master - d37fa7c)

[Vaclav Petras]

On Sun, May 7, 2017 at 8:00 AM, Markus Neteler <nete...@osgeo.org> wrote:
>
> On May 7, 2017 12:36 AM, "Vaclav Petras" <wenzesl...@gmail.com> wrote:
> >
> > On Fri, May 5, 2017 at 6:36 AM, Travis CI <bui...@travis-ci.org> wrote:
> > >
> > > GRASS-GIS / grass-ci (master)
> > > Build #2145 was broken.
> > > ...
> > > git-svn-id: https://svn.osgeo.org/grass/grass/trunk@71024
15284696-431f-4ddb-bdfa-cd5b030d7da7
> > > ...
> >
> > >
> > > We have updated our sudo-enabled Precise images! Read our blog post
for more details. Thank you!
> > > ...
> >
> > There is some issue with packages in the Travis build:
>
> ...
> > The Travis build is based on Ubuntu 12.04 Precise and uses
ppa:ubuntugis/ubuntugis-unstable which seems to support 12.04.
> ...
>
> Is there a way to update to a more recent Ubuntu version?

It is mostly Travis-CI who decides what is running there, but they now have
Ubuntu 14.04 Trusty as a beta [1]. I've tried that since we had nothing to
loose and it seems to work now:

On Mon, May 8, 2017 at 5:22 PM, Travis CI <bui...@travis-ci.org> wrote:
>
> GRASS-GIS / grass-ci (master)
> Build #2153 was fixed.
> 6 minutes and 23 seconds
> Václav Petráš da79a7f Changeset →
>   travis: atempt to fix repo error using trusty beta environment
>
> git-svn-id: https://svn.osgeo.org/grass/grass/trunk@71066
15284696-431f-4ddb-bdfa-cd5b030d7da7

[1] https://docs.travis-ci.com/user/trusty-ci-environment
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Still Failing: GRASS-GIS/grass-ci#2150 (master - 6f1ff0c)

[Vaclav Petras]

Please follow the discussion started from the first failed commit for
updates:

[GRASS-dev] Broken: GRASS-GIS/grass-ci#2145 (master - d37fa7c)
http://lists.osgeo.org/pipermail/grass-dev/2017-May/084921.html
http://lists.osgeo.org/pipermail/grass-dev/2017-May/084932.html
http://lists.osgeo.org/pipermail/grass-dev/2017-May/084933.html


On Mon, May 8, 2017 at 1:47 PM, Yann  wrote:
>
>
> Travis needs some love: Unable to locate External PROJ.4 includes in the
configure process
>
>
> checking for proj_api.h... no
>
> configure: error: *** Unable to locate External PROJ.4 includes.
>
> include/Make/Vars.make:1: include/Make/Platform.make: No such file or
directory
>
> make: *** No rule to make target `include/Make/Platform.make'. Stop.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Broken: GRASS-GIS/grass-ci#2145 (master - d37fa7c)

[Vaclav Petras]

On Fri, May 5, 2017 at 6:36 AM, Travis CI  wrote:
>
> GRASS-GIS / grass-ci (master)
> Build #2145 was broken.
> ...
> git-svn-id: https://svn.osgeo.org/grass/grass/trunk@71024
15284696-431f-4ddb-bdfa-cd5b030d7da7
> ...
>
> We have updated our sudo-enabled Precise images! Read our blog post for
more details. Thank you!
> ...

There is some issue with packages in the Travis build:

"""
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libgdal-dev : Depends: libgdal1h (= 1.10.0-1~precise2) but it is not going
to be installed
"""

The build fails with error:

"""
checking for location of External PROJ.4 includes...
checking for proj_api.h... no
configure: error: *** Unable to locate External PROJ.4 includes.
include/Make/Vars.make:1: include/Make/Platform.make: No such file or
directory
make: *** No rule to make target `include/Make/Platform.make'.  Stop.
"""

The Travis build is based on Ubuntu 12.04 Precise and uses
ppa:ubuntugis/ubuntugis-unstable which seems to support 12.04. The missing
file is from libproj-dev. I don't have the this issue on 16.04. That's all
I have now.

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

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

[Vaclav Petras]

On Fri, May 5, 2017 at 3:43 AM, Moritz Lennert  wrote:

> Markus is probably right: working with an intermediate file solves all
> this and I don't think it would imply a serious speed decrease.
>

I have tested r.vect.stats (with pipe) and compared it with pipe in shell -
the time is the same (expected behavior). Here is the test with pipe in
shell for 19693050 (almost 20 million) points:

time sh -c "v.out.ascii input=points layer=-1 format=point sep=pipe |
r.in.xyz input=- output=bin2 method=mean sep=pipe --o"
real1m5.982s
user1m39.120s
sys0m1.740s

And here is the same test but using temporary file (similar result with and
without SSD):

time sh -c "v.out.ascii input=points layer=-1 format=point sep=pipe
output=tmp.txt --o; r.in.xyz input=tmp.txt output=bin3 method=mean sep=pipe
--o"
real1m32.933s
user1m30.472s
sys0m1.796s

According to this, using temporary file requires 1.4 more time.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Vaclav Petras]

On Fri, May 5, 2017 at 3:55 AM, Martin Landa  wrote:

> BTW, meanwhile I changed in r71022 default
> method from 'mean' (module was calculating mean value of categories)
> to 'n' (number of points in cell).
>

Before it gave expected result for points with Z, e.g. in full NC loc:

r.vect.stats in=elev_lid792_bepts out=ground

Now it gives error (likely due to column=options['column']), but more
importantly, other binning modules (r.in.lidar, r.in.xyz) have mean as
default, so we need to be careful not to be inconsistent and produce
expected results. Can this have no default? Or perhaps the "use" paradigm
as with other modules such as v.to.rast is appropriate here
(use=attr|cat|z), then again we have the issue of default value versus no
value for default, but at least it is general enough to accommodate both
XYZ point clouds and points with attributes.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Vaclav Petras]

On Wed, May 3, 2017 at 5:34 AM, Moritz Lennert <mlenn...@club.worldonline.be>
wrote:
>
> On 02/05/17 15:53, Vaclav Petras wrote:
>> I'm using pipe_command() which is just convenience function setting
>> stdout=PIPE. Similarly feed_command() is just setting stdin=PIPE which
>> I'm not using because I'm feeding the stdout of the other process
>> directly (stdin=first_process.stdout). What I don't understand,
>> regardless of using stdin=PIPE or stdin=first_process.stdout for the
>> second process, is what should be next.
>
> Do you really need the in_process.communicate() ? Here's what I used
> in a local script and it works, without communicate(). Then again,
> I don't think the data flowing through this pipe ever exceeded available
memory.
>
> pin = gscript.pipe_command('v.db.select',
>map = firms_map,
> ...
> total_turnover_map = 'turnover_%s' % nace2
> p = gscript.start_command('r.in.xyz',
>   input_='-',
>   stdin=pin.stdout,
> ...
> if p.wait() is not 0:
> gscript.fatal("Error in r.in.xyz with nace %s" % nace2)

The Popen.wait() documentation [1] says: "Warning: This will deadlock when
using stdout=PIPE and/or stderr=PIPE and the child process generates enough
output to a pipe such that it blocks waiting for the OS pipe buffer to
accept more data. Use communicate() to avoid that."

And since I'm using stdout=PIPE (pipe_command()), I use communicate(). What
troubles me is that Popen.communicate(input=None) documentation [2] says:
"Note: The data read is buffered in memory, so do not use this method if
the data size is large or unlimited."

It says "data read", so it probably talks about stdout=PIPE when
communicate() does not return None(s) but data (stdout=PIPE and communicate
with the same process), i.e. it doesn't apply to this case and I don't have
to be troubled. As for the wait(), I think that it may work (works most of
the time), it is just not guaranteed to work with large data and it depends
on how smart the OS will be.

Vaclav

[1] https://docs.python.org/2/library/subprocess.html#subprocess.Popen.wait
[2]
https://docs.python.org/2/library/subprocess.html#subprocess.Popen.communicate
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.binning

[Vaclav Petras]

On Wed, May 3, 2017 at 6:57 AM, Markus Neteler  wrote:

> > The module name r.binning is rather non-descriptive. I would suggest
> > r.vect.stats because it can be regarded as the inverse of v.rast.stats,
> and
> > because it is similar to r.resamp.stats. All do statistical aggregation.
>
> +1  r.vect.stats sounds more descriptive.


Done in r71021. Thanks for the feedback.

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

Re: [GRASS-dev] [GRASS-SVN] r70999 - grass-addons/grass7/raster/r.learn.ml

[Vaclav Petras]

On Tue, May 2, 2017 at 12:45 PM,  wrote:

> Author: spawley
> Date: 2017-05-02 09:45:12 -0700 (Tue, 02 May 2017)
> New Revision: 70999
>
> Modified:
>grass-addons/grass7/raster/r.learn.ml/r.learn.ml.py
>grass-addons/grass7/raster/r.learn.ml/r_learn_utils.py
> Log:
> r.learn.ml using multiprocessing for all cross-validations
>
> Modified: grass-addons/grass7/raster/r.learn.ml/r.learn.ml.py
> ===
> --- grass-addons/grass7/raster/r.learn.ml/r.learn.ml.py 2017-05-02
> 13:41:15 UTC (rev 70998)
> +++ grass-addons/grass7/raster/r.learn.ml/r.learn.ml.py 2017-05-02
> 16:45:12 UTC (rev 70999)
> @@ -249,13 +249,15 @@
> ...
> @@ -176,9 +215,9 @@
>  try:
>  list(scoring_methods.keys()).index(i)
>  except:
> -print('Scoring ' + i + ' is not a valid scoring method')
> -print('Valid methods are:')
> -print(scoring_methods.keys())
> +gscript.fatal('Scoring ' + i + ' is not a valid scoring
> method')
> +gscript.message('Valid methods are:')
> +gscript.message(scoring_methods.keys())
>

Hi Steven,

the fatal call will end the execution. What you can do is to put there a
multiline string.

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

Re: [GRASS-dev] [GRASS-SVN] r70814 - grass-addons/grass7/raster/r.vif

[Vaclav Petras]

On Fri, Mar 31, 2017 at 8:56 AM,  wrote:

> Author: pvanbosgeo
> Date: 2017-03-31 05:56:38 -0700 (Fri, 31 Mar 2017)
> New Revision: 70814
>
> Modified:
>grass-addons/grass7/raster/r.vif/r.vif.html
>grass-addons/grass7/raster/r.vif/r.vif.py
> Log:
> r.vif addon: computation of vif is now in Python, resulting in strongly
> reduced computing times. There is an option to use a random subsample of
> raster cells as input to further speed up the computations. There is
> furthermore a 'low-memory' option (this is the old implementation which
> uses r.regression.multi).
>
> ...
>
 # import libraries
>  import os
>  import sys
>  import math
>  import numpy as np
> -import grass.script as grass
> +from scipy import stats
>

Hi Paulo,

it seems that the scipy is not used. I would just remove the line to make
the module work on computers without scipy, but you may be still planning
some changes, so I don't want to interfere. Please let me know.

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

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

[Vaclav Petras]

On Tue, May 2, 2017 at 3:24 AM, Moritz Lennert  wrote:

> But I'm not against a wrapper. I added a prototype with limited
>> functionality to addons [1]. However, I'm not sure how to account for
>> large data - that's what discouraged me from creating a wrapper. The
>> Python subprocess documentation says use communicate() but its doc says
>> "The data read is buffered in memory, so do not use this method if the
>> data size is large or unlimited." [2] Do I have to do the buffering
>> myself then or is it just fine? Is there some code like this in GRASS?
>>
>
> Wouldn't using pipe_command() and feed_command() in the grass.script be a
> solution ?



I'm using pipe_command() which is just convenience function setting
stdout=PIPE. Similarly feed_command() is just setting stdin=PIPE which I'm
not using because I'm feeding the stdout of the other process directly
(stdin=first_process.stdout). What I don't understand, regardless of using
stdin=PIPE or stdin=first_process.stdout for the second process, is what
should be next.

https://grass.osgeo.org/grass70/manuals/libpython/script.html#script.core.pipe_command
https://grass.osgeo.org/grass70/manuals/libpython/script.html#script.core.feed_command
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.binning

[Vaclav Petras]

On Tue, May 2, 2017 at 5:31 AM, Paulo van Breugel 
wrote:

> Just had a look at r.binning, very useful.
>

Thanks. But is is not complete yet.


>
> There is a small error in the code, you are importing grass.script as gs,
> so on line 33 it should be
>
> options, flags = gs.parser()
>
> instead of
>
> options, flags = grass.parser()
>

Thanks. Fixed.

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


>
> I could have made the correction, but I am not sure what is customary in
> case of these kind of 'typos'.
>

Good question. If it looks like the person is working on it, it is little
safer to just tell then fix, I think. Actually, I'll send you similar email
later today.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Vaclav Petras]

[Switching from grass-user to grass-dev.]

On Mon, May 1, 2017 at 5:11 PM, Markus Metz 
wrote:

> > > 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.
>
> I would rather keep r.in.xyz as simple as possible and instead add
> wrapper scripts for specific tasks. Maybe r.in.lidar could be sync'ed back
> to r.in.xyz and a new wrapper script could be created, something like
> r.in.lidar.filter ;-)
>

I was perhaps not clear enough. The code of r.in.lidar and r.in.xyz is the
same even now except for the separation of the binning code and LAS versus
ASCII. There is some filtering related to lidar, but I don't understand if
it is what you mean. Nevertheless, some filtering in r.in.xyz and getting
some functionality from r.in.lidar would make sense (as they are used
interchangeably depending on libLAS availability); unfortunately not really
making it simpler.


> > >
> > >>
> > >> 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
>
> Why would a new C module be a better solution than a simple wrapper
> combining v.out.ascii + r.in.xyz? Considering code maintenance, a wrapper
> script would be easier to maintain. Otherwise, a dedicated C module would
> be another clone of r.in.xyz, taking as input not a text file but a GRASS
> vector with points.
>

I agree, script would be easier to maintain, but considering the
duplication between r.in.xyz and r.in.lidar (and possibly also r.in.pdal
which I haven't mentioned yet), I though moving the binning code to the
library and perhaps gaining some performance improvement along the way is a
better option.

But I'm not against a wrapper. I added a prototype with limited
functionality to addons [1]. However, I'm not sure how to account for large
data - that's what discouraged me from creating a wrapper. The Python
subprocess documentation says use communicate() but its doc says "The data
read is buffered in memory, so do not use this method if the data size is
large or unlimited." [2] Do I have to do the buffering myself then or is it
just fine? Is there some code like this in GRASS?

Thanks for the feedback,
Vaclav

[1] https://trac.osgeo.org/grass/changeset/70996
[2]
https://docs.python.org/2/library/subprocess.html#subprocess.Popen.communicate
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wxGUI unusual high CPU usage debugging

[Vaclav Petras]

On Tue, Apr 25, 2017 at 6:38 AM, Markus Neteler  wrote:

> If you can
> > figure out the actual python program that it runs, that would be
> helpful.
>

It runs wxgui.py [1], so you can use something like:

cd grass/src
python gui/wxpython/wxgui.py

or:

python $GISBASE/gui/wxpython/wxgui.py

Well, but that's just how to run the Python code directly.

Vaclav

[1]
https://trac.osgeo.org/grass/browser/grass/trunk/general/g.gui/main.c#L106
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.fill.gaps porting

[Vaclav Petras]

On Mon, Apr 17, 2017 at 2:58 PM, Benjamin Ducke 
wrote:

> > I've added a figure which shows the r.slope.aspect products from the
> > surface without and with -p. You can see that the smoothing gives
> > significantly different results and probably better ones. I had the same
> > experience in past when trying to patch result of r.neighbors with the
> > original raster. Perhaps using smaller distance as you say or greater
> > power would help, but I haven't tested that yet.
>
> I find the results for "curvature" most interesting.
> In the unsmoothed LiDAR data, that metric is basically useless.
>
>
It is the same for profile and tangential curvature. At certain zoom level,
you can see, with a lot of imagination, some pattern, but comparing to the
more expected result from the smoothed data, it is just noise.


> If I understand correctly, then slope, aspect
> and curvature are all computed within a small
> neighbourhood of cells.


Right, that's what r.slope.aspect does. You can avoid that by using
r.param.scale, but for another analysis, it would matter (depending on the
implementation/method).


> So if LiDAR data is
> also noisy by nature, then it is not surprising
> that these metrics are all distorted by strongly
> fluctuating local means.
>
>
Yes, there is noise. Usually, you either interpolate from points or you do
binning at much courser res averaging the noise out.


> Please try experimenting with the power parameter,
> if you have the time. In theory, this should allow
> you to interpolate over larger distances with less
> of a low-pass effect (or the other way around,
> depending on what you want to achieve).
>

I have this on my todo list.


>
> >
> > I managed to commit just the figure its caption. If somebody gets to it,
> > please extent the section.
>
> I will update the HTML page, including a more
> prominent mentioning of the default smoothing.
> I also found some small typos that need fixing.


Thanks. I just added a section, high res image and some basic text.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.fill.gaps porting

[Vaclav Petras]

On Sat, Apr 15, 2017 at 8:32 AM, Benjamin Ducke 
wrote:

> The thing is: I originally developed this module for
> gradiometer data. That data is very noisy and has
> high local variation. Interpolating that type of
> data while preserving original measurements will
> usually result in unsatisfactory output. Also note
> that the smoothing increases with the interpolation
> radius. For tiny holes in LiDAR data, try "distance=1"
> or "2". Of course, LiDAR data probably has different
> properties and does not need low-pass filtering
> like gradiometer data. So try "-p" to preserve the
> original values.
>
> An alternative would be to invert the behaviour of
> the module and assume "-p" by default.
>
> I don't work with LiDAR data myself, but I would very
> interested to know your results!
>


I've added a figure which shows the r.slope.aspect products from the
surface without and with -p. You can see that the smoothing gives
significantly different results and probably better ones. I had the same
experience in past when trying to patch result of r.neighbors with the
original raster. Perhaps using smaller distance as you say or greater power
would help, but I haven't tested that yet.

I managed to commit just the figure its caption. If somebody gets to it,
please extent the section.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.fill.gaps porting

[Vaclav Petras]

On Sat, Apr 15, 2017 at 8:57 AM, Markus Neteler  wrote:

> > These are 250x232,
>
> Would it be possible to have larger pics here? I guess they come from
> Benjamin?
>

There are two next to each other, so the combined width is 500 which is
almost our max for display (600).
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.fill.gaps porting

[Vaclav Petras]

On Sat, Apr 15, 2017 at 7:51 AM, Maris Nartiss  wrote:

> As you added an example with LiDAR data - it is too large. Reduce its
> size as default module help tab is much more narrow.
>


Maris, we agreed with Markus that the problem is in wxPython GUI versus
submitting guidelines. Please open a ticket if you are bothered by it.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.fill.gaps porting

[Vaclav Petras]

On Sat, Apr 15, 2017 at 8:03 AM, Markus Neteler  wrote:
>
> > it is nice to see porting of old addons.
> > As you added an example with LiDAR data - it is too large. Reduce its
> > size as default module help tab is much more narrow.
>
> The HTML code currently is this:
>
>   


These are 250x232, so I assume you mean r_fill_gaps_lidar.png.

> Please use the img code as per submitting docs style guide in trac.

The current code is:





which is almost exactly the following from Submitting/Docs [1]:





The submitting guide does not consider the wxPython GUI manual tab which
doesn't understand more advanced HTML correctly. Please advise on the next
steps.

Vaclav

[1] https://trac.osgeo.org/grass/wiki/Submitting/Docs
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] 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-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Temporal tests failing: t.rast.aggregate

[Vaclav Petras]

There are new tests for t.rast.aggregate which are failing. The change
happened between these revisions:

2017-03-04 03:01:30 (SVN revision 70724
)
2017-03-05 03:01:30 (SVN revision 70728
)

These are the tests:

http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2017-03-05-08-00/report_for_nc_basic_spm_grass7_nc/temporal/t.rast.aggregate/test_aggregation_absolute/index.html
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2017-03-05-08-00/report_for_nc_basic_spm_grass7_nc/temporal/t.rast.aggregate/test_aggregation_relative/index.html

You can see the change here:

http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/index.html

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

Re: [GRASS-dev] GRASS GIS and GSoC

[Vaclav Petras]

Zeke,

you should try to fix some tickets (as suggested on the GSoC wiki page you
linked); see the lists below. Alternatively, for your project, it may be
appropriate to implement a small tool for some dataset which is easy to
handle for you (e.g. something you used before). Look at the r.modis
modules because the idea is very similar to the overall idea of the
proposal. Look also at the current sample dataset for GRASS GIS and the
idea of generalized sample datasets.

Trivial:

https://trac.osgeo.org/grass/query?priority=trivial=a
ssigned=new=reopened=500=id=summar
y=priority=status=owner=type=milestone=priority

Minor:

https://trac.osgeo.org/grass/query?priority=minor=ass
igned=new=reopened=500=id=summary&
col=priority=status=type=owner=milestone=priority

Normal enhancement:

https://trac.osgeo.org/grass/query?priority=normal=as
signed=new=reopened=enhancement=500
ol=id=summary=priority=status=type=owner
=milestone=priority

r.modis:

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

Sample datasets:

https://trac.osgeo.org/grass/wiki/SampleDataset
http://grass.osgeo.org/download/sample-data/


On Tue, Mar 28, 2017 at 6:15 AM, Blumentrath, Stefan <
stefan.blumentr...@nina.no> wrote:

> I cannot offer to mentor your project, but I could make some shell scripts
> available for you, that turn publicly available data into GRASS Locations
> and mapsets.
>
> It is not really much, but depending on the approach you choose they might
> be a helpful startingpoint.
>

I'm willing to (co-)mentor. For the other potential mentors: Having a
collection of "shell scripts" is actually a very good qualification for
(co-)mentoring this project.

Vaclav (Vashek)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS wiki: uploading figures efficiently

[Vaclav Petras]

Hi,

I wonder if there is a better way of uploading and managing images on the
GRASS (user) wiki (MediaWiki). I always go to a separate page to upload an
image, then I go to get a code snipped somewhere to add it to a page the
way I want. I can't exactly say what workflow I'm looking for, but adding
files to a text file and SVN/Git or copy pasting in some WYSIWIG seems just
much simpler. Please, let me know if I'm missing something.

Perhaps some of the following can be installed, but it is hard to say
without trying.

https://www.mediawiki.org/wiki/Extension:MsUpload
https://www.mediawiki.org/wiki/Extension:UploadWizard
https://www.mediawiki.org/wiki/Extension:SimpleBatchUpload

Use cases (pages with lot of images - tutorials/workshops):

https://grasswiki.osgeo.org/wiki/Workshop_on_urban_growth_modeling_with_FUTURES
https://grasswiki.osgeo.org/wiki/Introduction_to_GRASS_GIS_with_terrain_analysis_examples

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

Re: [GRASS-dev] Introduction for GSoC 2017

[Vaclav Petras]

On Sat, Mar 18, 2017 at 3:30 AM, Blumentrath, Stefan <
stefan.blumentr...@nina.no> wrote:

> Could also porting (competition) of the i.ortho.photo modules (and here
> especially the missing GUI modules around it) to GRASS 7 become scope of
> this GSoC idea?
>

See also:

https://trac.osgeo.org/grass/browser/grass/trunk/imagery/i.ortho.photo


> The lack of Orthorectification tools in GRASS 7 is the only reason for me
> to keep GRASS 6 in parallel…
>

Perhaps, there should be a list of tickets or a wiki to collect things
needed for people to fully switch to G7 (needs to be created by those who
actually use G6).

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

Re: [GRASS-dev] Introduction for GSoC 2017

[Vaclav Petras]

On Wed, Mar 15, 2017 at 3:00 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

>
> >
> >> - A tool to attribute class values to raster objects. This is much
> >>   simpler and "just" a combination of GUI + r.what + form to add a
> >>   value + writing everything to a text file. In other words, it is
> >the
> >>   current GUI raster interrogation tool enhanced to add a value and
> >to
> >>   write info to a file.
> >>
> >
> >This sounds like raster attribute table for GRASS GIS. This needs some
> >serious design.
>
> No, I was not aiming for raster attribute tables. The main motivation for
> me is that when you create segments in an object-based image analysis
> approach and you want to then extract some objects as training objects this
> is currently not easy to do. For such training you have to identify the
> objects and indicate which class they're in. My idea is not to store this
> info within the gisdbase, but to output it to text file (yes, again ;-))
> which can then be used as input to further treatment (e.g. v.class.mlR &
> co).
>
>
>
I don't say that this can't be implemented through external CSV files and
the tools for handling them and transferring raster values into them are
generally useful. The thing I'm uncomfortable about is that it looks like a
raster attribute table from user point of view but it is different and also
at one point CSV won't be enough for some they will need actual database or
SQL. We had ASCII vectors in the past... (not that I would be around for
that ;-)

>Moritz and all,
> >
> >in cases like this, when a GSoC idea can be split into a separate
> >features
> >and they are reasonable feature requests (they wouldn't be part of the
> >idea
> >otherwise, right?), it would be good if we create the appropriate
> >tickets
> >for each of those. We did this last summer when we used keywords (tags)
> >`gsoc2016` and `cartography` for each ticket related to the GSoC
> >Cartography Improvements idea:
> >
> >https://trac.osgeo.org/grass/query?status=assigned=
> >closed=new=reopened=~gsoc2016+cartography
> >
> >For this idea it could be e.g. `gsoc2017` and `ImageAnalysisGUI`, but
> >please suggest something better (it must be one word, no spaces).
>
> +1
>
> Do you think we should create these tickets now, or as part of the first
> phase of the project ?



Yes, now.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Helping beginners and GSoC students find simple problems to tackle

[Vaclav Petras]

Dear all,

we suggest specific tickets to GSoC often tailored to a specific GSoC idea
they are interested in. However, in general it is hard to find a right
topic for a person who wants to start contributing to GRASS GIS (as opposed
to writing additional modules with some specific functionality).

I suggest introducing some special keyword (tag) to Trac tickets which
would mark the ticket as suitable/recommended for contributors-beginners.

Tag "beginners" seems to refer to problems affecting the beginners (the
users). Tag "simple" may not be good either, because how simple it is quite
relative. Perhaps there can be a special property to show estimated
complexity of solving the ticket.

Best,
Vaclav



PS: Currently, the following queries give many tickets which might be
suitable for contributors-beginners:

Trivial:

https://trac.osgeo.org/grass/query?priority=trivial=a
ssigned=new=reopened=500=id=summar
y=priority=status=owner=type=milestone=priority

Minor:

https://trac.osgeo.org/grass/query?priority=minor=ass
igned=new=reopened=500=id=summary&
col=priority=status=type=owner=milestone=priority

Normal enhancement:

https://trac.osgeo.org/grass/query?priority=normal=as
signed=new=reopened=enhancement=500&
col=id=summary=priority=status=type=
owner=milestone=priority
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Introduction for GSoC '17

[Vaclav Petras]

On Wed, Mar 15, 2017 at 7:55 AM, Anisha Godha 
wrote:

> I am a fourth year student in Geological Technology at Indian Institute of
> Technology Roorkee. This January, I built an ArcGIS plug-in in Python that
> automates the Laminar Flow Model method to give a glacier's thickness
> distribution raster. For my thesis, I will be working around developing a
> framework that gives recommendation for specific Spatial Interpolation
> Techniques based on user dataset.



It seems you have expertise in these specific areas, so it might be better
for you to consider also topics which are focused more on something related
to what you work on. The topics you can propose are not limited by the list
on the wiki [1]. However, it may be harder to find mentors in this case.

Also, for the programming now and during application period, you have a
choice of working on some ticket or you can implement some of your previous
work in GRASS GIS (or port it to GRASS GIS).

Vaclav

[1] https://trac.osgeo.org/grass/wiki/GSoC/2017
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Introduction for GSoC 2017

[Vaclav Petras]

Dear Moritz and students,

here are some of my ideas for these ideas. This is a good start. I think we
need enhancement ticket with use cases for each item.

On Tue, Mar 14, 2017 at 6:25 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> - A general vector interactive attribute table editor which pops
>   up an attribute editing form when you click on a vector map.
>   Currently, to do this, you have to go into digitizing mode.
>

This is what the original query dialog in GUI was doing, but then it was
replaced by something which is optimized for (ready only) queries and does
not allow editing. You need to specify how the editing dialog would be
connected to the current GUI; e.g. new button?


> In
>   addition, it would be great to be able to somehow (text input file ?)
>   be able to define the columns you see in the form so that you don't
>   have to scroll through tens of lines before you reach those that you
>   want to edit.
>

Is a text file the user friendly way you are looking for? Should this be
stored between GUI sessions?


> - A tool to attribute class values to raster objects. This is much
>   simpler and "just" a combination of GUI + r.what + form to add a
>   value + writing everything to a text file. In other words, it is the
>   current GUI raster interrogation tool enhanced to add a value and to
>   write info to a file.
>

This sounds like raster attribute table for GRASS GIS. This needs some
serious design.

There is more of these individual features which may be useful, e.g.
imagery group support in the Data tab or r.pack/r.unpack equivalent for
imagery groups. Also the GUI dialog which shows for (instead of) i.group
needs some improvements.


Rachit, Manan, and other students,

it is important that you look and work on some of existing tickets or even
find some problems or small possible enhancements by exploring the current
functionality.

An good example ticket is the one by Moritz:

https://trac.osgeo.org/grass/ticket/3310

You can also do some general tickets to familiarize yourself with different
parts of the GRASS GIS code base, for example:

https://trac.osgeo.org/grass/ticket/3314


Moritz and all,

in cases like this, when a GSoC idea can be split into a separate features
and they are reasonable feature requests (they wouldn't be part of the idea
otherwise, right?), it would be good if we create the appropriate tickets
for each of those. We did this last summer when we used keywords (tags)
`gsoc2016` and `cartography` for each ticket related to the GSoC
Cartography Improvements idea:

https://trac.osgeo.org/grass/query?status=assigned=
closed=new=reopened=~gsoc2016+cartography

For this idea it could be e.g. `gsoc2017` and `ImageAnalysisGUI`, but
please suggest something better (it must be one word, no spaces).

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

Re: [GRASS-dev] To contribute in GRASS GIS

[Vaclav Petras]

On Thu, Mar 9, 2017 at 2:11 PM, Anna Petrášová 
wrote:
>
> Hi Sushil,
>
> here are some general enhancements you could look at, all in C:
> https://trac.osgeo.org/grass/ticket/1852
> https://trac.osgeo.org/grass/ticket/3217
> https://trac.osgeo.org/grass/ticket/2123
> https://trac.osgeo.org/grass/ticket/1996

Hi Sushil, here are some additional options; there is a lot of options to
choose from and lot of tasks to do.

Moderate difficulty:

https://trac.osgeo.org/grass/ticket/2125
https://trac.osgeo.org/grass/ticket/1506

Compiler/static check warnings:

https://trac.osgeo.org/grass/ticket/1326
https://trac.osgeo.org/grass/ticket/1325
https://trac.osgeo.org/grass/ticket/1324
https://trac.osgeo.org/grass/ticket/1322
https://trac.osgeo.org/grass/ticket/1311
https://trac.osgeo.org/grass/ticket/2069

More difficult:

https://trac.osgeo.org/grass/ticket/2074
https://trac.osgeo.org/grass/ticket/2992

Another option is converting GRASS GIS 6 addon modules to GRASS GIS version
7. These are the potential candidates (which would need to be first
discussed if porting is actually useful):

https://grass.osgeo.org/grass64/manuals/addons/r.convergence.html
https://grass.osgeo.org/grass64/manuals/addons/r.boxcount.html
https://grass.osgeo.org/grass64/manuals/addons/r.clim.html
https://grass.osgeo.org/grass64/manuals/addons/r.traveltime.html

Vaclav

On Thu, Mar 9, 2017 at 9:32 AM, SUSHIL KHANCHI <16bcs...@smvdu.ac.in> wrote:
> Hello,
>
> I am an engineering student in Computer Science  from INDIA.
>
> I would like to contribute to GRASS GIS project and take part in Gsoc.I
want
> to implement algorithms in C.For getting familiar to your work, I would
like
> to get my hands on your projects issues.
>
> Can you please guide me to your project where I can start with fixing
small
> bugs.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] RGB colored and Transparent areas in one vector map

[Vaclav Petras]

On Tue, Mar 7, 2017 at 4:10 AM, Nikos Alexandris 
wrote:

> I would like to use a hexagon symbol (we don't
> have one I think)
>

We actually do:

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

I though it might be useful, e.g. for legend of v.mkgrid -h.

Did you open the ticket for no color from attr table?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2017 - Generalized GUI code for Qt-based GUI

[Vaclav Petras]

On Wed, Mar 8, 2017 at 2:21 AM, Ondrej Svoboda  wrote:

> A topic I am most interested in is Generalized GUI code for Qt-based GUI
> [1].
>

It would be good if you fork & clone the repo from last year [3] and make
it work on your computer. It should be easy to find few things which you
can fix or improve in the application period. Alternatively, since you have
experience with QGIS plugins, you can turn that code into a QGIS plugin
instead of fixing and improving.

Also, go ahead and start writing down what would be the particular things
you would implement during GSoC. The topic is very broad and the above
steps will help you narrow it down for GSoC.

[3] https://github.com/pesekon2/GRASS-Qt-based-GUI
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSOC

[Vaclav Petras]

Hi Shreyan,

sounds good!

On Tue, Mar 7, 2017 at 7:49 AM, Shreyan Mehta 
wrote:

> Integration of PDAL into GRASS GIS


The best way to start on your application for this topic is compiling
v.in.pdal module (vector/v.in.pdal directory) with latest PDAL, see #3243
[1]. Read also #2732 [2], so you have a bigger picture and than you can
develop the idea more at the wiki [3], so you can get an early feedback.
You can also create tickets for specific things if you think that would
work better. You can of course solve some of them or some other ones in the
application period. Be sure to follow the tips on the wiki [4].

Best,
Vaclav

[1] https://trac.osgeo.org/grass/ticket/3243
[2] https://trac.osgeo.org/grass/ticket/2732
[3]
https://trac.osgeo.org/grass/wiki/GSoC/2017/IntegrationOfPDALintoGRASSGISIdea
[4] https://trac.osgeo.org/grass/wiki/GSoC/2017#Tipsforstudents
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] RGB colored and Transparent areas in one vector map

[Vaclav Petras]

On Mon, Mar 6, 2017 at 11:20 AM, Nikos Alexandris <n...@nikosalexandris.net>
wrote:
>
> Vaclav Petras:
>
>> Try setting the column value to "none" (usually implemented for
parameters,
>> I'm not sure here).
>
>
> Does not work, already tried that before.

It would make sense to have it, please open a feature request.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] RGB colored and Transparent areas in one vector map

[Vaclav Petras]

On Mon, Mar 6, 2017 at 6:44 AM, Nikos Alexandris 
wrote:

> I have an rgb_column with RGBs for a vector map. For some areas, I would
> like to have no color, as in trasparent.
>
> If I am not wrong, we can't do that, ie define "nv" as we can do in
> color rules for a raster map.
>


Try setting the column value to "none" (usually implemented for parameters,
I'm not sure here).

Note that "nv" is 'no value' (NULL), not 'no color' in the color rules
syntax.

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

Re: [GRASS-dev] Working with TGIS without starting GRASS explicitly

[Vaclav Petras]

Older, but the general ideas still apply:

On Thu, Sep 22, 2016 at 12:01 PM, Laurent C.  wrote:
>
> My software is not really a GRASS module, it is more independent and
> use only GRASS as a back-end. It is fully written in Python and using
> --exec or GRASS_BATCH_JOB does not seems very practical.

You can use --exec only for the part of the code which is using GRASS, i.e.
you have two scripts, one which is the main program, and other one which
the the GRASS GIS script or even a module which you call using --exec.

> 2016-09-22 1:36 GMT-05:00 Blumentrath, Stefan :
> > Hei Laurent,
> >
> > What about using the --exec magic from > GRASS 7.2?
> >
https://grass.osgeo.org/grass72/manuals/grass7.html#batch-jobs-with-the-exec-interface
> > (or the GRASS_BATCH_JOB solution)?
> >
> > Cheers
> > Stefan
> >
> > 2016-09-21 18:27 GMT-05:00 Laurent C. :
> >> Hi Sören,
> >>
> >> Setting LD_LIBRARY_PATH is working, thanks. But it cannot be set at
> >> run-time, which is not very user-friendly.

Well, that's really complain to operating system authors I think.
Unfortunately, I don't really know the story behind it.

> >> I guess this issue is related to the ticket 2424 [1].

Yes. Same issue. Linked this conversation there.

> >> I managed to get it work at run-time by restarting the program with
> >> sys.execv() after setting the path [2], but I find it a bit ugly and
> >> quite verbose to be multi-platform.

As [2] says, not really reliable.

> >> It would be great if an easier option was possible.

Yes. GRASS GIS libraries do not install as other libraries like Qt for
example, the distribution of GRASS GIS binaries would need to change. There
are issues related to this on Mac as well. Any solution will likely make
having parallel GRASS GIS installations much more difficult. But somebody
experienced with packaging would need to speak to that.

Vaclav

> >> [1] https://trac.osgeo.org/grass/ticket/2424
> >> [2]
http://stackoverflow.com/questions/6543847/setting-ld-library-path-from-inside-python
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Next events workshop

[Vaclav Petras]

On Wed, Jan 25, 2017 at 3:49 AM, Luca Delucchi  wrote:

> is someone thinking to submit any workshop for FOSS4G 2017 in Boston
> and FOSS4G EU 2017 in Paris?
>

The deadline for FOSS4G 2017 Boston is Monday, March 13. If anybody else
plans to submit a workshop or is willing to help during a workshop, please
let me know, so we can sync.

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

Re: [GRASS-dev] GRASS working under Mac El Capitan with SIP/rootless?

[Vaclav Petras]

On Wed, Sep 14, 2016 at 11:14 AM, Michael Barton 
wrote:

> Oddly, the only things I've run into that don't work so far are 3D mode,
> vector digitizer, and raster digitizer. The only errors are the following
> in the terminal at startup:
>
> Launching  GUI in the background, please wait...
> GRASS 7.3.svn (nc_spm_08_grass7):~ > Unable to import pyGRASS:
> grass_gis.7.3.svn not found.
> Some functionality will be not accessible
>
> And the following in the console after startup:
>
> 3D view mode not available
>
> Reason: grass_gis.7.3.svn not found.
>
> Vector digitizer not available
>
> Reason: cannot import name GV_LINES
>
> Note that the wxGUI's vector digitizer is currently disabled
> (hopefully this will be fixed soon). Please keep an eye out
> for updated versions of GRASS. In the meantime you can use
> "v.digit" from the Develop Vector menu.
>
> The 3D mode error seems similar to the pyGRASS not importing error
> I'm not sure where GV_LINES comes from.
>
> Any ideas on this? If these turn out to be the only problems, we are close
> to finally getting this issue resolved.
>

This is likely caused by the fact that the dynamic libraries are not loaded
because the DYLD_LIBRARY_PATH is ignored. If you disable SIP you will get
past that.

Anyway I don't understand why the modules are working (e.g. GRASS and GUI
starts) and ctypes are not (v digitizer, 3D, PyGRASS depend on ctypes
loading the GRASS libs). It seems that that's the part needed to resolve
this issue. (It is actually the same for Homebrew as well.)

PyGRASS should not be touched during startup and in GUI, so I don't know
where "Unable to import pyGRASS" is coming from but that's a secondary
issue not spotted elsewhere (it is also an old version).

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

[GRASS-dev] What long-term support means for GRASS GIS?

[Vaclav Petras]

Hi,

I know we've already touched on that, but I'm still unclear about what
"long-term support" means for us. The release announcement for 7.2 says:

  As a stable release series, 7.2.x enjoys long-term support.

which is more or less the same what 7.0 announcement says:

  As a stable release 7.0 will enjoy long-term support.

Both are from a stable branch, i.e. not development (=trunk), both are
releases, i.e. not daily builds or something like that, and finally both
are stable releases, i.e. not release candidates. So what the long-term
support means? Are all GRASS GIS releases long-term support? Is it in
comparison to other software support policies? How it would look like if
would have release which is not long-term support? What should we
communicate to users and potential users?

Thanks,
Vaclav

https://grass.osgeo.org/news/42/15/GRASS-GIS-7-0-0/
https://grass.osgeo.org/news/66/15/GRASS-GIS-7-2-0-released/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] github / travis sync - push file to grass-gis/homebrew-grass-dev repo when grass-gis is synsed to svn?

[Vaclav Petras]

On Thu, Feb 9, 2017 at 4:25 PM, Rainer M Krug  wrote:

> Would it be possible to push a file containing e.g. the time to
> grass-gis/homebrew-grass-dev?
>
> The content of the file does not matter, but e.g. the time would be
> fine.
>

That would be a big workaround IMO. I think using daily cron jobs on travis
is a better option (if it works). I enabled them and now we need to wait to
see if that works (Travis CI has currently large backlog on Mac builds,
https://www.traviscistatus.com/).

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

Re: [GRASS-dev] new addon module: i.superpixels.slic - image segmentation using the SLIC segmentation method

[Vaclav Petras]

Congratulations to the authors of i.superpixels.slic to a great
achievement! I've noticed lot of promising commits.

I've a suggestion to rename the one of the option called `k`. I think we
were recently changing a lot of options in modules from a letter to a more
descriptive name (num, number, pixels, num_pixels, ...?).

k=integer
Number of super pixels
Default: 200

I've also added an example, so please review or add. (I suppose combination
with i.segment can be included in another example.)

Vaclav


On Tue, Jan 31, 2017 at 1:19 PM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> Dear all,
>
> Thanks to initial work by Rashad, extensively completed by Markus Metz,
> we now have a new addon module which allows to segment images into
> so-called superpixels, using the SLIC algorithm as proposed by Achanta
> et al [1].
>
> The module uses a spatially constrained kmeans algorithm to group
> neighboring pixels into larger ensemble, the "superpixels". These
> superpixels can be used as a specific form of segmentation by itself,
> or they can be used as seed input to i.segment's region-growing
> algorithm.
>
> Thank you very much to the two authors for the great work !
>
> Moritz
>
>
>
> [1] http://ivrl.epfl.ch/research/superpixels
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Still Failing: GRASS-GIS/grass-ci#1898 (master - 7fa0125)

[Vaclav Petras]

On Mon, Feb 6, 2017 at 8:50 AM, Markus Neteler  wrote:

> > Otherwise, there is no problem at all with using the git repo.
>
> Perhaps yes if that brings back the Mac tests at lowest cost


Assuming that the Homebrew repo will be tested separately, the question is
if we want to bring in another dependency - OSGeo Subversion to GitHub sync
- or if we want to keep dependencies to minimum. For now, getting code from
GitHub is the only way it works because of the broken SSL certificates, so
sure we can use it, but that's for now.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Still Failing: GRASS-GIS/grass-ci#1898 (master - 7fa0125)

[Vaclav Petras]

On Mon, Feb 6, 2017 at 8:52 AM, Markus Neteler  wrote:

> On Mon, Feb 6, 2017 at 8:52 AM, Rainer M Krug  wrote:
> > Markus Neteler  writes:
> > How do you mean? The script is in the folder .travis (hidden to be
> > in line with the naming of the .travis.yml file and as it is of no
> > importance for GRASS itself). There were the scripts (see changeset
> > https://trac.osgeo.org/grass/changeset/70483 )
>
> Yes - I was just wondering where the "svn" call is located which I
> cannot see in these scripts.


That's the reason it should not be done the way that the travis test/build
(.travis.yml) in the main repo (its git copy) uses code which is actually
in a different repo (the Homebrew recipe) and is downloaded again for the
test (from Subversion repo in this case). Unless there are strong reasons
to do it otherwise, the test/build instructions in the main repo should
trigger builds which are based only on the code from that repo.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Still Failing: GRASS-GIS/grass-ci#1909 (master - 05df514)

[Vaclav Petras]

On Sat, Feb 4, 2017 at 8:48 AM, Yann  wrote:
>
> Is Travis doing OK ?


Sorry for the noise. The Mac compilation had 3rd party dependencies and
other issues, see e.g.

https://trac.osgeo.org/grass/ticket/3250

I committed

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

which revers the Mac part of

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

The following commit also un-hides the scripts which are in the .travis dir.

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

We can consider renaming .travis dir to travis only. But I think
.travis.yml must have exactly this name.

Rainer, I added you to the GRASS GIS org on GitHub, you should be able to
transfer the ownership of the Homebrew repo if you decide to do so in order
to give more people direct access to that code. I suggest using Travis cron
job which can be setup in Travis if one have access to the repo.

https://docs.travis-ci.com/user/cron-jobs/

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

Re: [GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Vaclav Petras]

On Wed, Feb 1, 2017 at 3:24 PM, Moritz Lennert  wrote:

> >please take a look at GAL project from 2008 [1]. Ma
>
>
I didn't really work out the differences to GAL project but this GSoC
project should be less ambitious, much more limited, cover smaller part of
the functionality, and perhaps be less high level. Another difference would
be that the GSoC proposal aims to cover both C and C++ APIs and is limited
only to module development (no GUI-aware/friendly API).


>
> I don't really agree with the idea that
>
> "Unfortunately, its [GRASS'] development is stagnating because of small
> interest
> from fresh and young developers. This is partially caused by the fact that
> its design and
> concepts are overcome by modern practices in a software development."
>
> I do not see GRASS stagnating. And even though GRASS uses an "old"
> language,


I think C is fine and that might be more clear now than in 2008, but C++ is
popular too. However, the motivation for GSoC is make writing of modules in
C and C++ easier. We may discuss if "development is stagnating because of
small interest" is true or not, but for sure we can have better interface
which would attract more people. There are people writing custom C or C++
code for basic geospatial things which GRASS libraries do in a way which is
better than what they have or aim for.

More pressing problem however are the modules which use variants of
all-in-memory and tiling-on-disk raster reading modes. I'm not sure what is
the state now, because MarkusM fixed a lot of those, but some addons were
not included into core because of custom segment libraries (and even now
they have custom all-in-memory implementations).

I imagine that it's unpleasant if all you believe in is OO, but that
> doesn't necessarily make OO the naturally best way to go... :-)
>

Similarly to Python API, OOP is not the only thing we should focus on. C++
is a multiparadigm language and OOP is just part of it (e.g. templates are
kind of big), plus there are different levels of doing OOP ("C with
classes" versus more complicated OOP). So yes, the student should be
familiar with more than just OOP.


>
> b) I'm afraid it's too big of a project for GSoC and that we would put the
> student in an uncomfortable position.


It should be much smaller than GAL project and it should be mostly
additions to API, not rewriting the libraries.

That's at least my idea. I hope this clarifies it a bit.

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

Re: [GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Vaclav Petras]

I did not include many details in the idea so here they are.

On Wed, Feb 1, 2017 at 11:59 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> I just the GSoC proposal for a "Higher level API for C and C++".
>

It it should not remove the existing API but build on to of it.


> I _think_ I understand where this comes from,
>

Good example is the random access to raster cells which runs in
all-in-memory and tiling-on-disk modes. Several modules need it, several
modules implement it in different ways. Segement library helps but solves
just part of the issue.


> but it does raise some very fundamental issues about how GRASS is written
> and should be written,
>

The implementation should stay the the intact, especially when talking
about GSoC. The point is to create a better API. Something link PyGRASS but
in C and C++. PyGRASS also uses existing C functions but wraps them in the
way they are easy to use (this would be case for C API) or more appropriate
to the language (C++).


> notably, but not only, the inclusion of a C++ API.
>

Add C++ API can be adding just few header files. Limiting the C++ API to
what "fits" into a header file has two advantages: same functionality needs
to be accessible in C API and it avoids (some/all?) issues of C++ linking.


>
> I just want to ensure that there is sufficient discussion on the list
> about such a project which could have far-reaching consequences. And if we
> ever decide to for such a project, then I think it has to be made
> absolutely clear that the student working on this needs to be extremely
> proficient in C/C++.
>

Agreed.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Still Failing: GRASS-GIS/grass-ci#1898 (master - 7fa0125)

[Vaclav Petras]

On Sun, Jan 29, 2017 at 9:48 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> (R)eject, accept (t)emporarily or accept (p)ermanently? svn: E175002:
> Unable to connect to a repository at URL
> 'https://svn.osgeo.org/grass/grass/trunk'
>
> svn: E175002: OPTIONS of 'https://svn.osgeo.org/grass/grass/trunk':
> Server certificate verification failed: issuer is not trusted
> (https://svn.osgeo.org)
>
> Error: Failed to download resource "grass-trunk"
> ***
>

It seems to me that would be better if Travis for GRASS used the actual
source code from the repository directly and not use Homebrew and the
Homebrew installation would be tested separately.

https://trac.osgeo.org/grass/ticket/3250

Now http://grass.osgeo.org/ (which probably shouldn't have the test badge
at all) shows failed build because of missing certificates while nothing
being bad with GRASS source code.

Travis CI cannot build repo based on another repo:

https://github.com/travis-ci/travis-ci/issues/631

But it has cron jobs:

https://docs.travis-ci.com/user/cron-jobs/

Daily build of the Homebrew formula repo seems more appropriate for testing
than the workaround in the code.

Since Travis CI is not 100% reliable for Mac, it will also separate all the
false positives. It still can send messages to grass-dev (all Travis is
already white listed, right?) but more people should get access to the repo
if that's the case.

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

Re: [GRASS-dev] Reviewing GSoC 2017 page

[Vaclav Petras]

On Wed, Jan 25, 2017 at 6:35 PM, Blumentrath, Stefan <
stefan.blumentr...@nina.no> wrote:

> I took the liberty to add one on “tools for generating unit tests from
> examples in module manuals”. Not sure if that is feasible or out of scope.
> Please feel free to remove it if you don`t find it suitable (I can`t mentor
> it anyway).
>

It is valid, but there is a lot of details which need to be considered
(would need to be addressed in the proposal). There is some post to mailing
list discussing some of those.


>
>
> Regarding:
>
> https://trac.osgeo.org/grass/wiki/GSoC/2017#Additionalfunctionalityforrunn
> ingGRASSGISmodulesinJupyterNotebook
>
> (which I also very much like to see become reality, esp. a function like
> “initGRASS()” from rgrass7)
>

Can you please be specific about differences between rgrass7 initGRASS()
and grass.script.setup.init()? It would be good to collect them.

https://grass.osgeo.org/grass70/manuals/libpython/script.html#module-script.setup

Here is an example from action where it is simplified (and not that robust)
but adds some other useful things:

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

Other thing to mention is that an ultimate solution may involve creating a
package separate from GRASS GIS (like rgrass7) and more importantly
changing the way GRASS GIS is installed and distributed (see e.g. ticket
for PyGRASS outside of GRASS session).


> I have the question if that by chance is supposed to be related to last
> years GSoC on a WebGUI for GRASS (see: https://trac.osgeo.org/grass/
> wiki/GSoC/2016/WebGrass).
>

Not directly related. Jupyter Notebook is independent and with some
additions of interactive maps it could be used as a web interface for
advanced or Python aware users. It can be used even now, but for
visualization, you need to deal with d.* commands (which is fine in general
but not for zooming, panning, ...) or you need to plug in other solution
for visualization (like MapServer reading from GRASS GIS Database). There
might be some code sharing between (some/any) web GRASS and Jupyter on the
side of Python API or JavaScript map display (if applicable).


>
>
> In order to be really useful, WebGRASS would need a console, and here
> Jupyter was already mentioned as an option.
>

For this part it is really just thing of WebGRASS, nothing to be done on
Jupyter site.


> In addition the WebUI struggled quite a bit with renderinig… So will this
> proposal be complementary?
>

I don't know what specifically you mean, but I guess it will be a struggle
for Jupyer as well.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Next events workshop

[Vaclav Petras]

On Thu, Jan 26, 2017 at 4:51 AM, Luca Delucchi  wrote:

> > Please, let me know if you want to collaborate on this or other workshop
> or
> > you have some topics you would like to see covered.
> >
>
> maybe we could also submit a Intro course, I could do that
>


Sure, my group was also thinking about intro workshop as an alternative.

I think at this point we can move the FOSS4G Boston conversation to private
to figure out the specifics. But if somebody else wants to join the
efforts, just write here.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Reviewing GSoC 2017 page

[Vaclav Petras]

Worked. Thanks for tuning the spam filter, Markus. I just put all the new
things at the beginning.

On Wed, Jan 25, 2017 at 10:01 AM, Vaclav Petras <wenzesl...@gmail.com>
wrote:

> Can somebody reorder the ideas so that the fresh ideas are at the top?
> When I try it, I get "Too many links" or "Page not modified".
>
> Thanks,
> Vaclav
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Reviewing GSoC 2017 page

[Vaclav Petras]

Can somebody reorder the ideas so that the fresh ideas are at the top? When
I try it, I get "Too many links" or "Page not modified".

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

Re: [GRASS-dev] Next events workshop

[Vaclav Petras]

I plan to submit a workshop for FOSS4G 2017 in Boston. GRASS and lidar
related.

Please, let me know if you want to collaborate on this or other workshop or
you have some topics you would like to see covered.

Vaclav

On Wed, Jan 25, 2017 at 3:49 AM, Luca Delucchi  wrote:

> is someone thinking to submit any workshop for FOSS4G 2017 in Boston
> and FOSS4G EU 2017 in Paris?
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GIScRG & QMRG - Call for Contribution to GIS / statistical open source software

[Vaclav Petras]

All, I'm forwarding the following this general call relevant also to GRASS
GIS contributors current and new. Deadline Feb 17.

Link:

http://bit.ly/2j9Igjt

Description:

GIScRG & QMRG - Call for Contribution to GIS / statistical open source
software
The GIScRG (Geographic Information Science Research Group of the RGS) and
QMRG (Quantitative Methods Research Group) are looking to use some of their
fund to support a contribution to some GIS / statistical open source
software. We have £500 to offer as a grant (or series of grants) to one or
more projects that will contribute to a piece of open source GIS /
statistical software.

The definition is intentionally vague because we are interpreting
'contribution' to including a range of potential options, including:
- development of a new package / library that offer an additional
geospatial feature to a program that did not exist before
- continued development of an existing code / library that adds a new
significant feature to an existing library
- a set of 'how to use x' documentation, that adds something to resources
that are already available

Any proposal must be make open source (as appropriate for the relevant
program) and should be documented appropriately.

We are asking people to submit proposals, with details including cost, to
http://bit.ly/2j9Igjt. The GIScRG and QMRG committees will then select one
(or more) proposals to fund.

Successful applications will also be offered the opportunity to run a
workshop on their work at a suitable conference (e.g. GISRUK or
Geocomputation) in return for a waived registration fee.

Issue call for applications: 20th Jan
Deadline for applications: 10th Feb
Announce winner(s): 17th Feb

If you have questions, please contact nick at clearmapping co uk /
n.bearman at liverpool ac uk.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] keyword for modules operating on level 1

[Vaclav Petras]

On Tue, Jan 17, 2017 at 8:41 AM, Martin Landa 
wrote:

> 2017-01-14 17:15 GMT+01:00 Martin Landa :
> > I just not sure what name to choose for such keyword - 'level1' or
> > 'level 1' seems to be too much cryptic for some users. Keywords like
> > 'no topology' are not suitable for searching, 'no-topology' doesn't
> > seems also nice. At the end I didn't find anything better than
> > 'level1'. Any better ideas?
>
> if no objections I would suggest both keys:
>
> level1, no-topology
>
> Any comments? Ma
>


I was thinking but I have no better suggestion. The whole thing makes
sense. And synonyms as keywords as well.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: [OSGeo] #1816: upgrade Trac to 1.2 release

[Vaclav Petras]

On Tue, Jan 10, 2017 at 11:43 AM, Markus Neteler  wrote:

> From the OSGeo ticket: Alternatives ( to review for supporting Trac 1.2 ) :
>   - https://trac-hacks.org/wiki/TracStatsPlugin
>

Looks good. May be useful. Seems very comprehensive. Last commit on GitHub
from Dec 2016.


>
>   - https://trac-hacks.org/wiki/TracTicketStatsPlugin
>   - https://trac-hacks.org/wiki/TicketChartsMacro
>

Both seems to depend on Flash and unmaintained or 3rd party projects.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: [OSGeo] #1816: upgrade Trac to 1.2 release

[Vaclav Petras]

On Tue, Jan 10, 2017 at 10:53 AM, Markus Neteler  wrote:

> Hi devs,
>
> are we really using TracMetrixPlugin? See below...
>
>
I don't know what part of Trac it is. It is this one?

https://trac.osgeo.org/grass/pdashboard

Nice overview, I used it several times just because it is there and you
don't need to do a query, but we can live without that. Perhaps there is
something similar.


> Or ditch it?
>
> Markus
>
>
> -- Forwarded message --
> From: OSGeo 
> Date: Tue, Jan 10, 2017 at 4:36 PM
> Subject: Re: [OSGeo] #1816: upgrade Trac to 1.2 release
> To:
>
>
> #1816: upgrade Trac to 1.2 release
> --+---
>  Reporter:  jmckenna  |   Owner:  strk
>  Type:  task  |  Status:  assigned
>  Priority:  normal|   Milestone:
> Component:  Trac  |  Resolution:
>  Keywords:  trac  |
> --+---
> Changes (by strk):
>
>  * cc: neteler (added)
>
>
> Comment:
>
>  SectionEdit upgraded so it will work with Trac 1.2, but TracMetrixPlugin
>  still fails and has no replacement yet, see https://trac-
>  hacks.org/ticket/13041 - The only instances using the Metrix plugin are
>  the GRASS and QGIS (deprecated) ones.
>
>  Markus: how useful is the Metrix plugin for you guys ?
>
> --
> Ticket URL: 
> OSGeo 
> OSGeo committee and general foundation issue tracker.
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Still Failing: GRASS-GIS/grass-ci#1837 (master - 542a054)

[Vaclav Petras]

On Sat, Jan 7, 2017 at 5:24 PM, Anna Petrášová 
wrote:

> it's failing on Mac only, but I don't see a log, so I can't fix it.


Why is Mac build using brew? I would expect it to use the source code from
the repo directly.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] d.linegraph indentation mess

[Vaclav Petras]

On Sun, Dec 18, 2016 at 4:29 PM, Vaclav Petras <wenzesl...@gmail.com> wrote:

> I'll just reindent all


Done. It was just the indent.

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

and do the classic int -> size_t replacements.


Not done. A lot of code would be to be changed including tr strings.
Leaving that for some other round of changes.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r70106 - grass/trunk/mswindows

[Vaclav Petras]

On Tue, Dec 20, 2016 at 5:03 PM,  wrote:
>
> Author: martinl
> Date: 2016-12-20 14:03:52 -0800 (Tue, 20 Dec 2016)
> New Revision: 70106
>
> Modified:
>grass/trunk/mswindows/GRASS-Installer.nsi.tmpl
> Log:
> wingrass: attempt to fix standalone installer to download and execute
vcredist exe files
>
> +   DetailPrint "Installing vcredist_2010_x86.exe ..."
> +   ExecWait
'"$TEMP\$ORIGINAL_UNTAR_FOLDER\bin\vcredist_2010_x86.exe" /q'
> +   DetailPrint "Installing vcredist_2013_x86.exe ..."
> +   ExecWait
'"$TEMP\$ORIGINAL_UNTAR_FOLDER\bin\vcredist_2010_x86.exe" /q'
> +!else

Is this a typo?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.select features without category skipped

[Vaclav Petras]

On Tue, Dec 20, 2016 at 10:36 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 20/12/16 16:18, Luca Delucchi wrote:
>
>> On 20 December 2016 at 16:08, Moritz Lennert
>>  wrote:
>>
>>
>>> You can go ahead and commit to trunk, unless someone objects. At least
>>> this
>>> way it gets some testing.
>>>
>>>
>> are you sure? you should submit it :-/
>>
>
> I had hoped to put the work on you... ;-)
>
> But it's done: r70103.
>
> But we should keep this in mind and observe whether this does not cause
> any issues. Maybe open a ticket ?



Isn't an empty vector map an expected result in this case? What happens
when you do this in GUI (where output is added automatically to Map
Display)? Ticket might be appropriate.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.randomforest built status

[Vaclav Petras]

On Sun, Dec 18, 2016 at 3:40 PM, Helmut Kudrnovsky  wrote:

> >
> > Is there any "best practice" example available?
> 
>
> I've done it in this way :
>
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/
> vector/v.in.natura2000/v.in.natura2000.py#L151
>
> accordingly an advice by Vaclav.
>
> Maybe there are some other ways to do it.


Here is a example for more complicated case:

https://trac.osgeo.org/grass/changeset/66482/grass-addons/grass7/vector/v.class.ml

But I don't know what is best practice, perhaps as simple solution as
possible - import in main() after parser() will work for most of the short
modules and dependencies.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] d.linegraph indentation mess

[Vaclav Petras]

On Sat, Dec 17, 2016 at 7:15 AM, Markus Neteler  wrote:

>
> Indeed, the if() statement in 735 has some issues: braces missing or
> indentation wrong.
>
> Any idea how to fix that correctly?
>


I need to look at these two if more closely, but otherwise I think I'll
just reindent all and do the classic int -> size_t replacements.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7.2RC2 problem

[Vaclav Petras]

Hi Michael,

On Thu, Dec 15, 2016 at 3:35 PM, Michael Barton 
wrote:

>
> from my compiling environment shell and from within a functioning grass
> environment.
>

When the log shows

```
Details: [Errno 2] No such file or directory
g.gui.dbmgr: Unable to fetch interface description for command
'g.gui.dbmgr'.

Details: dyld: Library not loaded:
/Applications/GRASS-7.2.app/Contents/MacOS/lib/libgrass_gis.7.2.0RC2.dylib
  Referenced from:
/Users/cmbarton/grass_source/grass-7.2.0RC2/dist.x86_64-apple-darwin15.6.0/bin/g.parser
  Reason: image not found
```

it doesn't seem that you have working GRASS environment. g.parser seems to
fail.

Anyway, this seems to be not important because according to what I wrote
earlier, the version of your Mac system libraries and the system Python (my
guess version 2.7.11 or older) do not work together. On Linux I would talk
to the packagers. I don't have any idea what you do on Mac in these cases.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.2.0

[Vaclav Petras]

On Sun, Dec 11, 2016 at 2:43 PM, Martin Landa 
wrote:

>
> 2016-12-11 20:39 GMT+01:00 Markus Neteler :
> > Sorry to bother: this does not sound like a GRASS GIS 7.2 problem to
> > me but a winGRASS packaging issue?
>
> yes, it seems to be a WinGRASS packaging issue (I will have time to
> look at it later in the end of week - Friday). From my POV, it's not
> blocker for GRASS release. Ma



I more or less agree, but what I don't know is if to package WinGRASS or
not if the lidar stuff is broken. For example, the current situation is
that from the current packages for the 7.0.x releases some support C++
modules and some lidar modules. However, I'm not sure if there is one 7.0.x
release which supports both. Of course, it is the packaging issue not the
release issue, but then should the package exist if it has a major issue?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.2.0

[Vaclav Petras]

On Sat, Dec 10, 2016 at 1:04 PM, Martin Landa 
wrote:

> 2016-12-10 17:52 GMT+01:00 Helena Mitasova :
> > Regarding the release there is also a major issue with v.in.lidar -
> Vasek is this still a problem in 7.2?
>
> do you mean Windows issue reported on ML. If so, it's problem of
> liblas package and WinGRASS packaging. Ma



Yes, that's it. Do you know how/where to push it upstream/downstream, so
that the right people look at it? It seemed that it is fixed at one point,
but the same behavior is back now.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.2.0

[Vaclav Petras]

On Sat, Dec 10, 2016 at 10:57 AM, Martin Landa 
wrote:

> 2016-12-10 16:51 GMT+01:00 Markus Neteler :
> > On Dec 7, 2016 10:02 PM, "Markus Neteler"  wrote:
> >> Now the current showstopper is MacOSX it seems...
> >
> > Is this really a GRASS issue?
> > Do we still wait?
>
> I don't think so. Putting to cpy Anna and Vaclav who knows more. Ma


The issue is with Mac OS system Python. On Linux, I would say "ask your
maintainers," no idea what you do on Mac. The Python version needs to be
updated. There is no way around it except for a major code change in GRASS
which would workaround a bug in Python on Mac (Mac libs (newly?) behaving
differently then other unixes or something like that). The bug is already
fixed and fix is released, so Mac needs to update Python.

I would say, even at the download site, that there are no Mac binaries
until Mac Python maintainers update to latest Python 2.7.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7.2RC2 problem

[Vaclav Petras]

The issue is solved in Python 2.7.12 from 2016-06-25.

https://hg.python.org/cpython/raw-file/v2.7.12/Misc/NEWS

On Wed, Dec 7, 2016 at 6:59 PM, Michael Barton 
wrote:

> We need to do something other than update Python.


There is not that much which can be done on the GRASS site. According to
Python issue #26083, the root of the problem is in Mac OS read() which
causes pre-2.7.12 subprocess package to fail on anything longer than 512
bytes when piping is used (significant part of GRASS Python code in GUI,
lib and modules). We can workaround it (example below causing other things
to fail), included fixed subprocess code in GRASS or switch to
subprocess32. None of these is feasible for 7.2 and they are not even worth
it considering that the fixed Python was released.

Example workaround (not recommended):

Index: gui/wxpython/core/toolboxes.py
===
--- gui/wxpython/core/toolboxes.py(revision 70036)
+++ gui/wxpython/core/toolboxes.py(working copy)
@@ -670,8 +670,20 @@
 try:
 task = gtask.parse_interface(module)
 except ScriptError as e:
+# This tries to solve failed build or run of a module
 sys.stderr.write("%s: %s\n" % (module, e))
 return '', ''
+except ValueError as e:
+# This is testing for Python's #26083 on Mac OS.
+# http://bugs.python.org/issue26083
+# The whole except ValueError should be removed once it
+# is fixed in Python (likely 2.7.12) or subprocess32 is used.
+from sys import platform
+if platform == "darwin":
+sys.stderr.write("%s: %s\n" % (module, e))
+return '', ''
+# raise exception again on other platforms
+raise

 return task.get_description(full=True), \
 task.get_keywords()
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7.2RC2 problem

[Vaclav Petras]

On Wed, Dec 7, 2016 at 7:00 PM, Michael Barton 
wrote:

> Also, why did this appear in GRASS 7.2 since mid-September? If we can
> answer that, perhaps we can avoid this issue.


Perhaps certain version of Python (the "patch" one, not just minor) or
change in Mac OS API. Does it happen with other versions of GRASS (freshly
compiled from scratch)?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7.2RC2 problem

[Vaclav Petras]

On Wed, Dec 7, 2016 at 2:23 PM, Anna Petrášová 
wrote:

> Looks like this:
> http://bugs.python.org/issue26083
>

Then it seems that the issue is unrelated to GRASS source code. Maybe an
update of system Python would help. Many GRASS modules written in Python
won't work with this Python bug.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7.2RC2 problem

[Vaclav Petras]

On Tue, Dec 6, 2016 at 7:03 PM, Michael Barton 
wrote:

> Here is what I had to do before.
>

What happens when you do it now? Or you already did that now?


>
> Compile normally (my steps 1-5)
>
> 5.1. Do NOT create binary distribution yet (do not run make bindist)
> 5.2. Launch GRASS (existing binary, preferably of same version)
> 5.3. cd to source wxpython folder. e.g.,
> cd /Users/cmbarton/grass_source/grass_trunk/gui/wxpython
> 5.4. recompile from within GRASS environment
> make clean
> make
>
> 6.0  then run bindist
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7.2RC2 problem

[Vaclav Petras]

In the log there is:

/Applications/Xcode.app/Contents/Developer/usr/bin/make xml/menudata.xml
GISRC=... LC_ALL=C python core/toolboxes.py > xml/menudata.xml
/Applications/Xcode.app/Contents/Developer/usr/bin/make
xml/module_tree_menudata.xml
GISRC=... LC_ALL=C python core/toolboxes.py "module_tree" >
xml/module_tree_menudata.xml

But in my log I see:

make xml/menudata.xml
make[1]: Entering directory '/home/vpetras/dev/grass/gcc_trunk/gui/wxpython'
GISRC=... LC_ALL=C python core/toolboxes.py > xml/menudata.xml
GISRC=... LC_ALL=C python core/toolboxes.py "validate" xml/menudata.xml
make[1]: Leaving directory '/home/vpetras/dev/grass/gcc_trunk/gui/wxpython'
make xml/module_tree_menudata.xml
make[1]: Entering directory '/home/vpetras/dev/grass/gcc_trunk/gui/wxpython'
GISRC=... LC_ALL=C python core/toolboxes.py "module_tree" >
xml/module_tree_menudata.xml
GISRC=... LC_ALL=C python core/toolboxes.py "validate"
xml/module_tree_menudata.xml
make[1]: Leaving directory '/home/vpetras/dev/grass/gcc_trunk/gui/wxpython'

One small difference are the lines "Leaving directory". Perhaps different
version of make?

But the bigger issue is that I have two "toolboxes.py "validate"
xml/...xml" lines and I don't see them in the Michael's Mac OS log. They
are in the Makefile:

xml/menudata.xml: core/toolboxes.py
$(call run_grass,$(PYTHON) $< > $@)
$(call run_grass,$(PYTHON) $< "validate" $@)

xml/module_tree_menudata.xml: core/toolboxes.py
$(call run_grass,$(PYTHON) $< "module_tree" > $@)
$(call run_grass,$(PYTHON) $< "validate" $@)

The "validate" step is supposed to create an error during compilation in
case something is wrong with the generated XMLs. But it seems that it is
not executed on Michael's Mac. Different Makefiles? Different make?

Unfortunately, the Travis CI log does not show anything (due to the
workaround for Mac?), so we can't compare.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7.2RC2 problem

[Vaclav Petras]

I don't know what to think about the log. There should be no "up to date"
massages after `make distclean`.

make[4]: `/Users/cmbarton/grass_source/grass-7.2.0RC2/dist.x86_64-
apple-darwin15.6.0/docs/man/man1/d.rhumbline.1' is up to date.

On Tue, Dec 6, 2016 at 5:56 PM, Michael Barton 
wrote:

> Try this.
>
> Michael
>
>
> > On Dec 6, 2016, at 3:39 PM, Anna Petrášová 
> wrote:
> >
> > On Tue, Dec 6, 2016 at 5:32 PM, Michael Barton 
> wrote:
> >
> > Please first make distclean and then run make.
> >
> > Thank you,
> > Anna
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] t.rast.out.xyz not exporting all cells in the computational region

[Vaclav Petras]

On Tue, Dec 6, 2016 at 12:34 PM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> Le 6 décembre 2016 17:53:48 GMT+01:00, Martin Landa <
> landa.mar...@gmail.com> a écrit :
> >Hi,
> >
> >2016-12-06 17:45 GMT+01:00 Markus Neteler :
> >> Big question: add to 7.2.0 or not? I am in favor.
> >
> >+1 Ma
>
> I understand the motivation, but IIUC it's definitely an API change that
> could break existing scripts, which is against our normal policy.
>
> Why not make the flag mean the contrary, i.e. include null values ? Then
> it wouldn't break anything...
>
> I'm pretty sure that most people exporting data via r.out.xyz would
> expect null values to be excluded...
>


r.out.xyz export XY and their values. When there is no value, nothing is
exported. This is the correct counterpart for r.in.xyz where you get NULLs
for cells without any input XY(Z).

I agree with Moritz. Adding a flag to export NULLs looks like the best way.
It doesn't break API nor expectations. NULLs simply not being there seems
like a better default here.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Passing computational region to individual commands

[Vaclav Petras]

On Wed, Nov 23, 2016 at 3:41 PM, Markus Neteler  wrote:

> GRASS_REGION does not affect the stored computational region (i.e. the
> WIND file) but appears to be only used by the following module call.


Yes. A module reads the region from the env var. The behavior is the same
if you do it in the GRASS session. The variable is simply in the env.
grass.py does nothing with it. Same for WIND_OVERRIDE.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] man error on compilation

[Vaclav Petras]

On Tue, Nov 22, 2016 at 1:01 PM, Yann Chemin 
wrote:

> the error came when I would not flush all containers from previous build.
> If I build with --no-cache, the issue does not come.
>
>
Yes, cache seems tricky. I checkout and compile in one step. Longer and
network intensive when you mess up compilation, but ensures clean and fresh
source.

# install GRASS GIS
WORKDIR /usr/local/src
RUN svn checkout https://svn.osgeo.org/grass/grass/trunk grass \
&& cd grass \
&&  ./configure \
--enable-largefile=yes \
--with-nls \
--with-cxx \
--with-readline \
--with-bzlib \
--with-pthread \
--with-proj-share=/usr/share/proj \
--with-geos=/usr/bin/geos-config \
--with-cairo \
--with-opengl-libs=/usr/include/GL \
--with-freetype=yes
--with-freetype-includes="/usr/include/freetype2/" \
--with-sqlite=yes \
--with-liblas=yes --with-liblas-config=/usr/bin/liblas-config \
&& make && make install && ldconfig


> Thanks for the check on empty keywords list


You're welcome.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] man error on compilation

[Vaclav Petras]

On Tue, Nov 22, 2016 at 11:12 AM, Yann Chemin 
wrote:

> I am compiling from SVN inside a docker (Debian testing)
>
>
I'm just doing it with Ubuntu in Docker and I have no issue with r68881
(docker run ... grass --config revision).


> for some reason inside man/ the build_keywords.py bugs at line 63.
>

This looks like module without keywords or with an empty keyword. Are you
using something else than code from trunk?


>
> GISBASE="/root/dev/grass_trunk/dist.x86_64-pc-linux-gnu"
> ARCH="x86_64-pc-linux-gnu" ARCH_DISTDIR="/root/dev/grass_
> trunk/dist.x86_64-pc-linux-gnu" VERSION_NUMBER=7.3.svn VERSION_DATE=2016
> python ./build_keywords.py /root/dev/grass_trunk/dist.
> x86_64-pc-linux-gnu/docs/html
> Traceback (most recent call last):
>   File "./build_keywords.py", line 63, in 
> firstchar = key[0].lower()
> IndexError: string index out of range


r69871 checks for an empty keyword and fail because empty keyword should
not happen. The error message tells file and line.

Hope this helps,
Vaclav

https://trac.osgeo.org/grass/changeset/69871
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Passing computational region to individual commands

[Vaclav Petras]

[was: Adding an expert mode to the parser]

On Sun, Sep 25, 2016 at 10:16 PM, Vaclav Petras <wenzesl...@gmail.com>
wrote:

> On Sun, Sep 25, 2016 at 5:40 PM, Sören Gebbert <
> soerengebb...@googlemail.com> wrote:
>
>> >r.mapclac --raster-region= --north= --south= --west= --east= --res=
>>> >--ewres= --nsres= --vect-region --raster-align= ...
>>>
>>
> I like this in the sense that if the region setting for the module is
> something which should be managed by these extra options, then they should
> be managed in parser, rather than introduced one by one for individual
> modules.
>
> But how is this different from using GRASS_REGION? Convenience of 
> --raster-region=?
> Better syntax than environmental variable?
>

It would work better when using GRASS GIS by grass command with --exec:

grass72 /path/to/grassdata/test1/PERMANENT/ --exec r.univar map=elevation
--region-raster=elevation

which needs to be now done using two commands:

grass72 /path/to/grassdata/test1/PERMANENT/ --exec g.region raster=elevation
grass72 /path/to/grassdata/test1/PERMANENT/ --exec r.univar map=elevation
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Standard option identifiers

[Vaclav Petras]

On Mon, Oct 31, 2016 at 11:38 PM, Helmut Kudrnovsky  wrote:

> G_OPT_R_INPUTS
> type : string
>

Once there is G_OPT_R_INPUTS, you don't need to provide `type: string`
that's provided automatically. Typically you change key or
description/label.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] Fwd: Geospatial devroom at FOSDEM 2017 on Sunday 5/2/2017 in Brussels

[Vaclav Petras]

On Mon, Oct 24, 2016 at 8:12 AM, Margherita Di Leo 
wrote:

> On Thu, Oct 20, 2016 at 4:00 PM, Moritz Lennert <
> mlenn...@club.worldonline.be> wrote:
>
>> After our latest discussions I think it might be interesting if someone
>> could present the GRASS GIS testing framework.
>>
>> Anyone interested amongst those who know it well ?
>>
>
> Right, this is a very welcome topic! I hope someone is willing to present
> it?
>

I don't think I would be able to go there.


> If you're not familiar with it, please feel free to propose more topics as
> well!
>

Performance with new compression methods and null file compression (an its
implementation if the rest is not dev enough).

Vaclav
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS GIS meetup in Raleigh, North Carolina, Nov 5

[Vaclav Petras]

Dear all,

next GRASS GIS Raleigh meetup is November 5. We had meetup almost every
month since December 2015. If you are or know people from the area, help us
spread the word for this one by tweets, personal emails, or whatever feels
appropriate to you. If not, then get inspired and organize one yourself.
See full announcement at the bottom of the email.

Best regards,
Vaclav


GRASS GIS Raleigh meetup, November 5, Hunt at NC State

Interested in using GRASS GIS as a geospatial processing backend? Or for
reproducible research with Python? Or as a surprisingly powerful desktop
GIS? Then come to the November GRASS GIS Raleigh meetup which will be
specifically focused on getting newcomers started with anything ranging
from using GRASS GIS to programing and contributing. The meetup is planned
for Saturday, November 5. Meet in 4502 Fishbowl at the Hunt library at NC
State Centennial Campus at 2 PM. Join any time during the afternoon; we
will be there at least till 6 PM, but there is an option to stay longer.

Contact Vaclav Petras (Vashek) if you have any questions:
wenzeslaus gmail com

See this page for details:
https://grasswiki.osgeo.org/wiki/GRASS_GIS_Raleigh_meetups_2016
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Color tables/rules now use standardized color parsing

[Vaclav Petras]

Dear all,

in r69708, I've changed the implementation of parsing color rules to use
the G_str_to_color() function instead of a custom mechanism. This, in
connection with r69683, adds the possibility to use HTML (CSS) style of
hexadecimal colors with leading hash.

So, now you can do:

r.colors elevation rules=- 

Re: [GRASS-dev] v.wedge

[Vaclav Petras]

On Tue, Oct 18, 2016 at 5:58 PM, Vincent Bain  wrote:

>
> Hoping it can be useful I attach the bash script, don't know if it's
> worth making it an addon, I guess it would be better to write new addons
> in python... perhaps someone can turn it into something more "trendy"?
>

You can add it to GRASS Subversion sandbox (you need to get access unless
you already have it) or you can use some service like GitHub. This way, you
give a clear(er) way to contribute and a way to obtain latest version. If
you add makefile and doc, then it will be possible to install it with
g.extension (on Linux and Mac with G72).

Vaclav
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Delete r.le.* now?

[Vaclav Petras]

On Thu, Sep 1, 2016 at 4:13 AM, Moritz Lennert 
wrote:
>>> I suggest identifying what is missing in r.li from r.le and opening
tickets
>>> for it. Then it seems that it is time to remove r.le.* from addons, so
it is
>>> clear that they don't need to be maintained.

I'm still unclear on whether we have the r.le functionality in other
modules or not. Here are the modules and their descriptions from the manual:

r.le.patch - calculates attribute, patch size, core (interior) size, shape,
fractal dimension, and perimeter measures for sets of patches in a landscape

r.le.index - Contains a set of measures for attributes, diversity, texture,
juxtaposition, and edge

r.le.trace - Displays the boundary of each r.le patch and shows how the
boundary is traced, displays the attribute, size, perimeter and shape
indices for each patch and saves the data in an output file

>>> In case somebody want to use r.le, the modules are still accessible in
6.4
>>> if I understand it correctly.
>>>
>>
>> +1 for remove r.le modules
>
>
> +1
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev