Blumentrath, Stefan | 3 Mar 11:13 2015
Picon

Re: Fwd: [OSGeo-Discuss] OSGeo accepted to GSoC 2015 - overview of slot assignments

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 <diregola <at> gmail.com>
Date: Tue, Mar 3, 2015 at 10:41 AM
Subject: [OSGeo-Discuss] OSGeo accepted to GSoC 2015 - overview of slot assignments
To: OSGeo Discussions <discuss <at> lists.osgeo.org>, 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!

 

Yours enthusiastically,

 

Madi and Anne

OSGeo GSoC Admins 2015

 

 

 

 

 

--

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   

 

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

 

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Blumentrath, Stefan | 3 Mar 10:13 2015
Picon

Python loop and SQLite performance issue?

Hi,

 

I am struggling with the performance of SQLite (I think), esp. when I use it in a python loop executed in parallel processes (using xargs) .

 

I am analyzing characteristics of a relatively large number (270k) of overlapping lake catchments which were generated in GRASS and now are stored in a PostGIS DB. I split the data in (10) chunks and analyse each chunk in it`s own GRASS 70 mapset (with SQLite backend) where I am looping over the catchments one by one (in python).

 

At first I tried to import the individual catchments using v.in.ogr. But v.in.ogr was slowing down the process significantly. It took 11 seconds to import a single, not very complex polygon (which is probably related to: https://trac.osgeo.org/grass/ticket/2185 ?; btw. my GRASSDB is not on NFS). So I switched to using gdal_rasterize and linked the resulting raster to GRASS (r.external) (as I am planning to work with rasters ater anyway). Rasterization and import takes all together less than a second. It made no difference for the speed of v.in.ogr if I imported the attribute table or not. However, converting the raster to vector in GRASS takes less than a second, so the topology creation does not seem to be the issue and also an attribute table is created…

 

Then I add a relatively large number of columns (400 or something) using v.db.addcolumn. That again takes 19 seconds for my single test process. If I run all 10 chunks in parallel (I have 24 cores and lots of memory available), adding the columns takes 30 seconds for each catchment, almost twice as much). During the loop the time spend on adding the columns continues increasing up to almost 30 min (at that point I canceled the process)… There is obviously something not working as it should be…

 

Analysing (r.univar) ca. 40 raster maps takes for the smaller catchments all together less than 5 seconds.

 

After that I removed all SQLite related code from my script and loaded results directly back to PostgreSQL/PostGIS. Then the smaller catchments are done in less than 5 seconds…

 

Does anyone have an idea what cause this performance loss is due to? Is it no good practice to call a python script (v.db.addcolumn) in a python loop, or is this related to SQLite journal files or …

I am grateful for any hints!

 

Cheers

Stefan

 

P.S.: I can share the script if that helps identifying the issue…

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Nikos Alexandris | 2 Mar 11:29 2015
Picon

Wrong HOME environment variable at start-up

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
Margherita Di Leo | 2 Mar 11:28 2015
Picon

Select vector feature - Error

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   

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.
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 2 Mar 03:56 2015

[GRASS GIS] #2606: Bugs in r.sun

#2606: Bugs in r.sun
----------------------+-----------------------------------------------------
 Reporter:  ojni0001  |       Owner:  grass-dev <at> …              
     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: <http://trac.osgeo.org/grass/ticket/2606>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 2 Mar 00:05 2015

[GRASS GIS] #2605: d.rast.leg: invalid literal for float(): rectangle

#2605: d.rast.leg: invalid literal for float(): rectangle
-------------------------+--------------------------------------------------
 Reporter:  pertusus     |       Owner:  grass-dev <at> …              
     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
 <module>
     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: <http://trac.osgeo.org/grass/ticket/2605>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Helmut Kudrnovsky | 1 Mar 22:54 2015
Picon

grass addon sync to github

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.
Andy Wickert | 1 Mar 19:40 2015
Picon

A better r.fillnulls

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
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Patrice Dumas | 1 Mar 17:01 2015
Picon

port of v.points.cog to python

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
Index: grass7/vector/Makefile
===================================================================
--- grass7/vector/Makefile	(révision 64773)
+++ grass7/vector/Makefile	(copie de travail)
 <at>  <at>  -35,6 +35,7  <at>  <at> 
 	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)
 <at>  <at>  -1,53 +0,0  <at>  <at> 
-<h2>DESCRIPTION</h2>
-
-
-<em>v.points.cog</em> condenses points or centroids sharing
-a common attribute into a single point in a new vector map at their
-average position (center of gravity).
-<p>
-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.
-<p>
-If needed you can use <em>v.digit</em> to adjust point positions
-created by this module, <!-- repel 2 points if v.distance < minimum? -->
-or use this module as a preprocessing step before running
-<em>v.label.sa</em> to deal with overlapping labels automatically. 
-
-<!--<p> appropriate for lat/lon? (weighted avg for y by cos(y)?) -->
-
-
-<h2>EXAMPLE</h2>
-
-Create single points at the average of all points in the
-<tt>bugsites</tt> map, and place a single label there.
-
-<div class="code"><pre>
-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
-</pre></div>
-
-
-<h2>SEE ALSO</h2>
-<em>
-<a href="v.label.sa.html">v.label.sa</a><br>
-<a href="v.label.html">v.label</a><br>
-<a href="v.digit.html">v.digit</a>
-</em>
-
-
-<h2>AUTHOR</h2>
-
-Hamish Bowman<br>
-<i>Dept. Marine Science<br>
-University of Otago<br>
-Dunedin, New Zealand</i>
-<br>
-
-<p>
-<i>Last changed: $Date$</i>
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)
 <at>  <at>  -1,142 +0,0  <at>  <at> 
-#!/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" != " <at> ARGS_PARSED <at> " ] ; then
-    exec g.parser "$0" "$ <at> "
-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  <at> another mapset
-DB=`v.db.connect "$MAP" -g layer="$LAYER" fs='|' | cut -f4 -d'|'`
-BASENAME=`echo "$MAP" | sed -e 's/ <at> .*//'`
-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)
 <at>  <at>  -1,4 +1,4  <at>  <at> 
-#!/bin/sh
+#!/usr/bin/env python
 #
 ############################################################################
 #
 <at>  <at>  -57,86 +57,74  <at>  <at> 
 ##% 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" != " <at> ARGS_PARSED <at> " ] ; then
-    exec g.parser "$0" "$ <at> "
-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  <at> another mapset
+    map_connection_info = grass.vector_db(map)[int(layer)]
+    db = map_connection_info['database']
+    basename = map.split(" <at> ")[0]

-# get column details so we can recreate it.
-# The db.* modules need special care when querying from  <at> another mapset
-DB=`v.db.connect "$MAP" -g layer="$LAYER" fs='|' | cut -f4 -d'|'`
-BASENAME=`echo "$MAP" | sed -e 's/ <at> .*//'`
-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()
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Nikos Alexandris | 28 Feb 11:06 2015
Picon

Broken "Search archive" link

This one <http://grass.osgeo.org/searchgrass.php> is broken.

Nikos
GRASS GIS | 28 Feb 10:09 2015

[GRASS GIS] #2604: recently open workspace in wxGUI

#2604: recently open workspace in wxGUI
-------------------------------+--------------------------------------------
 Reporter:  martinl            |       Owner:  grass-dev <at> …              
     Type:  enhancement        |      Status:  new                      
 Priority:  normal             |   Milestone:  7.1.0                    
Component:  wxGUI              |     Version:  svn-trunk                
 Keywords:  workspace, recent  |    Platform:  Unspecified              
      Cpu:  Unspecified        |  
-------------------------------+--------------------------------------------
 To be implemented:

  * ability to automatically open last workspace file when starting GRASS
  * add "Recently open workspaces" item to the menu "File" in Layer Manager

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2604>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Gmane