From pertusus at free.fr Sun Mar 1 08:01:15 2015
From: pertusus at free.fr (Patrice Dumas)
Date: Sun, 1 Mar 2015 17:01:15 +0100
Subject: [GRASS-dev] port of v.points.cog to python
Message-ID: <20150301160115.GA25881@free.fr>
Hello,
Here is a rewrite of the v.points.cog module in python. I tried
translating code only, keeping the code organization, variables names as it
was previously to help those who would want to review the differences
with the shell script. I also did the few changes required for changes
in grass7, but there weren't that much since python function already
abstract some commands.
I did a svn copy of the grass6 module before doing the modifications.
I cannot (and don't want to...) claim any copyright on a code translation.
I didn't test thoroughly, but since it is code translation, I don't expect
big surprises.
--
Pat
-------------- next part --------------
Index: grass7/vector/Makefile
===================================================================
--- grass7/vector/Makefile (r?vision 64773)
+++ grass7/vector/Makefile (copie de travail)
@@ -35,6 +35,7 @@
v.out.ply \
v.out.png \
v.ply.rectify \
+ v.points.cog \
v.stats \
v.surf.icw \
v.surf.mass \
Index: grass7/vector/v.points.cog/description.html
===================================================================
--- grass7/vector/v.points.cog/description.html (r?vision 64773)
+++ grass7/vector/v.points.cog/description.html (copie de travail)
@@ -1,53 +0,0 @@
-DESCRIPTION
-
-
-v.points.cog condenses points or centroids sharing
-a common attribute into a single point in a new vector map at their
-average position (center of gravity).
-
-For this to work well your clusters of points must be gregarious
-(Gaussian distribution) - if two groups of points habitate in two
-corners of the map the output point will fall in the center and
-match niether well.
-
-If needed you can use v.digit to adjust point positions
-created by this module,
-or use this module as a preprocessing step before running
-v.label.sa to deal with overlapping labels automatically.
-
-
-
-
-
EXAMPLE
-
-Create single points at the average of all points in the
-bugsites map, and place a single label there.
-
-
-v.points.cog in=bugsites out=bug_cog column=str1
-
-d.vect -c bugsites color=none icon=basic/circle
-
-d.vect bug_cog disp=attr attrcol=str1 lcolor=black \
- lsize=14 xref=center yref=center bgcolor=white
-
SEE ALSO
-
-v.label.sa
-v.label
-v.digit
-
-
-
-AUTHOR
-
-Hamish Bowman
-Dept. Marine Science
-University of Otago
-Dunedin, New Zealand
-
-
-
-Last changed: $Date$
Index: grass7/vector/v.points.cog/v.points.cog
===================================================================
--- grass7/vector/v.points.cog/v.points.cog (r?vision 64773)
+++ grass7/vector/v.points.cog/v.points.cog (copie de travail)
@@ -1,142 +0,0 @@
-#!/bin/sh
-#
-############################################################################
-#
-# MODULE: v.points.cog
-#
-# AUTHOR(S): Hamish Bowman
-#
-# PURPOSE: Condense points or centroids sharing a common attribute into a single point
-#
-# COPYRIGHT: (c) 2010 Hamish Bowman, and the GRASS Development Team
-#
-# This program is free software under the GNU General Public
-# License (>=v2). Read the file COPYING that comes with GRASS
-# for details.
-#
-#############################################################################
-#%Module
-#% description: Condense points or centroids sharing a common attribute into a single point.
-#% keywords: vector, cluster
-#%End
-#%option
-#% key: input
-#% type: string
-#% gisprompt: old,vector,vector
-#% description: Name of input vector map
-#% required : yes
-#%end
-#%option
-#% key: output
-#% type: string
-#% gisprompt: new,vector,vector
-#% description: Name for output vector map
-#% required : yes
-#%end
-#%option
-#% key: column
-#% type: string
-#% description: Column containing common attribute
-#% required : yes
-#%end
-#%option
-#% key: layer
-#% type: integer
-#% answer: 1
-#% description: Layer number
-#% required: no
-#%end
-
-##%option
-##% key: type
-##% type: string
-##% description: Feature type(s)
-##% options: point,centroid
-##% answer: point
-##% required: no
-##% multiple: yes
-##%end
-
-
-if [ -z "$GISBASE" ] ; then
- echo "You must be in GRASS GIS to run this program." 1>&2
- exit 1
-fi
-
-if [ "$1" != "@ARGS_PARSED@" ] ; then
- exec g.parser "$0" "$@"
-fi
-
-MAP="$GIS_OPT_INPUT"
-COLUMN="$GIS_OPT_COLUMN"
-LAYER="$GIS_OPT_LAYER"
-
-# check for input map
-eval `g.findfile element=vector file="$MAP"`
-if [ ! "$file" ] ; then
- g.message -e "Vector map <$MAP> does not exist."
- exit 1
-fi
-
-# check for column
-if [ `v.info -c "$MAP" layer="$LAYER" --quiet | cut -f2 -d'|' | grep -c "^$COLUMN$"` -ne 1 ] ; then
- g.message -e "Column <$COLUMN> not found."
- exit 1
-fi
-
-# get column details so we can recreate it.
-# The db.* modules need special care when querying from @another mapset
-DB=`v.db.connect "$MAP" -g layer="$LAYER" fs='|' | cut -f4 -d'|'`
-BASENAME=`echo "$MAP" | sed -e 's/@.*//'`
-db.describe -c table="$BASENAME" database="$DB" > /dev/null
-if [ $? -ne 0 ] ; then
- g.message -e "Unable to describe table"
- exit 1
-fi
-COLUMN_DESC=`db.describe -c table="$BASENAME" database="$DB" | grep " $COLUMN:" | cut -f3- -d:`
-
-
-if [ `echo "$COLUMN_DESC" | grep -c CHARACTER` -eq 1 ] ; then
- COLUMN_TYPE="string"
- COLUMN_LEN=`echo "$COLUMN_DESC" | cut -f2 -d:`
- COLUMN_DEFN="varchar($COLUMN_LEN)"
-else
- COLUMN_TYPE="number"
- COLUMN_DEFN=`echo "$COLUMN_DESC" | cut -f1 -d:`
-fi
-
-# cheap hack to avoid conflict
-if [ "$COLUMN" = "cat" ] ; then
- OUT_COLUMN="cat_"
-else
- OUT_COLUMN="$COLUMN"
-fi
-
-
-(
-IFS='|'
-for ITEM in `v.db.select "$MAP" -c column="$COLUMN" layer="$LAYER" | sort | uniq | tr '\n' '|'` ; do
- #echo "[$ITEM]"
- if [ "$COLUMN_TYPE" = "string" ] ; then
- WHERE_STR="$COLUMN = '$ITEM'"
- else
- WHERE_STR="$COLUMN = $ITEM"
- fi
-
- v.out.ascii "$MAP" column="$COLUMN" layer="$LAYER" where="$WHERE_STR" | \
- awk -F'|' \
- 'BEGIN { sum_x=0; sum_y=0; i=0 }
- { sum_x += $1; sum_y += $2; i++ }
- END { if(i>0) { printf("%.15g|%.15g|%s\n", sum_x/i, sum_y/i, $4) } }'
-done
-) | v.in.ascii out="$GIS_OPT_OUTPUT" columns="x double, y double, $OUT_COLUMN $COLUMN_DEFN"
-#echo columns="x double, y double, $OUT_COLUMN $COLUMN_DEFN"
-
-retval=$?
-
-# cleanup cheap hack
-if [ $COLUMN = "cat" ] ; then
- v.db.dropcol map="$GIS_OPT_OUTPUT" column="cat_" --quiet
-fi
-
-exit $retval
Index: grass7/vector/v.points.cog/v.points.cog.py
===================================================================
--- grass7/vector/v.points.cog/v.points.cog.py (r?vision 64773)
+++ grass7/vector/v.points.cog/v.points.cog.py (copie de travail)
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/usr/bin/env python
#
############################################################################
#
@@ -57,86 +57,74 @@
##% multiple: yes
##%end
+import sys
+import grass.script as grass
-if [ -z "$GISBASE" ] ; then
- echo "You must be in GRASS GIS to run this program." 1>&2
- exit 1
-fi
+def main():
-if [ "$1" != "@ARGS_PARSED@" ] ; then
- exec g.parser "$0" "$@"
-fi
+ map = options['input']
+ column = options['column']
+ layer = options['layer']
+ output = options['output']
-MAP="$GIS_OPT_INPUT"
-COLUMN="$GIS_OPT_COLUMN"
-LAYER="$GIS_OPT_LAYER"
+ result = grass.find_file(map, element='vector')
+ if len(result['name']) == 0:
+ grass.fatal(_("Vector map <%s> does not exist") % map)
-# check for input map
-eval `g.findfile element=vector file="$MAP"`
-if [ ! "$file" ] ; then
- g.message -e "Vector map <$MAP> does not exist."
- exit 1
-fi
+ if column not in grass.vector_columns(map, layer).keys():
+ grass.fatal(_("Column <%s>, layer %s not found") % (map, layer))
-# check for column
-if [ `v.info -c "$MAP" layer="$LAYER" --quiet | cut -f2 -d'|' | grep -c "^$COLUMN$"` -ne 1 ] ; then
- g.message -e "Column <$COLUMN> not found."
- exit 1
-fi
+ # get column details so we can recreate it.
+ # The db.* modules need special care when querying from @another mapset
+ map_connection_info = grass.vector_db(map)[int(layer)]
+ db = map_connection_info['database']
+ basename = map.split("@")[0]
-# get column details so we can recreate it.
-# The db.* modules need special care when querying from @another mapset
-DB=`v.db.connect "$MAP" -g layer="$LAYER" fs='|' | cut -f4 -d'|'`
-BASENAME=`echo "$MAP" | sed -e 's/@.*//'`
-db.describe -c table="$BASENAME" database="$DB" > /dev/null
-if [ $? -ne 0 ] ; then
- g.message -e "Unable to describe table"
- exit 1
-fi
-COLUMN_DESC=`db.describe -c table="$BASENAME" database="$DB" | grep " $COLUMN:" | cut -f3- -d:`
+ map_description = grass.db_describe(basename, database=db)
+ if 'cols' not in map_description:
+ grass.fatal(_("Unable to describe table"))
+ for column_desc in map_description['cols']:
+ if column_desc[0] == column:
+ break
+ if 'CHARACTER' in column_desc[1]:
+ column_type = "string"
+ column_len = column_desc[2]
+ column_defn = "varchar(%d)" % (column_len)
+ else:
+ column_type = "number"
+ column_defn = column_desc[1]
-if [ `echo "$COLUMN_DESC" | grep -c CHARACTER` -eq 1 ] ; then
- COLUMN_TYPE="string"
- COLUMN_LEN=`echo "$COLUMN_DESC" | cut -f2 -d:`
- COLUMN_DEFN="varchar($COLUMN_LEN)"
-else
- COLUMN_TYPE="number"
- COLUMN_DEFN=`echo "$COLUMN_DESC" | cut -f1 -d:`
-fi
+ # cheap hack to avoid conflict
+ if column == 'cat':
+ out_column = "cat_"
+ else:
+ out_column = column
-# cheap hack to avoid conflict
-if [ "$COLUMN" = "cat" ] ; then
- OUT_COLUMN="cat_"
-else
- OUT_COLUMN="$COLUMN"
-fi
+ average_points_positions = ''
+ for item in sorted(set(grass.vector_db_select(map, columns=column, layer=int(layer))['values'])):
+ if column_type == "string":
+ where_str = "%s = '%s'" % (column, item)
+ else:
+ where_str = "%s = %s" % (column, str(item))
+
+ out_ascii_output = grass.read_command('v.out.ascii', input=map, output='-', column=column, layer=layer, where=where_str).splitlines()
+ if len(out_ascii_output) > 1:
+ sum_x = 0.
+ sum_y = 0.
+ for item_point in out_ascii_output:
+ position = item_point.split('|')
+ sum_x += float(position[0])
+ sum_y += float(position[1])
+ average_points_positions += "%.15g|%.15g|%s\n" % (sum_x/len(out_ascii_output), sum_y/len(out_ascii_output), position[-1])
+ retval = grass.write_command('v.in.ascii', stdin=average_points_positions, input='-', output=output, columns="x double, y double, %s %s" % (out_column, column_defn))
+ # cleanup cheap hack
+ if column == 'cat':
+ grass.run_command('v.db.dropcol', map=output, column='cat_', quiet=True)
-(
-IFS='|'
-for ITEM in `v.db.select "$MAP" -c column="$COLUMN" layer="$LAYER" | sort | uniq | tr '\n' '|'` ; do
- #echo "[$ITEM]"
- if [ "$COLUMN_TYPE" = "string" ] ; then
- WHERE_STR="$COLUMN = '$ITEM'"
- else
- WHERE_STR="$COLUMN = $ITEM"
- fi
+ sys.exit(retval)
- v.out.ascii "$MAP" column="$COLUMN" layer="$LAYER" where="$WHERE_STR" | \
- awk -F'|' \
- 'BEGIN { sum_x=0; sum_y=0; i=0 }
- { sum_x += $1; sum_y += $2; i++ }
- END { if(i>0) { printf("%.15g|%.15g|%s\n", sum_x/i, sum_y/i, $4) } }'
-done
-) | v.in.ascii out="$GIS_OPT_OUTPUT" columns="x double, y double, $OUT_COLUMN $COLUMN_DEFN"
-#echo columns="x double, y double, $OUT_COLUMN $COLUMN_DEFN"
-
-retval=$?
-
-# cleanup cheap hack
-if [ $COLUMN = "cat" ] ; then
- v.db.dropcol map="$GIS_OPT_OUTPUT" column="cat_" --quiet
-fi
-
-exit $retval
+if __name__ == "__main__":
+ options, flags = grass.parser()
+ main()
From neteler at osgeo.org Sun Mar 1 10:02:47 2015
From: neteler at osgeo.org (Markus Neteler)
Date: Sun, 1 Mar 2015 19:02:47 +0100
Subject: [GRASS-dev] [GRASS-PSC] RFC 4: Release procedure
In-Reply-To:
References: <539821A5.4010109@club.worldonline.be>
Message-ID:
Hi,
On Tue, Feb 17, 2015 at 1:54 PM, Markus Neteler wrote:
> On Fri, Jun 20, 2014 at 3:39 AM, Scott Mitchell wrote:
>> Agreed, and I like Markus? idea of testing it on an upcoming release.
>
> (just a low priority comment here)
>
> While doing so it turns out that one week between RC2 and final is a bit short.
> And some urgent fixes came in only during the RC procedure. We need to
> [add] a phrase if this requires a new RC (not this time though!) or not
> or depends.
Overall, we got the release out :-)
Any opinions on above remaining issue?
> Overall, RFC4 looks pretty reasonable to me.
Let's vote soon (once above issue is added to RFC4).
Markus
From andrewwickert at gmail.com Sun Mar 1 10:40:41 2015
From: andrewwickert at gmail.com (Andy Wickert)
Date: Sun, 1 Mar 2015 12:40:41 -0600
Subject: [GRASS-dev] A better r.fillnulls
Message-ID:
Hi GRASS-dev,
When I use r.fillnulls, I am often faced with the problem that it breaks
the domain up into blocks, thus (1) creating discontinuities and/or (2)
having problems in regions where there is insufficient data. (2) is
important because I am often trying to just create some smooth variation
between two datasets or fill in less-important regions to have a full grid
to be able to run a utility or model.
My workaround as of now is this:
r.to.points in=map out=map type=point column=attrcol
v.surf.bspline in=map raster_output=mapSplines column=attrcol
# But the spline fit makes the real data blurry too, so patch the spline fit
# in-between the data points
r.patch in=map,mapSplines out=mapFilled
I find this to be preferable for both the reasons stated above, and was
wondering if it would be worthwhile to think about including multiple
methods for r.fillnulls so one could do something like this too.
Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From neteler at osgeo.org Sun Mar 1 11:37:02 2015
From: neteler at osgeo.org (Markus Neteler)
Date: Sun, 1 Mar 2015 20:37:02 +0100
Subject: [GRASS-dev] A better r.fillnulls
In-Reply-To:
References:
Message-ID:
On Sun, Mar 1, 2015 at 7:40 PM, Andy Wickert wrote:
...
> I find this to be preferable for both the reasons stated above, and was
> wondering if it would be worthwhile to think about including multiple
> methods for r.fillnulls so one could do something like this too.
Did you use the GRASS 6 version? Because in GRASS 7 several methods
have been implemented:
http://grass.osgeo.org/grass70/manuals/r.fillnulls.html
method: Interpolation method to use
Options: bilinear, bicubic, rst
Default: rst
Both bilinear and bicubic use r.resamp.bspline.
Markus
From hellik at web.de Sun Mar 1 13:54:45 2015
From: hellik at web.de (Helmut Kudrnovsky)
Date: Sun, 1 Mar 2015 13:54:45 -0800 (PST)
Subject: [GRASS-dev] grass addon sync to github
Message-ID: <1425246885917-5190784.post@n6.nabble.com>
Hi devs,
I have a few g7-addons in grass svn and I want to put them also in github.
do you know any script/tool to sync addons in svn with github?
-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/grass-addon-sync-to-github-tp5190784.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
From trac at osgeo.org Sun Mar 1 15:05:31 2015
From: trac at osgeo.org (GRASS GIS)
Date: Sun, 01 Mar 2015 23:05:31 -0000
Subject: [GRASS-dev] [GRASS GIS] #2605: d.rast.leg: invalid literal for
float(): rectangle
Message-ID: <042.c198e9d03e590749a56cb0f8e4006a81@osgeo.org>
#2605: d.rast.leg: invalid literal for float(): rectangle
-------------------------+--------------------------------------------------
Reporter: pertusus | Owner: grass-dev@?
Type: defect | Status: new
Priority: normal | Milestone: 7.0.1
Component: Display | Version: svn-releasebranch70
Keywords: | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
I get a traceback for d.rast.leg.
{{{
d.rast.leg raster_selection_basins_change lines=2
}}}
{{{
Traceback (most recent call last):
File "/usr/local/grass-7.0.0svn//scripts/d.rast.leg", line 167, in
main()
File "/usr/local/grass-7.0.0svn//scripts/d.rast.leg", line 103, in main
f = tuple([float(x) for x in s.split()[1:5]])
ValueError: invalid literal for float(): rectangle:
}}}
This is triggered by a wrong parsing of d.info which returns:
{{{
frame rectangle: 0.000000 640.000000 0.000000 480.000000
}}}
Original code is
[float(x) for x in s.split()[1:5]]
which naturally the to x being 'rectangle:'
I attach a patch where I propose instead:
[float(x) for x in s.split(":")[1].split()[0:4]]
It seems more robust, though I don't know if the : will be there forever.
Overall, the approach is not very robust, but I have no idea on what's
going on so I only propose that fix which may not be appropriate in other
cases.
--
Ticket URL:
GRASS GIS
From trac at osgeo.org Sun Mar 1 18:56:22 2015
From: trac at osgeo.org (GRASS GIS)
Date: Mon, 02 Mar 2015 02:56:22 -0000
Subject: [GRASS-dev] [GRASS GIS] #2606: Bugs in r.sun
Message-ID: <042.0c578eee7068ec8f15b5021f378c131f@osgeo.org>
#2606: Bugs in r.sun
----------------------+-----------------------------------------------------
Reporter: ojni0001 | Owner: grass-dev@?
Type: defect | Status: new
Priority: normal | Milestone:
Component: Default | Version: unspecified
Keywords: | Platform: MSWindows 7
Cpu: x86-64 |
----------------------+-----------------------------------------------------
I am new to this, so some things I write here may not be how it should be.
My environment:
Win7 x64
GRASS Version (7beta and RC1) and hence 32 bit binary
(although I mentioned GRASS7, but it may be present in GRASS 6, and
earlier versions)
I have 2 issues, probably needs 2 tickets but I am mentioning here both.
I used a virtual landscape with elevation = constant (i.e. flat)
Issue 1.
I found that if I am using the aspect raster, zero degree is East and 270
is South (as mentioned in the help).
But if I am using a single value for aspect, zero or 360 degrees is North
and 180 degree is
South. I don't know if 90 degree is East or West. So, either help document
has to be changed or the algorithm.
Issue 2.
When the slope is more than 60 degrees (probably from 45 degrees) facing
North (northwards from east or west and North), the global radiation
values are increasing
i.e. the radiation value for slope of 70 degrees is more than when the
slope is 60 degrees
the radiation value for slope of 90 degrees is more than when the slope
is 80 degrees
Here, is a small table for demonstration (aspect of 0 or 360 is North, as
mentioned in issue 1 above)
Jan->17 (day=17), Feb->16 (day=47), Mar->16 (day=75) April->15 (day=105),
May->15 (day=135)
slope aspect Jan Feb Mar Apr May
10 345 1.61 2.45 3.59 5.24 6.52
20 345 0.93 1.73 2.93 4.70 6.18
30 345 0.36 1.04 2.21 4.03 5.67
40 345 0.13 0.46 1.49 3.26 5.01
50 345 0.12 0.15 0.85 2.42 4.22
60 345 0.11 0.16 0.85 2.38 4.17
70 345 0.10 '''0.59 1.63 3.38 5.12'''
80 345 '''0.54 1.29 2.47 4.30 5.94'''
90 345 '''1.20 2.05 3.28 5.11 6.62'''
10 360 1.59 2.42 3.57 5.23 6.52
20 360 0.87 1.66 2.87 4.67 6.17
30 360 0.27 0.91 2.11 3.99 5.66
40 360 0.13 0.26 1.30 3.21 5.00
50 360 0.12 0.14 0.47 2.36 4.21
60 360 0.11 0.13 0.56 2.48 4.35
70 360 '''0.10 0.35 1.51 3.49 5.32
'''
80 360 '''0.38 1.12 2.42 4.41 6.15
'''
90 360 '''1.08 1.97 3.28 5.22 6.81'''
For testing I have attached a zipped file (simulation for slope 0 to 90,
step 10 degrees and for aspect 0 to 360, step 15 degrees) with the script
and sample elevation (flat landscape) file. The table may look a bit
different but the pattern will be similar.
Thank you.
Nirmal
--
Ticket URL:
GRASS GIS
From andrewwickert at gmail.com Sun Mar 1 23:35:20 2015
From: andrewwickert at gmail.com (Andy Wickert)
Date: Mon, 2 Mar 2015 01:35:20 -0600
Subject: [GRASS-dev] A better r.fillnulls
In-Reply-To:
References:
Message-ID:
On Sun, Mar 1, 2015 at 1:37 PM, Markus Neteler wrote:
> On Sun, Mar 1, 2015 at 7:40 PM, Andy Wickert
> wrote:
> ...
> > I find this to be preferable for both the reasons stated above, and was
> > wondering if it would be worthwhile to think about including multiple
> > methods for r.fillnulls so one could do something like this too.
>
> Did you use the GRASS 6 version? Because in GRASS 7 several methods
> have been implemented:
>
> http://grass.osgeo.org/grass70/manuals/r.fillnulls.html
>
> method: Interpolation method to use
> Options: bilinear, bicubic, rst
> Default: rst
>
> Both bilinear and bicubic use r.resamp.bspline.
>
> Markus
>
Hi Markus,
Sorry for the silly question! I missed that change in GRASS 7.
Best,
Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From neteler at osgeo.org Sun Mar 1 23:41:23 2015
From: neteler at osgeo.org (Markus Neteler)
Date: Mon, 2 Mar 2015 08:41:23 +0100
Subject: [GRASS-dev] A better r.fillnulls
In-Reply-To:
References:
Message-ID:
On Mar 2, 2015 8:35 AM, "Andy Wickert" wrote:
>
> On Sun, Mar 1, 2015 at 1:37 PM, Markus Neteler wrote:
> Sorry for the silly question! I missed that change in GRASS 7.
Not silly at all. We accumulated quite a bit of new functionality in G7...
Future releases shall come more frequently so that it is less overwhelming
for all :)
Best,
Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From lucadeluge at gmail.com Mon Mar 2 00:01:52 2015
From: lucadeluge at gmail.com (Luca Delucchi)
Date: Mon, 2 Mar 2015 09:01:52 +0100
Subject: [GRASS-dev] grass addon sync to github
In-Reply-To: <1425246885917-5190784.post@n6.nabble.com>
References: <1425246885917-5190784.post@n6.nabble.com>
Message-ID:
On 1 March 2015 at 22:54, Helmut Kudrnovsky wrote:
> Hi devs,
>
Hi Helmut,
> I have a few g7-addons in grass svn and I want to put them also in github.
>
> do you know any script/tool to sync addons in svn with github?
>
Could I ask you why?
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
From trac at osgeo.org Mon Mar 2 02:24:46 2015
From: trac at osgeo.org (GRASS GIS)
Date: Mon, 02 Mar 2015 10:24:46 -0000
Subject: [GRASS-dev] [GRASS GIS] #2606: Bugs in r.sun
In-Reply-To: <042.0c578eee7068ec8f15b5021f378c131f@osgeo.org>
References: <042.0c578eee7068ec8f15b5021f378c131f@osgeo.org>
Message-ID: <051.b56fc73f7a0787b55f980e49d5a5b172@osgeo.org>
#2606: Bugs in r.sun
----------------------+-----------------------------------------------------
Reporter: ojni0001 | Owner: grass-dev@?
Type: defect | Status: new
Priority: normal | Milestone: 7.0.1
Component: Raster | Version: unspecified
Keywords: r.sun | Platform: MSWindows 7
Cpu: x86-64 |
----------------------+-----------------------------------------------------
Changes (by martinl):
* keywords: => r.sun
* component: Default => Raster
* milestone: => 7.0.1
--
Ticket URL:
GRASS GIS
From diregola at gmail.com Mon Mar 2 02:28:08 2015
From: diregola at gmail.com (Margherita Di Leo)
Date: Mon, 2 Mar 2015 11:28:08 +0100
Subject: [GRASS-dev] Select vector feature - Error
Message-ID:
Hi,
when i try to select a feature with the "select vector feature" button from
map display, I get an Error pop up that reads:
Error occured during calling of handler: _onMapClickHandler
Handler was unregistered.
Reason: VectorSelectBase instance has no attribute 'map'
Traceback (most recent call last):
File "/usr/local/grass-7.1.svn/gui/wxpython/mapwin/base.py", line 191, in
HandlersCaller
handler(event)
File "/usr/local/grass-7.1.svn/gui/wxpython/gui_core/vselect.py", line
187, in _onMapClickHandler
vWhatDic = self.QuerySelectedMap()
File "/usr/local/grass-7.1.svn/gui/wxpython/gui_core/vselect.py", line
272, in QuerySelectedMap
message=_("Failed to query vector map(s) <%s>.") % self.map)
AttributeError: VectorSelectBase instance has no attribute 'map'
Thanks
--
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-leo at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From nik at nikosalexandris.net Mon Mar 2 02:29:30 2015
From: nik at nikosalexandris.net (Nikos Alexandris)
Date: Mon, 02 Mar 2015 12:29:30 +0200
Subject: [GRASS-dev] Wrong HOME environment variable at start-up
Message-ID:
In ~/.grass.bashrc, I put the test-line `echo ~ # or echo $HOME`
(sans backticks, of course).
Launching up G70, or G71, the echoed message reports HOME as being the
Mapset in which I launch GRASS! For example, `grass70
/geo/grassdb/ols/PERMANENT` will give "/geo/grassdb/ols/PERMANENT".
Thus, `source ~/.bash_aliases`, inside .grass.bashrc, fails to deliver.
Now, asking for $HOME, inside GRASS, shows no error, ie: `echo $HOME`
gives "/home/nik". Nevertheless, there is no single line anywhere in
~/.bash* or ~/.grass* or ~/.grass7/* that refers to HOME.
Can someone help me understand what I have probably setup wrong?
Thanks, Nikos
From trac at osgeo.org Mon Mar 2 03:49:06 2015
From: trac at osgeo.org (GRASS GIS)
Date: Mon, 02 Mar 2015 11:49:06 -0000
Subject: [GRASS-dev] [GRASS GIS] #2603: grass 7 startup problem
In-Reply-To: <039.a1b653b9d6f70705729cff642ad0ba53@osgeo.org>
References: <039.a1b653b9d6f70705729cff642ad0ba53@osgeo.org>
Message-ID: <048.198803190f83b3f7593343e0f1fee59b@osgeo.org>
#2603: grass 7 startup problem
-------------------------+--------------------------------------------------
Reporter: neuba | Owner: grass-dev@?
Type: defect | Status: new
Priority: normal | Milestone: 7.0.1
Component: Startup | Version: 7.0.0
Keywords: | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by neuba):
I have both Grass 7 and Grass 6.4 installed on my computer. How can solve
this problem.
--
Ticket URL:
GRASS GIS
From trac at osgeo.org Mon Mar 2 04:07:55 2015
From: trac at osgeo.org (GRASS GIS)
Date: Mon, 02 Mar 2015 12:07:55 -0000
Subject: [GRASS-dev] [GRASS GIS] #2603: grass 7 startup problem
In-Reply-To: <039.a1b653b9d6f70705729cff642ad0ba53@osgeo.org>
References: <039.a1b653b9d6f70705729cff642ad0ba53@osgeo.org>
Message-ID: <048.be73392e169a2911556d5eaa589c6e57@osgeo.org>
#2603: grass 7 startup problem
-------------------------+--------------------------------------------------
Reporter: neuba | Owner: grass-dev@?
Type: defect | Status: new
Priority: normal | Milestone: 7.0.1
Component: Startup | Version: 7.0.0
Keywords: | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by martinl):
Replying to [comment:4 neuba]:
> I have both Grass 7 and Grass 6.4 installed on my computer. How can
solve this problem.
Did you install GRASS using standalone installer or via OSGeo4W?
--
Ticket URL:
GRASS GIS
From trac at osgeo.org Mon Mar 2 04:27:03 2015
From: trac at osgeo.org (GRASS GIS)
Date: Mon, 02 Mar 2015 12:27:03 -0000
Subject: [GRASS-dev] [GRASS GIS] #2603: grass 7 startup problem
In-Reply-To: <039.a1b653b9d6f70705729cff642ad0ba53@osgeo.org>
References: <039.a1b653b9d6f70705729cff642ad0ba53@osgeo.org>
Message-ID: <048.73db856fb7712148cb3671f44cfb1f34@osgeo.org>
#2603: grass 7 startup problem
--------------------------+-------------------------------------------------
Reporter: neuba | Owner: grass-dev@?
Type: defect | Status: closed
Priority: normal | Milestone: 7.0.1
Component: Startup | Version: 7.0.0
Resolution: fixed | Keywords:
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Changes (by neuba):
* status: new => closed
* resolution: => fixed
Comment:
Replying to [comment:5 martinl]:
> Replying to [comment:4 neuba]:
> > I have both Grass 7 and Grass 6.4 installed on my computer. How can
solve this problem.
>
> Did you install GRASS using standalone installer or via OSGeo4W?
I used GRASS using standalone. I solve the problem by deleting GIBASE and
GRASS_SH in environment of my computer.
It is possible to set these variable for both grass 6.4 and grass 7.0
Bye
--
Ticket URL:
GRASS GIS
From trac at osgeo.org Mon Mar 2 08:30:47 2015
From: trac at osgeo.org (GRASS GIS)
Date: Mon, 02 Mar 2015 16:30:47 -0000
Subject: [GRASS-dev] [GRASS GIS] #2601: Raster query fails with unicode
error
In-Reply-To: <040.541deadabff0aaa3d3b9660f428ccb07@osgeo.org>
References: <040.541deadabff0aaa3d3b9660f428ccb07@osgeo.org>
Message-ID: <049.70600eb336fa5db7c8010892616e49d0@osgeo.org>
#2601: Raster query fails with unicode error
-------------------------+--------------------------------------------------
Reporter: marisn | Owner: grass-dev@?
Type: defect | Status: new
Priority: normal | Milestone: 7.0.1
Component: wxGUI | Version: 7.0.0
Keywords: query | Platform: MSWindows XP
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Changes (by annakrat):
* keywords: => query
* milestone: => 7.0.1
Comment:
I can't reproduce it. I tried on Windows 8. Any idea why it doesn't work
on your side?
--
Ticket URL:
GRASS GIS
From trac at osgeo.org Mon Mar 2 08:33:02 2015
From: trac at osgeo.org (GRASS GIS)
Date: Mon, 02 Mar 2015 16:33:02 -0000
Subject: [GRASS-dev] [GRASS GIS] #2602: GUI preferences dialog fails to
open
In-Reply-To: <040.6509d418a3f553976db6ecf3b6e2fd2a@osgeo.org>
References: <040.6509d418a3f553976db6ecf3b6e2fd2a@osgeo.org>
Message-ID: <049.474b694a187a4e93267b5782ca1f633b@osgeo.org>
#2602: GUI preferences dialog fails to open
-------------------------+--------------------------------------------------
Reporter: marisn | Owner: grass-dev@?
Type: defect | Status: new
Priority: normal | Milestone: 7.0.1
Component: wxGUI | Version: 7.0.0
Keywords: | Platform: MSWindows XP
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by annakrat):
Works for me with English locale on Windows 8. Is locale the problem?
--
Ticket URL:
GRASS GIS
From trac at osgeo.org Mon Mar 2 15:43:21 2015
From: trac at osgeo.org (GRASS GIS)
Date: Mon, 02 Mar 2015 23:43:21 -0000
Subject: [GRASS-dev] [GRASS GIS] #2434: v.surf.bspline
In-Reply-To: <042.b50fe80e18898260d6656f3241b0b09e@osgeo.org>
References: <042.b50fe80e18898260d6656f3241b0b09e@osgeo.org>
Message-ID: <051.21253e578c14f8311f5c6e35aa131053@osgeo.org>
#2434: v.surf.bspline
----------------------------+-----------------------------------------------
Reporter: baharmon | Owner: grass-dev@?
Type: defect | Status: new
Priority: major | Milestone: 7.0.1
Component: Raster | Version: svn-releasebranch70
Keywords: v.surf.bspline | Platform: MSWindows 8
Cpu: OSX/Intel |
----------------------------+-----------------------------------------------
Comment(by annakrat):
Anyone has any idea? I looked at it but without the ability to debug on
Windows I couldn't find anything.
--
Ticket URL:
GRASS GIS
From glynn at gclements.plus.com Mon Mar 2 20:25:48 2015
From: glynn at gclements.plus.com (Glynn Clements)
Date: Tue, 3 Mar 2015 04:25:48 +0000
Subject: [GRASS-dev] Wrong HOME environment variable at start-up
In-Reply-To:
References:
Message-ID: <21749.14284.63245.606024@cerise.gclements.plus.com>
Nikos Alexandris wrote:
> In ~/.grass.bashrc, I put the test-line `echo ~ # or echo $HOME`
> (sans backticks, of course).
> Launching up G70, or G71, the echoed message reports HOME as being the
> Mapset in which I launch GRASS! For example, `grass70
> /geo/grassdb/ols/PERMANENT` will give "/geo/grassdb/ols/PERMANENT".
>
> Thus, `source ~/.bash_aliases`, inside .grass.bashrc, fails to deliver.
> Now, asking for $HOME, inside GRASS, shows no error, ie: `echo $HOME`
> gives "/home/nik". Nevertheless, there is no single line anywhere in
> ~/.bash* or ~/.grass* or ~/.grass7/* that refers to HOME.
>
> Can someone help me understand what I have probably setup wrong?
Before starting the child shell process, the startup script sets HOME
to the mapset directory and writes out a .bashrc file to that
directory which (among other things) sets HOME back to the correct
value. The contents of ~/.grass.bashrc are copied into that file, but
before the point that HOME is reverted.
This is essentially a hack to force the shell's history file to be
written to the mapset directory rather than the user's HOME directory,
so that each mapset has its own separate shell history.
For bash, it would probably be better to just set HISTFILE, but other
shells may not have such a feature.
For all shells, it may be better to restore HOME before executing the
user-supplied commands from ~/.grass.bashrc, ~/.grass.cshrc, etc.
In the meantime, you could have ~/.grass.bashrc restore HOME itself;
nothing written to the generated .bashrc file uses it.
--
Glynn Clements
From mlennert at club.worldonline.be Tue Mar 3 00:31:10 2015
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Tue, 03 Mar 2015 09:31:10 +0100
Subject: [GRASS-dev] [GRASS-PSC] RFC 4: Release procedure
In-Reply-To:
References: <539821A5.4010109@club.worldonline.be>
Message-ID: <54F5714E.4090401@club.worldonline.be>
On 01/03/15 19:02, Markus Neteler wrote:
> Hi,
>
> On Tue, Feb 17, 2015 at 1:54 PM, Markus Neteler wrote:
>> On Fri, Jun 20, 2014 at 3:39 AM, Scott Mitchell wrote:
>>> Agreed, and I like Markus? idea of testing it on an upcoming release.
>>
>> (just a low priority comment here)
>>
>> While doing so it turns out that one week between RC2 and final is a bit short.
>> And some urgent fixes came in only during the RC procedure. We need to
>> [add] a phrase if this requires a new RC (not this time though!) or not
>> or depends.
>
> Overall, we got the release out :-)
> Any opinions on above remaining issue?
I think that with time we will get better at this procedure and the one
week limit should be ok, but I have no objections to add a phrase to
step 6 such as
"A final, concerted bug squashing effort by all developers of no more
than one week. During that same time the release announcement is
drafted. If an important bug is discovered for which a fix needs some
more testing, an RC3 can exceptionally be published, with another week
of testing before final release."
Moritz
From mlennert at club.worldonline.be Tue Mar 3 00:45:51 2015
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Tue, 03 Mar 2015 09:45:51 +0100
Subject: [GRASS-dev] Select vector feature - Error
In-Reply-To:
References:
Message-ID: <54F574BF.5050807@club.worldonline.be>
On 02/03/15 11:28, Margherita Di Leo wrote:
> Hi,
>
> when i try to select a feature with the "select vector feature" button
> from map display, I get an Error pop up that reads:
>
> Error occured during calling of handler: _onMapClickHandler
> Handler was unregistered.
>
> Reason: VectorSelectBase instance has no attribute 'map'
>
> Traceback (most recent call last):
> File "/usr/local/grass-7.1.svn/gui/wxpython/mapwin/base.py", line
> 191, in HandlersCaller
> handler(event)
> File "/usr/local/grass-7.1.svn/gui/wxpython/gui_core/vselect.py",
> line 187, in _onMapClickHandler
> vWhatDic = self.QuerySelectedMap()
> File "/usr/local/grass-7.1.svn/gui/wxpython/gui_core/vselect.py",
> line 272, in QuerySelectedMap
> message=_("Failed to query vector map(s) <%s>.") % self.map)
> AttributeError: VectorSelectBase instance has no attribute 'map'
I cannot reproduce using freshly checked out trunk and the NC dataset.
BTW, two remarks for enhancement:
- It would be nice if the tool allowed to select also by drawing a
polygon, not only by clicking.
- There is no close button on the little window listing the selected
features.
Moritz
From Stefan.Blumentrath at nina.no Tue Mar 3 01:13:48 2015
From: Stefan.Blumentrath at nina.no (Blumentrath, Stefan)
Date: Tue, 3 Mar 2015 09:13:48 +0000
Subject: [GRASS-dev] Python loop and SQLite performance issue?
Message-ID: <2fa8f049fd9a4f75af17f89bcb8c8bc7@NINSRV23.nina.no>
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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From neteler at osgeo.org Tue Mar 3 01:59:05 2015
From: neteler at osgeo.org (Markus Neteler)
Date: Tue, 3 Mar 2015 10:59:05 +0100
Subject: [GRASS-dev] Fwd: [OSGeo-Discuss] OSGeo accepted to GSoC 2015 -
overview of slot assignments
In-Reply-To:
References:
Message-ID:
FYI
---------- Forwarded message ----------
From: Margherita Di Leo
Date: Tue, Mar 3, 2015 at 10:41 AM
Subject: [OSGeo-Discuss] OSGeo accepted to GSoC 2015 - overview of slot
assignments
To: OSGeo Discussions , OSGeo-SoC <
soc at 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-leo at 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
Discuss at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Stefan.Blumentrath at nina.no Tue Mar 3 02:13:10 2015
From: Stefan.Blumentrath at nina.no (Blumentrath, Stefan)
Date: Tue, 3 Mar 2015 10:13:10 +0000
Subject: [GRASS-dev] Fwd: [OSGeo-Discuss] OSGeo accepted to GSoC 2015
- overview of slot assignments
In-Reply-To:
References:
Message-ID: <317669c481b246a4a0eb12214a3c00d9@NINSRV23.nina.no>
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-bounces at lists.osgeo.org [mailto:grass-dev-bounces at 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 >
Date: Tue, Mar 3, 2015 at 10:41 AM
Subject: [OSGeo-Discuss] OSGeo accepted to GSoC 2015 - overview of slot assignments
To: OSGeo Discussions >, OSGeo-SoC >
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-leo at 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
Discuss at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From trac at osgeo.org Tue Mar 3 04:07:23 2015
From: trac at osgeo.org (GRASS GIS)
Date: Tue, 03 Mar 2015 12:07:23 -0000
Subject: [GRASS-dev] [GRASS GIS] #2602: GUI preferences dialog fails to
open
In-Reply-To: <040.6509d418a3f553976db6ecf3b6e2fd2a@osgeo.org>
References: <040.6509d418a3f553976db6ecf3b6e2fd2a@osgeo.org>
Message-ID: <049.62c4ae7d548cee48a1320065293b288c@osgeo.org>
#2602: GUI preferences dialog fails to open
-------------------------+--------------------------------------------------
Reporter: marisn | Owner: grass-dev@?
Type: defect | Status: new
Priority: normal | Milestone: 7.0.1
Component: wxGUI | Version: 7.0.0
Keywords: | Platform: MSWindows XP
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by marisn):
It is caused by a faulty translation to Latvian language (shame on me).
Issue is fixed in trunk with r64789
Leaving open, as r64789 needs to be backported to release branch.
--
Ticket URL:
GRASS GIS
From trac at osgeo.org Tue Mar 3 04:30:14 2015
From: trac at osgeo.org (GRASS GIS)
Date: Tue, 03 Mar 2015 12:30:14 -0000
Subject: [GRASS-dev] [GRASS GIS] #2602: GUI preferences dialog fails to
open
In-Reply-To: <040.6509d418a3f553976db6ecf3b6e2fd2a@osgeo.org>
References: <040.6509d418a3f553976db6ecf3b6e2fd2a@osgeo.org>
Message-ID: <049.2221aa2048857c2469698679eaf2ca2f@osgeo.org>
#2602: GUI preferences dialog fails to open
---------------------------+------------------------------------------------
Reporter: marisn | Owner: grass-dev@?
Type: defect | Status: closed
Priority: normal | Milestone: 7.0.1
Component: wxGUI | Version: 7.0.0
Resolution: fixed | Keywords:
Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Changes (by neteler):
* status: new => closed
* resolution: => fixed
Comment:
Replying to [comment:3 marisn]:
> Leaving open, as r64789 needs to be backported to release branch.
Backported, closing.
--
Ticket URL:
GRASS GIS
From landa.martin at gmail.com Tue Mar 3 05:38:42 2015
From: landa.martin at gmail.com (Martin Landa)
Date: Tue, 3 Mar 2015 14:38:42 +0100
Subject: [GRASS-dev] Select vector feature - Error
In-Reply-To: <54F574BF.5050807@club.worldonline.be>
References:
<54F574BF.5050807@club.worldonline.be>
Message-ID:
Hi,
2015-03-03 9:45 GMT+01:00 Moritz Lennert :
[...]
> BTW, two remarks for enhancement:
>
> - It would be nice if the tool allowed to select also by drawing a polygon,
> not only by clicking.
right, it's in TODO.
> - There is no close button on the little window listing the selected
> features.
Sending in copy to the author (Matej Krejci), thanks for testing. Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
From massimodisasha at gmail.com Tue Mar 3 07:23:40 2015
From: massimodisasha at gmail.com (epi)
Date: Tue, 3 Mar 2015 10:23:40 -0500
Subject: [GRASS-dev] display monitor (how to everlay 2 layers)
In-Reply-To:
References:
Message-ID: <6F245A1A-A2E1-41B4-AA1E-5BB184036E82@gmail.com>
Hi,
i?m trying to generate a png from python using the the d.mon / d. last / d.vect commands
in the past (grass70) this code worked fine :
GRASS_TRANSPARENT=TRUE
GRASS_TRUECOLOR=TRUE
GRASS_PNG_COMPRESSION=9
GRASS_PNG_AUTO_WRITE=TRUE
export GRASS_TRANSPARENT GRASS_TRUECOLOR GRASS_PNG_COMPRESSION GRASS_PNG_AUTO_WRITE
d.mon start=cairo --q output={mapname}.png
g.region rast={mapname} n={n} s={s} w={w} e={e} -a --q
d.rast map={mapname} --q
d.vect map={mapname} color={vcolor} size={vsize} icon={icon} --q
d.mon stop=cairo --q
but now is not generating any png :(
browsing the add ons i saw v.out.png is no more in trunk and i gave it a try :
###
import os
import sys
from grass.script import core as grass
from grass.script import gisenv
from grass.pygrass.modules.shortcuts import display as d
from grass.pygrass.modules.shortcuts import general as g
os.environ['GRASS_RENDER_IMMEDIATE'] = 'png'
os.environ['GRASS_RENDER_FILE'] = 'pfile3.png'
os.environ['GRASS_RENDER_FILE_COMPRESSION'] = '9'
os.environ['GRASS_RENDER_WIDTH'] = '640'
os.environ['GRASS_RENDER_HEIGHT'] = '480'
os.environ['GRASS_RENDER_TRANSPARENT']='TRUE'
monitor_old = None
genv = gisenv()
if 'MONITOR' in genv:
monitor_old = genv['MONITOR']
g.gisenv(unset='MONITOR')
d.vect(map='p')
d.rast(map='basemap')
###
this time the png is generated, but i?m no more able to overlay 2 different layers to compose my map ?
Have you any thoughts on what?s wrong in those procedures ?
I tried on the osgeolive, the first approach works for grass70.
building grass71 and try it again ? no png is generated.
Thanks for any advice.
Massimo.
From landa.martin at gmail.com Tue Mar 3 07:30:27 2015
From: landa.martin at gmail.com (Martin Landa)
Date: Tue, 3 Mar 2015 16:30:27 +0100
Subject: [GRASS-dev] display monitor (how to everlay 2 layers)
In-Reply-To: <6F245A1A-A2E1-41B4-AA1E-5BB184036E82@gmail.com>
References:
<6F245A1A-A2E1-41B4-AA1E-5BB184036E82@gmail.com>
Message-ID:
Hi,
2015-03-03 16:23 GMT+01:00 epi :
> GRASS_TRANSPARENT=TRUE
> GRASS_TRUECOLOR=TRUE
> GRASS_PNG_COMPRESSION=9
> GRASS_PNG_AUTO_WRITE=TRUE
> export GRASS_TRANSPARENT GRASS_TRUECOLOR GRASS_PNG_COMPRESSION GRASS_PNG_AUTO_WRITE
render-related variables has been renamed to GRASS_RENDER_, see [1].
> os.environ['GRASS_RENDER_IMMEDIATE'] = 'png'
> os.environ['GRASS_RENDER_FILE'] = 'pfile3.png'
> os.environ['GRASS_RENDER_FILE_COMPRESSION'] = '9'
> os.environ['GRASS_RENDER_WIDTH'] = '640'
> os.environ['GRASS_RENDER_HEIGHT'] = '480'
> os.environ['GRASS_RENDER_TRANSPARENT']='TRUE'
>
> monitor_old = None
> genv = gisenv()
> if 'MONITOR' in genv:
> monitor_old = genv['MONITOR']
> g.gisenv(unset='MONITOR')
>
> d.vect(map='p')
> d.rast(map='basemap')
> ###
>
> this time the png is generated, but i'm no more able to overlay 2 different layers to compose my map ...
You need to define GRASS_RENDER_READ_FILE='TRUE'. Martin
[1] http://grass.osgeo.org/grass70/manuals/variables.html#list-of-selected-grass-environment-variables-for-rendering
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
From massimodisasha at gmail.com Tue Mar 3 08:13:29 2015
From: massimodisasha at gmail.com (epi)
Date: Tue, 3 Mar 2015 11:13:29 -0500
Subject: [GRASS-dev] display monitor (how to everlay 2 layers)
In-Reply-To:
References:
<6F245A1A-A2E1-41B4-AA1E-5BB184036E82@gmail.com>
Message-ID:
Thank Martin,
I tried with this :
http://nbviewer.ipython.org/gist/anonymous/e72c4a3b311370ade0db
but I still have the same behavior
Thanks a lot to for looking into this!
Massimo.
> On Mar 3, 2015, at 10:30 AM, Martin Landa wrote:
>
> Hi,
>
> 2015-03-03 16:23 GMT+01:00 epi :
>> GRASS_TRANSPARENT=TRUE
>> GRASS_TRUECOLOR=TRUE
>> GRASS_PNG_COMPRESSION=9
>> GRASS_PNG_AUTO_WRITE=TRUE
>> export GRASS_TRANSPARENT GRASS_TRUECOLOR GRASS_PNG_COMPRESSION GRASS_PNG_AUTO_WRITE
>
> render-related variables has been renamed to GRASS_RENDER_, see [1].
>
>> os.environ['GRASS_RENDER_IMMEDIATE'] = 'png'
>> os.environ['GRASS_RENDER_FILE'] = 'pfile3.png'
>> os.environ['GRASS_RENDER_FILE_COMPRESSION'] = '9'
>> os.environ['GRASS_RENDER_WIDTH'] = '640'
>> os.environ['GRASS_RENDER_HEIGHT'] = '480'
>> os.environ['GRASS_RENDER_TRANSPARENT']='TRUE'
>>
>> monitor_old = None
>> genv = gisenv()
>> if 'MONITOR' in genv:
>> monitor_old = genv['MONITOR']
>> g.gisenv(unset='MONITOR')
>>
>> d.vect(map='p')
>> d.rast(map='basemap')
>> ###
>>
>> this time the png is generated, but i'm no more able to overlay 2 different layers to compose my map ...
>
> You need to define GRASS_RENDER_READ_FILE='TRUE'. Martin
>
> [1] http://grass.osgeo.org/grass70/manuals/variables.html#list-of-selected-grass-environment-variables-for-rendering
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From trac at osgeo.org Tue Mar 3 10:02:25 2015
From: trac at osgeo.org (GRASS GIS)
Date: Tue, 03 Mar 2015 18:02:25 -0000
Subject: [GRASS-dev] [GRASS GIS] #2598: g.extension compilation fails
In-Reply-To: <042.ea4d2b813a6fcad1e54c96e268892240@osgeo.org>
References: <042.ea4d2b813a6fcad1e54c96e268892240@osgeo.org>
Message-ID: <051.fec1f0b40377f90ae3e12c2b3af4eec4@osgeo.org>
#2598: g.extension compilation fails
----------------------+-----------------------------------------------------
Reporter: ewcgrass | Owner: grass-dev@?
Type: defect | Status: new
Priority: normal | Milestone: 7.0.1
Component: Default | Version: svn-releasebranch70
Keywords: | Platform: Linux
Cpu: x86-64 |
----------------------+-----------------------------------------------------
Comment(by ewcgrass):
I have managed to get g.extension to compile several (but not all) addon
modules. I did this by copying (as root user) all files located inside the
grass7.0.1svn-x86_64-unknown-linux-gnu-21_02_2015/include/grass and
/include/Make, grass7.0.1svn-x86_64-unknown-linux-gnu-21_02_2015/tools,
and grass7.0.1svn-x86_64-unknown-linux-gnu-21_02_2015/lib directories,
into the respective sub-directories inside grass7.0.1svn-x86_64-unknown-
linux-gnu-21_02_2015/dist.x86_64-unknown-linux-gnu. It would appear that
the requirement for the /dist.x86_64-unknown-linux-gnu directory may have
somehow found it's way into a make or other file somewhere, perhaps as a
remnant from past development work? I suggest this because I found
reference to that directory in the /include/Make/Platform.make.orig file.
My search for references to this directory were not extensive, so perhaps
it is present elsewhere too?
I am not a coder, but I do not view what I have done to get g.extension to
compile to be a proper fix (it is a band-aid fix only). However, I am
hoping this information may help those who are more familiar with the code
related to g.extension, or to other compilation activities within GRASS,
to find the source of this problem?
The modules that still refuse to compile appear to be doing so because of
some issues related to file permissions (??) and/or missing header files.
For example, I have not been able to find geos_c.h anywhere within the
/grass7.0.1svn-x86_64-unknown-linux-gnu-21_02_2015 directory, which is
needed to compile r.stream.order, r.stream.snap, v.surf.mass,
v.centerpoint, etc. Also, some errors appear to maybe be related to syntax
errors; for example for modules v.transects and r.stream.basins.
I intend to report back with more information as/if time permits for me to
"explore" more deeply into the remaining compilation problems.
--
Ticket URL:
GRASS GIS
From kratochanna at gmail.com Tue Mar 3 10:48:50 2015
From: kratochanna at gmail.com (=?UTF-8?B?QW5uYSBQZXRyw6HFoW92w6E=?=)
Date: Tue, 3 Mar 2015 13:48:50 -0500
Subject: [GRASS-dev] display monitor (how to everlay 2 layers)
In-Reply-To:
References:
<6F245A1A-A2E1-41B4-AA1E-5BB184036E82@gmail.com>
Message-ID:
On Tue, Mar 3, 2015 at 11:13 AM, epi wrote:
> Thank Martin,
>
> I tried with this :
>
> http://nbviewer.ipython.org/gist/anonymous/e72c4a3b311370ade0db
>
> but I still have the same behavior
>
I think it's GRASS_RENDER_FILE_READ, not GRASS_RENDER_READ_FILE.
http://grass.osgeo.org/grass71/manuals/cairodriver.html
Anna
> Thanks a lot to for looking into this!
>
> Massimo.
>
>
> On Mar 3, 2015, at 10:30 AM, Martin Landa wrote:
>
> Hi,
>
> 2015-03-03 16:23 GMT+01:00 epi :
>
> GRASS_TRANSPARENT=TRUE
> GRASS_TRUECOLOR=TRUE
> GRASS_PNG_COMPRESSION=9
> GRASS_PNG_AUTO_WRITE=TRUE
> export GRASS_TRANSPARENT GRASS_TRUECOLOR GRASS_PNG_COMPRESSION
> GRASS_PNG_AUTO_WRITE
>
>
> render-related variables has been renamed to GRASS_RENDER_, see [1].
>
> os.environ['GRASS_RENDER_IMMEDIATE'] = 'png'
> os.environ['GRASS_RENDER_FILE'] = 'pfile3.png'
> os.environ['GRASS_RENDER_FILE_COMPRESSION'] = '9'
> os.environ['GRASS_RENDER_WIDTH'] = '640'
> os.environ['GRASS_RENDER_HEIGHT'] = '480'
> os.environ['GRASS_RENDER_TRANSPARENT']='TRUE'
>
> monitor_old = None
> genv = gisenv()
> if 'MONITOR' in genv:
> monitor_old = genv['MONITOR']
> g.gisenv(unset='MONITOR')
>
> d.vect(map='p')
> d.rast(map='basemap')
> ###
>
> this time the png is generated, but i'm no more able to overlay 2
> different layers to compose my map ...
>
>
> You need to define GRASS_RENDER_READ_FILE='TRUE'. Martin
>
> [1]
> http://grass.osgeo.org/grass70/manuals/variables.html#list-of-selected-grass-environment-variables-for-rendering
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From landa.martin at gmail.com Tue Mar 3 10:53:43 2015
From: landa.martin at gmail.com (Martin Landa)
Date: Tue, 3 Mar 2015 19:53:43 +0100
Subject: [GRASS-dev] display monitor (how to everlay 2 layers)
In-Reply-To:
References:
<6F245A1A-A2E1-41B4-AA1E-5BB184036E82@gmail.com>
Message-ID:
2015-03-03 19:48 GMT+01:00 Anna Petr??ov? :
> I think it's GRASS_RENDER_FILE_READ, not GRASS_RENDER_READ_FILE.
> http://grass.osgeo.org/grass71/manuals/cairodriver.html
you are right, Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
From trac at osgeo.org Tue Mar 3 12:59:47 2015
From: trac at osgeo.org (GRASS GIS)
Date: Tue, 03 Mar 2015 20:59:47 -0000
Subject: [GRASS-dev] [GRASS GIS] #2598: g.extension compilation fails
In-Reply-To: <042.ea4d2b813a6fcad1e54c96e268892240@osgeo.org>
References: <042.ea4d2b813a6fcad1e54c96e268892240@osgeo.org>
Message-ID: <051.2bbd7769786565c78557431524f5d833@osgeo.org>
#2598: g.extension compilation fails
----------------------+-----------------------------------------------------
Reporter: ewcgrass | Owner: grass-dev@?
Type: defect | Status: new
Priority: normal | Milestone: 7.0.1
Component: Default | Version: svn-releasebranch70
Keywords: | Platform: Linux
Cpu: x86-64 |
----------------------+-----------------------------------------------------
Comment(by ewcgrass):
Have resolved the geos_c.h header file issue by installing the geos-devel
package system-wide. Geos-devel should be added to the optional
requirements.html list.
--
Ticket URL:
GRASS GIS
From hmitaso at ncsu.edu Tue Mar 3 17:55:15 2015
From: hmitaso at ncsu.edu (Helena Mitasova)
Date: Tue, 3 Mar 2015 20:55:15 -0500
Subject: [GRASS-dev] [GRASS-PSC] RFC 4: Release procedure
In-Reply-To: <54F5714E.4090401@club.worldonline.be>
References: <539821A5.4010109@club.worldonline.be>
<54F5714E.4090401@club.worldonline.be>
Message-ID:
I agree with the suggested modification by Moritz,
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
hmitaso at 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 Mar 3, 2015, at 3:31 AM, Moritz Lennert wrote:
> On 01/03/15 19:02, Markus Neteler wrote:
>> Hi,
>>
>> On Tue, Feb 17, 2015 at 1:54 PM, Markus Neteler wrote:
>>> On Fri, Jun 20, 2014 at 3:39 AM, Scott Mitchell wrote:
>>>> Agreed, and I like Markus? idea of testing it on an upcoming release.
>>>
>>> (just a low priority comment here)
>>>
>>> While doing so it turns out that one week between RC2 and final is a bit short.
>>> And some urgent fixes came in only during the RC procedure. We need to
>>> [add] a phrase if this requires a new RC (not this time though!) or not
>>> or depends.
>>
>> Overall, we got the release out :-)
>> Any opinions on above remaining issue?
>
> I think that with time we will get better at this procedure and the one week limit should be ok, but I have no objections to add a phrase to step 6 such as
>
> "A final, concerted bug squashing effort by all developers of no more than one week. During that same time the release announcement is drafted. If an important bug is discovered for which a fix needs some more testing, an RC3 can exceptionally be published, with another week of testing before final release."
>
> Moritz
> _______________________________________________
> grass-psc mailing list
> grass-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-psc
From Michael.Barton at asu.edu Tue Mar 3 18:57:26 2015
From: Michael.Barton at asu.edu (Michael Barton)
Date: Wed, 4 Mar 2015 02:57:26 +0000
Subject: [GRASS-dev] [GRASS-PSC] RFC 4: Release procedure
In-Reply-To:
References: <539821A5.4010109@club.worldonline.be>
<54F5714E.4090401@club.worldonline.be>
Message-ID: <1E9DAE96-ADCD-4465-A8C4-BD2D5693462C@asu.edu>
I agree.
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 Mar 3, 2015, at 6:55 PM, Helena Mitasova wrote:
>
> I agree with the suggested modification by Moritz,
>
> 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
> hmitaso at 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 Mar 3, 2015, at 3:31 AM, Moritz Lennert wrote:
>
>> On 01/03/15 19:02, Markus Neteler wrote:
>>> Hi,
>>>
>>> On Tue, Feb 17, 2015 at 1:54 PM, Markus Neteler wrote:
>>>> On Fri, Jun 20, 2014 at 3:39 AM, Scott Mitchell wrote:
>>>>> Agreed, and I like Markus? idea of testing it on an upcoming release.
>>>>
>>>> (just a low priority comment here)
>>>>
>>>> While doing so it turns out that one week between RC2 and final is a bit short.
>>>> And some urgent fixes came in only during the RC procedure. We need to
>>>> [add] a phrase if this requires a new RC (not this time though!) or not
>>>> or depends.
>>>
>>> Overall, we got the release out :-)
>>> Any opinions on above remaining issue?
>>
>> I think that with time we will get better at this procedure and the one week limit should be ok, but I have no objections to add a phrase to step 6 such as
>>
>> "A final, concerted bug squashing effort by all developers of no more than one week. During that same time the release announcement is drafted. If an important bug is discovered for which a fix needs some more testing, an RC3 can exceptionally be published, with another week of testing before final release."
>>
>> Moritz
>> _______________________________________________
>> grass-psc mailing list
>> grass-psc at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-psc
>
> _______________________________________________
> grass-psc mailing list
> grass-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-psc
From massimodisasha at gmail.com Tue Mar 3 20:40:50 2015
From: massimodisasha at gmail.com (epi)
Date: Tue, 3 Mar 2015 23:40:50 -0500
Subject: [GRASS-dev] display monitor (how to everlay 2 layers)
In-Reply-To:
References:
<6F245A1A-A2E1-41B4-AA1E-5BB184036E82@gmail.com>
Message-ID: <00E39C10-061B-47EF-96F2-06F39894F2E9@gmail.com>
Martin, Anna,
Thank you so much, it works great.
Massimo.
> On Mar 3, 2015, at 1:53 PM, Martin Landa wrote:
>
> 2015-03-03 19:48 GMT+01:00 Anna Petr??ov? :
>> I think it's GRASS_RENDER_FILE_READ, not GRASS_RENDER_READ_FILE.
>> http://grass.osgeo.org/grass71/manuals/cairodriver.html
>
> you are right, Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
From landa.martin at gmail.com Wed Mar 4 00:19:34 2015
From: landa.martin at gmail.com (Martin Landa)
Date: Wed, 4 Mar 2015 09:19:34 +0100
Subject: [GRASS-dev] [GRASS-PSC] RFC 4: Release procedure
In-Reply-To: <54F5714E.4090401@club.worldonline.be>
References: <539821A5.4010109@club.worldonline.be>
<54F5714E.4090401@club.worldonline.be>
Message-ID:
Hi,
2015-03-03 9:31 GMT+01:00 Moritz Lennert :
> "A final, concerted bug squashing effort by all developers of no more than
> one week. During that same time the release announcement is drafted. If an
> important bug is discovered for which a fix needs some more testing, an RC3
> can exceptionally be published, with another week of testing before final
> release."
make sense to me, Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
From radim.blazek at gmail.com Wed Mar 4 01:11:40 2015
From: radim.blazek at gmail.com (Radim Blazek)
Date: Wed, 4 Mar 2015 10:11:40 +0100
Subject: [GRASS-dev] [GRASS GIS] #1628: segfault in r.walk
In-Reply-To: <21367.40277.93194.362247@cerise.gclements.plus.com>
References: <042.cd10e8d2eb8b89369d63f56a9e1f5d41@osgeo.org>
<051.a36efe773ba5400a995e27aad9a5408b@osgeo.org>
<21367.40277.93194.362247@cerise.gclements.plus.com>
Message-ID:
Sorry for not responding earlier, I missed somehow this mail.
On Sat, May 17, 2014 at 7:33 PM, Glynn Clements
wrote:
> Is there any reason to retain lib/sites as a separate library, rather
> than simply merging it into v.in.sites? There isn't a ctypes wrapper
> for it, so I'm reasonably sure it isn't used elsewhere in GRASS.
>
> [Radim: does QGIS use it?]
No, QGIS does not use lib/sites.
I appreciate a lot that you asked me and I'll always do in such cases.
I probably missed the email because I was 'cc' only and not 'to'.
Thanks
Radim
From peter.zamb at gmail.com Wed Mar 4 06:14:07 2015
From: peter.zamb at gmail.com (Pietro)
Date: Wed, 4 Mar 2015 15:14:07 +0100
Subject: [GRASS-dev] vector group by based on attribute table
Message-ID:
Dear all,
I'm looking for a GRASS module that unify the geometries and the
values, If I have a configuration like:
geo features | cat | id | A | B
geofeature1 => cat1, id1, a1, b1
geofeature2 => cat2, id1, a2, b2
geofeature3 => cat3, id2, a3, b3
geofeature4 => cat4, id2, a4, b4
geofeature5 => cat5, id2, a5, b5
I would like to have something like:
SELECT id, mean(A) as meanA, mean(B) as meanB FROM table GROUP BY id;
geo features | cat | meanA | meanB
geo1, geo2 => id1, mean(a1, a2), mean(b1, b2)
geo3, geo4, geo5 => id2, mean(a3, a4, a5), mean(b3, b4, b5)
There is already something to do this simple operation?
Do you have any suggestions?
Thank you
Pietro
From mlennert at club.worldonline.be Wed Mar 4 07:29:03 2015
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed, 04 Mar 2015 16:29:03 +0100
Subject: [GRASS-dev] vector group by based on attribute table
In-Reply-To:
References:
Message-ID: <54F724BF.9040104@club.worldonline.be>
On 04/03/15 15:14, Pietro wrote:
> Dear all,
>
> I'm looking for a GRASS module that unify the geometries and the
> values, If I have a configuration like:
>
> geo features | cat | id | A | B
> geofeature1 => cat1, id1, a1, b1
> geofeature2 => cat2, id1, a2, b2
> geofeature3 => cat3, id2, a3, b3
> geofeature4 => cat4, id2, a4, b4
> geofeature5 => cat5, id2, a5, b5
>
> I would like to have something like:
>
> SELECT id, mean(A) as meanA, mean(B) as meanB FROM table GROUP BY id;
>
> geo features | cat | meanA | meanB
> geo1, geo2 => id1, mean(a1, a2), mean(b1, b2)
> geo3, geo4, geo5 => id2, mean(a3, a4, a5), mean(b3, b4, b5)
>
> There is already something to do this simple operation?
> Do you have any suggestions?
>
Does this mean you want to fusion the geofeatures (thus imlying that
they are adjacent) or do you want to group them in a sort of typology ?
If the first, then it should probably be possible to integrate this into
v.dissolve.
If the second, I could imagine a combination of v.reclass / v.category
to create a new/second layer and then your SQL query to populate the
table of that layer.
Moritz
From peter.zamb at gmail.com Wed Mar 4 07:35:44 2015
From: peter.zamb at gmail.com (Pietro)
Date: Wed, 4 Mar 2015 16:35:44 +0100
Subject: [GRASS-dev] vector group by based on attribute table
In-Reply-To: <54F724BF.9040104@club.worldonline.be>
References:
<54F724BF.9040104@club.worldonline.be>
Message-ID:
On Wed, Mar 4, 2015 at 4:29 PM, Moritz Lennert
wrote:
> On 04/03/15 15:14, Pietro wrote:
>>
>> Dear all,
>>
>> I'm looking for a GRASS module that unify the geometries and the
>> values, If I have a configuration like:
>>
>> geo features | cat | id | A | B
>> geofeature1 => cat1, id1, a1, b1
>> geofeature2 => cat2, id1, a2, b2
>> geofeature3 => cat3, id2, a3, b3
>> geofeature4 => cat4, id2, a4, b4
>> geofeature5 => cat5, id2, a5, b5
>>
>> I would like to have something like:
>>
>> SELECT id, mean(A) as meanA, mean(B) as meanB FROM table GROUP BY id;
>>
>> geo features | cat | meanA | meanB
>> geo1, geo2 => id1, mean(a1, a2), mean(b1, b2)
>> geo3, geo4, geo5 => id2, mean(a3, a4, a5), mean(b3, b4, b5)
>>
>> There is already something to do this simple operation?
>> Do you have any suggestions?
>
>
> Does this mean you want to fusion the geofeatures (thus imlying that they
> are adjacent) or do you want to group them in a sort of typology ?
No, I don't want the fusion of the geometry features, I like the idea
of different/distinct geometry features with the same category.
> If the second, I could imagine a combination of v.reclass / v.category to
> create a new/second layer and then your SQL query to populate the table of
> that layer.
Ok, I will look into it, thanks for the suggestion.
Pietro
From mlennert at club.worldonline.be Wed Mar 4 09:03:01 2015
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed, 04 Mar 2015 18:03:01 +0100
Subject: [GRASS-dev] [GRASS-PSC] RFC 4: Release procedure
In-Reply-To:
References: <539821A5.4010109@club.worldonline.be> <54F5714E.4090401@club.worldonline.be>
Message-ID: <54F73AC5.3080002@club.worldonline.be>
On 04/03/15 09:19, Martin Landa wrote:
> Hi,
>
> 2015-03-03 9:31 GMT+01:00 Moritz Lennert :
>> "A final, concerted bug squashing effort by all developers of no more than
>> one week. During that same time the release announcement is drafted. If an
>> important bug is discovered for which a fix needs some more testing, an RC3
>> can exceptionally be published, with another week of testing before final
>> release."
>
> make sense to me, Martin
>
Ok, I've added the change. In any case we are a small enough team to
handle things flexibly if needed. For me, the idea of elaborating a
release procedure is mostly to make the process more explicit and thus
ease communication, not to hammer laws into stone
Moritz
From trac at osgeo.org Wed Mar 4 09:12:27 2015
From: trac at osgeo.org (GRASS GIS)
Date: Wed, 04 Mar 2015 17:12:27 -0000
Subject: [GRASS-dev] [GRASS GIS] #2607: Python shell hint results in OSError
error(None): None
Message-ID: <040.3971a1a2a8e964a352aaac26d5a40d5c@osgeo.org>
#2607: Python shell hint results in OSError error(None): None
-------------------------+--------------------------------------------------
Reporter: marisn | Owner: grass-dev@?
Type: defect | Status: new
Priority: normal | Milestone:
Component: wxGUI | Version: 7.0.0
Keywords: | Platform: MSWindows Vista
Cpu: Unspecified |
-------------------------+--------------------------------------------------
In Python shell type in:
{{{
from grass.pygrass.modules.shortcuts import raster as r
r.
}}}
and observe how it gets filled with gazzilion of error messages: "OSError
error(None): None"
Due to this error, it is impossible to use Python shell, as it is trying
to execute error message as a command instead of just providing it as an
"error text that messes up CLI".
--
Ticket URL:
GRASS GIS
From p.vanbreugel at gmail.com Wed Mar 4 09:49:02 2015
From: p.vanbreugel at gmail.com (Paulo van Breugel)
Date: Wed, 4 Mar 2015 18:49:02 +0100
Subject: [GRASS-dev] raster digitizer
Message-ID:
When editing a raster using the raster digitizer, the resolution is changes
(lower resolution) after saving the edits. Is this the intended behaviour,
and if so, what is determining the resolution?
My prefered behaviour would be that the resolution used follows that of the
region settings.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From trac at osgeo.org Wed Mar 4 09:54:32 2015
From: trac at osgeo.org (GRASS GIS)
Date: Wed, 04 Mar 2015 17:54:32 -0000
Subject: [GRASS-dev] [GRASS GIS] #2608: Launching Python script on Windows
fails with missing freeze_support
Message-ID: <040.7de23d5903674d9ee8157dfeff0a04e2@osgeo.org>
#2608: Launching Python script on Windows fails with missing freeze_support
-------------------------+--------------------------------------------------
Reporter: marisn | Owner: grass-dev@?
Type: defect | Status: new
Priority: normal | Milestone:
Component: Python | Version: 7.0.0
Keywords: | Platform: MSWindows Vista
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Launch the following script on Windows:
{{{
from grass.pygrass.modules.shortcuts import raster as r
r.mapcalc("rand0 = round(rand(0,1))", s=True)
r.neighbors(input="rand0", output="count", method="count")
r.mapcalc("rand1 = if (count > 3, 1, null())")
r.mapcalc("rand2 = if (count < 1, 1, null())")
}}}
and observe an error:
{{{
C:\Users\tests\Documents\rand.py
Traceback (most recent call last):
File "", line 1, in
File "C:\Program Files\GRASS GIS
7.0.0\Python27\lib\multiprocessing\forking.py", line 380, in
main
prepare(preparation_data)
File "C:\Program Files\GRASS GIS
7.0.0\Python27\lib\multiprocessing\forking.py", line 495, in
prepare
'__parents_main__', file, path_name, etc
File "C:\Users\tests\Documents\rand.py", line 2, in
r.mapcalc("rand0 = round(rand(0,1))", s=True)
File "C:\Program Files\GRASS GIS
7.0.0\etc\python\grass\pygrass\modules\interface\module.py",
line 616, in __call__
return self.run()
File "C:\Program Files\GRASS GIS
7.0.0\etc\python\grass\pygrass\modules\interface\module.py",
line 714, in run
get_msgr().debug(1, self.get_bash())
File "C:\Program Files\GRASS GIS
7.0.0\etc\python\grass\pygrass\messages\__init__.py", line
352, in get_msgr
_instance[0] = Messenger(*args, **kwargs)
File "C:\Program Files\GRASS GIS
7.0.0\etc\python\grass\pygrass\messages\__init__.py", line
175, in __init__
self.start_server()
File "C:\Program Files\GRASS GIS
7.0.0\etc\python\grass\pygrass\messages\__init__.py", line
185, in start_server
self.server.start()
File "C:\Program Files\GRASS GIS
7.0.0\Python27\lib\multiprocessing\process.py", line 130, in
start
self._popen = Popen(self)
File "C:\Program Files\GRASS GIS
7.0.0\Python27\lib\multiprocessing\forking.py", line 258, in
__init__
cmd = get_command_line() + [rhandle]
File "C:\Program Files\GRASS GIS
7.0.0\Python27\lib\multiprocessing\forking.py", line 358, in
get_command_line
is not going to be frozen to produce a Windows executable.''')
RuntimeError:
Attempt to start a new process before the current process
has finished its bootstrapping phase.
This probably means that you are on Windows and you have
forgotten to use the proper idiom in the main module:
if __name__ == '__main__':
freeze_support()
...
The "freeze_support()" line can be omitted if the program
is not going to be frozen to produce a Windows executable.
}}}
--
Ticket URL:
GRASS GIS
From kratochanna at gmail.com Wed Mar 4 10:36:14 2015
From: kratochanna at gmail.com (=?UTF-8?B?QW5uYSBQZXRyw6HFoW92w6E=?=)
Date: Wed, 4 Mar 2015 13:36:14 -0500
Subject: [GRASS-dev] raster digitizer
In-Reply-To:
References:
Message-ID:
On Wed, Mar 4, 2015 at 12:49 PM, Paulo van Breugel
wrote:
> When editing a raster using the raster digitizer, the resolution is
> changes (lower resolution) after saving the edits. Is this the intended
> behaviour, and if so, what is determining the resolution?
>
> My prefered behaviour would be that the resolution used follows that of
> the region settings.
>
Hm, that's how it should behave. Are you sure it's not doing that? I don't
change region anywhere in the code so it must use the computational region.
Anna
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From p.vanbreugel at gmail.com Wed Mar 4 11:07:54 2015
From: p.vanbreugel at gmail.com (Paulo van Breugel)
Date: Wed, 4 Mar 2015 20:07:54 +0100
Subject: [GRASS-dev] raster digitizer
In-Reply-To:
References:
Message-ID:
Hi Anna,
OK, I did some further testing in another mapset, and it seems it was a
problem with the region settings. After setting the region using 'set
computational region from selected map(s)' the region wasn't set correctly.
It seems to work fine now though. Sorry for the buzz.
On Wed, Mar 4, 2015 at 7:36 PM, Anna Petr??ov?
wrote:
>
>
> On Wed, Mar 4, 2015 at 12:49 PM, Paulo van Breugel > wrote:
>
>> When editing a raster using the raster digitizer, the resolution is
>> changes (lower resolution) after saving the edits. Is this the intended
>> behaviour, and if so, what is determining the resolution?
>>
>> My prefered behaviour would be that the resolution used follows that of
>> the region settings.
>>
>
> Hm, that's how it should behave. Are you sure it's not doing that? I don't
> change region anywhere in the code so it must use the computational region.
>
> Anna
>
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From kratochanna at gmail.com Wed Mar 4 11:12:43 2015
From: kratochanna at gmail.com (=?UTF-8?B?QW5uYSBQZXRyw6HFoW92w6E=?=)
Date: Wed, 4 Mar 2015 14:12:43 -0500
Subject: [GRASS-dev] raster digitizer
In-Reply-To:
References:
Message-ID:
On Wed, Mar 4, 2015 at 2:07 PM, Paulo van Breugel
wrote:
> Hi Anna,
>
> OK, I did some further testing in another mapset, and it seems it was a
> problem with the region settings. After setting the region using 'set
> computational region from selected map(s)' the region wasn't set correctly.
> It seems to work fine now though. Sorry for the buzz.
>
>
> no problem
Anna
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Mar 4, 2015 at 7:36 PM, Anna Petr??ov?
> wrote:
>
>>
>>
>> On Wed, Mar 4, 2015 at 12:49 PM, Paulo van Breugel <
>> p.vanbreugel at gmail.com> wrote:
>>
>>> When editing a raster using the raster digitizer, the resolution is
>>> changes (lower resolution) after saving the edits. Is this the intended
>>> behaviour, and if so, what is determining the resolution?
>>>
>>> My prefered behaviour would be that the resolution used follows that of
>>> the region settings.
>>>
>>
>> Hm, that's how it should behave. Are you sure it's not doing that? I
>> don't change region anywhere in the code so it must use the computational
>> region.
>>
>> Anna
>>
>>>
>>> _______________________________________________
>>> grass-dev mailing list
>>> grass-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From trac at osgeo.org Wed Mar 4 11:16:22 2015
From: trac at osgeo.org (GRASS GIS)
Date: Wed, 04 Mar 2015 19:16:22 -0000
Subject: [GRASS-dev] [GRASS GIS] #2608: Launching Python script on
Windows fails with missing freeze_support
In-Reply-To: <040.7de23d5903674d9ee8157dfeff0a04e2@osgeo.org>
References: <040.7de23d5903674d9ee8157dfeff0a04e2@osgeo.org>
Message-ID: <049.e845f095d924884c532e93687a4f96be@osgeo.org>
#2608: Launching Python script on Windows fails with missing freeze_support
-------------------------+--------------------------------------------------
Reporter: marisn | Owner: grass-dev@?
Type: defect | Status: new
Priority: normal | Milestone: 7.0.1
Component: Python | Version: 7.0.0
Keywords: | Platform: MSWindows Vista
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Changes (by martinl):
* milestone: => 7.0.1
--
Ticket URL:
GRASS GIS
From neteler at osgeo.org Wed Mar 4 11:29:39 2015
From: neteler at osgeo.org (Markus Neteler)
Date: Wed, 4 Mar 2015 20:29:39 +0100
Subject: [GRASS-dev] [GRASS-PSC] RFC 4: Release procedure
In-Reply-To: <54F73AC5.3080002@club.worldonline.be>
References: <539821A5.4010109@club.worldonline.be>
<54F5714E.4090401@club.worldonline.be>
<54F73AC5.3080002@club.worldonline.be>
Message-ID:
On Wed, Mar 4, 2015 at 6:03 PM, Moritz Lennert
wrote:
> On 04/03/15 09:19, Martin Landa wrote:
>>
>> Hi,
>>
>> 2015-03-03 9:31 GMT+01:00 Moritz Lennert :
>>>
>>> "A final, concerted bug squashing effort by all developers of no more
>>> than one week. During that same time the release announcement is drafted. If
>>> an important bug is discovered for which a fix needs some more testing, an
>>> RC3 can exceptionally be published, with another week of testing before final
>>> release."
>>
>>
>> make sense to me, Martin
>>
>
> Ok, I've added the change. In any case we are a small enough team to handle
> things flexibly if needed. For me, the idea of elaborating a release
> procedure is mostly to make the process more explicit and thus ease
> communication, not to hammer laws into stone
Great, so I'll make a motion on this in the next days unless any
objection pops up before.
Markus
From trac at osgeo.org Wed Mar 4 13:09:21 2015
From: trac at osgeo.org (GRASS GIS)
Date: Wed, 04 Mar 2015 21:09:21 -0000
Subject: [GRASS-dev] [GRASS GIS] #2609: Upload raster category labels to a
point file
Message-ID: <044.72574e7d5b6799a757f34748a8bdd2b7@osgeo.org>
#2609: Upload raster category labels to a point file
-------------------------+--------------------------------------------------
Reporter: pvanbosgeo | Owner: grass-dev@?
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.1
Component: Default | Version: unspecified
Keywords: | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
An option in r.what.rast to upload raster category labels to a point file
--
Ticket URL:
GRASS GIS
From ychemin at gmail.com Wed Mar 4 16:38:25 2015
From: ychemin at gmail.com (Yann Chemin)
Date: Thu, 5 Mar 2015 06:08:25 +0530
Subject: [GRASS-dev] GRASS GIS spectral analysis status
Message-ID:
Hi Devs,
Just looking at what GRASS does in the spectral domain, as a planetary scientist asked me how far GRASS could go to replace ENVI capabilities in that matter.
i.spec.unmix
i.spec.sam
i.spectral
is there any other tool that directly relate to spectral analysis?
Thx
Yann
PS: would there be a potential for GSoC or the ESA equivalent?
From trac at osgeo.org Thu Mar 5 01:22:46 2015
From: trac at osgeo.org (GRASS GIS)
Date: Thu, 05 Mar 2015 09:22:46 -0000
Subject: [GRASS-dev] [GRASS GIS] #2610: GRASS Gis v 6.4.4. KeyError:
'version' when start
Message-ID: <048.a8977d3604979bbcf759e28b3a6c4981@osgeo.org>
#2610: GRASS Gis v 6.4.4. KeyError: 'version' when start
----------------------------+-----------------------------------------------
Reporter: gisandforestry | Owner: grass-dev@?
Type: defect | Status: new
Priority: normal | Milestone: 7.0.1
Component: Startup | Version: 6.4.4
Keywords: | Platform: Linux
Cpu: x86-64 |
----------------------------+-----------------------------------------------
I use manjaro linux, I have one ssd for my primary disk and a second disk
for my data. I store the Grass Data on my second drive. When I try to
start Grass I get the following error.
{{{
GRASS 6.4.4 (Hellas):~ > ERROR: MAPSET Hellas - permission denied
Traceback (most recent call last):
File "/opt/grass64/etc/wxpython/wxgui.py", line 140, in
sys.exit(main())
File "/opt/grass64/etc/wxpython/wxgui.py", line 133, in main
app = GMApp(workspaceFile)
File "/opt/grass64/etc/wxpython/wxgui.py", line 45, in __init__
wx.App.__init__(self, False)
File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py", line
8628, in __init__
self._BootstrapApp()
File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py", line
8196, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
File "/opt/grass64/etc/wxpython/wxgui.py", line 79, in OnInit
workspace = self.workspaceFile)
File "/opt/grass64/etc/wxpython/lmgr/frame.py", line 83, in __init__
self.baseTitle = _("GRASS GIS %s Layer Manager") %
grass.version()['version']
KeyError: 'version'
}}}
--
Ticket URL:
GRASS GIS
From trac at osgeo.org Thu Mar 5 01:31:04 2015
From: trac at osgeo.org (GRASS GIS)
Date: Thu, 05 Mar 2015 09:31:04 -0000
Subject: [GRASS-dev] [GRASS GIS] #2610: GRASS Gis v 6.4.4. KeyError:
'version' when start
In-Reply-To: <048.a8977d3604979bbcf759e28b3a6c4981@osgeo.org>
References: <048.a8977d3604979bbcf759e28b3a6c4981@osgeo.org>
Message-ID: <057.6ba812fec5f8171cacf37b59d59207fc@osgeo.org>
#2610: GRASS Gis v 6.4.4. KeyError: 'version' when start
----------------------------+-----------------------------------------------
Reporter: gisandforestry | Owner: grass-dev@?
Type: defect | Status: new
Priority: normal | Milestone: 6.4.5
Component: Startup | Version: 6.4.4
Keywords: | Platform: Linux
Cpu: x86-64 |
----------------------------+-----------------------------------------------
Changes (by martinl):
* milestone: 7.0.1 => 6.4.5
--
Ticket URL:
GRASS GIS
From trac at osgeo.org Thu Mar 5 01:33:18 2015
From: trac at osgeo.org (GRASS GIS)
Date: Thu, 05 Mar 2015 09:33:18 -0000
Subject: [GRASS-dev] [GRASS GIS] #2610: GRASS Gis v 6.4.4. KeyError:
'version' when start
In-Reply-To: <048.a8977d3604979bbcf759e28b3a6c4981@osgeo.org>
References: <048.a8977d3604979bbcf759e28b3a6c4981@osgeo.org>
Message-ID: <057.9d2a267f7cd3ae28e9694d86a38fd460@osgeo.org>
#2610: GRASS Gis v 6.4.4. KeyError: 'version' when start
----------------------------+-----------------------------------------------
Reporter: gisandforestry | Owner: grass-dev@?
Type: defect | Status: new
Priority: normal | Milestone: 6.4.5
Component: Startup | Version: 6.4.4
Keywords: | Platform: Linux
Cpu: x86-64 |
----------------------------+-----------------------------------------------
Comment(by martinl):
It should be already fixed in SVN, probably it's time for 6.4.5RC1...
--
Ticket URL:
GRASS GIS
From neteler at osgeo.org Thu Mar 5 02:17:08 2015
From: neteler at osgeo.org (Markus Neteler)
Date: Thu, 5 Mar 2015 11:17:08 +0100
Subject: [GRASS-dev] Planning GRASS GIS 6.4.5 release
Message-ID:
Hi devs,
we have accumulated some relevant fixes in the 6.4 release branch.
Time to publish a new minor release.
FYI: The last release happened before r60974 (25 June 2014)
Following our proposed
http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
the release procedure would be:
Step 1 - Proposal of release: Done.
Step 2 (day X) - Soft freeze of release branch: suggestion 20 March 2015
Step 3 (X+30 days) - Hard freeze & RC1:
[important at least for the winGRASS package]
... etc according to RFC4.
Coordination to be done here:
http://trac.osgeo.org/grass/wiki/Grass6Planning
Any objections?
Best,
Markus
From landa.martin at gmail.com Thu Mar 5 02:27:26 2015
From: landa.martin at gmail.com (Martin Landa)
Date: Thu, 5 Mar 2015 11:27:26 +0100
Subject: [GRASS-dev] Planning GRASS GIS 6.4.5 release
In-Reply-To:
References:
Message-ID:
2015-03-05 11:17 GMT+01:00 Markus Neteler :
> Step 2 (day X) - Soft freeze of release branch: suggestion 20 March 2015
why not soft freeze since today? Are expecting some heavy changes in
this branch?
Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
From mlennert at club.worldonline.be Thu Mar 5 02:30:23 2015
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Thu, 05 Mar 2015 11:30:23 +0100
Subject: [GRASS-dev] Planning GRASS GIS 6.4.5 release
In-Reply-To:
References:
Message-ID: <54F8303F.2050609@club.worldonline.be>
On 05/03/15 11:17, Markus Neteler wrote:
> Hi devs,
>
> we have accumulated some relevant fixes in the 6.4 release branch.
> Time to publish a new minor release.
> FYI: The last release happened before r60974 (25 June 2014)
>
> Following our proposed
> http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
> the release procedure would be:
>
> Step 1 - Proposal of release: Done.
>
> Step 2 (day X) - Soft freeze of release branch: suggestion 20 March 2015
>
> Step 3 (X+30 days) - Hard freeze & RC1:
As there has not been that much recent development and thus, AFAIK, not
that much to backport, maybe +30 is a bit too much in this case.
Just applying the flexibility I wrote about...
;-)
Moritz
From neteler at osgeo.org Thu Mar 5 06:04:00 2015
From: neteler at osgeo.org (Markus Neteler)
Date: Thu, 5 Mar 2015 15:04:00 +0100
Subject: [GRASS-dev] Planning GRASS GIS 6.4.5 release
In-Reply-To:
References:
Message-ID:
On Thu, Mar 5, 2015 at 11:27 AM, Martin Landa wrote:
> 2015-03-05 11:17 GMT+01:00 Markus Neteler :
>> Step 2 (day X) - Soft freeze of release branch: suggestion 20 March 2015
>
> why not soft freeze since today? Are expecting some heavy changes in
> this branch?
AFAIK the backport of the topology fixes.
Markus
From trac at osgeo.org Thu Mar 5 14:39:51 2015
From: trac at osgeo.org (GRASS GIS)
Date: Thu, 05 Mar 2015 22:39:51 -0000
Subject: [GRASS-dev] [GRASS GIS] #2611: add stream power index to GRASS GIS
Message-ID: <040.d8a5e654f7b1ff5a7eff3bc9c8df06ce@osgeo.org>
#2611: add stream power index to GRASS GIS
-------------------------+--------------------------------------------------
Reporter: hellik | Owner: grass-dev@?
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.1
Component: Raster | Version: svn-releasebranch70
Keywords: | Platform: All
Cpu: All |
-------------------------+--------------------------------------------------
related to this discussion:
http://osgeo-org.1560.x6.nabble.com/Stream-power-Index-calculation-
td5190756.html
add stream power index to GRASS GIS.
as calculation parameters are already there, candidates for including are:
r.watershed
r.topidx
thanks
--
Ticket URL:
GRASS GIS
From markus.metz.giswork at gmail.com Thu Mar 5 23:26:59 2015
From: markus.metz.giswork at gmail.com (Markus Metz)
Date: Fri, 6 Mar 2015 08:26:59 +0100
Subject: [GRASS-dev] Planning GRASS GIS 6.4.5 release
In-Reply-To:
References:
Message-ID:
On Thu, Mar 5, 2015 at 3:04 PM, Markus Neteler wrote:
> On Thu, Mar 5, 2015 at 11:27 AM, Martin Landa wrote:
>> 2015-03-05 11:17 GMT+01:00 Markus Neteler :
>>> Step 2 (day X) - Soft freeze of release branch: suggestion 20 March 2015
>>
>> why not soft freeze since today? Are expecting some heavy changes in
>> this branch?
>
> AFAIK the backport of the topology fixes.
Yes. I want to do the backports next week.
Markus M
>
> Markus
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
From trac at osgeo.org Fri Mar 6 00:56:08 2015
From: trac at osgeo.org (GRASS GIS)
Date: Fri, 06 Mar 2015 08:56:08 -0000
Subject: [GRASS-dev] [GRASS GIS] #2612: pygrass: grid module still contains
references to old type names
Message-ID: <042.45e974d3da78726cfdc4dcb922c262d9@osgeo.org>
#2612: pygrass: grid module still contains references to old type names
-------------------------------+--------------------------------------------
Reporter: mlennert | Owner: grass-dev@?
Type: defect | Status: new
Priority: normal | Milestone: 7.0.1
Component: Default | Version: svn-trunk
Keywords: pygrass grid type | Platform: Unspecified
Cpu: Unspecified |
-------------------------------+--------------------------------------------
The grid module in pygrass still calls types as 'rast' and 'vect', instead
of 'raster' and 'vector'.
IIUC, the attached patch should solve this, but as I'm not sure of
possible consequences, I'd rather have someone who knows pygrass better
look over it.
--
Ticket URL:
GRASS GIS
From trac at osgeo.org Fri Mar 6 01:36:45 2015
From: trac at osgeo.org (GRASS GIS)
Date: Fri, 06 Mar 2015 09:36:45 -0000
Subject: [GRASS-dev] [GRASS GIS] #2613: Polygons disappear after v.overlay
AND operation
Message-ID: <038.3d311469ca1dbe4a0ede16cf2013e11f@osgeo.org>
#2613: Polygons disappear after v.overlay AND operation
--------------------------------------------+-------------------------------
Reporter: dido | Owner: grass-dev@?
Type: defect | Status: new
Priority: major | Milestone:
Component: Vector | Version: 7.0.0
Keywords: v.overlay and polygons damaged | Platform: MSWindows 7
Cpu: x86-64 |
--------------------------------------------+-------------------------------
A shapefile polygon set A has been cut using a grid polygon B using a
v.overlay AND operation. The result is expected to contain all the A
polygons that are enclosed within the grid polygon B.
The output is almost as expected but several A polygons within the B
rectangle are missing. GRASS version is 7.0.0.RC1. Here is the io console
log:
(Fri Mar 06 11:07:12 2015)
v.overlay ainput=K3445_NEW_FISH at BGM_POLY_UTM
binput=GRID_K34058 at BGM_POLY_UTM operator=and output=K34058_NEW
Copying vector features from ...
Copying vector features from ...
Snapping boundaries with 1e-008 ...
Breaking lines...
Removing duplicates...
Cleaning boundaries at nodes...
Breaking lines...
Removing duplicates...
Cleaning boundaries at nodes...
Breaking lines...
Removing duplicates...
Cleaning boundaries at nodes...
WARNING: Number of incorrect boundaries: 949
Merging lines...
Attaching islands...
Building areas...
25262 areas built
7375 isles built
Attaching islands...
Number of nodes: 41280
Number of primitives: 60697
Number of points: 0
Number of lines: 0
Number of boundaries: 60697
Number of centroids: 0
Number of areas: 25262
Number of isles: 7375
Querying vector map ...
Querying vector map ...
Writing centroids...
WARNING: Unable to delete file
'E:\mapping\GRASS7DB/BGM_POLY_UTM/BGM_POLY_UTM/.tmp/unknown/vector/tmp_7316/coor'
Building topology for vector map