Re: [GRASS-dev] display monitor (how to everlay 2 layers)

[epi]

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

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

Re: [GRASS-dev] [GRASS-PSC] RFC 4: Release procedure

[Michael Barton]

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
> hmit...@ncsu.edu
> http://geospatial.ncsu.edu/osgeorel/
> "All electronic mail messages in connection with State business which are 
> sent to or received by this account are subject to the NC Public Records Law 
> and may be disclosed to third parties.” 
> 
> On 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-...@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-psc
> 
> ___
> grass-psc mailing list
> grass-...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-psc

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

Re: [GRASS-dev] [GRASS-PSC] RFC 4: Release procedure

[Helena Mitasova]

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
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/
"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On 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-...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-psc

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

Re: [GRASS-dev] [GRASS GIS] #2598: g.extension compilation fails

[GRASS GIS]

#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 

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

Re: [GRASS-dev] display monitor (how to everlay 2 layers)

[Martin Landa]

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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] display monitor (how to everlay 2 layers)

[Anna Petrášová]

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@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2598: g.extension compilation fails

[GRASS GIS]

#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 

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

Re: [GRASS-dev] display monitor (how to everlay 2 layers)

[epi]

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

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

Re: [GRASS-dev] display monitor (how to everlay 2 layers)

[Martin Landa]

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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] display monitor (how to everlay 2 layers)

[epi]

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.

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

Re: [GRASS-dev] Select vector feature - Error

[Martin Landa]

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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2602: GUI preferences dialog fails to open

[GRASS GIS]

#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 

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

Re: [GRASS-dev] [GRASS GIS] #2602: GUI preferences dialog fails to open

[GRASS GIS]

#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 

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

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

[Blumentrath, Stefan]

Good to hear.

As for the “GRASS GIS locations created from public data” idea, I might be able 
to provide some shell scripts to start with and I guess many others have 
something similar too. A central question there would be likely licensing of 
the data which is not always clear I am afraid?!

Cheers
Stefan

From: grass-dev-boun...@lists.osgeo.org 
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Markus Neteler
Sent: 3. mars 2015 10:59
To: GRASS developers list
Subject: [GRASS-dev] Fwd: [OSGeo-Discuss] OSGeo accepted to GSoC 2015 - 
overview of slot assignments

FYI

-- Forwarded message --
From: Margherita Di Leo mailto:direg...@gmail.com>>
Date: Tue, Mar 3, 2015 at 10:41 AM
Subject: [OSGeo-Discuss] OSGeo accepted to GSoC 2015 - overview of slot 
assignments
To: OSGeo Discussions 
mailto:disc...@lists.osgeo.org>>, OSGeo-SoC 
mailto:s...@lists.osgeo.org>>

Dear All,

it is our pleasure to announce that OSGeo has been accepted as mentoring 
organization also this year! [1]
The OSGeo GSoC Team has been reshaped with respect to former communications, 
and it's now composed by myself (Madi) in the role of primary admin and the 
experienced Anne Ghisla in the role of co-admin.

Now it's time for prospecting students to carefully browse the list of ideas 
and contact developers team of their interest. Mentor registration is not yet 
open and will be announced in due time. Students can officially apply on 
Melange from 16th to 27th of March.

All, do keep an eye (and a calendar client reminder) on all GSoC 2015 dates [2]!

This year, we will be using slightly different procedure for assigning slots to 
selected projects. The experience from previous years made it possible to 
define the criteria that will be applied this year, and hopefully will be 
improved in the future:

1. Each project requires at least two mentors. The soundness of the project, 
the selection of reliable mentors and student is responsibility of its 
community. However, this year we strongly encourage the community to assign to 
the wannabe-GSoC-student some small programming tasks or bug fixes, in order to 
be sure that (s)he is familiar with the selected software, the programming 
environment, version control system, mailing list, etc and can code. Particular 
attention should be paid in the selection of mentors that won't disappear in 
the course of the GSoC.

2. Each OSGeo software will have one slot assigned, provided that the 
conditions at point 1 are met.

3. Like previous years, OSGeo will host some like-minded projects that 
requested it, and will assign 1 slot to each guest, provided that the 
conditions at point 1 are met.

4. This year we want to encourage projects that entail the integration between 
two or more OSGeo software. For this reason, one extra slot will be assigned to 
(sound) projects that aim at integrating two or more software, provided that 
mentors of respective communities are involved.

5. If the number of slots will allow it, extra slots can be assigned to 
projects that have gained a good rate of success in the course of past years 
(reliable -not disappearing- mentors, student success, etc).

Further discussion on specific slot assignments will take place among mentors 
in due time. This is the admins outline of this year's criteria.

Please send answers to this announcement to soc [3] list, and forward this mail 
to all relevant mailing lists of your knowledge.

And now, let s do this thing!
http://tinyurl.com/l32yzgp

Yours enthusiastically,

Madi and Anne
OSGeo GSoC Admins 2015

[1] 
http://google-opensource.blogspot.it/2015/03/mentoring-organizations-for-google.html
[2] https://www.google-melange.com/gsoc/events/google/gsoc2015
[3] http://lists.osgeo.org/mailman/listinfo/soc




--
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not in 
any circumstance be regarded as stating an official position of the European 
Commission.

___
Discuss mailing list
disc...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

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

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

[Markus Neteler]

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 <
s...@lists.osgeo.org>


Dear All,

it is our pleasure to announce that *OSGeo has been accepted as mentoring
organization* also this year! [1]
The OSGeo GSoC Team has been reshaped with respect to former
communications, and it's now composed by myself (Madi) in the role of
primary admin and the experienced Anne Ghisla in the role of co-admin.

Now it's time for prospecting students to carefully browse the list of
ideas and contact developers team of their interest. Mentor registration is
not yet open and will be announced in due time. Students can officially
apply on Melange from 16th to 27th of March.

All, do keep an eye (and a calendar client reminder) on all *GSoC 2015
dates* [2]!

This year, we will be using slightly different *procedure for assigning
slots* to selected projects. The experience from previous years made it
possible to define the criteria that will be applied this year, and
hopefully will be improved in the future:

1. Each project requires at least *two mentors*. The soundness of the
project, the selection of reliable mentors and student is responsibility of
its community. However, this year we strongly encourage the community to
assign to the wannabe-GSoC-student some small programming tasks or bug
fixes, in order to be sure that (s)he is familiar with the selected
software, the programming environment, version control system, mailing
list, etc and can code. Particular attention should be paid in the
selection of mentors that *won't disappear* in the course of the GSoC.

2. Each OSGeo software will have *one* slot assigned, provided that the
conditions at point 1 are met.

3. Like previous years, OSGeo will host some like-minded projects that
requested it, and will assign *1* slot to each guest, provided that the
conditions at point 1 are met.

4. This year we want to encourage projects that entail the* integration
between two or more OSGeo software*. For this reason, one extra slot will
be assigned to (sound) projects that aim at integrating two or more
software, provided that mentors of respective communities are involved.

5. If the number of slots will allow it, extra slots can be assigned to
projects that have gained a good *rate of success* in the course of past
years (reliable -not disappearing- mentors, student success, etc).

Further discussion on specific slot assignments will take place among
mentors in due time. This is the admins outline of this year's criteria.

Please send answers to this announcement* to soc [3] list*, and forward
this mail to all relevant mailing lists of your knowledge.

*And now, let s do this thing!*
*http://tinyurl.com/l32yzgp *

Yours enthusiastically,

Madi and Anne
OSGeo GSoC Admins 2015

[1]
http://google-opensource.blogspot.it/2015/03/mentoring-organizations-for-google.html
[2] https://www.google-melange.com/gsoc/events/google/gsoc2015
[3] http://lists.osgeo.org/mailman/listinfo/soc




-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.

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

[GRASS-dev] Python loop and SQLite performance issue?

[Blumentrath, Stefan]

Hi,

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

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

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

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

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

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

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

Cheers
Stefan

P.S.: I can share the script if that helps identifying the issue...
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Select vector feature - Error

[Moritz Lennert]

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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-PSC] RFC 4: Release procedure

[Moritz Lennert]

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