Re: [GRASS-dev] Implement a REST API for GRASS

[Blumentrath, Stefan]

Seen this: https://bitbucket.org/huhabla/open-graas? 
Cheers
Stefan

Von: grass-dev [grass-dev-boun...@lists.osgeo.org] im Auftrag von Maris Nartiss 
[maris@gmail.com]
Gesendet: Donnerstag, 25. Mai 2017 09:42
An: Pietro
Cc: GRASS developers list
Betreff: Re: [GRASS-dev] Implement a REST API for GRASS

I assume that both are equally dangerous. My opinion is that GRASS GIS
should not be exposed to any non trustable users, as various smaller
and larger bugs are too common. Unless, of course, it runs inside a
throw-away VM.

2017-05-25 10:33 GMT+03:00 Pietro :
> Dear Māris,
>
> On Wed, May 24, 2017 at 8:52 PM, Maris Nartiss  wrote:
>>
>> GRASS GIS code has never been developed with security in mind. I would
>> not suggest to run it in a non-trustable environment.
>
>
> Do you think that expose some GRASS modules through a REST API can be more
> dangerous than exposing the same modules through a WPS service? Why?
>
> Pietro
___
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] Having trouble building GRASS from source and asking for help

[Blumentrath, Stefan]

Hi, 

To me this looks like checkinstall is failing caus not all required 
metainformation is given.
See: https://manpages.debian.org/jessie/checkinstall/checkinstall.8.en.html

Try specifying amongst others - -pkgversion

Hope that helps... 

Cheers 
Stefan


Von: grass-dev [grass-dev-boun...@lists.osgeo.org] im Auftrag von Paul Schrum 
[paul.sch...@gmail.com]
Gesendet: Montag, 15. Mai 2017 22:14
An: grass-dev@lists.osgeo.org
Betreff: [GRASS-dev] Having trouble building GRASS from source and asking   
for help

I am attempting to build GRASS on my machine and I suppose I am having trouble. 
 I am so bewildered by all of this I can't actually be sure.  I am posting to 
request help.  Here is my situation:

I am new to GRASS development, and I am working on GSoC on integrating PDAL 
interoperability.   I have not yet set up my project's wiki page or I would 
link it in this sentence.

I am running OSGeo-live on Oracle Virtual Box with my base OS being Windows 8.1.

My mentor, Vashek Petras, directed me to start here: 
https://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu#Dependencies
and work through the build procedure.  On that page, I got down as far as 
"simple configure, compile and install" and ran that once.  I don't remember 
what it told me, but I figured it was okay since I could always do it again, so 
I executed the next line (under the "or"):

./configure && make -j2  &&  sudo checkinstall

When I do this, I get the message
Building Debian package... FAILED!

so I am thinking this is bad and I should get this to succeed before moving on 
to other steps.  Here is more information:  When I try to run it again, I get a 
screen of Warnings:

checkinstall 1.6.2, Copyright 2009 Felipe Eduardo Sanchez Diaz Duran
   This software is released under the GNU GPL.



*
 Debian package creation selected ***
*

*** Warning: The package name "%PACKAGE_NAME" contains upper case
*** Warning: letters. dpkg might not like that so I changed
*** Warning: them to lower case.

*** Warning: The package name "%package_name" does not start with
*** Warning: an alphanumetic character. dpkg might not like that so I prefixed
*** Warning: it with a number 0.

*** Warning: The package name "0%package_name" contains illegal
*** Warning: characters. dpkg might not like that so I changed
*** Warning: them to dashes.

*** Warning: The package version "%PACKAGE_VERSION" is not a
*** Warning: debian policy compliant one. Please specify an alternate one

I let it continue to run, but eventually it offers to show me the log, which 
appears here:

dpkg-deb: error: parsing file '/var/tmp/tmp.J1ZMR3Tl3Q/package/DEBIAN/control' 
near line 11 package '0-package-name':
 empty value for version
/var/tmp/tmp.J1ZMR3Tl3Q/dpkgbuild.log (END)

Is this enough information for someone to help me?

- Paul Schrum
Raleigh, NC, US
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Introduction for GSoC 2017

[Blumentrath, Stefan]

Thanks Yann! Great news!
I will use the modules on tilted digital camera images (from wildlife camera 
traps).
But I can check if we have some good aerial photos somewere in a drawer….

Cheers
Stefan


From: Yann Chemin [mailto:dr.yann.che...@gmail.com]
Sent: fredag 12. mai 2017 09.19
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>; Luca Delucchi 
<lucadel...@gmail.com>
Cc: GRASS-dev <grass-dev@lists.osgeo.org>; Manan Singh <mananpa...@gmail.com>
Subject: Re: [GRASS-dev] Introduction for GSoC 2017

Hi Stefan,
the first throw is there in SVN, just update and recompile.
The two GUI are g.gui.iphoto2image and g.gui.iimage2target.
Finalization of the names are also open to suggestion, so far I just 
concatenated the old module names in v6 and added to g.gui.
Please test and if you have a scanned aerial photo with good info about camera 
and XYZ of fiducials, please throw it my side too so I can validate/finalize 
the output accuracy.
Cheers,
Yann

--
Yann Chemin
Planetary Scientist
Latest: https://peerj.com/preprints/2124/
-
JRC: 
https://www.thefreelibrary.com/3628+-+CANHEMON+Remote+sensing+based+forest+canopy+health+monitoring...-a0453990005
OSGeo: https://wiki.osgeo.org/wiki/Open_Monitoring_Systems_Working_Group

On 21 March 2017 at 08:31, Yann 
<dr.yann.che...@gmail.com<mailto:dr.yann.che...@gmail.com>> wrote:
Hi Stefan,

please also launch the main menu: i.ortho.photo at the command line, it tends 
to be erratic.

(careful the i.photo.2target is not yet existing)

Ciao,
Yann



On 21/03/2017 08:04, Blumentrath, Stefan wrote:
Hi Yann,

Thanks so much! Very cool!
I will test the photo2image GUI tool ASAP!

Cheers
Stefan

From: Yann Chemin 
[mailto:dr.yann.che...@gmail.com<mailto:dr.yann.che...@gmail.com>]
Sent: tirsdag 21. mars 2017 07.56
To: Luca Delucchi <lucadel...@gmail.com<mailto:lucadel...@gmail.com>>
Cc: GRASS-dev <grass-dev@lists.osgeo.org<mailto:grass-dev@lists.osgeo.org>>; 
Manan Singh <mananpa...@gmail.com<mailto:mananpa...@gmail.com>>; Blumentrath, 
Stefan <stefan.blumentr...@nina.no<mailto:stefan.blumentr...@nina.no>>
Subject: Re: [GRASS-dev] Introduction for GSoC 2017


Hi all,

I have added to SVN trunk one of the two missing gui modules of i.ortho.photo 
recently: g.gui.iphoto2image at the command line launches it. All other modules 
but one are operational (still not fully tested though), I have already started 
working on the last one, which is also GUI based.

Cheers,
Yann

On Mar 20, 2017 5:25 PM, "Luca Delucchi" 
<lucadel...@gmail.com<mailto:lucadel...@gmail.com><mailto:lucadel...@gmail.com<mailto:lucadel...@gmail.com>>>
 wrote:
On 18 March 2017 at 08:30, Blumentrath, Stefan
<stefan.blumentr...@nina.no<mailto:stefan.blumentr...@nina.no><mailto:stefan.blumentr...@nina.no<mailto:stefan.blumentr...@nina.no>>>
 wrote:
Hi,
Hi,
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?
I fully support this idea, GUI for i.ortho.photo is the most important
loss from GRASS 6

Cheers,

Stefan

--
ciao
Luca

www.lucadelu.org<http://www.lucadelu.org><http://www.lucadelu.org>
___
grass-dev mailing list
grass-dev@lists.osgeo.org<mailto:grass-dev@lists.osgeo.org><mailto:grass-dev@lists.osgeo.org<mailto: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] GRASS GIS and GSoC

[Blumentrath, Stefan]

Hi again,

I would be pleased to be co-mentor, but unfortunately I am a) not really a 
software developer (more an above the average interested user probably) and 
more important b) I will be on paternity leave most of the summer, so I will 
not have capacity to follow up properly.

Wrapping a module around the libraries Luca and Marcus mentioned would be the 
way to go I guess for Sentinel-data.

Another approach for fetching open or public data could also be to try to 
improve the g.gui.cswbrowser module [1] and add a “Add data from catalogue” 
module. But I am not sure if that is feasible (see [2]).
It would be really cool and flexible for all sorts of publicly available data 
and following standards (CSW, Atom feeds…). Users could provide URL to 
catalogues of their choice, search the data and add what is available in a 
standard-adherent way…
A drawback is that the wx.metadata tools are not production ready yet… So, 
those knowing the code and issues better could probably give a hint if this is 
a path worth following or not. But maybe this can be a “standalone module” as 
well?

Cheers,
Stefan

1: 
https://grasswiki.osgeo.org/wiki/ISO/INSPIRE_Metadata_Support#Browsing_and_searching-_g.gui.cswbrowser
2: https://github.com/geopython/MetaSearch/issues/25 and 
http://hub.qgis.org/issues/11733


From: Zechariah Krautwurst [mailto:zfkra...@ncsu.edu]
Sent: onsdag 29. mars 2017 16.27
To: Markus Neteler <nete...@osgeo.org>
Cc: Luca Delucchi <lucadel...@gmail.com>; Blumentrath, Stefan 
<stefan.blumentr...@nina.no>; GRASS developers list (grass-dev@lists.osgeo.org) 
<grass-dev@lists.osgeo.org>; Václav Petráš <wenzesl...@gmail.com>
Subject: Re: [GRASS-dev] GRASS GIS and GSoC


Vashek, thank you for your time and for being willing to co-mentor the project. 
Let's keep trying to rope someone else in! I will look at the existing tickets 
and see how I can help.

Stefan, thank you for getting me that script. You're right, it's a great 
starting point. Keep us posted if you're into co-mentoring with Vashek!

Markus and Luca, thank you for the resources. I look forward to exploring some 
of the ideas there.

Please continue to send any thoughts or ideas my way, especially in regards to 
GSoC and finding a second mentor. I'll reply here with any updates to the 
project development and GSoC application process.

Thanks again!

Zeke

On Wed, Mar 29, 2017 at 5:30 AM, Markus Neteler 
<nete...@osgeo.org<mailto:nete...@osgeo.org>> wrote:
On Wed, Mar 29, 2017 at 9:42 AM, Luca Delucchi 
<lucadel...@gmail.com<mailto:lucadel...@gmail.com>> wrote:
> On 29 March 2017 at 08:58, Blumentrath, Stefan
> <stefan.blumentr...@nina.no<mailto:stefan.blumentr...@nina.no>> wrote:
>>> I would like to have something similar to r.modis for sentinel data... :-)
...
> https://github.com/ibamacsr/sentinelsat/

Python module for batch download of Sentinel data:

- http://www.cesbio.ups-tlse.fr/multitemp/?p=6419
- http://olivierhagolle.github.io/Sentinel-download/
- http://krstn.eu/download-Sentinel-2-images/
- https://github.com/IgorGarkusha/RSUtils

Markus


--
Markus Neteler
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog



--

Zechariah F. Krautwurst

NCSU College of Natural Resources

MGIST Candidate 2017

zfkra...@ncsu.edu<mailto:zfkra...@ncsu.edu>

(336) 416-3870
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS GIS and GSoC

[Blumentrath, Stefan]

> I would like to have something similar to r.modis for sentinel data... :-)

Sentinel (or more general Copernicus) data could be a very good case as it 
comes - in contrast to many other open data - with a dedicated and stabe API 
for downloading:
https://scihub.copernicus.eu/userguide/5APIsAndBatchScripting
, is of wider interest and has a wide spatial coverage...

Though the data management should be properly thought through (external vs. 
import, update of earlier downloads...) since the data can be massive.

Inspiration might be taken from the Semi-automated classification Plugin in 
QGIS (https://plugins.qgis.org/plugins/SemiAutomaticClassificationPlugin/).

Cheers
Stefan

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

Re: [GRASS-dev] [release] GRASS 7.2.1RC1

[Blumentrath, Stefan]

Maybe enough (best) to handle it in the manual?
Meaning, add that information to the notes?
Users can avoid that lines/boundaries are broken by running v.dissolve in 
advance if needed?

Cheers
Stefan 

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

Re: [GRASS-dev] GRASS GIS and GSoC

[Blumentrath, Stefan]

Hi Zeke,

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.

BTW. comparable tools to r.modis for other sensors would be awesome too!!!

Cheers,
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of 
Zechariah Krautwurst
Sent: tirsdag 28. mars 2017 00.56
To: grass-dev@lists.osgeo.org
Subject: [GRASS-dev] GRASS GIS and GSoC

Hello All,

My name is Zeke Krautwurst and I am interested in participating in GSoC this 
summer through GRASS GIS. I have been in contact with developers Vashek Petras 
and Anna Petrasova at NCSU.  Vashek recommended that I reach out to the broader 
dev community as well, potentially to find a lead mentor.

As part of my Master of Geospatial Information Science and Technology 
coursework at NCSU, I am working on a few projects using Python, PostgreSQL, 
and database development that I think will apply to the needs of the GRASS GIS 
Locations created from public 
data
 project.

Through April, I will be creating a GUI and Python scripts to convert multiple 
formats of publicly available microbiome data into a standardized geospatial 
format. I also hope to create a normalized PostgreSQL database that 
accommodates the scripts, the microbiome data, and associated metadata which 
could all be deployed through a web-based framework.

I want to use GRASS GIS for both of those assignments in place of ArcMap and I 
think that completing those projects will give me the experience I need to be 
useful to the GRASS GIS project over the summer. Additionally, I am looking to 
develop and complete my MGIST capstone project this coming Fall and I would be 
happy to continue this work through graduation in Dec 2017.

Thanks for your time and please let me know if anyone has any feedback or 
advice!

Best,

Zeke

--

Zechariah F. Krautwurst

NCSU College of Natural Resources

MGIST Candidate 2017

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

Re: [GRASS-dev] Introduction for GSoC 2017

[Blumentrath, Stefan]

Hi Yann,

Thanks so much! Very cool!
I will test the photo2image GUI tool ASAP!

Cheers
Stefan

From: Yann Chemin [mailto:dr.yann.che...@gmail.com]
Sent: tirsdag 21. mars 2017 07.56
To: Luca Delucchi <lucadel...@gmail.com>
Cc: GRASS-dev <grass-dev@lists.osgeo.org>; Manan Singh <mananpa...@gmail.com>; 
Blumentrath, Stefan <stefan.blumentr...@nina.no>
Subject: Re: [GRASS-dev] Introduction for GSoC 2017


Hi all,

I have added to SVN trunk one of the two missing gui modules of i.ortho.photo 
recently: g.gui.iphoto2image at the command line launches it. All other modules 
but one are operational (still not fully tested though), I have already started 
working on the last one, which is also GUI based.

Cheers,
Yann

On Mar 20, 2017 5:25 PM, "Luca Delucchi" 
<lucadel...@gmail.com<mailto:lucadel...@gmail.com>> wrote:
On 18 March 2017 at 08:30, Blumentrath, Stefan
<stefan.blumentr...@nina.no<mailto:stefan.blumentr...@nina.no>> wrote:
> Hi,
>

Hi,

>
> 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?
>

I fully support this idea, GUI for i.ortho.photo is the most important
loss from GRASS 6

>
>
> Cheers,
>
> Stefan
>


--
ciao
Luca

www.lucadelu.org<http://www.lucadelu.org>
___
grass-dev mailing list
grass-dev@lists.osgeo.org<mailto: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] Introduction for GSoC 2017

[Blumentrath, Stefan]

Hi,

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?

Workflows from GRASS 6 could be improved a bit in that context quite a bit too, 
e.g.:

-  Having both image and target map in an interactive window for 
setting image coordinates and GCPs

-  Possibility to move points for image coordinates to improve RMSE

-  Pick altitude from target terrain

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

Cheers,
Stefan

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

Re: [GRASS-dev] r.in.gdal and xargs

[Blumentrath, Stefan]

Hi again,

Now, I investigated a bit more:

When I use just one process in xargs (P 1) I get no error.  r.mapcalc works 
nicely together with the same xargs approach and 10 processes.
I think this can be tracked down to the creation of the directory .tmp/HOST 
which seems to fail if more processes try to create it at (almost) the same 
time...

The temp-file creation behavior seems affects also other modules like e.g. 
r.null.

Opened a ticket on trac:
https://trac.osgeo.org/grass/ticket/3309

Cheers
Stefan


-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of 
Blumentrath, Stefan
Sent: mandag 6. mars 2017 15.57
To: Vincent Bain <b...@toraval.fr>
Cc: GRASS developers list (grass-dev@lists.osgeo.org) 
<grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] r.in.gdal and xargs

I can parallelize on a higher level, so i can set P to 1 here.
If it is a bug I can open a ticket... 


Von: Vincent Bain [b...@toraval.fr]
Gesendet: Montag, 6. März 2017 15:07
An: Blumentrath, Stefan
Cc: GRASS developers list (grass-dev@lists.osgeo.org)
Betreff: Re: [GRASS-dev] r.in.gdal and xargs

Yes, perhaps something to do with r.in.gdal temp files handling.

And what if you try to reduce P value ?
well, of course it will slow down the bulk import...


Le lundi 06 mars 2017 à 14:02 +, Blumentrath, Stefan a écrit :
> Thanks Vincent for your swift reply.
>
> In principle the pipe to xargs works, as 99% of the data is imported 
> properly. And also in the case were I get roors, the command is started 
> properly...
>
> Thus, I suspect that r.in.gdal can have issues when run in parallel; or the 
> creation of temp files, in particular the creation of the .tmp/HOST directory 
> within the mapset...
>
> Cheers
> Stefan
>
>


___
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] r.in.gdal and xargs

[Blumentrath, Stefan]

Thanks Vincent for your swift reply.

In principle the pipe to xargs works, as 99% of the data is imported properly. 
And also in the case were I get roors, the command is started properly...

Thus, I suspect that r.in.gdal can have issues when run in parallel; or the 
creation of temp files, in particular the creation of the .tmp/HOST directory 
within the mapset...

Cheers
Stefan


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

[GRASS-dev] r.in.gdal and xargs

[Blumentrath, Stefan]

Dear all,

I am trying to import time series data using a combination of xargs an r.in 
gdal:
cat current_datasets_age.txt | awk -v U="myunits" -v N="name" '{ print 
"r.in.gdal input=$1 ".bil output=" $2 "_tmp title=\"" N " in " U " at " $3 "\" 
--o --q -o\0"}' | xargs -P 10 -I {} -0 bash -c {}

In some cases (5 out of ~20k) I get:
ERROR: Unable to make mapset element .tmp/HOST 
(/grassdata/ETRS_33N/timseries/.tmp): File exists

It does not happen regularly. Can there be race conditions?
I am using GRASS 7.2 (r70188) on Ubuntu 14.04 LTS.

I am grateful for any hint.

Kind regards,
Stefan
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] update wiki page export to spatialite dbase with v.out.ogr

[Blumentrath, Stefan]

Hi,

If you are n latest GRASS 7.2.1svn, maybe you hit this one:
https://trac.osgeo.org/grass/ticket/3270

Cheers
Stefan

-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Paulo 
van Breugel
Sent: torsdag 2. februar 2017 08.20
To: Vincent Bain 
Cc: GRASS developers email list 
Subject: Re: [GRASS-dev] update wiki page export to spatialite dbase with 
v.out.ogr



On 02-02-17 08:17, Vincent Bain wrote:
> Le jeudi 02 février 2017 à 08:10 +0100, Paulo van Breugel a écrit :
>
>> I haven't tried that, but would that append objects to an existing 
>> layer within the spatialite database?
> yes it does... without warning for duplicates.
Would be good to add a few lines on that on the wiki page. Could you do that?
>
>> In the manual it is stated that v.out.ogr exports 3D vector data as 
>> 2.5D simple features if possible. I don't know if that is supported 
>> by Spatialite, but if not, it is indeed good to mention.
> I thought it would be nice to write a brief page related to raster 
> export with rasterlite format option available at r.out.gdal. I'll try 
> to propose it soon.
I didn't know that option, would be great if you could add something about that 
option to the wiki page
>
> V.
>

___
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] Reviewing GSoC 2017 page

[Blumentrath, Stefan]

Thanks, quite some interesting GSoC ideas.

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).

Regarding:
https://trac.osgeo.org/grass/wiki/GSoC/2017#AdditionalfunctionalityforrunningGRASSGISmodulesinJupyterNotebook
(which I also very much like to see become reality, esp. a function like 
“initGRASS()” from rgrass7) 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).

In order to be really useful, WebGRASS would need a console, and here Jupyter 
was already mentioned as an option. In addition the WebUI struggled quite a bit 
with renderinig… So will this proposal be complementary?

Cheers
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Vaclav 
Petras
Sent: torsdag 26. januar 2017 00.22
To: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] Reviewing GSoC 2017 page

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 
> 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

Re: [GRASS-dev] [GRASS GIS] #3269: r.roughness.vector: bug in rescale formula

[Blumentrath, Stefan]

Hi Steven,

And many thanks for clarification and contrasting results in detail…
And sorry for throwing the question at the list without having checked that (I 
just scanned the module code).

I noticed the difference in the references referred to in both modules. From 
scanning the code they seemed to do  the same thing, but now I see that the 
main difference is probably that r.vector.ruggedness uses slope directly for 
weighting vector strength, while r.roughness.vector uses the “inverted” slope / 
colatitude angle (90 – slope). Apart from that both modules look quite similar 
(as are the names) in terms of what they do to the DEM.

So, there might still be a point of consolidating them into one module which 
offers both the “Sappington et al. 2007 metric” and the “Hobson 1972 metric”…

Just a thought…

Kind regards,
Stefan


From: Steven Pawley [mailto:dr.stevenpaw...@gmail.com]
Sent: onsdag 25. januar 2017 21.18
To: Luca Delucchi <lucadel...@gmail.com>
Cc: Blumentrath, Stefan <stefan.blumentr...@nina.no>; 
carlos.grohm...@gmail.com; grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] [GRASS GIS] #3269: r.roughness.vector: bug in rescale 
formula

Hi,

There seems to be some difference in the calculation between these two add-ons. 
Apologies for any duplication, but in the way of explanation I wrote the 
parallelized r.vector.ruggedness because I needed to calculate the VRM measure 
in a hurry and was confused about the results from r.roughness.vector.

The result from r.vector.ruggedness is identical (apart from how slope and 
aspect are calculated) to the result from the Sappington et al. 2007 paper and 
the Sappington-authored script in ArcGIS (see attached derived from the 
nc_spm_08 grass dataset). The form of the calculation is slightly different 
(but the end result is the same) because I average rather than sum the x,y, and 
z rasters to avoid a strong edge effect because AFAIK r.mapcalc doesn't have an 
automated method of dealing with bordering nulls (hence the averaging 
workaround). The r.vector.ruggedness results are also the same as how SAGA GIS 
calculates this metric, and it is this version of the 'VRM' metric that has 
been used extensively in the literature over the past few years.

r.roughness.vector appears to produce a very different result (see attached). 
Perhaps this represents an alternative implementation, but the main difference 
lies in how the DEM is decomposed into its x,y, and z components.

So if the add-ons are to be merged then perhaps this needs to be resolved?

Steve

On Tue, Jan 24, 2017 at 3:43 PM, Luca Delucchi 
<lucadel...@gmail.com<mailto:lucadel...@gmail.com>> wrote:
On 24 January 2017 at 09:55, Blumentrath, Stefan
<stefan.blumentr...@nina.no<mailto:stefan.blumentr...@nina.no>> wrote:
> Hi,
>

Hi,

> Another related question: There are now two AddOns for this purpose:
>
> r.roughness.vector (last changed 2 years ago)
>
> and from 2016: r.vector.ruggedness
>
> Both basically calculate the same metric(s), though they have their 
> differences and both have their pros:
> r.roughness.vector offers more advanced options (esp. useful for multi scale 
> application)
> r.vector.ruggedness uses parallelization
>
> Having two modules for one task / metric, which are not conceptually 
> different is a bit confusing...
> IMHO both should be merged into one, keeping the strength of each of them...
>

+1 for merging... this could be a work for the next code sprint

> Other thoughts?
>
> Cheers
> Stefan
>

--
ciao
Luca

www.lucadelu.org<http://www.lucadelu.org>
___
grass-dev mailing list
grass-dev@lists.osgeo.org<mailto: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] [GRASS GIS] #3269: r.roughness.vector: bug in rescale formula

[Blumentrath, Stefan]

Hi,

Another related question: There are now two AddOns for this purpose:

r.roughness.vector (last changed 2 years ago)

and from 2016: r.vector.ruggedness

Both basically calculate the same metric(s), though they have their differences 
and both have their pros:
r.roughness.vector offers more advanced options (esp. useful for multi scale 
application)
r.vector.ruggedness uses parallelization

Having two modules for one task / metric, which are not conceptually different 
is a bit confusing...
IMHO both should be merged into one, keeping the strength of each of them...

Other thoughts?

Cheers
Stefan


-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of GRASS 
GIS
Sent: tirsdag 24. januar 2017 08.45
Subject: [GRASS-dev] [GRASS GIS] #3269: r.roughness.vector: bug in rescale 
formula

#3269: r.roughness.vector: bug in rescale formula
--+-
 Reporter:  sbl   |  Owner:  grass-dev@…
 Type:  defect| Status:  new
 Priority:  normal|  Milestone:  7.2.1
Component:  Default   |Version:  unspecified
 Keywords:  AddOn,r.roughness.vector  |CPU:  Unspecified
 Platform:  All   |
--+-
 There is a little bug in the formula that produces the "Fischers K" output  
(line 317).
 "- 1" should not be in there.

--
Ticket URL: 
GRASS GIS 

___
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] i.landsat8.swlst: suggestions for

[Blumentrath, Stefan]

Hi Nikos/devs,

Currently, I am Co-supervising a student who is using i.landsat8.swlst module 
for his bachelor thesis.

During that work we stumbled upon some minor issues where we would like to 
propose some changes in the module:

-  The k-flag does the opposite of what the description tells. It sets 
the computational region to the Landsat scene. I would say, it is more in line 
with other GRASS modules if the computational region is not changed by default. 
So I would rather change the description than the behavior (please find a 
suggestion in the diff below). However, maybe it is even more coherent with the 
rest of the GRASS modules if the flag is removed?

-  Currently, the module always overwrites an existing MASK and 
requires either the QAB band or a raster representing unreliable pixels which 
the module then uses as an inverted mask. I would like to propose to leave the 
(cloud) masking out of the module and leave that to other modules 
(i.landsat8.qc, r.reclass, r.mask...).

Please find attached a diff covering the suggested changes in i.landsat8.swlst 
plus some message and UI cosmetics.

Nikos, if you prefer a PR on github I can create one (don`t know how you sync 
gtihub and svn...)?

If you agree in the proposed changes I will also check and adjust the manual 
accordingly...

Kind regards,
Stefan


i.landsat8.swlst.diff
Description: i.landsat8.swlst.diff
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.what.rast: topology really necessary?

[Blumentrath, Stefan]

Hi Martin,

And thanks so much for your effort!

I just patched r70332 and tested in NC, where it works perfectly fine with:

v.random --overwrite --verbose output=random_topo npoints=5000
v.db.addtable map=random_topo columns="elev double precision"

v.out.ascii -c --overwrite --verbose input=random_topo type=point 
output=$HOME/test.asc columns=elev format=point
v.in.ascii -b --overwrite --verbose input=$HOME/test.asc output=random_notopo 
skip=1

time v.what.rast --verbose map=random_notopo raster=elev_ned_30m@PERMANENT 
column=elev
time v.what.rast --verbose map=random_topo raster=elev_ned_30m@PERMANENT 
column=elev

BTW. during testing I noticed that v.db.addtable also requires topology level 2 
(therefore I exported to ASCII and imported without topology)...

Again, thanks so much! This can provide a quite efficient workflow for my 
colleagues with GPS-tracking data (points) in PostGIS...

Cheers
Stefan 

-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com] 
Sent: lørdag 14. januar 2017 17.06
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (grass-dev@lists.osgeo.org) 
<grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] v.what.rast: topology really necessary?

Hi Stefan,

2017-01-11 11:38 GMT+01:00 Blumentrath, Stefan <stefan.blumentr...@nina.no>:

could you try patch for v.what.rast [1]? Ma

[1] https://trac.osgeo.org/grass/ticket/3249#comment:13

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.what.rast: topology really necessary?

[Blumentrath, Stefan]

Forgot to ask: could this go into the release branch none the less (you 
recently changed milestone to 7.4)?

-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com] 
Sent: lørdag 14. januar 2017 17.06
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (grass-dev@lists.osgeo.org) 
<grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] v.what.rast: topology really necessary?

Hi Stefan,

2017-01-11 11:38 GMT+01:00 Blumentrath, Stefan <stefan.blumentr...@nina.no>:

could you try patch for v.what.rast [1]? Ma

[1] https://trac.osgeo.org/grass/ticket/3249#comment:13

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.what.rast: topology really necessary?

[Blumentrath, Stefan]

Hi Martin,

Thanks for the hint. Will do so...

Cheers
Stefan


-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com] 
Sent: onsdag 11. januar 2017 11.26
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (grass-dev@lists.osgeo.org) 
<grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] v.what.rast: topology really necessary?

Hi Stefan,

2017-01-10 22:49 GMT+01:00 Blumentrath, Stefan <stefan.blumentr...@nina.no>:
> After repeated testing, a colleague of mine pointed out that I know occupy 
> almost all available PostGIS connections on our server.
> It seems that connections hang from testing and that either v.external or 
> v.what.rast does not close the PG connection properly after the module 
> finishes... Or are there other possible explanations?

I would guess that the command which segfauls could be a problem. I tested all 
the commands including v.what.rast which segfaults and check number of active 
connection via pg_top. No connection hanged even I launched the command with 
segfault.

> Where should I look to find the source of the issue?

Install pgtop on the server, login as postgres user and run pg_top command. It 
will show you number of active connection. Run GRASS command and check number 
of connection.

Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.external: ID confusion

[Blumentrath, Stefan]

Hi again,

And sorry, some more v.external issues...

When I try to connect to a remote server in GRASS 7.2.1svn with v.external, I 
get "database not found" error.

In GRASS 7.0 the database is found with exactly the same command.

However, linking the table fails in 7.0 because the ID column is in mixed cases 
and column names are not quoted in the SQL generated by v.external.
BTW. Is it necessary to sort the ID column? Does it make sense if UUIDs are 
used as primary keys?

Cheers
Stefan


-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com] 
Sent: mandag 9. januar 2017 18.17
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (grass-dev@lists.osgeo.org) 
<grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] v.external: ID confusion

Hi Stefan,

2017-01-09 16:42 GMT+01:00 Blumentrath, Stefan <stefan.blumentr...@nina.no>:
> Did I overlook something at import or should I open a ticket?

yes, please. Also provide all command and sample data to reproduce this issue. 
Thanks, Ma

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.what.rast: topology really necessary?

[Blumentrath, Stefan]

Hei again,

And sorry for the numerous emails...

After repeated testing, a colleague of mine pointed out that I know occupy 
almost all available PostGIS connections on our server.
It seems that connections hang from testing and that either v.external or 
v.what.rast does not close the PG connection properly after the module 
finishes... Or are there other possible explanations?

Where should I look to find the source of the issue?

Ciao,
Stefan

-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com] 
Sent: tirsdag 10. januar 2017 15.39
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (grass-dev@lists.osgeo.org) 
<grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] v.what.rast: topology really necessary?

Hi,

2017-01-10 13:18 GMT+01:00 Blumentrath, Stefan <stefan.blumentr...@nina.no>:
> Thanks for your swift relpy. Unfortunately, without topology, v.what.rast 
> segfaults in r70332.
>
> v.external --overwrite input=PG:dbname=gisdata layer=points 
> output=points_pg73ot -bo v.what.rast map=points_pg73ot raster=rand 
> column=morphology Reading features from vector map...
> Segmentation fault (core dumped)

hm, I can confirm it. Unfortunately it's something hidden. It segfaults at

#4  0x77ba5d5d in get_feature (Map=0x7fffbed0, fid=-1,
type=-1) at read_pg.c:614
#5  0x77ba5829 in read_next_line_pg (Map=0x7fffbed0, 
line_p=0x63b3e0, line_c=0x60ad70, ignore_constraints=0) at
read_pg.c:468

when I comment out this line, it segfauls on completely different place:

#7  0x7729e187 in G__calloc (file=0x772e21a0 "lib/gis/parser.c", 
line=658, m=1024, n=1) at alloc.c:81
#8  0x772c243b in recreate_command (original_path=0) at parser.c:658
#9  0x772c2b77 in G_recreate_command () at parser.c:802

It seems to be memory issue. Please report an issue in trac. Ma

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.what.rast: topology really necessary?

[Blumentrath, Stefan]

Hi Martin,

Thanks for your swift relpy. Unfortunately, without topology, v.what.rast 
segfaults in r70332.

v.external --overwrite input=PG:dbname=gisdata layer=points 
output=points_pg73ot -bo
v.what.rast map=points_pg73ot raster=rand column=morphology
Reading features from vector map...
Segmentation fault (core dumped)

Ciao,
Stefan

-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com] 
Sent: tirsdag 10. januar 2017 12.40
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (grass-dev@lists.osgeo.org) 
<grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] v.what.rast: topology really necessary?

Hi Stefan,

2017-01-10 11:09 GMT+01:00 Blumentrath, Stefan <stefan.blumentr...@nina.no>:
> Is there any reason that v.what.rast requires topology level 2? “r.what”
> works without topology…

AFAIU, topology is not required. I change that in r70331 (trunk).
After some testing could be backported to relbr72. Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] v.what.rast: topology really necessary?

[Blumentrath, Stefan]

Hi again,

Is there any reason that v.what.rast requires topology level 2? "r.what" works 
without topology...

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

[GRASS-dev] v.external: ID confusion

[Blumentrath, Stefan]

Hi,

I tried to link a PG table to GRASS for point sampling using v.external (in 
GRASS 7.0.6).

With that linked layer (which is not in public schema and has column "point_id" 
as primary key) I get a lot of:

WARNING: No record for category  in table
 

when I use v.what.rast on that layer.

The results suggest that not the proper IDs were used when values were loaded 
to attribute table. Because values in the attribute table of the points do not 
match with values in the raster at point locations. Furthermore, some points, 
which are supposed to have values in the attribute table, have none...

Did I overlook something at import or should I open a ticket?

Kind regards,
Stefan
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.stream.basins: issues with points on other layer than 1

[Blumentrath, Stefan]

Hi,

I had some trouble with r.stream.basins which labeled all basins created with 
points option as -1.
After some investigation I found out that the problem was that my vector points 
map only had categories on layer 2.
After transferring the categories to layer 1 everything worked fine. During my 
test with NC dataset I also saw that if there only some points on a layer have 
a category, no basin is produced for the points without category; even if the 
message of the module says differently.

The latter can be reproduced with NC data like this:
g.region -p raster=elev_lid792_1m
r.watershed elevation=elev_lid792_1m accumulation=flow_accum drainage=draindir
echo "638867.632469|220039.545432|7
638563.344273|220045.597694|12
638945.422741|220706.456664|999
638978.525142|220455.417819|" | v.in.ascii input=- output=points columns="cat 
integer" cat=3 --o
r.stream.basins --o --v -c direction=draindir points=points memory=3000 
basins=basins

>From that experience I would like to suggest either

a)   Adding a layer option to the module

b)  Give at least a warning if features in the vector map are lacking a 
category

c)   Clarify the behavior in the manual
or maybe a combination of a-c...

I could assist with c)...
What do you think?

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

Re: [GRASS-dev] pysal file I/O

[Blumentrath, Stefan]

Depends what you are planing to do in more detail. But maybe the pygrass Vector 
or VectorTopo module could be of help...
https://grass.osgeo.org/grass70/manuals/libpython/pygrass_vector.html

Cheers
Stefan

Von: grass-dev [grass-dev-boun...@lists.osgeo.org] im Auftrag von Paulo van 
Breugel [p.vanbreu...@gmail.com]
Gesendet: Freitag, 23. Dezember 2016 22:34
An: Helmut Kudrnovsky; grass-dev@lists.osgeo.org
Betreff: Re: [GRASS-dev] pysal file I/O

On 23 December 2016 3:26:58 pm Helmut Kudrnovsky  wrote:

> pvanbosgeo wrote
>> I am trying to write a script using pysal for point pattern analysis. From
>> their manual, "PySAL contains a new file input-output API that should be
>> used for all file IO operations" (
>> pysal.readthedocs.io/en/latest/users/tutorials/fileio.html).
>>
>> Does anybody know or has suggestions how to get a grass vector layer ready
>> for further analysis with pysal within a grass script using this I/O api?
>>
>> Paulo
>>
>> ___
>> grass-dev mailing list
>
>> grass-dev@.osgeo
>
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
> In mentioned doc, there are e.g. Shapefile or csv listed as exchange format?
>
> AFAIU  the I/O api is able to read these listed exchange formats.
>
>

Yes, but I was wondering if it would be possible without first converting / 
exporting to another format.

>
> -
> best regards
> Helmut
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/pysal-file-I-O-tp5301192p5301198.html
> Sent from the Grass - Dev mailing list archive at 
> Nabble.com.
> ___
> 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] how to reproject a raster map with absolute numbers without losing data

[Blumentrath, Stefan]

Hei,

What about something like this (example converts from UTM33 to WGS84 and 
creates ):
r.stats -gn1 INPUTMAP | cs2cs -E -f "%.6f" +proj=utm +no_defs +zone=33 
+a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 +to_meter=1 +to 
+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs | tr '\t' ' ' | r.in.xyz --o 
--v z=6 input=- output=REPROJECTED_MAP separator=space

Or is cs2cs to slow or does it modify also z?

BTW, I think several modules would benefit from a -b do not build topology...

Cheers
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Moritz 
Lennert
Sent: 30. november 2016 19:36
To: Markus Metz 
Cc: grass-dev 
Subject: Re: [GRASS-dev] how to reproject a raster map with absolute numbers 
without losing data



Le 29 novembre 2016 22:33:39 GMT+01:00, Markus Metz 
> a écrit :
> For
>reprojection, something like r.in.xyz could work:

I'm currently going through this process and it raises a series of issues:


>
>1. convert raster cells to vector points with raster cell value as
>vector z
>value.

I use r.to.vect for this. The -b flag allows +/- fast conversion, 
but it takes into account all cells. It would be great to have a flag telling 
it to only convert non-null cells. Or at least a hint to set a mask, which 
seems to have the desired effect.


>2. reproject these vector points to the target location

I locally modified v.proj to add a 'Don't build topology' flag.

Is there any indication against this ?

>3. export the vector points with v.out.ascii format=point
>4. import the exported points with r.in.xyz method=sum

This works nicely.

Thanks ! If I find the time I will wrap this into a r.proj.aggregate (?) 
script...



>
>The method options of r.in.xyz could be added to r.proj for 
>spatial
>aggregation, but that would mean that most of the code of r.in.xyz
>would
>need to be copied to r.proj, then adapted. That would be an interesting
>enhancement, also considering that gdalwarp offers as resampling
>methods
>near, bilinear, cubic, cubicspline, lanczos, average, mode, max, min,
>med,
>Q1, Q3.

But it doesn't offer sum

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

Re: [GRASS-dev] how to reproject a raster map with absolute numbers without losing data

[Blumentrath, Stefan]

-Original Message-
From: Moritz Lennert [mailto:mlenn...@club.worldonline.be] 
Sent: torsdag 1. desember 2016 00.01

>>
>>BTW, I think several modules would benefit from a -b do not build 
>>topology...

>Which other modules are you thinking about?
>Moritz


All modules which produce points, e.g. v.to.points, but also v.extract would 
benefit (there may be more for sure).

In a project I had to patch data on a specific land cover type from three 
countries, which should be then merged into one dataset. Thus the workflow was 
v.extract -> v.patch. Building the topology, esp for maps with a lot of areas 
is often the most time consuming step...

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

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

[Blumentrath, Stefan]

Dear all,

Yesterday I pushed a GRASS GIS 7 / Python version of r.colors.out_sld to AddOns.

Further improvements to the GRASS 6 version are category label support, UTF-8 
encoding and a preliminary manual 
(https://grass.osgeo.org/grass70/manuals/addons/r.colors.out_sld.html).

It is still limited to SLD v1.0.0.

The produced SLDs validate without issues in GeoServer, but further testing is 
very welcome...

Mvh
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of 
Blumentrath, Stefan
Sent: 21. november 2016 14:07
To: GRASS developers list (grass-dev@lists.osgeo.org) 
<grass-dev@lists.osgeo.org>
Subject: [GRASS-dev] r.colors.out_sld

Hi,

In order to get some of my data properly from GRASS into GeoNode (which is 
based on GeoServer) I would like to also export the GRASS color tables into 
SLD, so I can import them to GeoServer too.

I found the r.colors.out_sld AddOn 
(https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.colors.out_sld/) for 
that purpose, but it is GRASS 6 Shell script. Even though I think it would work 
with GRSS 7 too, my questions are:

1)  Are there other solutions in GRASS 7 to produce SLD I might have 
overlooked?

2)  If not, do you think it there is a point porting r.colors.out_sld to 
GRASS7 / Python (which I would volunteer for)? or

3)  Would it be better to add SLD export as a flag to r.colors.out?

Kind regards,
Stefan


Stefan Blumentrath
Researcher II

Norwegian Institute for Nature Research - NINA
Postal address: Gaustadalléen 21, NO-0349 Oslo, NORWAY
Delivery/Visiting address: Gaustadalléen 21, NO-0349 Oslo, NORWAY
Phone: +47 46 34 11 58 * Cell: +47 46 34 11 58 * Fax: +47 73 80 14 01 * 
www.nina.no<http://www.nina.no/>


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

[GRASS-dev] r.colors.out_sld

[Blumentrath, Stefan]

Hi,

In order to get some of my data properly from GRASS into GeoNode (which is 
based on GeoServer) I would like to also export the GRASS color tables into 
SLD, so I can import them to GeoServer too.

I found the r.colors.out_sld AddOn 
(https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.colors.out_sld/) for 
that purpose, but it is GRASS 6 Shell script. Even though I think it would work 
with GRSS 7 too, my questions are:

1)  Are there other solutions in GRASS 7 to produce SLD I might have 
overlooked?

2)  If not, do you think it there is a point porting r.colors.out_sld to 
GRASS7 / Python (which I would volunteer for)? or

3)  Would it be better to add SLD export as a flag to r.colors.out?
Kind regards,
Stefan


Stefan Blumentrath
Researcher II

Norwegian Institute for Nature Research - NINA
Postal address: Gaustadalléen 21, NO-0349 Oslo, NORWAY
Delivery/Visiting address: Gaustadalléen 21, NO-0349 Oslo, NORWAY
Phone: +47 46 34 11 58 * Cell: +47 46 34 11 58 * Fax: +47 73 80 14 01 * 
www.nina.no


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

Re: [GRASS-dev] t.connect and t.rast.what not in GUI

[Blumentrath, Stefan]

Sorry for the delay!

Please find attached a patch against trunk which adds GUI entries for
r3.in.lidar
r3.flow
r3.gradient
t.rast3d.algebra
t.rast.algebra
t.rast.contour
t.rast.to.vect
t.vect.algebra
v.decimate
v.out.lidar

and removes
v.krige from menu.

This list of new modules in trunk is fetched from: 
https://trac.osgeo.org/grass/wiki/Release/7.2.0-News

Cheers
Stefan


-Original Message-
From: Anna Petrášová [mailto:kratocha...@gmail.com] 
Sent: 30. september 2016 00:12
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (grass-dev@lists.osgeo.org) 
<grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] t.connect and t.rast.what not in GUI

On Thu, Sep 29, 2016 at 5:47 PM, Blumentrath, Stefan 
<stefan.blumentr...@nina.no> wrote:
> Thanks Anna,
>
> I just checked the new modules for 7.2.0 listed here:
> https://trac.osgeo.org/grass/wiki/Release/7.2.0-News
>
> And found that actually none of them seem to have made it into the GUI...
> v.krige on the other hand is still in the GUI though it has been removed from 
> the code...
>
> I can try to create a new patch for that if you like...

That would be great. I would omit g.gui.datacatalog, d.frame, d.legend.vect and 
maybe some others, I don't think we have to have all modules accessible from 
menu.

Thank you

>
> Cheers
> Stefan
>
>
> -Original Message-
> From: Anna Petrášová [mailto:kratocha...@gmail.com]
> Sent: 29. september 2016 15:20
> To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
> Cc: GRASS developers list (grass-dev@lists.osgeo.org) 
> <grass-dev@lists.osgeo.org>
> Subject: Re: [GRASS-dev] t.connect and t.rast.what not in GUI
>
> On Wed, Sep 28, 2016 at 8:48 AM, Blumentrath, Stefan 
> <stefan.blumentr...@nina.no> wrote:
>> Hi,
>>
>>
>>
>> It seems that t.connect and t.rast.what have not been added to the 
>> GUI (both in G73 and G72)!
>>
>>
>>
>> Please find attached a patch where I tried to add them. Hope that is 
>> the proper way.
>>
>>
>>
>> I placed t.connect under temporal, but it might be better suited 
>> under Database, don’t now...
>>
>>
>
> I added it there and backported to 7.2. Thank you!
>
> Anna
>
>>
>> Cheers
>>
>> Stefan
>>
>>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev


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

Re: [GRASS-dev] [GRASS-user] v.rast.stats ERROR

[Blumentrath, Stefan]

-Original Message-
From: Moritz Lennert [mailto:mlenn...@club.worldonline.be] 
Sent: 21. oktober 2016 11:30
>> However, it seems that for raster maps more special characters are
>> legal and also v.in.ogr uses layer names from the original data
>> source which can cause conflicts in SQL DB backends...
>
>That's why the option of not having table names identical to map names 
>might be more flexible, but it creates a bit of confusion when people 
>assume that identity of names.

Having map names and table names - as far as possible - identical is very 
convenient. I would not change that.

>
>> Maybe legal file names, column and table handling is something to
>> re-consider for GRASS 8?
>
>Sure.
>
>How much of a problem is there really, though ? What do you propose 
>needs changing ?
>
>Moritz

No idea how much of a problem that is in praxis. Table or column name issues 
pop up here and there and are usually fixed with a simple workaround. Users can 
always cause trouble for themselves when managing attribute data through 
db.execute and the SQL which is supported by their backend. The latter often 
allows for things which can cause problems for GRASS modules.
Furthermore, one can of course also get data where column names are not 
compliant with GRASS standards

The current handling of column and table names regarding special characters, 
upper/lower case is not really consistent, which is untypical for GRASS (at 
least from my experience).
However,  e.g. quoting all SQL identifiers would require significant changes 
(as quoting is also backend depending) and involves likely quite some work. So, 
it is probably not worth changing anything. I shall have a look at the 
documentation, if limitations of SQL in GRASS should be made more explicit 
there...

Kind regards,
Stefan
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] v.rast.stats ERROR

[Blumentrath, Stefan]

Yes, but in vector maps starting with a number or having a "." in the name is 
not allowed. Also SQL keywords are excluded...
See: https://grass.osgeo.org/programming7/legal__vname_8c_source.html

So, the same logic may be used to check column names (I guess that is what 
Markus intended).

However, it seems that for raster maps more special characters are legal and 
also v.in.ogr uses layer names from the original data source which can cause 
conflicts in SQL DB backends...

Maybe legal file names, column and table handling is something to re-consider 
for GRASS 8?

Cheers
Stefan

-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Moritz 
Lennert
Sent: 21. oktober 2016 09:34
To: Markus Neteler ; GRASS developers list 

Subject: Re: [GRASS-dev] [GRASS-user] v.rast.stats ERROR

On 20/10/16 22:11, Markus Neteler wrote:
> (moved to GRASS-dev)
>
> Topic: v.rast.stats error message
>
> On Fri, Oct 14, 2016 at 8:35 PM, Helmut Kudrnovsky  wrote:
>>> ERROR: Unable to add column <1_average DOUBLE PRECISION>.
>>> ERROR: Adding columns failed. Exiting.
>>
>> AFAIR in SQL column names starting with a number isn't allowed.
>
> Is there any Python wrapper around Vect_legal_filename() which could 
> be used here to generate a better error message?

Even though a Python wrapper for Vect_legal_filename would be useful, it 
wouldn't help here as the problem is the attribute column name, not the 
filename.

Moritz
___
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] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

[Blumentrath, Stefan]

Hi again,

Interesting discussion!

With my user and amateur addon-developer perspective I would conclude that:
- we all agree that tests/unittests are very useful even if not "the silver 
bullet"
- things one does in "unittests" might also partly be done in the code of the 
module (e.g. check for a specific state of input or environment variables ...), 
so a requirement for unittest might have to go hand in hand with a requirement 
for "maturity" of the module?
- "unittests" can also differ a lot in complexity so it is probably not too 
easy to say which level of unit tests should be required for a new core module, 
and the presence of a test alone does not necessarily mean that a module is 
"well tested"...
- it might be a good starting point to "require" only "simple" unittests for 
new core modules in that sense that a unit test makes sure that at least 
examples from the manual work without throwing an error? That would at the same 
time test code and manual/documentation... There was the idea to use examples 
from the manual to auto-generate tests, was`nt it?
- with more tests on "higher level" modules, also "lower level functions" (e.g. 
library) might be covered. This could on the one hand help to trace (side) 
effect of changes on lower level functions, but on the other hand might require 
to also update all output-tests which were written based on that bogus library 
function, would not it?
- like some others here I never wrote a test for my addons, but I would be 
willing to learn! Here the simple examples Vaclav provided were very helpful, 
as for me as a rookie the more involved examples and the full documentation of 
the unittests are hard to understand. Maybe you can add a very minimalistic 
example to the test documentation that only checks (e.g. based on NC data set) 
that e.g. "r.example -g input=mymap" works without throwing an error?

And finally, Martins request regarding an RFC for "promoting modules to core" 
should not drown in the discussion about unittests (even if the latter probably 
is a precondition to the former)...

Cheers
Stefan

P.S.: For automatized tests of addons there might be a dependency issue, as a 
test-server would have to be equipped with all possible dependencies in order 
to be able to run the addons?



-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Moritz 
Lennert
Sent: 7. oktober 2016 08:32
To: Vaclav Petras ; Anna Petrášová 
Cc: GRASS developers list ; Markus Metz 

Subject: Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move 
to core

On 06/10/16 23:34, Vaclav Petras wrote:
> On Tue, Oct 4, 2016 at 4:55 PM, Anna Petrášová  > wrote:
>
> [...]
>
> c) test correctness of results.
> It just depends how you write them, and yes, for some modules c) is
> more difficult to implement than for others.
>
>
> On Thu, Oct 6, 2016 at 5:00 PM, Anna Petrášová  > wrote:
>
> There is correct result in the sense "as author intended". So you can
> use pen and paper and solve very small example. That doesn't mean it
> will cover all options, but better than nothing. [...]
>
>
> For r.forestfrag, I wrote a test which was based on an example in the 
> original paper which was computing value of one cell in 3x3 window. It 
> is a really trivial example which tests 1 number and two other numbers 
> which are intermediate results. However, by writing it, I actually 
> discovered that although the results for a large area look good, this 
> small example, which I was able compute by hand, is failing. After 
> investigation, it turned out that the error is actually in r.mapcalc.
> Computing the result outside of GRASS was crucial in this case. It was 
> an index and I was able to compute it by hand (and check it with the 
> example in the paper). For some other modules it could be more 
> difficult and I don't want to compute it without GRASS for more than 
> one cell even in this case, but it was certainly possible to write a 
> test of correctness for this module. Note that the test doesn't show 
> if the (forest fragmentation) index makes sense or if it is useful, 
> but it shows that the module gives the result it promised.
>
> This is the original test:
>
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.fore
> stfrag/testsuite/r_forestfrag_trivial.py

Nice example, thanks !

>
> This is the r.mapcalc bug:
>
> https://trac.osgeo.org/grass/ticket/3067
>
> And this is test which specifically shows the bug (would show if it 
> would be reintroduced):
>
> https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/test
> suite/test_row_above_below_bug.py

Here we have an example of a test with 70 lines of code which was comitted 
almost at the same time 

Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

[Blumentrath, Stefan]

Agreed with Paulo.
My impression is that new users rely on the menu to explore the software and 
its modules...


From: Paulo van Breugel [mailto:p.vanbreu...@gmail.com]
Sent: 7. oktober 2016 13:35
To: Moritz Lennert <mlenn...@club.worldonline.be>; Blumentrath, Stefan 
<stefan.blumentr...@nina.no>; Vaclav Petras <wenzesl...@gmail.com>; Anna 
Petrášová <kratocha...@gmail.com>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>; Markus Metz 
<markus.metz.gisw...@gmail.com>
Subject: Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move 
to core


On 7 October 2016 1:26:09 pm Moritz Lennert 
<mlenn...@club.worldonline.be<mailto:mlenn...@club.worldonline.be>> wrote:

> On 07/10/16 11:35, Blumentrath, Stefan wrote:
>> Ahhh, yes, there was that branch of the discussion too...
>>
>> g.extension is great and I do not see any limit with that, esp. not
>> for single user environments.
>>
>> However, on our server I download, compile and install centrally all
>> addons from source using a script. Thus, the main perceivable
>> difference between core modules and addons would be visibility in the
>> GUI...
>>
>> For me personally, that is no issue. But people who start with GRASS
>> likely often explore GRASS "graphically", thus a toolbox-approach
>> would be very nice I think. Having an "Addons" entry in the menu (if
>> there is space for that) where all installed addons register, would
>> be a demonstration of existing addional functionality...
>
> [...]
>
> On 05/10/16 23:10, Anna Petrášová wrote:
>  > Hmm, this is already implemented (several years I would say). Look
>  > into the tab Modules in layer manager. At least we now know, that
>  > nobody here is using it...
>
> Yes, I have to admit that I rarely use the other tabs in the GUI, to my
> own disadvantage most probably...
>
> But maybe we can think more radically. Just as several OS have moved
> away from the classical menu paradigm to search-based access to
> functionalities (e.g. gnome-shell, etc), why not completely get rid of
> the menus and only leave the modules tab as entry point ?

That works for some but surely not all users.

>
> Again, just brainstorming...
>
> Moritz
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org<mailto: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] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

[Blumentrath, Stefan]

Ahhh, yes, there was that branch of the discussion too...

g.extension is great and I do not see any limit with that, esp. not for single 
user environments.

However, on our server I download, compile and install centrally all addons 
from source using a script.
Thus, the main perceivable difference between core modules and addons would be 
visibility in the GUI...

For me personally, that is no issue. But people who start with GRASS likely 
often explore GRASS "graphically", thus a toolbox-approach would be very nice I 
think. Having an "Addons" entry in the menu (if there is space for that) where 
all installed addons register, would be a demonstration of existing addional 
functionality...
However, as you can imagine manually editing xml files for the numerous addons 
is no option for me. If it would be possible to implement your suggestion to 
add modules automatically to the GUI at install by means of Makefile (instead 
of g.extension) that would be splendid. But maybe I could change my script to 
use g.extension -s...

Advantages I see for moving addons to core:
- GRASS offers more "popular" functionality out of the box (new users probably 
do not check addons immediately when starting with GRASS)
- usually functionality is maintained to new major version (even if probably 
some exceptions exist, e.g. orthorectification GUI which has not been ported to 
G7 yet)
- moving an addon to core can be a kind of "award" or "reward" for an addon 
developer, thus it might be an incentive to e.g. add tests, documentation ...
- it might also help to motivate / involve more devs to contribute to core 
development?

Cheers
Stefan


-Original Message-
From: Moritz Lennert [mailto:mlenn...@club.worldonline.be] 
Sent: 7. oktober 2016 11:00
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>; Vaclav Petras 
<wenzesl...@gmail.com>; Anna Petrášová <kratocha...@gmail.com>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>; Markus Metz 
<markus.metz.gisw...@gmail.com>
Subject: RE: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move 
to core



Le 7 octobre 2016 10:41:50 GMT+02:00, "Blumentrath, Stefan" 
<stefan.blumentr...@nina.no> a écrit :
>Hi again,
>
>Interesting discussion!
>
>With my user and amateur addon-developer perspective I would conclude
>that:
[...]
>And finally, Martins request regarding an RFC for "promoting modules to 
>core" should not drown in the discussion about unittests (even if the 
>latter probably is a precondition to the former)...

And what is your take on the actual need to move modules to core ? Why is it an 
advantage ? And as a corollary to that: what limits/issues do you see with 
g.extension ?

Moritz



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

Re: [GRASS-dev] g.gui.tplot: AttributeError: 'module' object has no attribute 'EVT_COMBOBOX_CLOSEUP'

[Blumentrath, Stefan]

Hei Anna,

Thanks for your reply!
Seems I have both gtk 2.8 and gtk 3.0 on my system.
But I only found libwxgtk2.8-dev and since GRASS is selfcompiled I guess it is 
build against 2.8...
Shall try to build against 3.0.
Anyway, ticket opened here: https://trac.osgeo.org/grass/ticket/3175

Cheers
Stefan 

-Original Message-
From: Anna Petrášová [mailto:kratocha...@gmail.com] 
Sent: 6. oktober 2016 00:11
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (grass-dev@lists.osgeo.org) 
<grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] g.gui.tplot: AttributeError: 'module' object has no 
attribute 'EVT_COMBOBOX_CLOSEUP'

On Mon, Oct 3, 2016 at 6:14 PM, Blumentrath, Stefan 
<stefan.blumentr...@nina.no> wrote:
> Hi,
>
>
>
> In the context of https://trac.osgeo.org/grass/ticket/3057 I just 
> tested g.gui.tplot from GRASS 7.2 (r68908) on a STRDS and got the 
> following error
> message:
>
>
>
> Traceback (most recent call last):
>
>   File "/usr/local/grass-7.2.svn/scripts/g.gui.tplot", line
>
> 130, in 
>
> main()
>
>   File "/usr/local/grass-7.2.svn/scripts/g.gui.tplot", line
>
> 116, in main
>
> frame = TplotFrame(parent=None,
>
> giface=StandaloneGrassInterface())
>
>   File
>
> "/usr/local/grass-7.2.svn/gui/wxpython/tplot/frame.py", line
>
> 106, in __init__
>
> self._layout()
>
>   File
>
> "/usr/local/grass-7.2.svn/gui/wxpython/tplot/frame.py", line
>
> 230, in _layout
>
> self.datasetSelectV.Bind(wx.EVT_COMBOBOX_CLOSEUP,
>
> AttributeError: 'module' object has no attribute
>
> 'EVT_COMBOBOX_CLOSEUP'
>
>
>
> I am on Ubuntu 14.04 LTS. Is that related to #3057? Any other ideas?

not related. This GUI event is apparently not supported. From documentation:
Notice that this event is only supported by wxMSW, wxGTK with GTK+
2.10 or later, and OSX/Cocoa.
What version of gtk do you use?
Anyway, we have to replace this event. It would be best to create a ticket for 
this.

Anna

>
>
>
> Cheers
>
> Stefan
>
>
> ___
> 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

[GRASS-dev] g.gui.tplot: AttributeError: 'module' object has no attribute 'EVT_COMBOBOX_CLOSEUP'

[Blumentrath, Stefan]

Hi,

In the context of https://trac.osgeo.org/grass/ticket/3057 I just tested 
g.gui.tplot from GRASS 7.2 (r68908) on a STRDS and got the following error 
message:

Traceback (most recent call last):
  File "/usr/local/grass-7.2.svn/scripts/g.gui.tplot", line
130, in 
main()
  File "/usr/local/grass-7.2.svn/scripts/g.gui.tplot", line
116, in main
frame = TplotFrame(parent=None,
giface=StandaloneGrassInterface())
  File
"/usr/local/grass-7.2.svn/gui/wxpython/tplot/frame.py", line
106, in __init__
self._layout()
  File
"/usr/local/grass-7.2.svn/gui/wxpython/tplot/frame.py", line
230, in _layout
self.datasetSelectV.Bind(wx.EVT_COMBOBOX_CLOSEUP,
AttributeError: 'module' object has no attribute
'EVT_COMBOBOX_CLOSEUP'

I am on Ubuntu 14.04 LTS. Is that related to #3057? Any other ideas?

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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Blumentrath, Stefan]

Sounds fair enough as requirements for new core modules. “Maintainable code” 
would in praxis mean “the module has undergone a code review by a core 
developer”?
Those requirements would add to Markus requirement of “maturity”, which I would 
interpret like “the module has been tested in praxis and options and flags are 
consolidated” (so no major changes are expected / planned)...?

I am afraid, it seems only very few of the suggested modules are covered with 
unit tests. Most of them have a good documentation. No idea about the 
maintainability of the code...

How should we proceed with this topic? Should the named modules (and from my 
point of view Moritz OBIA modules would be very welcome too) be considered as a 
kind of “wish list” from the community? Probably more voices would be needed, 
as we currently have no “download statistics” or similar measures which may 
tell us something about the popularity or wide spread application of a module 
that would give reason to integrate it into core...
Where should such wishes be collected? A wiki page? Knowing of such interest 
might be an incentive for an addon-developer to write a test or to improve 
documentation...

Identified candidates could be added to core once they fulfill the requirements 
above. Would that happen only in minor releases or would that also be possible 
in point releases?

Or is that already too much formality and if someone wishes to see an addon in 
core that is simply discussed on ML?

Cheers
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Sören 
Gebbert
Sent: 30. september 2016 22:29
To: Markus Neteler 
Cc: GRASS developers list 
Subject: Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

Hi,
I would strongly suggest to move only those addons into core, that have good 
documentation, maintainable code and python tests that run in the gunittest 
framework.

Just my 2c
Sören

2016-07-03 20:09 GMT+02:00 Markus Neteler 
>:

Hi,

we may consider to move a few (!) mature addons to core.

Thoughts?

Markus

___
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] Upcoming 7.2.0: review which addons to move to core

[Blumentrath, Stefan]

Hi,

This discussion is actually a bit old, but maybe it is not too late to consider 
adding selected addons to trunk?

>From my personal user point of view the r.streams.* modules and r.geomorphon 
>are indeed top candidates for inclusion in core!

However, also:

i.segment.hierarchical (though manual is not yet complete)
v.class.mlpy (drawback: requires mlpy library) or v.class.ml and
r.randomforest
could nicely complement the image classification tools in GRASS.

r.gwr would strengthen the general modeling power of GRASS.

The wx.metadata modules would be very relevant for institutional users too, but 
I guess the currently numerous dependencies prohibit to move them to core...

Cheers
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Michael 
Barton
Sent: 5. juli 2016 00:06
To: GRASS developers 
Subject: Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

The r.stream* modules have been around for quite awhile and are very useful.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu



On Jul 4, 2016, at 2:00 AM, 
grass-dev-requ...@lists.osgeo.org 
wrote:

From: Helmut Kudrnovsky >
Subject: Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core
Date: July 3, 2016 at 1:25:20 PM MST
To: >


Markus Neteler wrote

Hi,

we may consider to move a few (!) mature addons to core.

Thoughts?

Markus

___
grass-dev mailing list


grass-dev@.osgeo


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] t.connect and t.rast.what not in GUI

[Blumentrath, Stefan]

Thanks Anna,

I just checked the new modules for 7.2.0 listed here:
https://trac.osgeo.org/grass/wiki/Release/7.2.0-News

And found that actually none of them seem to have made it into the GUI...
v.krige on the other hand is still in the GUI though it has been removed from 
the code...

I can try to create a new patch for that if you like...

Cheers
Stefan


-Original Message-
From: Anna Petrášová [mailto:kratocha...@gmail.com] 
Sent: 29. september 2016 15:20
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (grass-dev@lists.osgeo.org) 
<grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] t.connect and t.rast.what not in GUI

On Wed, Sep 28, 2016 at 8:48 AM, Blumentrath, Stefan 
<stefan.blumentr...@nina.no> wrote:
> Hi,
>
>
>
> It seems that t.connect and t.rast.what have not been added to the GUI 
> (both in G73 and G72)!
>
>
>
> Please find attached a patch where I tried to add them. Hope that is 
> the proper way.
>
>
>
> I placed t.connect under temporal, but it might be better suited under 
> Database, don’t now...
>
>

I added it there and backported to 7.2. Thank you!

Anna

>
> Cheers
>
> Stefan
>
>
> ___
> 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

[GRASS-dev] t.connect and t.rast.what not in GUI

[Blumentrath, Stefan]

Hi,

It seems that t.connect and t.rast.what have not been added to the GUI (both in 
G73 and G72)!

Please find attached a patch where I tried to add them. Hope that is the proper 
way.

I placed t.connect under temporal, but it might be better suited under 
Database, don't now...

Cheers
Stefan


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

Re: [GRASS-dev] Adding an expert mode to the parser

[Blumentrath, Stefan]

Hi,

I have been struggling with similar issues and solved them by writing a 
GRASS_BATCH_JOB script that I execute in parallel in different mapsets.
Thus, the approach Markus and Sören sketch looks very useful to me (even for 
people who are not on HPC).

Do you have more options / flags in mind than the region settings? Just asking 
to get a better idea about the amount of how module complexity may increase 
with the changes you plan?

If it is only region settings per module-call that should not be overwhelming 
for users. E.g., the QGIS-GRASS plugin (and I guess Processing too) has a 
button for «use region of this map» for every command with raster input, which 
is pointing in this direction (though not as sophisticated as your solution). 
And QGIS aimed at simplifying the interaction with GRASS analysis ;-).

In order to not blowing up the manual too much, one might write a compact 
standard description that points to g.region or a central, more detailed 
description of the new options, which will be the same for every module that 
uses them, would not they?

After you explained a bit more what you are after I do not really see a problem 
with this. In fact I am very positive!
But I have to admit that I did not understand the difference between 
--raster-region and --vector-region. Are you planning to implement some 
vector-tiles solution?

Cheers
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Vaclav 
Petras
Sent: 26. september 2016 04:28
To: Markus Neteler 
Cc: GRASS developers list ; Markus Metz 

Subject: Re: [GRASS-dev] Adding an expert mode to the parser


On Sun, Sep 25, 2016 at 3:49 PM, Markus Neteler 
> wrote:
when doing each job in its own mapset and reintegrate it in a single
target mapset as if able to process then in parallel in one mapset by
simply specifying the respective region to the command of interest.
Yes, different from the current paradigm and not for G7.

I think, we can accommodate this behavior in G7. In fact, each command can run 
with a separate region even now. It can set it on its own, take it from 
GRASS_REGION or WIND_OVERRIDE. But if you are talking about automatic patching, 
that's of course different.


But my original comment was targeted at the increasing number of
module parameters and how to handle that (with some new HPC related
idea as an example).

I think we need to talk about specific use cases and decide based on that. For 
some, Advanced or HPC tab might be enough. Some others might be better 
addressed by a specific global options like what Soeren just suggested (in the 
style of --overwrite).
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[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


-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Laurent 
C.
Sent: 22. september 2016 02:47
To: Sören Gebbert 
Cc: GRASS developers list 
Subject: Re: [GRASS-dev] Working with TGIS without starting GRASS explicitly

Hello all,

I've ran into another related issue.
One of the goal of running the software outside of GRASS shell is to batch 
process simulations in various Locations/mapsets.

I set the GRASS session for each case. The simulation works well for the first 
case.
However when starting the second case, tgis.init() fails with the following 
error:

ERROR: Unable to execute sql statement. There is no temporal database 
connection defined for mapset 

The mapset and location are properly set.
If this case is run first, it works well and it's the second one that fail.
Running t.connect -c between two cases does not solve the problem.
Actually, t.connect -p shows the correct connection parameters, but
tgis.init() still fails.

Regards,
Laurent


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.
> I guess this issue is related to the ticket 2424 [1].
>
> 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.
>
> It would be great if an easier option was possible.
>
> Regards,
> Laurent
>
> [1] https://trac.osgeo.org/grass/ticket/2424
> [2] 
> http://stackoverflow.com/questions/6543847/setting-ld-library-path-fro
> m-inside-python
>
>
> 2016-09-21 15:40 GMT-05:00 Sören Gebbert :
>> Hi,
>> i think you have to put the GRASS libraries into your LD_LIBRARY_PATH 
>> so that the python wrapper can access them.
>>
>> Best regards
>> Soeren
>>
>> 2016-09-21 20:37 GMT+02:00 Laurent C. :
>>>
>>> Hello all,
>>>
>>> I'm trying to adapt a python module in order for it to be run 
>>> outside of GRASS.
>>> I followed the instructions from the wiki and 
>>> lib/python/script/setup.py
>>>
>>> gsetup.init() run without error and I can list maps like in the example.
>>>
>>> However, when I try to import the temporal module, I receive this error:
>>>
>>> import grass.temporal as tgis
>>>   File "/usr/lib/grass70/etc/python/grass/temporal/__init__.py", 
>>> line 1, in 
>>> from core import *
>>>   File "/usr/lib/grass70/etc/python/grass/temporal/core.py", line 
>>> 38, in 
>>> from c_libraries_interface import *
>>>   File
>>> "/usr/lib/grass70/etc/python/grass/temporal/c_libraries_interface.py
>>> ",
>>> line 19, in 
>>> import grass.lib.gis as libgis
>>>   File "/usr/lib/grass70/etc/python/grass/lib/gis.py", line 23, in 
>>> 
>>> _libs["grass_gis.7.0.4"] = load_library("grass_gis.7.0.4")
>>>   File "/usr/lib/grass70/etc/python/grass/lib/ctypes_loader.py", 
>>> line 55, in load_library
>>> return self.load(path)
>>>   File "/usr/lib/grass70/etc/python/grass/lib/ctypes_loader.py", 
>>> line 71, in load
>>> raise ImportError,e
>>> ImportError: libgrass_datetime.7.0.4.so: cannot open shared object
>>> file: No such file or directory
>>>
>>>
>>> Did I forgot to set-up something or this is a bug?
>>>
>>> Cheers,
>>> Laurent
>>> ___
>>> 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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Blumentrath, Stefan]

Hei Laurent,

Not sure about python, but in bash you have to add this:

#For the temporal modules
export TGISDB_DRIVER=sqlite
export TGISDB_DATABASE=$MYGISDBASE/$MYLOC/PERMANENT/tgis/sqlite.db

to your script in order to make TGIS work when using GRASS modules withot 
starting GRASS explicitly...

See: 
https://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly#Bash_examples_.28GNU.2FLinux.29

Cheers
Stefan

-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Laurent 
C.
Sent: 21. september 2016 20:37
To: GRASS developers list 
Subject: [GRASS-dev] Working with TGIS without starting GRASS explicitly

Hello all,

I'm trying to adapt a python module in order for it to be run outside of GRASS.
I followed the instructions from the wiki and lib/python/script/setup.py

gsetup.init() run without error and I can list maps like in the example.

However, when I try to import the temporal module, I receive this error:

import grass.temporal as tgis
  File "/usr/lib/grass70/etc/python/grass/temporal/__init__.py", line 1, in 

from core import *
  File "/usr/lib/grass70/etc/python/grass/temporal/core.py", line 38, in 

from c_libraries_interface import *
  File "/usr/lib/grass70/etc/python/grass/temporal/c_libraries_interface.py",
line 19, in 
import grass.lib.gis as libgis
  File "/usr/lib/grass70/etc/python/grass/lib/gis.py", line 23, in 
_libs["grass_gis.7.0.4"] = load_library("grass_gis.7.0.4")
  File "/usr/lib/grass70/etc/python/grass/lib/ctypes_loader.py", line 55, in 
load_library
return self.load(path)
  File "/usr/lib/grass70/etc/python/grass/lib/ctypes_loader.py", line 71, in 
load
raise ImportError,e
ImportError: libgrass_datetime.7.0.4.so: cannot open shared object
file: No such file or directory


Did I forgot to set-up something or this is a bug?

Cheers,
Laurent
___
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] v.in.pygbif addon: Manual does not build

[Blumentrath, Stefan]

Hi again,

There seem to have  been other issues, which I tried to address with the help 
of an HTML validator.
Since that was quite helpful, I took the liberty to add the link to: 
https://validator.w3.org/
to https://trac.osgeo.org/grass/wiki/Submitting/Docs

Hope that is OK.

Cheers
Stefan




-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of 
Blumentrath, Stefan
Sent: 18. september 2016 23:29
To: Helmut Kudrnovsky <hel...@web.de>; grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

Thanks Helmut, Vaclav, Markus for your support.

Should be fixed now (by moving the import to "dev main()").
I would have liked to do it earlier but we had a failure on the server where I 
had the code...

Kind regards,
Stefan

-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Helmut 
Kudrnovsky
Sent: 13. september 2016 17:21
To: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

Markus Neteler wrote
> On Tue, Sep 13, 2016 at 4:52 PM, Helmut Kudrnovsky 

> hellik@

>  wrote:
>>>Thanks for your swift reply!
>>>
>>>In v.in.pygbif the import of pygbif is also done in a try-except
statement.
>>>
>>>Maybe the difference is that pyspatialite is installed on the build
system,
>> while pygbif is (naturally) not >(yet)?
> 
> Exactly...
> 
> root@osgeo6:/home/neteler# pip install pygbif
> bash: pip: command not found
> 
> How to get pip into this Debian box? (keeping the other 10 virtual 
> sites on the system intact) Will be easy but I am more RPM oriented...

apt-get install python-pip?



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/v-in-pygbif-addon-Manual-does-not-build-tp5285571p5285594.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

[Blumentrath, Stefan]

Thanks Helmut, Vaclav, Markus for your support.

Should be fixed now (by moving the import to "dev main()").
I would have liked to do it earlier but we had a failure on the server where I 
had the code...

Kind regards,
Stefan

-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Helmut 
Kudrnovsky
Sent: 13. september 2016 17:21
To: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

Markus Neteler wrote
> On Tue, Sep 13, 2016 at 4:52 PM, Helmut Kudrnovsky 

> hellik@

>  wrote:
>>>Thanks for your swift reply!
>>>
>>>In v.in.pygbif the import of pygbif is also done in a try-except
statement.
>>>
>>>Maybe the difference is that pyspatialite is installed on the build
system,
>> while pygbif is (naturally) not >(yet)?
> 
> Exactly...
> 
> root@osgeo6:/home/neteler# pip install pygbif
> bash: pip: command not found
> 
> How to get pip into this Debian box? (keeping the other 10 virtual 
> sites on the system intact) Will be easy but I am more RPM oriented...

apt-get install python-pip?



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/v-in-pygbif-addon-Manual-does-not-build-tp5285571p5285594.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
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] ubuntu gis policy

[Blumentrath, Stefan]

Thanks Martin,

Would be great if you could forward the mail, as I am not on that ml...

Cheers
Stefan

-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com] 
Sent: 16. september 2016 14:18
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] ubuntu gis policy

Hi Stefan,

2016-09-16 13:12 GMT+02:00 Blumentrath, Stefan <stefan.blumentr...@nina.no>:
> As recently also discussed on the QGIS mailinglist, packages from a 
> repository named "unstable" can get blocked by system administrators (who not 
> necessarily will take the time to try to understand what is behind all 
> applications), regardless if I as a user tell them that "unstable" actually 
> means "current release"...

I completely understand, and agree with your opinion. It's very confusing. Also 
from Debian point of view (experimental -> unstable -> testing -> stable). 
Please express your opinion on ubuntugis ml (or I can forward your message if 
you prefer). Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] ubuntu gis policy

[Blumentrath, Stefan]

Hei Martin,

Do you have any chance to influence the naming of the PPAs?

As recently also discussed on the QGIS mailinglist, packages from a repository 
named "unstable" can get blocked by system administrators (who not necessarily 
will take the time to try to understand what is behind all applications), 
regardless if I as a user tell them that "unstable" actually means "current 
release"...

Would be nice to have a more admin-friendly name there...

Cheers
Stefan

-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Martin 
Landa
Sent: 16. september 2016 13:03
To: GRASS users list ; GRASS developers list 

Subject: [GRASS-dev] ubuntu gis policy

Hi all,

recently ubuntugis maintainers changed their policy. This means that currently 
is used this workflow:

OSGeoLive nightly --> UbuntuGIS Testing --> UbuntuGIS Unstable --> UbuntuGIS 
Stable

What does it means for GRASS?

1) experimental packages (like Release Candidates) are uploaded to Testing PPA 
[1]
2) final version packages are uploaded to Testing and Unstable [2]
3) Stable PPA can contain older version [3]

For user who want to help with testing experimental packages: please use 
Testing PPA otherwise use Unstable (if you prefer up-to-date
version) or Stable PPA (you prefer stability - slightly older versions).

Martin

[1] https://launchpad.net/~ubuntugis/+archive/ubuntu/ubuntugis-testing
[2] https://launchpad.net/~ubuntugis/+archive/ubuntu/ubuntugis-unstable
[3] https://launchpad.net/~ubuntugis/+archive/ubuntu/ppa

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
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

[GRASS-dev] v.in.pygbif addon: Manual does not build

[Blumentrath, Stefan]

Hei,

Does anyone have an idea why the v.in.pygbif addon-manual does not build? I 
managed to install it through g.extension and it works fine.
The pygbif library is a dependency of v.in.pygbif. Therefore, I tried to align 
dependency handling (import) with the working solution in v.class.mlpy as 
another module with external dependencies. That obviously did not help, 
unfortunately.
Are error logs from the automatic builds available online somewhere I could 
check?

I have some uncommitted modifications for the module I like to commit. It would 
be great to fix the built of the manual in one go.

Thanks for helping in advance.

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

Re: [GRASS-dev] Separate sqlite database files for vector maps

[Blumentrath, Stefan]

Hei Sören,

I ran into this recently too, with lots of “Busy SQLite” warnings, when I tried 
to modify two or more vector maps in parallel.
So the work you are planning to do would be very much appreciated.

However, in order to not break existing modules like v.db.join, queries across 
SQLite DBs would have to be supported.
Here the “attach” keyword might be a starting point for required additions to 
e.g. v.db.join: http://sqlite.org/lang_attach.html

It is probably also necessary to think about how (or more precise where) tables 
are supposed to be handled which are not linked to a vector map... Will all 
non-map tables be saved in their own SQLite DB file?

Do you plan to store tables linked to additional layers in the same SQLite file 
as the vector map?

How would modules like db.tables or db.copy behave? What happens if you connect 
the attribute table of map a (or just table a) to map b?

Just some thoughts ...

Cheers
Stefan


From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Sören 
Gebbert
Sent: 9. september 2016 23:07
To: GRASS developers list 
Subject: [GRASS-dev] Separate sqlite database files for vector maps

Dear devs,
i would like to implement sqlite database support as separated file for each 
vector map. Similar to the dbf approach but with sqlite. Other databases are no 
option in my case.
The reasons for this approach are the following:

* The temporal vector algebra would hugely benefit from separated sqlite vector 
map files, since it can compute in parallel, no race condition or serial 
processing of database requests is required
* Vector maps can easily be moved between locations with full database content, 
no data loss. Simply the vector map directory must be archived
* Merging of mapsets is much easier, since the vector map sqlite databases 
don't need to be merged, only copied

This approach would be implemented in addition to all other existing approaches.

However, i don't know were to start with this, any hints or suggestions?

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

[GRASS-dev] Access current region in pygrass

[Blumentrath, Stefan]

Hi devs,

I am trying to access the Bbox of my current region in pygrass (GRASS 7.0.4), 
following examples here:
https://grass.osgeo.org/grass70/manuals/libpython/pygrass.gis.html#module-pygrass.gis.region.

Unfortunately, "north" returns always 1, for some reason I do not understand...

This is what I do:

>>> from grass.pygrass.gis.region import Region
>>> Region()
projection: 3 (Latitude-Longitude)
zone:   0
datum:  wgs84
ellipsoid:  wgs84
north:  75N
south:  60N
west:   15E
east:   6W
nsres:  1
ewres:  1
rows:   15
cols:   339
cells:  5085

>>> r = Region()
>>> r
projection: 3 (Latitude-Longitude)
zone:   0
datum:  wgs84
ellipsoid:  wgs84
north:  75N
south:  60N
west:   15E
east:   6W
nsres:  1
ewres:  1
rows:   15
cols:   339
cells:  5085

So, the region definition in my Python object "r" looks OK, but then
>>> r.north
1.0

Where I would expect to get 75.0 and
>>> r.get_bbox


I must be overlooking something pretty obvious... Any hint?

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

[GRASS-dev] New addon: v.in.pygbif from Code Sprint Bonn

[Blumentrath, Stefan]

Dear Code-sprinters (and others),

Thanks for the awesome event and the great time in Bonn!
It was really exciting and a lot of fun working together with all of you. The 
experience definitely - more than - compensated travel costs and conference fee!

With the kind support from Lucca and Vero, the v.in.pygbif addon I was working 
on in Bonn is now finally usable and committed to addons.
v.in.pygbif builds upon Helmuts v.in.gbif addon and adds the possibility to 
query and fetch species occurrence data directly from GBIF.
In fact, it is more or less a graphical frontend to the pygbif package 
(http://pygbif.readthedocs.io/en/latest/index.html), which thus is a dependency 
of v.in.pygbif.

The GBIF data which is provided in WGS84 is re-projected into the projection of 
the current location at import. Import of global occurrences is by default 
limited to current computational region. This limit can be skipped in latlon 
locations.
Here my question is: Should I allow for unlimited/restricted import also in 
other CRS with global application? If yes, could you point me to EPSG codes of 
CRS you like me to add?

v.in.pygbif offers most of the relevant filter options from pygbif. I did some 
more testing yesterday, but still not all options are fully tested (also 
because the content of the returns from GBIF API are hard to predict)...
Anyway, I just pushed v.in.pygbif to addons together with a basic 
documentation. So, I would be glad for any test and report of issues / 
enhancements.

Many thanks again to Lucca and Vero for extensive testing and help along the 
way.

Known toDo`s are:

-Code clean up (e.g. some lines are a bit long)

-Add a cleanup routing when the user cancels / kills the process

-Handle layers in input mask map

-Proper implement shell script output for matching of taxon names

I hope it is of use for some of you...

Kind regards,
Stefan

P.S.: I would wish that the GBIF API would also provide information about the 
coordinate precision, which should be available in GBIF. Unfortunately this 
information does not seem to be available through the GBIF API :(.


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

Re: [GRASS-dev] g.search.module: shell style output

[Blumentrath, Stefan]

Hi,

As a side note:
The shell script output of v.db.connect is not “parsable” like in g.region 
(n=...) either.
However, it is well formatted as a kind of table output...

Cheers
Stefan



From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Jachym 
Cepicky
Sent: 22. august 2016 22:43
To: Vaclav Petras 
Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] g.search.module: shell style output

Vasku,

IIRC, "-g" flag was introduced first time in 2007 for g.region module and only 
reason for taking "g" letter was, that "s" for "shell script" was taken (or 
some similar reason). AFAIK there was never defined official GRASS rule for 
using -g flag for parsable output as well as how the output should look like - 
people simple started to adopt it (like usually in GRASS).

Putting rule to developer guidelines for parsable output as well as promoting 
the "-g" flag for all modules would certainly be an option

Jachym

po 22. 8. 2016 v 4:39 odesílatel Vaclav Petras 
> napsal:
On Fri, Aug 19, 2016 at 2:15 AM, Jachym Cepicky 
> wrote:
Hi,

no special reason for not listing the module description too, just did not came 
to my mind

Thanks. Good to know.


Just do it [1]

While using the modified version, I actually realized that "shell script style" 
usually produces key-value pairs which can which can be evaluated by shell's 
eval or grass.script.parse_command. Not all modules comply with this, e.g. 
`g.extension -g` produces multiple key-values with same keys and order matters, 
so this must be parsed in a special way. The result is actually exactly the 
information g.search.modules is producing:

$ g.extension -g
...
name=v.habitat.dem
description=Calculates DEM derived characteristics of habitats.
keywords=vector,raster,terrain,statistics,sun,zonal statistics
name=v.in.gbif
description=importing of GBIF species distribution data
keywords=vector,geometry
`g.extension -l` produces list of modules in the same way as currently 
`g.search.modules -g` produces:

$ g.extension -l

v.habitat.dem
v.in.gbif
As a result, I don't know what to do with -g, at this point I would just 
replace the letter by -n (names only) or -s (short output with names only) and 
add -t for table output (that's in the attached patch). -g can go to renamed 
options for compatibility reasons for now.
For the future, we should try to keep in mind that g.extension and 
g.search.module should have unified interfaces and/or outputs. And more 
generally, we should define what -g "shell script style" means.


J

[1] https://www.youtube.com/watch?v=ZXsQAXx_ao0

čt 18. 8. 2016 v 20:32 odesílatel Vaclav Petras 
> napsal:
Hi Jachym,
the g.search.module -g flag (shell style output) outputs just names. Do you 
have a particular reason for it? My use case is something like that:

g.search.modules keyword="support" -g | sed -e "s/|[^|]*$//g" | sed -e 
"s/|/\t/g"
with the following desired output (name + keywords, description removed by sed):

g.versiongeneral,support,citing,copyright,version,license
t.supporttemporal,metadata,time
r.supportraster,metadata
r.support.statsraster,statistics
r.out.gdalraster,export
v.out.ogrvector,export,OGR
r3.supportraster3d,metadata,voxel
g.findetcgeneral,map management,scripts
v.externalvector,import,external,OGR,PostGIS
g.messagegeneral,support,scripts
g.tempfilegeneral,support,scripts
v.supportvector,metadata
r.externalraster,import,external

I can actually see that outputting just module names can be advantageous in 
some cases. But I want to get something like, so I can throw sed and grep on it:

v.support|vector,metadata|Updates vector map metadata.
If we permit change of the interface, I think -g could do the output above. 
This would make the -g output more like the others: same information as by 
default and with -j, so we can even consider it fixing a bug.

The current output with -g can be generated with some other flag. -n* for 
"names only" perhaps?
Best,
Vaclav

* https://lists.osgeo.org/pipermail/grass-dev/2016-August/081556.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Final Report

[Blumentrath, Stefan]

Hi Mayank,

Thanks for WebGRASS! I am glad we can test it and thanks also for fixing the 
compilation issue so fast!

For me it would be absolutely OK that www-users cannot browse the whole server 
for GRASS DBs. And that all WebGRASS users are forced to work in one DB might 
be almost a pluss - from the administrators perspective ;-).

What I really like about WebGRASS is the simplicity of installing it. No long 
configuration and settings to be changed many places. Fast compile and It runs!

A clear drawback however is the Google based authentication, which seems to be 
the only available authentication method at the moment. Esp. for internal 
server deployment that does not feel right. Se also: 
https://github.com/rashadkm/webgrass/issues/19

Another question is: does WebGRASS currently only allow for a single connection 
at a time?
I opened one login page in one browser, and then tried to access WebGRASS in 
parallel from another browser, but I got a Connection Refused error...
Is that intentional or a known limitation of the chosen approach? The main aim 
of the web-UI is to give several users easy-access to GRASS on a server, isn`t 
it?

Or is the concept that each user should start his/her WebGRASS session 
(WebGRASS does not require root permissions to start the server process)? Would 
not that lead to possible issues with port conflicts?

Cheers
Stefan


-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Yann
Sent: 16. august 2016 18:46
To: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] Final Report

Maybe not the right place to say, but the GRASS GIS data directory is not 
editable, so cannot change to another GRASSDATA directory name.

On 16/08/2016 02:10, Mayank Agrawal wrote:
> This is my last report of the GSoC project. I would like to thank 
> Rashad and Massimo, my mentors.
> Brief Description My project focussed on the development of web based 
> GUI for the Grass “WebGrass” where people can use Grass modules on 
> their data through a web browser without actually installing GRASS. 
> GRASS is running on a server. The user interface is built using wt web 
> toolkit.
> The state of the project before my GSoC Was not implemented but a proof of 
> concept was there.
> The addition that your project brought to the software A working 
> webapp. People can use data from their system and apply different modules and 
> get output. A Web based UI like GRASS and modules implementation.
> Whole "WebGrass" is a very big project for one gsoc and we try to 
> implement as much as possible.
> Things implemented- * Location and Mapset wizard
>   * UI of the modules
>   * Modules implementation like desktop grass (command line output also)
>   * Authorization of the user
>   * Input/output/processing of raster data
>   * display of raster data
>   * Input/output/processing of vector data
>
>  From this project, a official start of "WebGrass" is done and I hope 
> it will be useful for the people. This has been a very interesting and 
> learning experience. I learned a lot from my mentors. I hope this project 
> keeps on growing and will continue to contribute to this project.
> Links - Github - https://github.com/mayank33/webgrass/commits/gsoc2016 
> https://github.com/mayank33/webgrass/commits/auth
> Project Page - https://trac.osgeo.org/grass/wiki/GSoC/2016/WebGrass
> Images- first page
> second page
> Module UI
>
>
> Mayank Agrawal Lab for Spatial Informatics IIIT Hyderabad India
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

--
-
Yann Chemin
Address: 3 Toul Melin, 56400 Plumergat
Mobile: +33 (0)7 83 85 52 34

___
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

[GRASS-dev] Rendering of vector layers can be slow

[Blumentrath, Stefan]

Hi,

At the moment I am fixing and quality checking relatively larger vector 
datasets with some 100k areas, of which some are quite complex (sea area / 
coast line). That requires visual inspection of the data and thus repeated 
rendering at different scales.

In this context I am struggling with rendering speed in GRASS 7.0.4. I am 
working on a relatively powerful server with local data in native GRASS format.

In comparison, QGIS on my local laptop renders the same data from PostGIS 
significantly faster, even when fetched through a WLAN connection...

Any possibilities to speed up rendering of vector maps?

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

[GRASS-dev] GUI: copy command in Python or R syntax

[Blumentrath, Stefan]

Hei,

In the light of the ongoing GSoC projects (esp. Web-GRASS) and recent questions 
regarding python syntax for GRASS commands, I was wondering what you think 
about the idea to offer the option to copy the command from the GUI (using the 
"Copy"-button) in other syntax than command line (e.g. defined by a environment 
variable let`s say: GRASS_CMD_COPY= (shell, python, R))?

That would help novices like me to move to Python and if the Web-GIS GUI 
provides a jupyter interpreter, it might come in handy there too...

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

Re: [GRASS-dev] [GRASS GIS] #3060: Create location from command line using "r.in.gdal" and similar

[Blumentrath, Stefan]

Already possible. See: https://grass.osgeo.org/grass70/manuals/grass7.html

Von: grass-dev [grass-dev-boun...@lists.osgeo.org] im Auftrag von GRASS GIS 
[t...@osgeo.org]
Gesendet: Freitag, 10. Juni 2016 19:40
Betreff: [GRASS-dev] [GRASS GIS] #3060: Create location from command line using 
"r.in.gdal" and similar

#3060: Create location from command line using "r.in.gdal" and similar
-+-
 Reporter:  mankoff  |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:  7.0.5
Component:  Startup  |Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 I find that I am continually creating some new dummy location just so I
 can then create the actual location I want using {{{r.in.gdal}}}. I could
 maintain a global dummy location and use that, but it makes the code less
 portable when I share it with others. Therefore, I often do this:

 {{{
 rm -fR grass
 mkdir grass
 grass70 -c EPSG:4326 ./grass/latlon
 r.in.gdal -c input=/path/to/somefile.TIF location=foo output=tmp
 exit
 grass70 ./grass/foo/PERMANENT
 }}}

 I find it difficult to know what EPSG code I should use for somefile.TIF,
 because it reports many (see below), therefore it would be nice to create
 the location from outside of GRASS, but using GRASS. For example,

 {{{grass70 -c input=/path/to/somefile importer=r.in.gdal}}}

 {{{
 Coordinate System is:
 PROJCS["WGS 84 / UTM zone 33N",
 GEOGCS["WGS 84",
 DATUM["WGS_1984",
 SPHEROID["WGS 84",6378137,298.257223563,
 AUTHORITY["EPSG","7030"]],
 AUTHORITY["EPSG","6326"]],
 PRIMEM["Greenwich",0,
 AUTHORITY["EPSG","8901"]],
 UNIT["degree",0.0174532925199433,
 AUTHORITY["EPSG","9122"]],
 AUTHORITY["EPSG","4326"]],
 PROJECTION["Transverse_Mercator"],
 PARAMETER["latitude_of_origin",0],
 PARAMETER["central_meridian",15],
 PARAMETER["scale_factor",0.9996],
 PARAMETER["false_easting",50],
 PARAMETER["false_northing",0],
 UNIT["metre",1,
 AUTHORITY["EPSG","9001"]],
 AXIS["Easting",EAST],
 AXIS["Northing",NORTH],
 AUTHORITY["EPSG","32633"]]
 Origin = (444892.500,8690407.500)
 Pixel Size = (15.000,-15.000)
 }}}

--
Ticket URL: 
GRASS GIS 

___
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] GSoC 2016 - PyQt GRASS - Report 2

[Blumentrath, Stefan]

> Side question: do the parser rules include flags ? I thought they were only 
> available for options.

Actually, I have no idea. I just checked the add-ons I wrote, and saw that I 
only used them for options. I was not aware of this limitation...
Thanks for pointing that out...

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

Re: [GRASS-dev] GSoC 2016 - PyQt GRASS - Report 2

[Blumentrath, Stefan]

Hei,

And thanks for your work on the PyQT-GSoC project!

When it comes to possible GUI improvements, I am wondering if it would be 
feasible to take e.g. parser rules into account by means of either

a)  generating widgets depending on parser rules (if e.g. two flags are 
mutually exclusive, use radio button instead of two tick-boxes)

b)  making the GUI “interactive” (e.g. a flag and an option are mutually 
exclusive, grey out the option when the flag is set, and the other way around)

If it in principle would be possible to make the GUI more dynamic that would be 
nice. Here I am thinking of e.g. to be able to generate lists for selections or 
default values, from for example a python script that is run before the GUI 
opens... A use-case would be the i.ortho.* modules (which still have not been 
ported to G7), where for example the values stored in a camera file (which is a 
simple text file) would have to be read into the GUI, so users can edit camera 
definitions, camera exposure parameters ...

Nothing essential, but it might open some new possibilities...

Kind regards,
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Ondrej 
Pešek
Sent: 5. juni 2016 10:22
To: Vaclav Petras 
Cc: GRASS developers list 
Subject: Re: [GRASS-dev] GSoC 2016 - PyQt GRASS - Report 2

Hi,

2016-06-04 20:47 GMT+02:00 Vaclav Petras 
>:

the screenshots looks good. For the code, it might little bit too soon to judge 
it, but just keep in mind the need for design we talked about earlier. For some 
simple help, you can use pylint tool which will demand some code style. Start 
with the file tools/pylintrc.txt in the GRASS source code.


yes, I want to write there also some comments etc. And I'll try the pylint.


When I ran it for v.buffer I see you are using text edit / line edit for float 
even when it is not [multiple]. I think Qt has double spin box which you can 
use. In general, you don't have to fully follow the current look or behavior. 
If you think that something can be done in a better way, do it.

For example, this would be one thing we can reconsider. The shorter description 
(label or description field) shows as the name/label for a field while the 
longer description (description field) shows as a tooltip of the label. One 
improvement could be showing it as a tooltip for the input field as well (or 
perhaps in a completely different way).

I will consider it all. While coding I was experimenting, but everytime I 
considered that the original widget = the best widget. Thanks for tips, I will 
try it your way. And the tooltip version sounds good. Should I put the name and 
type (input=string) upper (where now is description) or on the right side (as 
in current version).

Thanks for tips and have a nice time,
Ondrej


[Image removed by 
sender.]

Bez virů. 
www.avast.com


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

Re: [GRASS-dev] GSoC 2016

[Blumentrath, Stefan]

Hei Mayank and Rashad,

And thanks for this very cool GSoC project!
Do you take some inspiration from RStudio Server? We use it and are quite happy 
with it. Nice features there are (for my taste) the editor, the console and 
git/svn integration? And also GRASS is most sexy with the command line at hand. 
But I can imagine that such things are not feasible within this project?...

Kind regards,
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Mayank 
Agrawal
Sent: 22. mai 2016 09:14
To: grass-dev@lists.osgeo.org
Subject: [GRASS-dev] GSoC 2016

Hi all,

I am Mayank Agrawal and I am a research student in Lab for Spatial Informatics 
in International Institute of Information Technology, Hyderabad,India. I am 
working on GRASS GIS project for GSoC 2016. My proposal is WebGrass, which will 
focus on the development of web based GUI for the Grass, where people can use 
Grass modules through a web browser without actually installing GRASS. GRASS 
will be running on a server. The user interface will be built using wt web 
toolkit.


Here
 is the Abstract.

Source code is hosted on Github and 
here is my fork under the 
branch gsoc2016.

Here is my first pull 
request

We are using 
Gitter
 for our communication.

This is the wiki on GRASS 
Trac.
And project WebGrass is running Here on server.




Sent with 
MailTrack
[Image removed by sender.]
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Added i.landsat8.swlst in grass-addons

[Blumentrath, Stefan]

Hi again,

I just pushed a new addon ("i.landsat8.qc") to addons svn.
i.landsat8.qc reclassifies Landsat8 QA band according to a user defined filter 
for bit pattern representing unacceptable quality pixels. It implements 
basically the procedure mentioned below...

Any feedback is welcome...

Kind regards,
Stefan

-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of 
Blumentrath, Stefan
Sent: 10. mai 2016 09:57
To: Nikos Alexandris <nikos.alexand...@unige.ch>; Vaclav Petras 
<wenzesl...@gmail.com>
Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] Added i.landsat8.swlst in grass-addons

Another issue I came across it that currently, a possibly existing user mask 
will be simply overwritten, while it might be more friendly to backup the user 
mask before and restore it after the module finished... However, in order to 
simplify the module a bit, an option might be to move the masking part out of 
the module, and probably write something like this: 
https://grass.osgeo.org/grass70/manuals/i.modis.qc.html for Landsat, if that 
does not exist yet(?). Seems you thought about it already?
Based on Markus tutorial 
(http://courses.neteler.org/processing-landsat8-data-in-grass-gis-7/#Applying_the_Landsat_8_Quality_Assessment_%28QA%29_Band)
 and the info here http://landsat.usgs.gov/qualityband.php that should be a 
quite doable job. If no landsat bitpattern module exists I might be able to 
volunteer...
The idea would be something like this: extract raster values from QA band, loop 
over those values, compare the bit pattern representation of the integer values 
with acceptable bit patterns defined by the user, add the result of the 
comparison to r.reclass rules, and finally reclassify the QA band...

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

Re: [GRASS-dev] Added i.landsat8.swlst in grass-addons

[Blumentrath, Stefan]

Hi Nikos,

There are no real benefits from removing the kelvin_to_celsius function except 
for that code is a few lines shorter and the function is no longer used (plus 
that it is unlikely that you will be using it in the module in future). But the 
same applies probably to the "copy" helper function and the other stuff I just 
commented out could be removed too I guess, but I am not educated as a 
programmer. So others are much more qualified to comment on coding styles...

However, now I also had a closer look at the output of i.landsat8.swlst from a 
methodological point of view. Here it seems that - at least in my case of the 
city of Oslo - the difference between land-cover-corrected-LST and not 
land-cover-corrected-LST (I used land cover type 70 as a constant which has an 
average emissivity value) is almost insignificant (~ +- 1 degree celsius). The 
max/min differences were between -20 and +20 degrees Celsius, but these values 
appeared only at the boundary of the LST maps. Within the scenes differences 
were never > +-5 degree and very rarely > +-2.
Given the amount of data and computation required to incorporate land cover 
effects, you might consider to make a land cover map optional and just use a 
constant in the map calculator expression if no landcover map is provided...?

Another issue I came across it that currently, a possibly existing user mask 
will be simply overwritten, while it might be more friendly to backup the user 
mask before and restore it after the module finished... However, in order to 
simplify the module a bit, an option might be to move the masking part out of 
the module, and probably write something like this: 
https://grass.osgeo.org/grass70/manuals/i.modis.qc.html for Landsat, if that 
does not exist yet(?). Seems you thought about it already?
Based on Markus tutorial 
(http://courses.neteler.org/processing-landsat8-data-in-grass-gis-7/#Applying_the_Landsat_8_Quality_Assessment_%28QA%29_Band)
 and the info here http://landsat.usgs.gov/qualityband.php that should be a 
quite doable job. If no landsat bitpattern module exists I might be able to 
volunteer...
The idea would be something like this: extract raster values from QA band, loop 
over those values, compare the bit pattern representation of the integer values 
with acceptable bit patterns defined by the user, add the result of the 
comparison to r.reclass rules, and finally reclassify the QA band...

But all in all the results look pretty good, which you could see here: 
http://urban.nina.no/layers/geonode%3Alc81980182015183lgn00_lst and here: 
http://urban.nina.no/layers/geonode%3Alc81980182015183lgn00_lst_const_lc if our 
GeoNode worked as it should...

Kind regards,
Stefan



-Original Message-
From: Nikos Alexandris [mailto:nikos.alexand...@unige.ch] 
Sent: 9. mai 2016 16:31
To: Vaclav Petras <wenzesl...@gmail.com>
Cc: Nikos Alexandris <n...@nikosalexandris.net>; Blumentrath, Stefan 
<stefan.blumentr...@nina.no>; grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] Added i.landsat8.swlst in grass-addons

* Vaclav Petras <wenzesl...@gmail.com> [2016-05-08 20:10:46 -0400]:

>On Sat, May 7, 2016 at 5:14 PM, Nikos Alexandris 
><n...@nikosalexandris.net>
>wrote:
>
>> -The k-flag (keep current computational region) is invers to GRASS
>>> standards. Maybe better to switch the behavior?
>>>
>>
>> Not sure.  It's kind of related to the #1 mistake everyone does, 
>> forget setting the right region extent.  So, I'd thought of letting 
>> the module operate on the whole scene.
>>
>
>Then really all GRASS modules should be changed.

:-) -- Let's change'm all!

I am joking, of course.  Will alter the behaviour in the module.

>
>>
>> Do we have a reference for this ("GRASS standards") or you mean the 
>> "common" behaviour of most modules?
>
>
>No. Perhaps we need another Submitting page on Trac or perhaps just 
>adding a best practice to the main Submitting page.

Yep!

Cheers, Nikos

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

Re: [GRASS-dev] Added i.landsat8.swlst in grass-addons

[Blumentrath, Stefan]

Dear Nikos,



I just tested your i.landsat8.swlst module. Cool stuff!



During my experiments I ran into one issue and identified some (minor) room for 
speed-ups (mainly replacing g.copy with g.rename). I did not do a full code 
review but made some suggestions in a pull request on github. I tested all 
changes and they seem to work fine.



Some other things I noticed beyond my changes:

-For me the manual did not build locally (meaning it was not available 
in the GUI)

-Given the fact that the FROM-GLC data has not been updated for a while 
(if I did not get the link wrong), I would encourage users to provide their own 
land cover map, possibly reclassified from topographic maps. The only one 
available at http://data.ess.tsinghua.edu.cn/ for my scene was not only a 
couple of years old, but also quite clowdy in addition.

-The k-flag (keep current computational region) is invers to GRASS 
standards. Maybe better to switch the behavior?

-The GUI would – for my taste – benefit from splitting the options over 
different tabs (guisection). Now most options and flags end up in “optional” 
which makes it a bit confusing for newcomers to see what is input and what 
output...



Anyway, great tool!



Cheers

Stefan




From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Vaclav 
Petras
Sent: 20. april 2016 16:19
To: Nikos Alexandris 
Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] Added i.landsat8.swlst in grass-addons


On Wed, Apr 20, 2016 at 9:54 AM, Nikos Alexandris 
> wrote:
I hope I didn't do anything wrong in adding this.  Due to lack of time,
I didn't check if all is well.  Please, let me know in case I overlooked
something that might hinder the normal workflow in the addons
repository.

It seems that it's fine. The online manual page is compiled and you Submitting 
Python in your TODO. Only some pictures are missing in manual page.

https://grass.osgeo.org/grass70/manuals/addons/i.landsat8.swlst.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] why is v.build.all (and many others) a windows batch file and not an executable?

[Blumentrath, Stefan]

Hi,

Seems a bit like an edge case with shell scripts on Windows...

Anyway, what about using a script to do the replacement?
Something like (did not test the details):

scripts=$(ls OSGeo4W/apps/grass/grass-7.0.3/scripts/*.py | sed 's/.\{4\}$//')
cp MY_OLD_GRASS_6_SCRIPT.sh MY_NEW_GRASS_7_SCRIPT.sh

for s in $scripts
do
cat MY_NEW_GRASS_7_SCRIPT.sh | sed "s|$s|python 
OSGeo4W/apps/grass/grass-7.0.3/scripts/$s.py|g" > MY_NEW_GRASS_7_SCRIPT.sh.tmp
mv MY_NEW_GRASS_7_SCRIPT.sh.tmp MY_NEW_GRASS_7_SCRIPT.sh
done

Cheers
Stefan


-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Markus 
Neteler
Sent: 30. april 2016 23:32
To: GRASS developers list 
Subject: Re: [GRASS-dev] [GRASS-user] why is v.build.all (and many others) a 
windows batch file and not an executable?

(moved temporarily here for catching expert answers, then I'll transfer the 
result to grass-user to avoid cross-posting)

The point is that the user wants to run without extra hassle (parameter updates 
are ok of course) existing G6 scripts in a G7 session on Windows:

--- start fwd ---
On Sat, Apr 30, 2016 at 10:53 AM, Bartolomei.Chris  wrote:
> Ok (I guess) but this causes severe problems running shell scripts that call 
> out the GRASS modules ... there is no way of knowing which modules are 
> compiled executables (which run fine from the shell script) and which ones 
> are Windows Batch files (which DON'T run when called from a script) ... 
> unless you run the script and figure out which modules make it crash.  If you 
> look in the bin directory, you'll see a mix of both ... for example r.mask, 
> v.build.all and v.db.addcolumn are Windows Batch files which you can''t run 
> from a shell script - you have to add the "python {path to 
> script}/{script}.py" to run it whereas in the same bin directory v.build, 
> v.clean, r.what, etc are compiled executables.
> This is really really (really) bad.  There are a lot of legacy shell scripts 
> that will need extensive rewriting for which there are no resources to do. 
> It's bad enough that msys is gone, the topology is no longer valid (have to 
> update all data), a large amount of the module syntax options have changed, 
> and so on ... for me all of this grief is because v.net doesn't snap points 
> to the network and the fix (in v7) won't be ported to v6.4.4  They 
> modules should all be compiled executables so legacy shell scripts users have 
> can run them ... please make at least ONE thing about this "upgrade" 
> semi-straightforward. It's been a nightmare.
--- end fwd ---

I hope someone can give suggestions here.

thanks
Markus
___
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] is it time to release GRASS71?

[Blumentrath, Stefan]

Hi,

A user perspective on this discussion:

I would be very, very keen on:
- this: https://trac.osgeo.org/grass/ticket/2579 (as well as the simple python 
import that is under development) and
- this: https://grasswiki.osgeo.org/wiki/ISO/INSPIRE_Metadata_Support and
- this: https://trac.osgeo.org/grass/ticket/2750 and 
- this: https://trac.osgeo.org/grass/browser/grass/trunk/temporal/t.rast.what 
and
- ...

Personally, I perceive GRASS as stable by design and  I very much share Markus 
N.`s view on GRASS being "my reliable number cruncher".

Backwards compatibility is less of an issue for me, as everybody can update for 
free. A significant gain in storage, performance and functionality weighs much 
more for me...

Summarizing: yes reliability is a very important quality of GRASS GIS. Yet, if 
you feel ready for a release I will embrace the new version (independent from 
its number), and am definitely willing contribute with testing release 
candidates... 

Kind regards,
Stefan




-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Markus 
Metz
Sent: 8. mars 2016 22:36
To: Moritz Lennert 
Cc: Martin Landa ; GRASS developers list 

Subject: Re: [GRASS-dev] is it time to release GRASS71?

On Mon, Feb 29, 2016 at 11:39 AM, Moritz Lennert  
wrote:
> On 28/02/16 00:02, Markus Metz wrote:
>>
>> On Thu, Feb 25, 2016 at 8:56 PM, Markus Neteler  wrote:
>>>
>>>
>>> On Feb 25, 2016 5:05 PM, "Vaclav Petras"  wrote:



 On Thu, Feb 25, 2016 at 10:00 AM, Martin Landa 
 
 wrote:
>
>
> this system is used also by QGIS, MapServer, moreover it's part of 
> GRASS history (with one exception - 6.3). I have no strong option 
> about that. I would say let's follow our tradition to use odd 
> numbers for dev versions. Martin




 The fact that other OSGeo projects are using it is quite 
 convincing. But anyway, I don't see a point in simply skipping a version 
 number.
>>>
>>>
>>> Well, we are using 7.1 visibly for so long as unstable/dev version.
>>> So it sounds perfectly fine to call the result 7.2.
>>
>>
>> Please be aware that because of many partial backports, relbr70 is 1) 
>> unstable (as was G6.4) and is in some regards less reliable than 
>> trunk.
>
>
> I would say this partly depends on the notion of stable and unstable. 
> Stable does not mean perfect. It just means that nothing significant 
> is going to change, or ? trunk can sometimes be in a non-functional 
> state while someone is introducing new functionality. Normally, stable 
> should never be in a non-functional state and when it is, then this is a bug 
> and will be fixed.

Assuming stable means no major changes in the code base will happen, a 
releasebranch should be stable and at the same time become more robust (bugs 
being eliminated with every z release with GRASS x.y.z).
>
>> Stable typically means backport only of critical bugxfixes.
>
>
> I do completely agree with this, and I agree that we have not been 
> careful enough and have succombed to the temptation of backporting 
> some new features. That should definitely be a no-go. Once a release 
> is out, only bug fixes should go in, no new features. If we want new 
> features to be available to users we have to release more often, 
> possibly by releasing development snapshots directly from trunk from time to 
> time.

The GRASS release policy is described in the GRASS release roadmap [0]. A 
release branch is identified by its major and minor version number. According 
to the GRASS release policy, a release branch should become more robust (have 
less bugs) with every revision. That implies that no new features are 
backported.

Following this policy would imply more frequent releases of more robust GRASS 
versions, and earlier availability of new features in a release branch because 
developers would (should) push for trunk being released as a new release branch 
because nice new features are not allowed to be backported.

>
>> Therefore, in order to stick with the odd/even numbering meaning, G7 
>> should have been released immediately as G71 to indicate a dev 
>> version. Not unstable (the code base will remain stable) but a dev 
>> version (testing new features). According to the odd/even numbering 
>> scheme, current trunk should be released as G7.3 and not G7.2 because 
>> it introduces new features.
>
Considering the history of GRASS GIS of the last 6 years, in particular 6.4, a 
GRASS GIS release x.y.0 means "new features, expect bugs". A GRASS GIS release 
x.y.z means "new features, hopefully less bugs than in x.y.(z-1), but there can 
be new bugs".

Markus M

[0] 
https://grasswiki.osgeo.org/wiki/Release_Roadmap#What_are_these_release_numbers.3F

Re: [GRASS-dev] installing wx.metadata fails

[Blumentrath, Stefan]

Hei,

I had similar issues recently.

Just now I tested again (fresh code for both GRASS 71 and AddOns) and the 
metadata tools seem to work.
However, I get still get an error message on compile:

[...]
GISRC=/usr/local/grass-7.1.svn/demolocation/.grassrc71 
GISBASE=/usr/local/grass-7.1.svn 
PATH="/usr/local/grass-7.1.svn/bin:/usr/local/grass-7.1.svn/bin:/usr/local/grass-7.1.svn/scripts:$PATH"
 
PYTHONPATH="/usr/local/grass-7.1.svn/etc/python:/usr/local/grass-7.1.svn/gui/wxpython:$PYTHONPATH"
 
LD_LIBRARY_PATH="/usr/local/grass-7.1.svn/bin:/usr/local/grass-7.1.svn/bin:/usr/local/grass-7.1.svn/scripts:/usr/local/grass-7.1.svn/lib:/usr/local/grass-7.1.svn/lib:"
 LC_ALL=C g.parser -t g.gui.metadata.py | sed s/\"/\"/g | sed 
's/.*/_("&")/' > 
/usr/local/grass-7.1.svn/locale/scriptstrings/g.gui.metadata_to_translate.c
/bin/sh: 1: cannot create 
/usr/local/grass-7.1.svn/locale/scriptstrings/g.gui.metadata_to_translate.c: 
Directory nonexistent
make[1]: 
[/usr/local/grass-7.1.svn/locale/scriptstrings/g.gui.metadata_to_translate.c] 
Error 2 (ignored)
make[1]: Leaving directory 
`/data/src/grass71-addons/gui/wxpython/wx.metadata/g.gui.metadata'

Kind regards,
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Paulo 
van Breugel
Sent: 23. februar 2016 09:58
To: GRASS developers email list 
Subject: [GRASS-dev] installing wx.metadata fails

I just tried to update the wx.metadata addon using g.extension (on grass 7 
master), resulting in the error below:

(Tue Feb 23 09:55:19 2016)
g.extension extension=wx.metadata url=
WARNING: Extension  already installed. Re-installing...
Fetching  from GRASS GIS Addons repository (be patient)...
Compiling...
Traceback (most recent call last):
  File "/tmp/grass7-paulo-8596/tmpWf3irR/wx.metadata/scripts
/db.csw.admin", line 127, in 
from mdlib.cswutil import *
ImportError: No module named mdlib.cswutil
make[1]: *** [db.csw.admin.tmp.html] Error 1
Traceback (most recent call last):
  File "/tmp/grass7-paulo-8596/tmpWf3irR/wx.metadata/scripts
/g.gui.cswbrowser", line 22, in 
from mdlib.cswlib import CSWBrowserPanel,
CSWConnectionPanel
ImportError: No module named mdlib.cswlib
make[1]: *** [g.gui.cswbrowser.tmp.html] Error 1
Traceback (most recent call last):
  File "/tmp/grass7-paulo-8596/tmpWf3irR/wx.metadata/scripts
/g.gui.metadata", line 43, in 
from mdlib import mdgrass
ImportError: No module named mdlib
make[1]: *** [g.gui.metadata.tmp.html] Error 1
Installing...
/usr/bin/install: cannot stat ‘/tmp/grass7-paulo-8596/tmpW
f3irR/wx.metadata/docs/html/db.csw.admin.html’: No such
file or directory
make[1]: *** [install] Error 1
/usr/bin/install: cannot stat ‘/tmp/grass7-paulo-8596/tmpW
f3irR/wx.metadata/docs/html/g.gui.cswbrowser.html’: No
such file or directory
make[1]: *** [install] Error 1
/usr/bin/install: cannot stat ‘/tmp/grass7-paulo-8596/tmpW
f3irR/wx.metadata/docs/html/g.gui.metadata.html’: No such
file or directory
make[1]: *** [install] Error 1
make: *** [installsubdirs] Error 2
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.bioclim output integer maps

[Blumentrath, Stefan]

Hi,

That might be a reasons to think about a general, unified option regarding 
integer, floating point or double output.
Markus`s solution in r.bioclim could be very useful in other modules too. Esp. 
those that produce a lot of data and default to double. Here I think e.g. about 
r.sun which can produce a lot of layers, where the digits often are 
insignificant. I know such an option is not especially easy to implement and 
would require quite some changes.

However, maybe it is worth it to think in that direction e.g. for GRASS 8?

Kind regards,
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Paulo 
van Breugel
Sent: 22. februar 2016 09:18
To: Markus Metz 
Cc: GRASS developers list 
Subject: Re: [GRASS-dev] r.bioclim output integer maps



On Sun, Feb 21, 2016 at 12:20 PM, Markus Metz 
> wrote:
On Wed, Feb 10, 2016 at 2:39 PM, Paulo van Breugel
> wrote:
>
>
> On Wed, Feb 10, 2016 at 1:16 PM, Markus Neteler 
> > wrote:
>>
>>
>> On Feb 10, 2016 12:03 PM, "Paulo van Breugel" 
>> >
>> wrote:
>> > On Wed, Feb 10, 2016 at 10:26 AM, Markus Neteler 
>> > >
>> > wrote:
>> >> I guess for the compatibility with WORLDCLIM (have added that, too).
>> >> The other Markus will know better :-)
>> >
>> > I still think it is really preferable to not round these numbers, but
>> > leave that to the user (perhaps include it as an option though). But in any
>> > case, the text you added makes things more explicit / clear, which is most
>> > important.
>>
>> Python patches are welcome!
>
>
> I could give that a try (wasn't difficult if I remember well), but I rather
> first hear from Markus (the other ;-) whether he thinks it is something that
> could/should be changed

It could be changed, but I am not sure if it is worth the trouble.
When I wrote the module, I used bioclim from worldclim as test suite
which also uses integer. That means when using worldclim as input, the
default settings produce output identical to worldclim's bioclim maps.

Instead of leaving the rounding to the user, you could also leave the
conversion to fp to the user. I prefer to have rounding to integer
because 1) users will not get the false impression of high accuracy
with floating point values,2) it saves a lot of disk space.

OK, that is clear. I think the most important is that this is now clearly 
explained in the manual pages.


Markus M

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

Re: [GRASS-dev] grass addons metadata temporary not available

[Blumentrath, Stefan]

Hi Martin,

Thanks for your reply. I shall try that.
I just reinstalled GRASS 7.1, but maybe I have to reinstall from a clean source 
and remove the existing GRASS settings / addons.

I shall report back...

Cheers
Stefan 

-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com] 
Sent: 17. februar 2016 13:39
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>; Matej Krejci 
<matejkre...@gmail.com>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] grass addons metadata temporary not available

Hi,

2016-02-17 13:33 GMT+01:00 Martin Landa <landa.mar...@gmail.com>:
>> Do you by chance have any idea what the reason might be that it does not 
>> work for me?
>> See: 
>> http://osgeo-org.1560.x6.nabble.com/problem-installing-wx-metadata-fr
>> om-g-extension-tp5244519p5249845.html
>> Or how I might solve the issue if it is only local...

what is exact problem do you have? I installed wx.metadata

g.extension wx.metadata

and run

g.gui.metadata

the GUI dialog pops up without any error. Do you have fresh installation? 
Probably clean up your .grass7/addons before installing.
Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass addons metadata temporary not available

[Blumentrath, Stefan]

Hei Martin,

Thanks for your work on the wx.metadata installation.

Do you by chance have any idea what the reason might be that it does not work 
for me?
See: 
http://osgeo-org.1560.x6.nabble.com/problem-installing-wx-metadata-from-g-extension-tp5244519p5249845.html
Or how I might solve the issue if it is only local...

Kind regards,
Stefan 

-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Martin 
Landa
Sent: 17. februar 2016 12:18
To: GRASS users list ; GRASS developers list 

Subject: Re: [GRASS-dev] grass addons metadata temporary not available

Hi,

2016-02-16 16:46 GMT+01:00 Martin Landa :
> We know about it. The building server (geo102) is down. I hope that 
> the server will be running soon. Martin

it's back. Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
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] problem installing wx.metadata from g.extension

[Blumentrath, Stefan]

Hi,

I tried building from source after installing the dependencies listed here:
https://grasswiki.osgeo.org/wiki/ISO/INSPIRE_Metadata_Support#Requirements_and_installation
plus python-reportlabs.

But I get an error for g.gui.metadata saying
“Traceback (most recent call last):
  File "/usr/local/grass-7.1.svn/scripts/g.gui.metadata", line 43, in 
import mdgrass
ImportError: No module named mdgrass
make: *** [g.gui.metadata.tmp.html] Error 1
rm g.gui.metadata.tmp.html”

I had a look at the g.gui.metadata.py but have no idea how to fix that...

It did compile after I changed line 43 in g.gui.metadata.py to:
set_path(modulename='g.gui.metadata', dirname='mdlib', 
path='/usr/local/grass-7.1.svn/scripts/')

However, when I then try to run the module I get:
“Traceback (most recent call last):
  File "/usr/local/grass-7.1.svn/scripts/g.gui.metadata", line 43, in 
set_path(modulename='g.gui.metadata', dirname='mdlib', 
path='/usr/local/grass-7.1.svn/scripts/')
  File "/usr/local/grass-7.1.svn/etc/python/grass/pygrass/utils.py", line 308, 
in set_path
return set_path(modulename=modulename, dirname=dirname, path=path)
  File "/usr/local/grass-7.1.svn/etc/python/grass/script/utils.py", line 370, 
in set_path
"(current dir '%s')." % (pathname, os.getcwd()))
ImportError: Not able to find the path 'g.gui.metadata/mdlib' directory 
(current dir '/data/home/stefan').”

I remember seeing that error before: 
http://osgeo-org.1560.x6.nabble.com/Installing-wx-metadata-fails-td5232359.html 
so maybe someone has a quick fix at hand?

Cheers
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Vaclav 
Petras
Sent: 12. januar 2016 03:49
To: Martin Landa 
Cc: GRASS developers list 
Subject: Re: [GRASS-dev] problem installing wx.metadata from g.extension


On Mon, Jan 11, 2016 at 9:54 AM, Martin Landa 
> wrote:
2016-01-11 15:44 GMT+01:00 Matej Krejci 
>:
> thanks for update wiki page, I have updated (r67551) dependency file for
> checking dependency before installation.

it would be nice to reduce number of dependencies for compiling to the
minimum. It's the reason why this extension is not available for
Windows [1]. Most of dependencies are need for running the tool but
for compiling. Now they are checked before compiling which should be
changed in the future.

Agreed, there is an post about it here:

https://lists.osgeo.org/pipermail/grass-dev/2015-February/073734.html
There is now even more examples in addons how this can be done.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] PostgreSQL as default backend for all users?

[Blumentrath, Stefan]

Hi,

I am looking into PostgreSQL as an alternative for SQLite at the moment. 
However I am missing an option to make PostgreSQL the default DB backend for 
all users on a Server installation of GRASS GIS. The db.connect manual says 
connection parameters are stored in the mapset`s VAR file. Did I overlook 
something?

What I had in mind was probably a setting in e.g. a file 
$HOME/.grass7/dbconnect_default which may contain e.g.:
driver=pg
database=MY_DATABASE
schema=$MAPSET
group=MY_GROUP_USER
which could be deployed in user`s home (and may also be useful for single users 
who want to use PG as backend).

But that would probably also require changes to the initialization of the DB 
backend, if the default behavior (meaning SQLite) should be overwritten?

Would you consider this worth an enhancement ticket?

Kind regards,
Stefan

P.S.: Sorry that I am not able to contribute with code properly...


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

Re: [GRASS-dev] grouping most important parameters in a 'main' tab

[Blumentrath, Stefan]

Agreed.

Such a “main” tab maight also be helpful to generate the GUI of the 
QGIS-GRASS-Plugin more automatically so that  module updates can be passed more 
easily to QGIS. I contributed to update of the module files (.qgm) which aimed 
exactly at reducing complexity (though some modules got split up there e.g. 
based on layer geometry types). As Paulo says, not always easy to determine 
what is “main”, but doable and a bit of work too...

For the possible benefits regarding the QGIS integration that means 
practically, that the workload of module parameter simplification is passed to 
GRASS devs...

Cheers
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Paulo 
van Breugel

I am all in favour of this. Easier for the casual user and it means less clicks 
for probably most user-cases. I guess it will not always be easy to determine 
what are the most important / common parameters, but for this module I think 
you got them all right under the main tab.

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

Re: [GRASS-dev] STVDS where only attributes change over time?

[Blumentrath, Stefan]

Hi Sören,

Thanks for your reply.
I shall think about a temporal DB and how it might be used in order to interact 
with TGRASS...

The GRASS data explorer for QGIS looks indeed cool...

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

[GRASS-dev] STVDS where only attributes change over time?

[Blumentrath, Stefan]

Hi devs,

The TGRASS concept is a great enhancement to GRASS which already proved it`s 
usefulness for my daily work with raster data in many cases. Now I am 
discovering the vector part of it. If I understand correctly, the concept for 
vector data is identically to the raster part, namely using whole, time stamped 
vector datasets.

In long term monitoring, where time series play a central role, one often has a 
fixed location and only attributes are updated (as it is the case in e.g. 
detailed vegetation studies, temperature logger, wildlife camera traps...). In 
such cases having geometries for each registration of data would lead to 
significant redundancy of data and unnecessary computation (building topology, 
spatially matching each map...).

My question is now, how much work would it cause to introduce a new type of 
space time dataset with fixed geometries and a linked attribute table which 
contains the temporal information along with (variable) attribute values 
("Space Time Vector Attribute Datasets")?

What would have to be changed?

Is it more appropriate to stick to database solutions (e.g. PostGIS) or R (or a 
combination of the two) and eventually fetch data from STRDS?

Kind regards,
Stefan
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] wx.metadata ready for testing

[Blumentrath, Stefan]

Hi Martin,

Thanks for following this up. I am travelling at the moment. Shall try it once 
I am back...

Cheers
Stefan

-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com] 
Sent: 28. oktober 2015 23:46
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: Paulo van Breugel <p.vanbreu...@gmail.com>; GRASS developers list 
<grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] wx.metadata ready for testing

2015-10-28 23:21 GMT+01:00 Martin Landa <landa.mar...@gmail.com>:
> please try out to remove previous lib version:
>
> rm -rf ~/.grass7/addons/etc/wx.metadata/
>
> and then
>
> g.extension wx.metadata
>
> Is it better? Ma

also try fresh svn trunk, r66637 should help. Ma

>>
>> 2015-10-07 12:30 GMT+02:00 Paulo van Breugel <p.vanbreu...@gmail.com>:
>>
>> I tried fresh installation (trunk) in installed to /usr/local. I cannot 
>> reproduce any of reported errors. Please send me related environmental 
>> variables:
>>
>> env | grep GIS
>>
>> env | grep GRASS
>>
>> ?
>>
>> Ma
>>
>>> ware/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata
>>>> >>> /usr/local/grass7/grass-7.1.svn/error.log
>>>> >
>>>> > make[1]: Entering directory
>>>> >
>>>> > `/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'
>>>> >
>>>> > if [ "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata" != ""
>>>> > ] ; then
>>>> > GISRC=/usr/local/grass7/grass-7.1.svn/demolocation/.grassrc71
>>>> > GISBASE=/usr/local/grass7/grass-7.1.svn
>>>> >
>>>> > PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:$PATH"
>>>> >
>>>> > PYTHONPATH="/usr/local/grass7/grass-7.1.svn/etc/python:/usr/local/grass7/grass-7.1.svn/gui/wxpython:$PYTHONPATH"
>>>> >
>>>> > LD_LIBRARY_PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:/usr/local/grass7/grass-7.1.svn/lib:/usr/local/grass7/grass-7.1.svn/lib::/lib:/usr/local/lib:/usr/local/gdal/lib"
>>>> > LC_ALL=C /usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata
>>>> > --html-description < /dev/null | grep -v '\|' > 
>>>> > g.gui.metadata.tmp.html ; fi
>>>> >
>>>> > Traceback (most recent call last):
>>>> >
>>>> >   File "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata",
>>>> > line 35, in 
>>>> >
>>>> > import mdgrass
>>>> >
>>>> > ImportError: No module named mdgrass
>>>> >
>>>> > make[1]: *** [g.gui.metadata.tmp.html] Error 1
>>>> >
>>>> > rm g.gui.metadata.tmp.html
>>>> >
>>>> > make[1]: Leaving directory
>>>> >
>>>> > `/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'
>>>> >
>>>> >
>>>> >
>>>> >>
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Martin Landa
>>>> http://geo.fsv.cvut.cz/gwiki/Landa
>>>> http://gismentors.cz/mentors/landa
>>>
>>>
>>
>>
>>
>> --
>> Martin Landa
>> http://geo.fsv.cvut.cz/gwiki/Landa
>> http://gismentors.cz/mentors/landa
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa



--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] no grass plugin in qgis installed from osgeo4w

[Blumentrath, Stefan]

Hei Vero,

Did you go through the advanced install in OSGeo4W? There you should have the 
“qgis-grass-plugin7” (and probably also necessary “qgis-grass-plugin-common”) 
available.

For the shell issue you can have a look here:
https://lists.osgeo.org/pipermail/grass-dev/2014-October/071294.html

Is OSGeoLive DVD/USB an alternative for you? That may help to avoid a lot of 
trouble (esp. when prepared and provided by you), caused e.g. by user names 
with non-ascii characters, missing-dlls access rights…

Cheers
Stefan


From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of 
Veronica Andreo
Sent: 27. oktober 2015 14:24
To: grass-dev 
Subject: [GRASS-dev] no grass plugin in qgis installed from osgeo4w

Hi devs,

me again, sorry...

So, this comes from the previous email, but it is a different issue...

I also got qgis stable (2.12) from osgeo4w 32bits installer and there seems to 
be NO grass plugin installed nor available in the plugin list.

There's also NO grass tools in Processing and I have the latest version 
avilable. I guess I missed selecting some other things in the installation 
process, but don't know what.

Any instruction is welcome! :)

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

Re: [GRASS-dev] grass in windows

[Blumentrath, Stefan]

Hi again,

The following threads can possibly be additional sources for inspiration:
http://www.qgis.nl/2014/04/22/qgis-in-de-klas-onder-windows/?lang=en
https://lists.osgeo.org/pipermail/qgis-user/2015-February/030837.html
http://linfiniti.com/2011/05/building-custom-qgis-installers-for-windows/


From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of 
Veronica Andreo
Sent: 27. oktober 2015 14:03
To: grass-dev 
Subject: [GRASS-dev] grass in windows

Hi devs :)

I'm a grass-in-Linux user but have to teach a grass course to windows users in 
two weeks... so, i used my mum's pc (64 bits, with windows 7) to test the stuff

I was recomended to install 32 bits version from osgeo4w 
(https://trac.osgeo.org/osgeo4w/). So, I downloaded, run as administrator, 
selected only grass stable (grass702-rc1) and qgis stable (2.12). I left the 
rest as it was by default, accepted all the dependencies and let the thing 
download and install. Then, reboot because it asked for it. Starting grass from 
desktop icon works fine, all fine, except that the windows shell is so 
limited... no going back to previous command, no tab completion, no selecting, 
nor copy-paste... :(

Then, I tested calling grass from MSYS shell, with the intention of getting 
some of linux shell funcionalities, but the command grass70 does not work... 
Attached, is a screenshot of the error i get...

So, i cannot start the program there... is there any tricks for that? Or simply 
not possible? Maybe I'm missing something when selecting packages at the 
installation...

Any hints, tips, tricks from grass-windows devs and users are highly 
appreciated and more than welcome :)

Cheers! :)
Vero
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Using a dynamic text in module header for parser

[Blumentrath, Stefan]

startcmd = 'python '+s.name<http://s.name>
# set env variable
aoev='GRASS_ADDON_PATH'
tmpdir = os.path.basename(s.name<http://s.name>)
if aoev in os.environ:
os.environ[aoev]=[tmpdir]+os.environ[aoev]
else:
os.environ[aoev]=[tmpdir]
# set permissions
os.chmod(s.name<http://s.name>, os.stat(s.name<http://s.name>).st_mode | 
stat.S_IEXEC)
# start module
os.system(startcmd)
os.remove(s.name<http://s.name>)

Let me know if this works under Windows too.
Michel
On 10/12/2015 12:55 PM, Blumentrath, Stefan wrote:
Hi again,

Now I found out that the parser section in the inner python script was not 
formated properly.

However, when I now call the inner script with '--ui' I get an error:
Unable to fetch interface description for command 'tmpjksdfjiol'

Details:
Try to set up GRASS_ADDON_PATH or GRASS_ADDON_BASE variable.

It was neither possible to run the script using grass.run_command() (on 
Windows).

Cheers
Stefan



From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of 
Blumentrath, Stefan
Sent: 12. oktober 2015 11:36
To: GRASS developers list 
(grass-dev@lists.osgeo.org<mailto:grass-dev@lists.osgeo.org>) 
<grass-dev@lists.osgeo.org><mailto:grass-dev@lists.osgeo.org>
Subject: [GRASS-dev] Using a dynamic text in module header for parser

Hi,

I would like to fill:
#% options:
and
#% answer
in a parser option for a python script dynamically.  In particular I want to 
have tickboxes for available mapsets in the module GUI...

Meaning something like this  (but less complex / not interactive):
http://permalink.gmane.org/gmane.comp.gis.grass.gui/667
My amateur programming skills do unfortunately not allow me to really 
understand how to accomplish what Glynn describes in the post above...

I tried to generate and run a temporary python script from within my script 
like this:
def main():

answer = grass.mapsets(search_path = True)
available_mapsets = str(grass.mapsets())

with tempfile.NamedTemporaryFile(delete = False) as s:
s.write('''#!/usr/bin/env python
# -*- coding: utf-8 -*-
# Here comes the full module with header for the parser
#% options: ''' + str(','.join(available_mapsets))
...
''')
startcmd = 'python ' + s.name<http://s.name>
os.system(startcmd)
os.remove(s.name<http://s.name>)

But that way the GUI never starts, when I call the outer script from GRASS and 
it seems that option never get parsed...

Any hints how to proceed?

Thanks for helping in advance.

Stefan




___

grass-dev mailing list

grass-dev@lists.osgeo.org<mailto:grass-dev@lists.osgeo.org>

http://lists.osgeo.org/mailman/listinfo/grass-dev


___
grass-dev mailing list
grass-dev@lists.osgeo.org<mailto: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

[GRASS-dev] Using a dynamic text in module header for parser

[Blumentrath, Stefan]

Hi,

I would like to fill:
#% options:
and
#% answer
in a parser option for a python script dynamically.  In particular I want to 
have tickboxes for available mapsets in the module GUI...

Meaning something like this  (but less complex / not interactive):
http://permalink.gmane.org/gmane.comp.gis.grass.gui/667
My amateur programming skills do unfortunately not allow me to really 
understand how to accomplish what Glynn describes in the post above...

I tried to generate and run a temporary python script from within my script 
like this:
def main():

answer = grass.mapsets(search_path = True)
available_mapsets = str(grass.mapsets())

with tempfile.NamedTemporaryFile(delete = False) as s:
s.write('''#!/usr/bin/env python
# -*- coding: utf-8 -*-
# Here comes the full module with header for the parser
#% options: ''' + str(','.join(available_mapsets))
...
''')
startcmd = 'python ' + s.name
os.system(startcmd)
os.remove(s.name)

But that way the GUI never starts, when I call the outer script from GRASS and 
it seems that option never get parsed...

Any hints how to proceed?

Thanks for helping in advance.

Stefan


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

Re: [GRASS-dev] Using a dynamic text in module header for parser

[Blumentrath, Stefan]

Hi again,

Now I found out that the parser section in the inner python script was not 
formated properly.

However, when I now call the inner script with '--ui' I get an error:
Unable to fetch interface description for command 'tmpjksdfjiol'

Details:
Try to set up GRASS_ADDON_PATH or GRASS_ADDON_BASE variable.

It was neither possible to run the script using grass.run_command() (on 
Windows).

Cheers
Stefan



From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of 
Blumentrath, Stefan
Sent: 12. oktober 2015 11:36
To: GRASS developers list (grass-dev@lists.osgeo.org) 
<grass-dev@lists.osgeo.org>
Subject: [GRASS-dev] Using a dynamic text in module header for parser

Hi,

I would like to fill:
#% options:
and
#% answer
in a parser option for a python script dynamically.  In particular I want to 
have tickboxes for available mapsets in the module GUI...

Meaning something like this  (but less complex / not interactive):
http://permalink.gmane.org/gmane.comp.gis.grass.gui/667
My amateur programming skills do unfortunately not allow me to really 
understand how to accomplish what Glynn describes in the post above...

I tried to generate and run a temporary python script from within my script 
like this:
def main():

answer = grass.mapsets(search_path = True)
available_mapsets = str(grass.mapsets())

with tempfile.NamedTemporaryFile(delete = False) as s:
s.write('''#!/usr/bin/env python
# -*- coding: utf-8 -*-
# Here comes the full module with header for the parser
#% options: ''' + str(','.join(available_mapsets))
...
''')
startcmd = 'python ' + s.name
os.system(startcmd)
os.remove(s.name)

But that way the GUI never starts, when I call the outer script from GRASS and 
it seems that option never get parsed...

Any hints how to proceed?

Thanks for helping in advance.

Stefan


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

Re: [GRASS-dev] wx.metadata ready for testing

[Blumentrath, Stefan]

Hi Martin,

Thanks for your patience.

Here is my shell output:

GRASS 7.1.svn (ETRS_32N):~/data_maintenance > env | grep GIS
GISRC=/tmp/grass7-stefan-19203/gisrc
GISBASE=/usr/local/grass-7.1.svn
GIS_LOCK=19203

GRASS 7.1.svn (ETRS_32N):~/data_maintenance > env | grep GRASS
GRASS_PYTHON=python
GRASS_GNUPLOT=gnuplot -persist
GRASS_PAGER=more
GRASS_ADDON_PATH=/home/stefan/grass-addons/
GRASS_PROJSHARE=/usr/local/share/proj
GRASS_VERSION=7.1.svn
GRASS_SKIP_MAPSET_OWNER_CHECK=1
GRASS_HTML_BROWSER=xdg-open
GRASS_ADDON_BASE=/home/stefan/.grass7/addons

GRASS 7.1.svn (ETRS_32N):~/data_maintenance > export 
GRASS_ADDON_PATH=/home/stefan/.grass7/addons/

GRASS 7.1.svn (ETRS_32N):~/data_maintenance > env | grep GRASS
GRASS_PYTHON=python
GRASS_GNUPLOT=gnuplot -persist
GRASS_PAGER=more
GRASS_ADDON_PATH=/home/stefan/.grass7/addons/
GRASS_PROJSHARE=/usr/local/share/proj
GRASS_VERSION=7.1.svn
GRASS_SKIP_MAPSET_OWNER_CHECK=1
GRASS_HTML_BROWSER=xdg-open
GRASS_ADDON_BASE=/home/stefan/.grass7/addons

GRASS 7.1.svn (ETRS_32N):~/data_maintenance > g.extension wx.metadata
Fetching  from GRASS GIS Addons repository (be patient)...
Compiling...
Traceback (most recent call last):
  File "/tmp/grass7-stefan-19203/tmpQpQIQ7/wx.metadata/scripts/db.csw.admin", 
line 127, in 
from cswutil import *
ImportError: No module named cswutil
make[1]: *** [db.csw.admin.tmp.html] Error 1
/bin/sh: 1: cannot create /usr/local/grass-7.1.svn/error.log: Permission denied
make: *** [db.csw.admin] Error 2
ERROR: Compilation failed, sorry. Please check above error messages.

GRASS 7.1.svn (ETRS_32N):~/data_maintenance > g.version -g
version=7.1.svn
date=2015
revision=66426M
build_date=2015-10-07
build_platform=x86_64-unknown-linux-gnu
build_off_t_size=8

Cheers
Stefan

-Original Message-
From: grass-dev-boun...@lists.osgeo.org 
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Martin Landa
Sent: 7. oktober 2015 22:30
To: Paulo van Breugel 
Cc: GRASS developers list 
Subject: Re: [GRASS-dev] wx.metadata ready for testing

Hi,

2015-10-07 12:30 GMT+02:00 Paulo van Breugel :

I tried fresh installation (trunk) in installed to /usr/local. I cannot 
reproduce any of reported errors. Please send me related environmental 
variables:

env | grep GIS

env | grep GRASS

?

Ma

> ware/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata
>> >>> /usr/local/grass7/grass-7.1.svn/error.log
>> >
>> > make[1]: Entering directory
>> >
>> > `/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'
>> >
>> > if [ "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata" != "" 
>> > ] ; then
>> > GISRC=/usr/local/grass7/grass-7.1.svn/demolocation/.grassrc71
>> > GISBASE=/usr/local/grass7/grass-7.1.svn
>> >
>> > PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:$PATH"
>> >
>> > PYTHONPATH="/usr/local/grass7/grass-7.1.svn/etc/python:/usr/local/grass7/grass-7.1.svn/gui/wxpython:$PYTHONPATH"
>> >
>> > LD_LIBRARY_PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:/usr/local/grass7/grass-7.1.svn/lib:/usr/local/grass7/grass-7.1.svn/lib::/lib:/usr/local/lib:/usr/local/gdal/lib"
>> > LC_ALL=C /usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata
>> > --html-description < /dev/null | grep -v '\|' > 
>> > g.gui.metadata.tmp.html ; fi
>> >
>> > Traceback (most recent call last):
>> >
>> >   File "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata", 
>> > line 35, in 
>> >
>> > import mdgrass
>> >
>> > ImportError: No module named mdgrass
>> >
>> > make[1]: *** [g.gui.metadata.tmp.html] Error 1
>> >
>> > rm g.gui.metadata.tmp.html
>> >
>> > make[1]: Leaving directory
>> >
>> > `/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'
>> >
>> >
>> >
>> >>
>> >
>>
>>
>>
>> --
>> Martin Landa
>> http://geo.fsv.cvut.cz/gwiki/Landa
>> http://gismentors.cz/mentors/landa
>
>



--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
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] v.rast.stats: NULL values for very small areas

[Blumentrath, Stefan]

Hi,

What about a flag for checking if all polygon categories are present in the 
raster version of the vector map, and giving a warning if that is not the case.

That will take more time but makes output more reliable.

Maybe one can - in case of non-rasterized polygons/lines - edit the raster map 
by writing cats to cells containing centroids (or midpoints for lines)

However, also then - in case of significant mismatch between map scale and 
resolution of the region - can cats be not present in the raster (if more than 
one centroid falls into a cell). That only indicates that the user either has 
to rethink settings, choose another approach (repeat the command for only the 
non-rasterized polygons) or ignore the issues...

Cheers
Stefan

-Original Message-
From: grass-dev-boun...@lists.osgeo.org 
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Maris Nartiss
Sent: 7. oktober 2015 10:23
To: Moritz Lennert 
Cc: Martin Landa ; GRASS developers list 

Subject: Re: [GRASS-dev] v.rast.stats: NULL values for very small areas

2015-10-06 19:26 GMT+03:00 Moritz Lennert :
>> I just wonder how to implement within Python script.
>
>
> Get areas of all polygons (or lenghts of lines) with v.to.db and then 
> divide the features into those with areas above pixel size and those 
> with areas below. Treat each set differently (i.e. the former as 
> before, the latter by using v.what.rast - with the -p flag - to get 
> the pixel value). As the updating of the table is done feature by 
> feature anyhow, all you lose in terms of performance is the additional 
> step of calculating areas/lengths of features.
>

First of all - v.rast.stats is not affected by the size of polygon but by its 
shape/location. It uses v.to.rast thus data will be provided if raster cell 
centre falls into vector polygon (no matter how small it could be). Thus 
theoretically it is possible to construct a large polygon that still gets NULL 
value.
Thus the discussion should be - should statistics be collected also for cells 
that only partially lie within the polygon. Raster cell is the smallest unit 
and it is homogeneous thus interpretation "collect data on all cells even if 
polygon just touches it" might seem to be a valid idea. Proposed solution with 
v.what.rast is not a solution as it will sample raster map at the location of 
centroid thus in case of polygon covering more than one cell, a value of one of 
cells will be provided.

Personally I tend to favour current behaviour. It could be a bit better 
documented as current documentation states: "The vector map will be rasterized 
according to the raster map resolution." It is correct but an extra explanation 
would be helpful like: "Stats are provided only for polygons covering raster 
cell centres (or whole raster cell area)."

Just my 0.02c,
Māris.
___
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] Collecting ideas for training manual for GRASS GIS

[Blumentrath, Stefan]

>From my experience the need for internationalization varies very much and 
>depends on a lot of things (one of them is culture and exposure to foreign 
>esp. English language).
Here in Norway, I guess no one would really miss a translation to Norwegian, as 
e.g. kids-TV, movies in the Cinema, and so on are not dubbed (like in e.g. the 
Netherlands). Actually, we even turn the GUI to English to have it aligned with 
manuals.

However, in other countries things can be quite different...

Personally, I would not spend an effort on translation into many languages but 
maybe (max) a few central ones, meaning: Spanish, and maybe Portuguese and / or 
French (no ideas about the importance of Asian or Arabic languages or 
Russian)...

Anyway, better to have one good annual in English than having lots of halfway 
translations.

Finally, terms in spatial analysis are often not too straight forward to 
translate and sometimes end up in funny translations...

Cheers
Stefan


-Original Message-
From: grass-dev-boun...@lists.osgeo.org 
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Luca Delucchi
Sent: 18. september 2015 06:27
To: Vaclav Petras 
Cc: Moritz Lennert ; GRASS-dev 

Subject: Re: [GRASS-dev] Collecting ideas for training manual for GRASS GIS

On 18 September 2015 at 04:45, Vaclav Petras  wrote:
> (Was: Re: [GRASS-dev] FOSS4G 2016 code sprint)
>
> Hi Moritz and Luca,
>

Hi Vaclav,

>>
>> We could also start a discussion about the software to use and create 
>> a repository and try to start to centralize the material already 
>> existing
>
> from technical point of view, we are now using HTML pages (which can 
> be tutorials as well, not only manual pages), wiki and then all other things.
> If we want to allow for an internationalization, that's yet another 
> question.
>

internationalization is the main topic, I think, we should provide it or not?
for some reason yes, newbie some times would like to have material in their 
native language, for some other reason is really difficult to maintain it 
updated because people start to work on it and after disappear.

Use some simple tool as Transfixer [0] maybe could be useful

> For the sources I'm involved in, you can have a look at:
>
> http://geospatial.ncsu.edu/osgeorel/courses.html
>
> in particular:
>
> http://courses.ncsu.edu/gis582/common/grass/
> http://ncsu-osgeorel.github.io/erosion-modeling-tutorial/grassgis.html
> http://ncsu-osgeorel.github.io/grass-temporal-workshop/
> http://ncsu-osgeorel.github.io/uav-lidar-analytics-course/assignments/
> lidar.html 
> http://ncsu-osgeorel.github.io/uav-lidar-analytics-course/assignments/
> water_flow.html http://ncsu-osgeorel.github.io/grass-intro-workshop/
> http://www4.ncsu.edu/~akratoc/GRASS_intro/
>

this is really cool material I have some question:
- could be this documentation moved in some official GRASS page (maintaining of 
course ncsu affiliation)
- do you have any idea how simple could be translate it?

> Ideally, the things should be in the OSGeo Educational Content 
> Inventory and we should be adding the stable or valuable things there 
> as we are collecting them.
>
> http://www.osgeo.org/educational_content?filter1=grass
>
> Vaclav

[0] https://www.transifex.com/

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
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] FOSS4G 2016 code sprint

[Blumentrath, Stefan]

Cool! I am inn (if nothing unpredictable happens)!
I could also imagine to work on something like the "GRASS GIS locations created 
from public data" idea for GSoC 2014/2015:
https://trac.osgeo.org/grass/wiki/GSoC/2015

Cheers
Stefan


-Original Message-
From: grass-dev-boun...@lists.osgeo.org 
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Luca Delucchi
Sent: 17. september 2015 02:55
To: Moritz Lennert 
Cc: GRASS-dev 
Subject: Re: [GRASS-dev] FOSS4G 2016 code sprint

On 16 September 2015 at 13:50, Moritz Lennert  wrote:

>
> I think that at such an occasion it also would be very interesting to 
> get a series of non-programmers together to work on a training manual 
> for GRASS, in the same line as the QGIS training manual [1]. I've very 
> often would have appreciated such a resource to enable people to 
> discover GRASS more autonomously.
>
> At this stage we have many different localized resources, but I think 
> having a centralized training manual which people could then translate 
> to different languages would be helpful.
>

We could also start a discussion about the software to use and create a 
repository and try to start to centralize the material already existing

> If we can get together a small team for 4 days, we should be able to 
> already get a basic manual up and running.
>

+1

> Just as a reminder: FOSS4G 2016 will take place in Bonn, Germany.
>
>
> Moritz
>
> [1] http://docs.qgis.org/2.8/en/docs/training_manual/



--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
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] Wildcards in multiple map input?

[Blumentrath, Stefan]

Hi Anna,

Thanks for your reply. The closest I found was this:
https://trac.osgeo.org/grass/ticket/1251

Might be dangerous to use an asterisk at command / parser level as the result 
of the evaluation (meaning the resulting list of maps) is not necessarily known 
to the user in advance (or may be different from what he or she expects)!?

Anyway, if you consider it a useful feature I will open a ticket …

Cheers
Stefan


From: Anna Petrášová [mailto:kratocha...@gmail.com]
Sent: 10. september 2015 15:44
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (grass-dev@lists.osgeo.org) 
<grass-dev@lists.osgeo.org>; Andrew McAninch <amcani...@gmail.com>; Radim 
Blazek (radim.bla...@gmail.com) <radim.bla...@gmail.com>
Subject: Re: [GRASS-dev] Wildcards in multiple map input?



On Wed, Sep 9, 2015 at 7:06 AM, Blumentrath, Stefan 
<stefan.blumentr...@nina.no<mailto:stefan.blumentr...@nina.no>> wrote:
Hi,

For the QGIS-GRASS-plugin update Radim, Pedro, Andrew and me were discussion 
how to implement multiple selections for map input in the UI in QGIS.

In this context I was thinking that the ability to use wildcards would be 
really handy for GRASS newcomers. People who are not afraid of the command line 
can of course easily pipe g.list output to modules with multiple input or 
re-use the latter from file like e.g. in temporal modules.

My idea would be to allow something like this:
r.series input=temperature_*_05_17 output=norway_national_day_temperature_avg 
method=average (in order to calculate average temperature for Norways national 
day for example)
in the GUI and/or command line, where wildcards are evaluated to a list of 
available maps following that pattern.
The “*” is not allowed in map names, right, so, whenever it appears in a 
multiple map input it might used to trigger a respective g.list operation…

My question is:
Would it be of interest and feasible to add such a feature to GRASS?
Just an idea to make things easier for beginners and those who only use the 
GUI...

I thought there was a ticket about this, but I can't find it. The suggestion I 
remember (but it never got implemented) is to reuse a dialog for selecting 
multiple maps using regular expressions (accessible from layer manager) and 
have a small button near the map entry in the autogenerated dialogs which would 
open this dialog and transfer the resulting map series back in the map entry 
field. So this would be implemented on the GUI level. Your suggestion would be 
implemented on parser level. I guess both have some pluses and minuses.

Anna



Cheers
Stefan


___
grass-dev mailing list
grass-dev@lists.osgeo.org<mailto: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

[GRASS-dev] Wildcards in multiple map input?

[Blumentrath, Stefan]

Hi,

For the QGIS-GRASS-plugin update Radim, Pedro, Andrew and me were discussion 
how to implement multiple selections for map input in the UI in QGIS.

In this context I was thinking that the ability to use wildcards would be 
really handy for GRASS newcomers. People who are not afraid of the command line 
can of course easily pipe g.list output to modules with multiple input or 
re-use the latter from file like e.g. in temporal modules.

My idea would be to allow something like this:
r.series input=temperature_*_05_17 output=norway_national_day_temperature_avg 
method=average (in order to calculate average temperature for Norways national 
day for example)
in the GUI and/or command line, where wildcards are evaluated to a list of 
available maps following that pattern.
The "*" is not allowed in map names, right, so, whenever it appears in a 
multiple map input it might used to trigger a respective g.list operation...

My question is:
Would it be of interest and feasible to add such a feature to GRASS?
Just an idea to make things easier for beginners and those who only use the 
GUI...

Cheers
Stefan

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

Re: [GRASS-dev] r.resample.rst behavior does not match manual

[Blumentrath, Stefan]

Hi Michael,

The second sentence you cite from the manual seems indeed a bit imprecise.
It should probably say something like:
“The extent of all resulting raster maps is taken from the settings of the 
current region (which may be different from the extent of the input raster 
map). The resolution of the current region however has to follow cleanly the 
resolution of the input map”

Yet, the example in the manual is correct. It might be modified in order to 
highlight the module behavior named above by exchanging the first g.region 
command by something like:

g.region n= s= e= w= align=elevation.dem -p
(I do not have the sample data available, so I cannot guess reasonable extent 
values or another raster or vector map with a smaller extent)…

Cheers
Stefan

From: grass-dev-boun...@lists.osgeo.org 
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Michael Barton
Sent: 30. august 2015 04:03
To: GRASS developers grass-developers grass-dev@lists.osgeo.org
Subject: [GRASS-dev] r.resample.rst behavior does not match manual

The r.resample.rst manual states…

 Reinterpolation (resampling) is done to higher, same or lower resolution 
specified by the ew_res and ns_res parameters.”

The very next sentence states...

All resulting raster maps are created using the settings of the current region 
(which may be different from that of the input raster map).”

So these two sentences contradict each other.

Additionally, I’ve got a 90m DEM that I want to resample to 30m. I’ve reset the 
region resolution to 30m. This is exactly the situation listed in the second 
sentence. Yet r.resample.rst gives the error:

ERROR: Input map resolution differs from current region resolution!

So what is the proper way to use this module? Whatever it is, the manual needs 
to be corrected.

Michael

C. Michael Barton
Director, Center for Social Dynamics  Complexity
Professor of Anthropology, School of Human Evolution  Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu














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

Re: [GRASS-dev] g.gui.metadata and wxgui addons in GRASS 7.1

[Blumentrath, Stefan]

Hi Matej,

Yes, thanks it does compile now.

And when I run g.gui.metadata the GUI starts although I get this:
Initialize of temporal tree catalogue error:  in method 
'TreeCtrl_GetFirstChild', expected argument 2 of type 'wxTreeItemId const ' 

Reason: in method 'TreeCtrl_GetFirstChild', expected argument 2 of type 
'wxTreeItemId const '

Traceback (most recent call last):
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata, line 958, in 
initTemporalTree
if self.itemExists(ml[2], varmapset) is False:
  File /usr/local/grass-7.1.svn/gui/wxpython/lmgr/datacatalog.py, line 213, 
in itemExists
item, cookie = self.GetFirstChild(root)
  File /usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_controls.py, 
line 5409, in GetFirstChild
return _controls_.TreeCtrl_GetFirstChild(*args, **kwargs)
TypeError: in method 'TreeCtrl_GetFirstChild', expected argument 2 of type 
'wxTreeItemId const '

I can browse the maps in my mapset and the pen and the “template” button get 
active. Yet, when I click on “template” I get:

WARNING: Epsg code cannot be identified
Traceback (most recent call last):
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata, line 291, in 
onCreateTemplate
if self.onEdit():
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata, line 303, in onEdit
ok = self.editMapMetadata()
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata, line 648, in 
editMapMetadata
self.xmlPath = self.mdCreator.saveXML(self.mdDestination, 
self.nameTMPteplate, self)
  File /usr/local/grass-7.1.svn/etc/wx.metadata/mdlib/mdgrass.py, line 513, 
in saveXML
profile = env.get_template(self.profilePath)
  File 
/usr/local/lib/python2.7/dist-packages/Jinja2-2.9.dev-py2.7.egg/jinja2/environment.py,
 line 812, in get_template
return self._load_template(name, self.make_globals(globals))
  File 
/usr/local/lib/python2.7/dist-packages/Jinja2-2.9.dev-py2.7.egg/jinja2/environment.py,
 line 774, in _load_template
cache_key = self.loader.get_source(self, name)[1]
  File 
/usr/local/lib/python2.7/dist-packages/Jinja2-2.9.dev-py2.7.egg/jinja2/loaders.py,
 line 187, in get_source
raise TemplateNotFound(template)
jinja2.exceptions.TemplateNotFound: etc/wx.metadata/profiles/basicProfile.xml

The location was defined using an EPSG code (25632). It is a standard ETRS/UTM 
based CRS which is quite common for the western to central parts of Europe (and 
INSPIRE compliant)…

Anyway, the first glimpse I got from g.gui.metadata looked promising! Thanks 
for your work on that!

Cheers
Stefan

From: Matej Krejci [mailto:matejkre...@gmail.com]
Sent: 25. august 2015 08:39
To: Blumentrath, Stefan stefan.blumentr...@nina.no
Cc: GRASS-dev grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] g.gui.metadata and wxgui addons in GRASS 7.1

Hi Stephan,

2015-08-21 22:08 GMT+02:00 Blumentrath, Stefan 
stefan.blumentr...@nina.nomailto:stefan.blumentr...@nina.no:
Hi Matej,

I just checked out your new revision. Now I get on sudo make 
MODULE_TOPDIR=/usr/local/grass-7.1.svn/:

make[1]: Entering directory 
`/data/src/grass7_addons/gui/wxpython/wx.metadata/g.gui.metadata'
if [ /usr/local/grass-7.1.svn/scripts/g.gui.metadata !=  ] ; then 
GISRC=/usr/local/grass-7.1.svn/demolocation/.grassrc71 
GISBASE=/usr/local/grass-7.1.svn 
PATH=/usr/local/grass-7.1.svn/bin:/usr/local/grass-7.1.svn/bin:/usr/local/grass-7.1.svn/scripts:$PATH
 
PYTHONPATH=/usr/local/grass-7.1.svn/etc/python:/usr/local/grass-7.1.svn/gui/wxpython:$PYTHONPATH
 
LD_LIBRARY_PATH=/usr/local/grass-7.1.svn/bin:/usr/local/grass-7.1.svn/scripts:/usr/local/grass-7.1.svn/lib:/usr/local/grass-7.1.svn/lib:
 LC_ALL=C /usr/local/grass-7.1.svn/scripts/g.gui.metadata --html-description  
/dev/null | grep -v '/body\|/html'  g.gui.metadata.tmp.html ; fi
Traceback (most recent call last):
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata, line 27, in module
sys.path.insert(2, os.path.join(os.getenv('GRASS_ADDON_BASE'), 'etc', 
'wx.metadata', 'mdlib'))
  File /usr/lib/python2.7/posixpath.py, line 77, in join
elif path == '' or path.endswith('/'):
AttributeError: 'NoneType' object has no attribute 'endswith'
make[1]: *** [g.gui.metadata.tmp.html] Error 1
rm g.gui.metadata.tmp.html
make[1]: Leaving directory 
`/data/src/grass7_addons/gui/wxpython/wx.metadata/g.gui.metadata'

Problem was that I never try make with sudo. I am not sure why it has effect. 
Problem should be fixed in r66007.

thank you for testing
Best
Matej


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

Re: [GRASS-dev] g.gui.metadata and wxgui addons in GRASS 7.1

[Blumentrath, Stefan]

Hi Matej,

I just checked out your new revision. Now I get on sudo make 
MODULE_TOPDIR=/usr/local/grass-7.1.svn/:

make[1]: Entering directory 
`/data/src/grass7_addons/gui/wxpython/wx.metadata/g.gui.metadata'
if [ /usr/local/grass-7.1.svn/scripts/g.gui.metadata !=  ] ; then 
GISRC=/usr/local/grass-7.1.svn/demolocation/.grassrc71 
GISBASE=/usr/local/grass-7.1.svn 
PATH=/usr/local/grass-7.1.svn/bin:/usr/local/grass-7.1.svn/bin:/usr/local/grass-7.1.svn/scripts:$PATH
 
PYTHONPATH=/usr/local/grass-7.1.svn/etc/python:/usr/local/grass-7.1.svn/gui/wxpython:$PYTHONPATH
 
LD_LIBRARY_PATH=/usr/local/grass-7.1.svn/bin:/usr/local/grass-7.1.svn/scripts:/usr/local/grass-7.1.svn/lib:/usr/local/grass-7.1.svn/lib:
 LC_ALL=C /usr/local/grass-7.1.svn/scripts/g.gui.metadata --html-description  
/dev/null | grep -v '/body\|/html'  g.gui.metadata.tmp.html ; fi
Traceback (most recent call last):
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata, line 27, in module
sys.path.insert(2, os.path.join(os.getenv('GRASS_ADDON_BASE'), 'etc', 
'wx.metadata', 'mdlib'))
  File /usr/lib/python2.7/posixpath.py, line 77, in join
elif path == '' or path.endswith('/'):
AttributeError: 'NoneType' object has no attribute 'endswith'
make[1]: *** [g.gui.metadata.tmp.html] Error 1
rm g.gui.metadata.tmp.html
make[1]: Leaving directory 
`/data/src/grass7_addons/gui/wxpython/wx.metadata/g.gui.metadata'


I did not update my GRASS 7.1 installation (it is r65797)…

Cheers
Stefan


From: Matej Krejci [mailto:matejkre...@gmail.com]
Sent: 21. august 2015 14:43
To: Blumentrath, Stefan stefan.blumentr...@nina.no
Cc: GRASS-dev grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] g.gui.metadata and wxgui addons in GRASS 7.1

Dear Stefan,

Thanks for bug report. I have done few changes(r65990) which should help but 
the installation from add-ons still doesn't work properly[1].

2015-08-20 14:41 GMT+02:00 Blumentrath, Stefan 
stefan.blumentr...@nina.nomailto:stefan.blumentr...@nina.no:
Hi,

I just tried to install g.gui.metadata addon with limited success.

No AddOn appears under wxGUI when I run g.extension from the GUI (while e.g. 
raster addons do show up). Is this probably do to the path in the AddOn repo 
(which starts with gui and not wxGUI). All other tree elements in g.extension 
are equal to folder names in the repository…
So, I finally compiled g.gui.extension from source after installing the 
dependencies.

Now, g.gui.metadata is available, but does not start:

Traceback (most recent call last):
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata,
line 1246, in module
main()
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata,
line 1240, in main
MAINFRAME = MdMainFrame()
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata,
line 88, in __init__
self.onInitEditor()
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata,
line 724, in onInitEditor
self.MdDataCatalogPanelLeft =
MdDataCatalog(self.leftPanel)
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata,
line 836, in __init__
self.InitTreeItems()
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata,
line 860, in InitTreeItems
self.initTemporalTree(location=location,
mapset=self.mapset)
 File /usr/local/grass-7.1.svn/scripts/g.gui.metadata,
line 923, in initTemporalTree
if self.itemExists(ml[2], varmapset) == False:
  File
/usr/local/grass-7.1.svn/gui/wxpython/lmgr/datacatalog.py,
line 213, in itemExists
item, cookie = self.GetFirstChild(root)
  File /usr/lib/python2.7/dist-
packages/wx-2.8-gtk2-unicode/wx/_controls.py, line 5409, in
GetFirstChild
return _controls_.TreeCtrl_GetFirstChild(*args,
**kwargs)
ValueError: invalid null reference in method
'TreeCtrl_GetFirstChild', expected argument 2 of type
'wxTreeItemId const '



Best
Matej

[1] https://lists.osgeo.org/pipermail/grass-dev/2015-August/076034.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] g.gui.metadata and wxgui addons in GRASS 7.1

[Blumentrath, Stefan]

Hi,

I just tried to install g.gui.metadata addon with limited success.

No AddOn appears under wxGUI when I run g.extension from the GUI (while e.g. 
raster addons do show up). Is this probably do to the path in the AddOn repo 
(which starts with gui and not wxGUI). All other tree elements in g.extension 
are equal to folder names in the repository...
So, I finally compiled g.gui.extension from source after installing the 
dependencies.

Now, g.gui.metadata is available, but does not start:

Traceback (most recent call last):
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata,
line 1246, in module
main()
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata,
line 1240, in main
MAINFRAME = MdMainFrame()
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata,
line 88, in __init__
self.onInitEditor()
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata,
line 724, in onInitEditor
self.MdDataCatalogPanelLeft =
MdDataCatalog(self.leftPanel)
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata,
line 836, in __init__
self.InitTreeItems()
  File /usr/local/grass-7.1.svn/scripts/g.gui.metadata,
line 860, in InitTreeItems
self.initTemporalTree(location=location,
mapset=self.mapset)
 File /usr/local/grass-7.1.svn/scripts/g.gui.metadata,
line 923, in initTemporalTree
if self.itemExists(ml[2], varmapset) == False:
  File
/usr/local/grass-7.1.svn/gui/wxpython/lmgr/datacatalog.py,
line 213, in itemExists
item, cookie = self.GetFirstChild(root)
  File /usr/lib/python2.7/dist-
packages/wx-2.8-gtk2-unicode/wx/_controls.py, line 5409, in
GetFirstChild
return _controls_.TreeCtrl_GetFirstChild(*args,
**kwargs)
ValueError: invalid null reference in method
'TreeCtrl_GetFirstChild', expected argument 2 of type
'wxTreeItemId const '

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

Re: [GRASS-dev] ​Can GRASS compute the line graph representation of an input graph?

[Blumentrath, Stefan]

Hi Anita,

For more sophisticated network analysis I tend to use igraph:
http://igraph.org/
It is quite easy to understand, well documented, efficient and supports also 
calculation of line graphs. It comes with both Python and R APIs.
Usually I feed graphs into it from GRASS (v.net) or PostGIS. I have not tried 
the new GDAL/OGR network driver...

Cheers
Stefan



-Original Message-
From: grass-dev-boun...@lists.osgeo.org 
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Luca Delucchi
Sent: 3. juni 2015 08:41
To: Anita Graser
Cc: GRASS-dev
Subject: Re: [GRASS-dev] ​Can GRASS compute the line graph representation of an 
input graph?

On 2 June 2015 at 19:46, Anita Graser anitagra...@gmx.at wrote:
 Hi,


Hi,

 I'm interested in computing a line graph for an input graph. I 
 couldn't find any reference to line graphs in the GRASS docs. Is there 
 a different term I should be using in my search or a hidden function 
 that would create such a graph?


I don't think so, but it seems really interesting

 I've posted this question on GIS.stackexchange as well, in case you 
 prefer to answer there:
 http://gis.stackexchange.com/questions/146713/can-grass-compute-the-li
 ne-graph-representation-of-an-input-graph

 Thanks and best wishes,
 Anita



--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
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

[GRASS-dev] GRASS 7: r.stream.extract fails to read big input maps

[Blumentrath, Stefan]

Dear all,

I tried to extract a river network from a huge DEM:

rows:   180752
cols:   141312
cells:  25542426624

r.watershed (in an older revision of GRASS 7) had no problem with the DEM and 
created raster streams very nicely. However, I could not convert them to vector 
because r.to.vect complained the streams weren't thinned properly. Since I 
would like to continue with the other r.streams.* addons anyway, I tried 
running r.stream.extract. On the entire DEM it failed with the error message 
below:

(Mon Apr 13 23:21:30 2015)
r.stream.extract --verbose elevation=dem_10m_nosefi_float@PERMANENT 
accumulation=dem_10m_nosefi_float_accum@Hydrologi threshold=1500 
stream_length=5 memory=5 stream_raster=dem_10m_nosefi_float_streams_ids 
stream_vector=dem_10m_nosefi_float_streams_ids
4.23% of data are kept in memory
Will need up to 1285.49 GB (1316340 MB) of disk space
Creating temporary files...
Loading input raster maps...
ERROR: Unable to load input raster map(s)
(Wed Apr 15 12:44:30 2015) Command finished (2243 min 0 sec)

From the error message (Unable to load input raster map(s)), I have no idea 
where I could start searching for the problem...

On a smaller catchment (with all in RAM calculation) r.stream.extract works 
fine...

Any ideas how to fix this? Running r.stream.extract per catchment (delineated 
earlier with r.watershed) would be a possible workaround...

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

[GRASS-dev] GDAL-GRASS-plugin 1.11.2

[Blumentrath, Stefan]

Hi,

I just tried to compile the GDAL-GRASS-plugin 1.11.2 against GRASS 7.0.1 (the 
release branch).

It seems that there are some issues with the configure /configure.in file in 
the plugin

There .7.0.svn is hard coded in the library links (while the stable release 
puts the libraries in a folder ending on .7.0.1svn). So, I had to run:
sed -i 's/\.7\.0\.svn/.7.0.1svn/g' configure
In order to be able to configure the plugin.

After that it seems to work fine although I get a warning messages on 
./configure:

checking for ranlib... ranlib
conftest2.c: In function 'g':
conftest2.c:2:1: warning: zero-length gnu_printf format string 
[-Wformat-zero-length]
void g(); void g(){printf();}
^


Furthermore, I had to specify the includes for my PostgreSQL in order to make 
make work:
CPPFLAGS=-I/usr/include/postgresql ./configure 
--with-grass=/usr/local/grass-7.0.1svn --with-gdal=/usr/local/bin/gdal-config

I also got an error on sudo make install:
cp: cannot stat '/usr/local/grass-7.0.1svn/etc/ellipse.table': No such file or 
directory
make: *** [install] Error 1

But GDAL / OGR do now read both GRASS 7 raster and vector nicely...

Kind regards,
Stefan
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [gdal-dev] GDAL-GRASS-plugin 1.11.2

[Blumentrath, Stefan]

Thanks Martin,

I just downloaded configure.in, configure and Makefile.in and now it works.
I still get the conftest2 warning, but that does not matter I guess...(?).

Cheers
Stefan



-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com] 
Sent: 30. mars 2015 18:28
To: Markus Neteler
Cc: Blumentrath, Stefan; gdal-dev (gdal-...@lists.osgeo.org); GRASS developers 
list (grass-dev@lists.osgeo.org)
Subject: Re: [gdal-dev] [GRASS-dev] GDAL-GRASS-plugin 1.11.2

2015-03-30 18:16 GMT+02:00 Markus Neteler nete...@osgeo.org:
 The path changed between G6 and G7, it should be

 etc/proj/*

 @Martin, is this fixed as well?

yes [1]. Martin

[1] 
http://trac.osgeo.org/gdal/browser/branches/1.11/gdal/frmts/grass/pkg/Makefile.in#L30

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] integrate v.concave.hull into v.hull [was point cloud analysis: new features]]

[Blumentrath, Stefan]

Hei Markus,

Assuming you have no attributes for those lines, what about the following 
procedure:

1) Turning all to closed line strings into areas in a first step (v.centroids) 
and then 
2) use some v.to.db (sides option) in order to distinguish inner and outer 
boundaries, in other words those which have no category at one side from those 
which have a category at both sides?
3) Then you can extract the latter and build areas only from them...

Cheers
Stefan 

-Original Message-
From: grass-dev-boun...@lists.osgeo.org 
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Markus Neteler
Sent: 23. mars 2015 12:17
To: Moritz Lennert
Cc: GRASS developers list; Markus Metz
Subject: Re: [GRASS-dev] integrate v.concave.hull into v.hull [was point cloud 
analysis: new features]]

Hi,

ok, to make it hopefully clear:
attached a screenshot of the lines describing contours of a lake.

I would like to turn this into a polygon describing the like, ideally in a 
non-manual way.

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

Re: [GRASS-dev] integrate v.concave.hull into v.hull [was point cloud analysis: new features]]

[Blumentrath, Stefan]

Hei Markus,

Not sure I fully understood you problem...

I guess you don`t have a grouping variable (e.g. a lake ID) for the contour 
lines? If you had one, you could probably extract the outer lines based on the 
attribute table (get max depth by lake (or min depth, depending on how it is 
coded), something like where=depth=max_depth) and turn them into polygon (if 
lines are properly closed).

Otherwise, if contour lines are not grouped by lake, personally I might have 
probably used PostGIS like this:
1) Polygonize all contour lines (ST_MakePolygon), eventually after checking if 
line strings are properly closed (ST_IsClosed)
2) SELECT all intersecting combinations of polygons in the resulting table 
(ST_Intersects)
3) LEFT JOIN polygonised contour lines with themselves using ST_CoveredBy
4) SELECT only those where left join IS NULL

Is that somehow in the direction you were thinking?

Cheers
Stefan

 
 Von: grass-dev-boun...@lists.osgeo.org grass-dev-boun...@lists.osgeo.org im 
 Auftrag von Markus Neteler nete...@osgeo.org

 I have a similar problem: imagine a set of contour lines which
 describe the bathymetry of a lake, so essentially contour lines which
 are closing a polygon but consist of different lines.

 I would like to get the respective polygon representation, i.e. the
 outer lines only and those turned into a polygon.

 I just tried v.concave.hull on it, however, it expects points and not lines.
 Does anyone have an idea how to achieve that?

 thanks
 markusN

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

[GRASS-dev] Python loop and SQLite performance issue?

[Blumentrath, Stefan]

Hi,

I am struggling with the performance of SQLite (I think), esp. when I use it in 
a python loop executed in parallel processes (using xargs) .

I am analyzing characteristics of a relatively large number (270k) of 
overlapping lake catchments which were generated in GRASS and now are stored in 
a PostGIS DB. I split the data in (10) chunks and analyse each chunk in it`s 
own GRASS 70 mapset (with SQLite backend) where I am looping over the 
catchments one by one (in python).

At first I tried to import the individual catchments using v.in.ogr. But 
v.in.ogr was slowing down the process significantly. It took 11 seconds to 
import a single, not very complex polygon (which is probably related to: 
https://trac.osgeo.org/grass/ticket/2185 ?; btw. my GRASSDB is not on NFS). So 
I switched to using gdal_rasterize and linked the resulting raster to GRASS 
(r.external) (as I am planning to work with rasters ater anyway). Rasterization 
and import takes all together less than a second. It made no difference for the 
speed of v.in.ogr if I imported the attribute table or not. However, converting 
the raster to vector in GRASS takes less than a second, so the topology 
creation does not seem to be the issue and also an attribute table is created...

Then I add a relatively large number of columns (400 or something) using 
v.db.addcolumn. That again takes 19 seconds for my single test process. If I 
run all 10 chunks in parallel (I have 24 cores and lots of memory available), 
adding the columns takes 30 seconds for each catchment, almost twice as much). 
During the loop the time spend on adding the columns continues increasing up to 
almost 30 min (at that point I canceled the process)... There is obviously 
something not working as it should be...

Analysing (r.univar) ca. 40 raster maps takes for the smaller catchments all 
together less than 5 seconds.

After that I removed all SQLite related code from my script and loaded results 
directly back to PostgreSQL/PostGIS. Then the smaller catchments are done in 
less than 5 seconds...

Does anyone have an idea what cause this performance loss is due to? Is it no 
good practice to call a python script (v.db.addcolumn) in a python loop, or is 
this related to SQLite journal files or ...
I am grateful for any hints!

Cheers
Stefan

P.S.: I can share the script if that helps identifying the issue...
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: [OSGeo-Discuss] OSGeo accepted to GSoC 2015 - overview of slot assignments

[Blumentrath, Stefan]

Good to hear.

As for the “GRASS GIS locations created from public data” idea, I might be able 
to provide some shell scripts to start with and I guess many others have 
something similar too. A central question there would be likely licensing of 
the data which is not always clear I am afraid?!

Cheers
Stefan

From: grass-dev-boun...@lists.osgeo.org 
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Markus Neteler
Sent: 3. mars 2015 10:59
To: GRASS developers list
Subject: [GRASS-dev] Fwd: [OSGeo-Discuss] OSGeo accepted to GSoC 2015 - 
overview of slot assignments

FYI

-- Forwarded message --
From: Margherita Di Leo direg...@gmail.commailto:direg...@gmail.com
Date: Tue, Mar 3, 2015 at 10:41 AM
Subject: [OSGeo-Discuss] OSGeo accepted to GSoC 2015 - overview of slot 
assignments
To: OSGeo Discussions 
disc...@lists.osgeo.orgmailto:disc...@lists.osgeo.org, OSGeo-SoC 
s...@lists.osgeo.orgmailto:s...@lists.osgeo.org

Dear All,

it is our pleasure to announce that OSGeo has been accepted as mentoring 
organization also this year! [1]
The OSGeo GSoC Team has been reshaped with respect to former communications, 
and it's now composed by myself (Madi) in the role of primary admin and the 
experienced Anne Ghisla in the role of co-admin.

Now it's time for prospecting students to carefully browse the list of ideas 
and contact developers team of their interest. Mentor registration is not yet 
open and will be announced in due time. Students can officially apply on 
Melange from 16th to 27th of March.

All, do keep an eye (and a calendar client reminder) on all GSoC 2015 dates [2]!

This year, we will be using slightly different procedure for assigning slots to 
selected projects. The experience from previous years made it possible to 
define the criteria that will be applied this year, and hopefully will be 
improved in the future:

1. Each project requires at least two mentors. The soundness of the project, 
the selection of reliable mentors and student is responsibility of its 
community. However, this year we strongly encourage the community to assign to 
the wannabe-GSoC-student some small programming tasks or bug fixes, in order to 
be sure that (s)he is familiar with the selected software, the programming 
environment, version control system, mailing list, etc and can code. Particular 
attention should be paid in the selection of mentors that won't disappear in 
the course of the GSoC.

2. Each OSGeo software will have one slot assigned, provided that the 
conditions at point 1 are met.

3. Like previous years, OSGeo will host some like-minded projects that 
requested it, and will assign 1 slot to each guest, provided that the 
conditions at point 1 are met.

4. This year we want to encourage projects that entail the integration between 
two or more OSGeo software. For this reason, one extra slot will be assigned to 
(sound) projects that aim at integrating two or more software, provided that 
mentors of respective communities are involved.

5. If the number of slots will allow it, extra slots can be assigned to 
projects that have gained a good rate of success in the course of past years 
(reliable -not disappearing- mentors, student success, etc).

Further discussion on specific slot assignments will take place among mentors 
in due time. This is the admins outline of this year's criteria.

Please send answers to this announcement to soc [3] list, and forward this mail 
to all relevant mailing lists of your knowledge.

And now, let s do this thing!
http://tinyurl.com/l32yzgp

Yours enthusiastically,

Madi and Anne
OSGeo GSoC Admins 2015

[1] 
http://google-opensource.blogspot.it/2015/03/mentoring-organizations-for-google.html
[2] https://www.google-melange.com/gsoc/events/google/gsoc2015
[3] http://lists.osgeo.org/mailman/listinfo/soc




--
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eumailto:margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not in 
any circumstance be regarded as stating an official position of the European 
Commission.

___
Discuss mailing list
disc...@lists.osgeo.orgmailto:disc...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

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