Re: [GRASS-dev] ubuntu 7.0.0RC1
Hi Martin, I also confirm, everything is ok now with sudo apt-get install grass70 Thank you very much! Best regards, Pedro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] SESSION_MANAGER environment variable not defined
Hi Anna, Sorry I let this languish! It installed without me explicitly asking it to be -- perhaps it was a dependency for something? In any case, it has made its way into my standard set of packages. I wonder if there is something between it and Unity keeping SESSION_MANAGER blank. Andy --- Andrew D. Wickert INSTAAR Geological Sciences, University of Colorado Boulder Now at: Universität Potsdam Institut für Erd- und Umweltwissenschaften Haus 29, Rm. 153 Karl-Liebknecht-Str. 24-25 14476 Potsdam-Golm, Deutschland On Wed, Jan 14, 2015 at 4:16 PM, Anna Petrášová kratocha...@gmail.com wrote: On Wed, Jan 14, 2015 at 8:59 AM, Andy Wickert wick...@colorado.edu wrote: Sorry, actually, they both give me problems, but the version that allows the GUI to start but not the add-layer dialog to open is 7.1.svn. Andy I am using Ubuntu 14.04 with wxPython 2.8 but I have self-compiled wxPython 3.0.1.1 for testing purposes. I don't have any similar problems. How did you get wxPython3, I don't think it's in standard repositories? --- Andrew D. Wickert INSTAAR Geological Sciences, University of Colorado Boulder Now at: Universität Potsdam Institut für Erd- und Umweltwissenschaften Haus 29, Rm. 153 Karl-Liebknecht-Str. 24-25 14476 Potsdam-Golm, Deutschland On Wed, Jan 14, 2015 at 2:55 PM, Andy Wickert wick...@colorado.edu wrote: Hi, apt-get version is 6.4.3. The version giving me problems with wxPython 3 is 7.1.svn Andy --- Andrew D. Wickert INSTAAR Geological Sciences, University of Colorado Boulder Now at: Universität Potsdam Institut für Erd- und Umweltwissenschaften Haus 29, Rm. 153 Karl-Liebknecht-Str. 24-25 14476 Potsdam-Golm, Deutschland On Wed, Jan 14, 2015 at 11:12 AM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2015-01-14 10:29 GMT+01:00 Andy Wickert wick...@colorado.edu: ERROR: wxGUI does not support wxPython 3.0.0.0 yet. Error in GUI startup. If necessary, please report this error to the GRASS developers. Switching to text mode now. which version are you using? Martin -- just to double-check, did you try adding a layer and have success in doing that? And what OS (and, if applicable, desktop) are you using? Fresh GRASS 7.0.0svn works together with wxPython 3 for me. Using Debian GNU/Linux unstable. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New splash screen for GRASS GIS 7?
I like this one - I think it well represents what GRASS is. (perhaps GRASS GIS?) GRASS. Bringing advanced geospatial technologies to the world. Helena Helena Mitasova Professor at the Department of Marine, Earth, and Atmospheric Sciences and Center for Geospatial Analytics North Carolina State University Raleigh, NC 27695-8208 hmit...@ncsu.edu http://geospatial.ncsu.edu/osgeorel/ All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.” On Jan 19, 2015, at 11:32 AM, Michael Barton wrote: Cool idea. Since GRASS is a global project, how about one of the first truly global like Mercator's of 1569 (https://en.m.wikipedia.org/wiki/History_of_cartography#/image/File:Mercator_1569.png) or Ortelius' of 1570 (https://en.m.wikipedia.org/wiki/History_of_cartography#/image/File:OrteliusWorldMap1570.jpg)? Better images than these from Wikipedia probably exist. With such a map, we could have a slightly different message on the splash screen too. Maybe something like OR GRASS. Advanced geospatial technology for everyone. Anyway. Those are a couple of ideas. Michael On Jan 17, 2015, at 3:58 AM, Yann Chemin yche...@gmail.com wrote: I for one, will welcome our new @!SPLASH!@ ... Yes +1 any wiki page to submit? On 17 January 2015 at 16:21, Markus Neteler nete...@osgeo.org wrote: Hi, I'd suggest, in order to clearly distinguish G6 from G7, to replace the current splash screen for the upcoming G7.0.0 release. We may consider to get community contributions for this. What do you think? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] porting i.spec.sam to grass7
On Jan 19, 2015 7:13 PM, Yann Chemin yche...@gmail.com wrote: Seems to be the last hurdle.. ogr_api.h In file included from /home/yann/dev/grass_yann/dist.x86_64-unknown-linux-gnu/include/grass/vect/digit.h:3:0, from /home/yann/dev/grass_yann/dist.x86_64-unknown-linux-gnu/include/grass/vector.h:4, from main.c:27: /home/yann/dev/grass_yann/dist.x86_64-unknown-linux-gnu/include/grass/vect/dig_structs.h:27:21: fatal error: ogr_api.h: No such file or directory #include ogr_api.h ^ compilation terminated. See the last line in this fix https://trac.osgeo.org/grass/changeset/64242 ... one more include you need. Markus -- On 19 January 2015 at 22:31, Markus Neteler nete...@osgeo.org wrote: On Mon, Jan 19, 2015 at 5:31 PM, Yann Chemin yche...@gmail.com wrote: Hi, porting to grass7 i.spec.sam (grass-addons/grass7/imagery/) I am getting a set of complaints like this: OBJ.x86_64-unknown-linux-gnu/spec_angle.o:(.bss+0x158): multiple definition of `Avector' OBJ.x86_64-unknown-linux-gnu/main.o:/home/yann/dev/grass-addons/grass7/imagery/i.spec.sam/main.c:92: first defined here while it is actually defined in global.h, and global.h is read in main.c as well as in spectral_angle.c . The line 92 in main.c is the first appearance, without declaring Avector (just using it). [neteler@pgis_north i.spec.sam]$ grep Avector *.h global.h:GLOBAL VEC *b, *Avector; I guess the GLOBAL declarations need to be fixed as time ago in other GRASS modules using extern. See for example: http://trac.osgeo.org/grass/changeset/32675/grass/trunk/raster/r.to.vect 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
[GRASS-dev] [GRASS GIS] #2554: v.nnstat: unwanted output about translation
#2554: v.nnstat: unwanted output about translation
---+
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: Addons | Version: svn-trunk
Keywords: v.nnstat translation info |Platform: Unspecified
Cpu: Unspecified|
---+
When I run v.nnstat I get output about translation that shouldn't be in
the module (see from 'Project-Id-Version'):
{{{
v.nnstat input=hospitals@PERMANENT
*** Nearest Neighbour Analysis results ***
Input settings .. 3D layer: 0 3D NNA: 0
Number of points .. 160
Area .. 209175870266.108368 [units^2]
Density of points . 0.00
Average distance between the nearest neighbours ... 14349.097
[units]
Average expected distance between the nearest neighbours .. 18078.642
[units]
Ratio rA/rE ... 0.793704
*** Results of two-tailed test of the mean ***
Null hypothesis: Point set is randomly distributed within the region.
Standard variate of the normal curve c = -4.992043
Null hypothesis CAN BE REJECTED at the significance levels alpha = 0.05
and alpha = 0.01 = point set is clustered.
Project-Id-Version: grassmods_fr
Report-Msgid-Bugs-To:
POT-Creation-Date: 2014-12-22 16:11+0100
PO-Revision-Date: 2014-01-01 11:35+0100
Last-Translator: Sylvain Maillard sylvain.maill...@gmail.com
Language-Team: Français grass-translati...@lists.osgeo.org
Language: fr
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Generator: Poedit 1.5.5
}}}
This seems to come from an empty, but translated G_message string. When I
comment that out I get the expected output ending at point set is
clustered:
{{{
Index: grass-addons/grass7/vector/v.nnstat/nearest_neighbour.cpp
===
--- grass-addons/grass7/vector/v.nnstat/nearest_neighbour.cpp (révision
64109)
+++ grass-addons/grass7/vector/v.nnstat/nearest_neighbour.cpp (copie de
travail)
@@ -134,7 +134,7 @@
if (nna-c = 2.58) {
G_message(_(Null hypothesis CAN BE REJECTED at the significance
levels alpha = 0.05 and alpha = 0.01 = point set is dispersed.));
}
-G_message(_());
+/*G_message(_());*/
}
void nn_statistics(struct points *pnts, struct nna_par *xD, struct
nearest *nna)
}}}
I don't really see any reason for this empty string, and if there is one,
then that string should probably not be marked for translation, or ?
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2554
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2553: v.kriging: ogr_api.h: No such file or directory
#2553: v.kriging: ogr_api.h: No such file or directory
-+--
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: Addons | Version: svn-trunk
Keywords: v.kriging ogr_api.h |Platform: Linux
Cpu: Unspecified |
-+--
Trying to install v.kriging, both via the g.extension wxGUI, or from the
addons source tree, I get the following error:
{{{
$ LANG=C make MODULE_TOPDIR=../../../../grass_trunk/dist.x86_64-unknown-
linux-gnu/
c++ -g -O2 -I/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64
-unknown-linux-gnu/include
-I/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-unknown-linux-
gnu/include -fopenmp -DPACKAGE=\grassmods\
-I/usr/include/postgresql -I/usr/include/pcl-1.7 -I/usr/include/eigen3
-I/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-unknown-linux-
gnu/include -I/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64
-unknown-linux-gnu/include -DRELDIR=\/data/home/mlennert/SRC/GRASS/grass-
addons/grass7/vector/v.kriging\ -o OBJ.x86_64-unknown-linux-gnu/utils.o
-c utils.cpp
In file included from
/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-unknown-linux-
gnu/include/grass/vect/digit.h:3:0,
from
/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-unknown-linux-
gnu/include/grass/vector.h:4,
from local_proto.h:16,
from utils.cpp:1:
/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-unknown-linux-
gnu/include/grass/vect/dig_structs.h:27:21: fatal error: ogr_api.h: No
such file or directory
#include ogr_api.h
^
compilation terminated.
../../../../grass_trunk/dist.x86_64-unknown-linux-
gnu//include/Make/Compile.make:35: recipe for target 'OBJ.x86_64-unknown-
linux-gnu/utils.o' failed
make: *** [OBJ.x86_64-unknown-linux-gnu/utils.o] Error 1
}}}
When I had a similar error a long time ago with i.pr, the solution was to
add 'EXTRA_CFLAGS = $(VECT_CFLAGS)' to the Makefile
[http://lists.osgeo.org/pipermail/grass-dev/2007-November/034353.html 1].
However, v.kriging's Makefile already contains that line.
{{{
$ gdal-config --cflags
-I/usr/include/gdal
}}}
System info:
{{{
Version de GRASS: 7.1.svn
Version SVN: 64098
Build Date: 2015-01-12
Build Platform: x86_64-unknown-linux-gnu
GDAL/OGR: 1.10.1
PROJ.4: 4.8.0
GEOS: 3.4.2
SQLite: 3.8.7.1
Python: 2.7.8
wxPython: 3.0.1.1
Plateforme: Linux-3.16.0-4-amd64-x86_64-with-debian-jessie-sid
}}}
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2553
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2554: v.nnstat: unwanted output about translation
#2554: v.nnstat: unwanted output about translation --+- Reporter: mlennert | Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: Component: Addons | Version: svn-trunk Resolution: fixed|Keywords: v.nnstat translation info Platform: Unspecified | Cpu: Unspecified --+- Changes (by neteler): * status: new = closed * resolution: = fixed Comment: Replying to [ticket:2554 mlennert]: I don't really see any reason for this empty string, and if there is one, then that string should probably not be marked for translation, or ? Right. Fixed in r64240. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2554#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale (UnicodeEncodeError)
#2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale (UnicodeEncodeError) +--- Reporter: santipardo | Owner: grass-dev@… Type: defect | Status: new Priority: blocker | Milestone: 7.0.0 Component: wxGUI | Version: svn-releasebranch70 Keywords: locale |Platform: Linux Cpu: x86-64 | +--- Changes (by martinl): * keywords: = locale * priority: normal = blocker -- Ticket URL: https://trac.osgeo.org/grass/ticket/2552#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] ubuntu 7.0.0RC1
2015-01-19 11:08 GMT+01:00 Martin Landa landa.mar...@gmail.com: the source of problems will be the line in control file Replaces: grass70 ( 7.0.0+0ubuntu3~) I have commented out these lines and regenerated packages again (as 7.0.0RC1-2). Could you please try to install it again? sudo apt-get update sudo apt-get install grass70 ? Thanks, Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale (UnicodeEncodeError)
#2552: GRASS 7.0 RC1 wxGUI: fails to launch in Spanish locale
(UnicodeEncodeError)
+---
Reporter: santipardo | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: svn-releasebranch70
Keywords: |Platform: Linux
Cpu: x86-64 |
+---
With Spanish locale (es_ES.UTF-8), GRASS 7.0 RC1 doesn't launch. I have
launched it perfectly in the same installation with locale en_US-UTF-8.
The problem is happening since beta 4.0.
CONF:
{{{
Linux Mint 17.1
$ locale | grep LANG
LANG=es_ES.UTF-8
}}}
TERMINAL OUTPUT:
{{{
Launching wxpython GUI in the background, please wait...
Traceback (most recent call last):
File /usr/bin/grass70, line 1461, in module
bash_startup()
File /usr/bin/grass70, line 1122, in bash_startup
_(3D raster MASK present)))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xc1' in
position 180: ordinal not in range(128)
ERROR: Variable 'LOCATION_NAME' not set
Traceback (most recent call last):
File /usr/lib/grass70/gui/wxpython/wxgui.py, line 37, in module
from lmgr.frame import GMFrame
File /usr/lib/grass70/gui/wxpython/lmgr/frame.py, line 50, in module
from lmgr.layertreeimport LayerTree, LMIcons
File /usr/lib/grass70/gui/wxpython/lmgr/layertree.py, line 37, in
module
from mapdisp.frameimport MapFrame
File /usr/lib/grass70/gui/wxpython/mapdisp/frame.py, line 65, in
module
class MapFrame(SingleMapFrame):
File /usr/lib/grass70/gui/wxpython/mapdisp/frame.py, line 71, in
MapFrame
page = None, Map = Map(), auimgr = None, name = 'MapWindow',
**kwargs):
File /usr/lib/grass70/gui/wxpython/core/render.py, line 408, in
__init__
self.mapfile = grass.tempfile(create = False) + '.ppm'
File /usr/lib/grass70/etc/python/grass/script/core.py, line 704, in
tempfile
return read_command(g.tempfile, flags=flags,
pid=os.getpid()).strip()
File /usr/lib/grass70/etc/python/grass/script/core.py, line 427, in
read_command
return handle_errors(returncode, stdout, args, kwargs)
File /usr/lib/grass70/etc/python/grass/script/core.py, line 310, in
handle_errors
returncode=returncode)
grass.exceptions.CalledModuleError: Module run None ['g.tempfile', '-d',
'pid=2237'] ended with error
Process ended with non-zero return code 1. See errors in the (error)
output.
}}}
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2552
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] ubuntu 7.0.0RC1
Hi all, 2015-01-18 4:39 GMT+01:00 Will Fields will.openfie...@gmail.com: That worked for me too. Thanks. first of all, thanks for testing. Finally I have access to Ubuntu machine, and I can confirm it. Installing grass70 package fails with The following packages have unmet dependencies: grass70 : Depends: grass70-core but it is not going to be installed Depends: grass70-gui but it is not going to be installed E: Unable to correct problems, you have held broken packages. But `apt-get show grass70` says Depends: grass70-core, grass70-gui It's strange, any expert here to explain this mystery? Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] ubuntu 7.0.0RC1
Hi, 2015-01-19 10:55 GMT+01:00 Martin Landa landa.mar...@gmail.com: But `apt-get show grass70` says Depends: grass70-core, grass70-gui It's strange, any expert here to explain this mystery? Martin the source of problems will be the line in control file Replaces: grass70 ( 7.0.0+0ubuntu3~) will check. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New splash screen for GRASS GIS 7?
Cool idea. Since GRASS is a global project, how about one of the first truly global like Mercator's of 1569 (https://en.m.wikipedia.org/wiki/History_of_cartography#/image/File:Mercator_1569.png) or Ortelius' of 1570 (https://en.m.wikipedia.org/wiki/History_of_cartography#/image/File:OrteliusWorldMap1570.jpg)? Better images than these from Wikipedia probably exist. With such a map, we could have a slightly different message on the splash screen too. Maybe something like GRASS. Bringing advanced geospatial technologies to the world. OR GRASS. Advanced geospatial technology for everyone. Anyway. Those are a couple of ideas. Michael On Jan 17, 2015, at 3:58 AM, Yann Chemin yche...@gmail.commailto:yche...@gmail.com wrote: I for one, will welcome our new @!SPLASH!@ ... Yes +1 any wiki page to submit? On 17 January 2015 at 16:21, Markus Neteler nete...@osgeo.orgmailto:nete...@osgeo.org wrote: Hi, I'd suggest, in order to clearly distinguish G6 from G7, to replace the current splash screen for the upcoming G7.0.0 release. We may consider to get community contributions for this. What do you think? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.orgmailto:grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- 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] porting i.spec.sam to grass7
On Mon, Jan 19, 2015 at 5:31 PM, Yann Chemin yche...@gmail.com wrote: Hi, porting to grass7 i.spec.sam (grass-addons/grass7/imagery/) I am getting a set of complaints like this: OBJ.x86_64-unknown-linux-gnu/spec_angle.o:(.bss+0x158): multiple definition of `Avector' OBJ.x86_64-unknown-linux-gnu/main.o:/home/yann/dev/grass-addons/grass7/imagery/i.spec.sam/main.c:92: first defined here while it is actually defined in global.h, and global.h is read in main.c as well as in spectral_angle.c . The line 92 in main.c is the first appearance, without declaring Avector (just using it). [neteler@pgis_north i.spec.sam]$ grep Avector *.h global.h:GLOBAL VEC *b, *Avector; I guess the GLOBAL declarations need to be fixed as time ago in other GRASS modules using extern. See for example: http://trac.osgeo.org/grass/changeset/32675/grass/trunk/raster/r.to.vect Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] porting i.spec.sam to grass7
Hi, porting to grass7 i.spec.sam (grass-addons/grass7/imagery/) I am getting a set of complaints like this: OBJ.x86_64-unknown-linux-gnu/spec_angle.o:(.bss+0x158): multiple definition of `Avector' OBJ.x86_64-unknown-linux-gnu/main.o:/home/yann/dev/grass-addons/grass7/imagery/i.spec.sam/main.c:92: first defined here while it is actually defined in global.h, and global.h is read in main.c as well as in spectral_angle.c . The line 92 in main.c is the first appearance, without declaring Avector (just using it). Yann -- ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Sun, Jan 18, 2015 at 5:49 PM, Markus Neteler nete...@osgeo.org wrote: If I turn the tests into a test suite script, I will use a vector from the the full version of the North Carolina sample dataset. Is this ok? This is ok. MarkusN says we should use the new dataset but I think it is not yet stable. I would invite everybody to switch to these simplified names: http://trac.osgeo.org/grass/wiki/SampleDataset At page bottom download the dataset (done by Helena). Is it stable enough? Anyway, first we have to solve the challenge of having the maps in different mapsets. How do you get them in examples and tests? Use name of mapset? Or expect everything to be on path? Once we decide to switch (for example in 7.1/trunk) we should do it officially, so we avoid the unclear situation caused by full NC and basic NC where the locations were incompatible and it was not defined which one to use. Which data you use when running the tests on you computer is your choice, so you can experiment with any dataset and develop your tests with the dataset which will be used in the future. I might be able to improve location handling in tests next month, or at least add the new NC and basic NC locations to my test server to accommodate the different tests (before the situation will stabilize). ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Mon, Jan 19, 2015 at 5:46 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Sun, Jan 18, 2015 at 5:49 PM, Markus Neteler nete...@osgeo.org wrote: If I turn the tests into a test suite script, I will use a vector from the the full version of the North Carolina sample dataset. Is this ok? This is ok. MarkusN says we should use the new dataset but I think it is not yet stable. I would invite everybody to switch to these simplified names: http://trac.osgeo.org/grass/wiki/SampleDataset At page bottom download the dataset (done by Helena). Is it stable enough? What is stable? The names, the size of the package or the selection of maps? Anyway, first we have to solve the challenge of having the maps in different mapsets. How do you get them in examples and tests? Use name of mapset? Or expect everything to be on path? Probably a simple g.mapsets call would be enough to get it in. Once we decide to switch (for example in 7.1/trunk) we should do it officially, so we avoid the unclear situation caused by full NC and basic NC where the locations were incompatible and it was not defined which one to use. I haven't used NC basic at all but would be happy to replace (all) my examples from full NC with the simplified names. Which data you use when running the tests on you computer is your choice, so you can experiment with any dataset and develop your tests with the dataset which will be used in the future. Yes but the point is that we need to switch to the simplified names as suggested by Helena (maybe with your collaboration in your lab): http://trac.osgeo.org/grass/wiki/SampleDataset At this point I could update the Piemonte location (also on the Web site) accordingly. I might be able to improve location handling in tests next month, or at least add the new NC and basic NC locations to my test server to accommodate the different tests (before the situation will stabilize). I am not sure what we are waiting for. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2532: TypeError: environment can only contain string when launching script on Windows
#2532: TypeError: environment can only contain string when launching script on
Windows
-+--
Reporter: annakrat | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: encoding |Platform: MSWindows 8
Cpu: Unspecified |
-+--
Comment(by annakrat):
Replying to [comment:14 glynn]:
Replying to [comment:13 annakrat]:
So I tried to encode the command string and I get different error:
{{{
raise err
xml.etree.ElementTree
.
ParseError
}}}
It seems that get_interface_description returns empty xml
Did you confirm that?
No, when I print the string I get xml, seems to be valid:
{{{
?xml version=1.0 encoding=UTF-8?
!DOCTYPE task SYSTEM C:\Users\akratoc\Programs\GRASS GIS 7.1.svn\gui\xml
\grass-interface.dtd
task name=test_workshopá.py
description
Adds the values of two rasters (A + B)
/description
...
}}}
I don't understand what's wrong with it.
Otherwise, my guess is that the XML is invalid due to encoding issues.
The program name is copied verbatim into the XML, in the task
name=... tag.
If GRASS was built with iconv support, the declared encoding of the XML
will be UTF-8; text nodes will be convert from the locale's encoding to
UTF-8 (and ,, will be converted to entities), but attribute values
aren't converted:
{{{
fprintf(stdout, task name=\%s\\n, st-pgm_name);
}}}
So, they need to be restricted to the intersection of the locale's
encoding and UTF-8 (which probably means ASCII).
I'm not sure that it's worth trying to support script names which
contain non-ASCII characters. However, scripts in directories whose names
contain non-ASCII characters need to be supported. The same applies to
other files; e.g. we can reasonably restrict map, mapset and location
names to ASCII, but we should support the situation where the database
path contains non-ASCII characters.
In any case, the GUI should be encoding the arguments which it passes to
Popen(); it shouldn't be passing unicode values.
Should the be encoding moved to `get_interface_description` in task.py?
The `EncodeString` function is in gui, not in python scripting library.
If I try to run the script (this time the script name is only ascii, but
the path has some non-ascii characters which are in cp1252), I get the gui
dialog and when I run it, I get an error:
{{{
Exception in thread Thread-28:
Traceback (most recent call last):
File C:\Users\akratoc\Programs\GRASS GIS
7.1.svn\Python27\lib\threading.py, line 810, in
__bootstrap_inner
self.run()
File C:\Users\akratoc\Programs\GRASS GIS
7.1.svn\gui\wxpython\core\gconsole.py, line 155, in run
self.resultQ.put((requestId, self.requestCmd.run()))
File C:\Users\akratoc\Programs\GRASS GIS
7.1.svn\gui\wxpython\core\gcmd.py, line 575, in run
env = self.env)
File C:\Users\akratoc\Programs\GRASS GIS
7.1.svn\gui\wxpython\core\gcmd.py, line 161, in __init__
args = map(EncodeString, args)
File C:\Users\akratoc\Programs\GRASS GIS
7.1.svn\gui\wxpython\core\gcmd.py, line 92, in EncodeString
return string.encode(_enc)
File C:\Users\akratoc\Programs\GRASS GIS
7.1.svn\Python27\lib\encodings\cp1252.py, line 12, in
encode
return
codecs.charmap_encode(input,errors,encoding_table)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe1 in
position 38: ordinal not in range(128)
}}}
because in Popen class in
[http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/core/gcmd.py#L161
gcmd.py] some of the arguments are of type `str`, some are `unicode`. So
if encode only the unicode ones, it starts to work.
{{{
for i in range(len(args)):
if type(args[i]) != str:
args[i] = EncodeString(args[i])
}}}
So I am not sure what should I do with these results.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2532#comment:15
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2553: v.kriging: ogr_api.h: No such file or directory
#2553: v.kriging: ogr_api.h: No such file or directory
---+
Reporter: mlennert | Owner: grass-dev@…
Type: defect| Status: closed
Priority: normal| Milestone:
Component: Addons| Version: svn-trunk
Resolution: fixed |Keywords: v.kriging, ogr_api.h
Platform: Linux | Cpu: Unspecified
---+
Changes (by neteler):
* keywords: v.kriging ogr_api.h = v.kriging, ogr_api.h
* status: new = closed
* resolution: = fixed
Comment:
Fixed in r64242 - it requires also
{{{
EXTRA_INC = ... $(PROJINC)
}}}
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2553#comment:1
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] porting i.spec.sam to grass7
On Mon, Jan 19, 2015 at 11:31 AM, Yann Chemin yche...@gmail.com wrote:
Hi,
porting to grass7 i.spec.sam (grass-addons/grass7/imagery/)
I am getting a set of complaints like this:
OBJ.x86_64-unknown-linux-gnu/spec_angle.o:(.bss+0x158): multiple
definition of `Avector'
OBJ.x86_64-unknown-linux-gnu/main.o:/home/yann/dev/grass-addons/grass7/imagery/i.spec.sam/main.c:92:
first defined here
while it is actually defined in global.h, and global.h is read in main.c
as well as in spectral_angle.c . The line 92 in main.c is the first
appearance, without declaring Avector (just using it).
You just miss an include guard:
#ifndef GRANDFATHER_H
#define GRANDFATHER_H
struct foo {
int member;
};
#endif /* GRANDFATHER_H */
(example from http://en.wikipedia.org/wiki/Include_guard)
Compare:
http://trac.osgeo.org/grass/browser/grass-addons/grass6/imagery/i.spec.sam/global.h?rev=50996
http://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.edge/gauss.h?rev=52501
Yann
--
___
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] Planning GRASS GIS 7.0.0RC1
On Jan 19, 2015, at 1:13 PM, Vaclav Petras wrote: On Mon, Jan 19, 2015 at 12:08 PM, Markus Neteler nete...@osgeo.org wrote: On Mon, Jan 19, 2015 at 5:46 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Sun, Jan 18, 2015 at 5:49 PM, Markus Neteler nete...@osgeo.org wrote: If I turn the tests into a test suite script, I will use a vector from the the full version of the North Carolina sample dataset. Is this ok? This is ok. MarkusN says we should use the new dataset but I think it is not yet stable. I would invite everybody to switch to these simplified names: http://trac.osgeo.org/grass/wiki/SampleDataset At page bottom download the dataset (done by Helena). Is it stable enough? What is stable? The names, the size of the package or the selection of maps? There is one thing about this data set that I would like to change - the name of the location itself. Given that distribution of data by mapsets does not work well, all data sets should be distributed as locations (or external data) and then we won't need the loc part in the name. So I suggest to use the name ncspm_baseline_v1.0 or ncarolina_baseline_v1.0 instead of loc_ncspm_baseline and we should have a single place where this data set is stored (on grass website under data?) to avoid creating multiple versions of the data set. I will remove mine and replace it by a link. Then the italian version of this data set would be piemonte_baseline Naming, selection and placement into mapsets. Anyway, first we have to solve the challenge of having the maps in different mapsets. How do you get them in examples and tests? Use name of mapset? Or expect everything to be on path? Probably a simple g.mapsets call would be enough to get it in. Switching of mapset is not applicable in tests (tests are isolated using GRASS means, i.e. processes and mapsets) but yes, changing path is the way. Do you think we should add it to each example which needs it? For tests it would be quite easy to do something like set up the search path automatically according to existing mapsets or search path set in PERMANENT but it is desired? I don't have a strong opinion, explicit g.mapsets calls sounds as a safe way to go but putting @mapsetname everywhere would also work, am I right? I suggest to distribute all mapsets with at least the baseline data set in PERMANENT. Then you would have to deal with data in different mapsets (and in fact in different locations) only for the examples where you need to combine data from two or more different specialized mapsets - for example lidar and networks. Once we decide to switch (for example in 7.1/trunk) we should do it officially, so we avoid the unclear situation caused by full NC and basic NC where the locations were incompatible and it was not defined which one to use. I haven't used NC basic at all but would be happy to replace (all) my examples from full NC with the simplified names. It's completely the same for me. I agree - we should retire all other small data sets and mark them as retired, although I expect that nc_spm_08 and nc_spm_08_grass7 will be still used for a while. I will post the relevant notes on my website and in our courses as well. Which data you use when running the tests on you computer is your choice, so you can experiment with any dataset and develop your tests with the dataset which will be used in the future. Yes but the point is that we need to switch to the simplified names as suggested by Helena (maybe with your collaboration in your lab): http://trac.osgeo.org/grass/wiki/SampleDataset At this point I could update the Piemonte location (also on the Web site) accordingly. Replacing the old one by a new one on my server should be quite simple because it is already there. Same if we decide to just use new NC instead of currently used full NC. Adding new location is what is very unpleasant to do now. I agree. I might be able to improve location handling in tests next month, or at least add the new NC and basic NC locations to my test server to accommodate the different tests (before the situation will stabilize). I am not sure what we are waiting for. If it is stable enough for trunk (i.e. it is worth to modify examples and tests) and it is clear how to access the maps in other mapsets then we just have to announce the official switch. Will this be the default dataset for 7.1 then? GRASS7.1 would be a good target. I am also working on a new external data set and on locations in other coordinate systems with some limited but hopefully meaningful map layers in them. Helena Vaclav 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
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC1
On Mon, Jan 19, 2015 at 12:08 PM, Markus Neteler nete...@osgeo.org wrote: On Mon, Jan 19, 2015 at 5:46 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Sun, Jan 18, 2015 at 5:49 PM, Markus Neteler nete...@osgeo.org wrote: If I turn the tests into a test suite script, I will use a vector from the the full version of the North Carolina sample dataset. Is this ok? This is ok. MarkusN says we should use the new dataset but I think it is not yet stable. I would invite everybody to switch to these simplified names: http://trac.osgeo.org/grass/wiki/SampleDataset At page bottom download the dataset (done by Helena). Is it stable enough? What is stable? The names, the size of the package or the selection of maps? Naming, selection and placement into mapsets. Anyway, first we have to solve the challenge of having the maps in different mapsets. How do you get them in examples and tests? Use name of mapset? Or expect everything to be on path? Probably a simple g.mapsets call would be enough to get it in. Switching of mapset is not applicable in tests (tests are isolated using GRASS means, i.e. processes and mapsets) but yes, changing path is the way. Do you think we should add it to each example which needs it? For tests it would be quite easy to do something like set up the search path automatically according to existing mapsets or search path set in PERMANENT but it is desired? I don't have a strong opinion, explicit g.mapsets calls sounds as a safe way to go but putting @mapsetname everywhere would also work, am I right? Once we decide to switch (for example in 7.1/trunk) we should do it officially, so we avoid the unclear situation caused by full NC and basic NC where the locations were incompatible and it was not defined which one to use. I haven't used NC basic at all but would be happy to replace (all) my examples from full NC with the simplified names. It's completely the same for me. Which data you use when running the tests on you computer is your choice, so you can experiment with any dataset and develop your tests with the dataset which will be used in the future. Yes but the point is that we need to switch to the simplified names as suggested by Helena (maybe with your collaboration in your lab): http://trac.osgeo.org/grass/wiki/SampleDataset At this point I could update the Piemonte location (also on the Web site) accordingly. Replacing the old one by a new one on my server should be quite simple because it is already there. Same if we decide to just use new NC instead of currently used full NC. Adding new location is what is very unpleasant to do now. I might be able to improve location handling in tests next month, or at least add the new NC and basic NC locations to my test server to accommodate the different tests (before the situation will stabilize). I am not sure what we are waiting for. If it is stable enough for trunk (i.e. it is worth to modify examples and tests) and it is clear how to access the maps in other mapsets then we just have to announce the official switch. Will this be the default dataset for 7.1 then? Vaclav Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] porting i.spec.sam to grass7
Seems to be the last hurdle.. ogr_api.h In file included from /home/yann/dev/grass_yann/dist.x86_64-unknown-linux-gnu/include/grass/vect/digit.h:3:0, from /home/yann/dev/grass_yann/dist.x86_64-unknown-linux-gnu/include/grass/vector.h:4, from main.c:27: /home/yann/dev/grass_yann/dist.x86_64-unknown-linux-gnu/include/grass/vect/dig_structs.h:27:21: fatal error: ogr_api.h: No such file or directory #include ogr_api.h ^ compilation terminated. -- On 19 January 2015 at 22:31, Markus Neteler nete...@osgeo.org wrote: On Mon, Jan 19, 2015 at 5:31 PM, Yann Chemin yche...@gmail.com wrote: Hi, porting to grass7 i.spec.sam (grass-addons/grass7/imagery/) I am getting a set of complaints like this: OBJ.x86_64-unknown-linux-gnu/spec_angle.o:(.bss+0x158): multiple definition of `Avector' OBJ.x86_64-unknown-linux-gnu/main.o:/home/yann/dev/grass-addons/grass7/imagery/i.spec.sam/main.c:92: first defined here while it is actually defined in global.h, and global.h is read in main.c as well as in spectral_angle.c . The line 92 in main.c is the first appearance, without declaring Avector (just using it). [neteler@pgis_north i.spec.sam]$ grep Avector *.h global.h:GLOBAL VEC *b, *Avector; I guess the GLOBAL declarations need to be fixed as time ago in other GRASS modules using extern. See for example: http://trac.osgeo.org/grass/changeset/32675/grass/trunk/raster/r.to.vect Markus -- ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] porting i.spec.sam to grass7
(the mail from my mobile isn't yet here, so I try again) On Mon, Jan 19, 2015 at 7:13 PM, Yann Chemin yche...@gmail.com wrote: Seems to be the last hurdle.. ogr_api.h In file included from /home/yann/dev/grass_yann/dist.x86_64-unknown-linux-gnu/include/grass/vect/digit.h:3:0, from /home/yann/dev/grass_yann/dist.x86_64-unknown-linux-gnu/include/grass/vector.h:4, from main.c:27: /home/yann/dev/grass_yann/dist.x86_64-unknown-linux-gnu/include/grass/vect/dig_structs.h:27:21: fatal error: ogr_api.h: No such file or directory #include ogr_api.h ^ compilation terminated. -- You need to add in the Makefile: EXTRA_INC = $(PROJINC) Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] ubuntu 7.0.0RC1
Hi Martin, works fine now for me! Many thanks! Cheers Stefan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
