Re: [SoC] Re: [GRASS-dev] SoC proposal

[Margherita Di Leo]

I would like to thank everyone of you for the answer.
I have to say that this project is not just my idea but it is the effect of
the discussion I had with Jarek on how the GUI shall work. We know that the
project is challenging and eventually the help of all of you is more than
appreciate, especially on the wxpython side.
I really hope to be worthy of your trust.

Thank you very much

madi


2011/4/5 Helena Mitasova 

> I can co-mentor as well - this could be another strong project by a student
> with excellent qualifications,
> Martin can you please add it to the ideas page - perhaps under raster so
> that we have everything in one place?
>
>
> Helena
>
> On Apr 5, 2011, at 10:43 AM, Markus Metz wrote:
>
> > On Tue, Apr 5, 2011 at 4:37 PM, Martin Landa 
> wrote:
> >> Hi,
> >>
> >> 2011/3/31 Margherita Di Leo :
> >>> I am willing to participate as student to GSoC with a GRASS GIS related
> >>> project.
> >>> I'm a third year PhD student and my main research interests lie in
> >>> hydrological modeling coupled with GIS.
> >>> My idea is the following: recently, in GRASS GIS new modules suitable
> for
> >>> hydrological analysis have been developed, r.stream*. I tested it and
> found
> >>> very complete and useful, I currently use it for hydrological analysis
> and
> >>> develop python scripts using it.
> >>> My idea for GSoC is to develop a sophisticated Graphical User Interface
> in
> >>> wxpython for r.stream*.
> >>> GIMP users may know the Filter Pack, that allow to see the preview of
> the
> >>> effects over an image. I imagine the r.stream* GUI something like that,
> in
> >>> which it's possible to see rapidly on a small portion of the area of
> >>> interest the result of the hydrological analysis, and then decide if
> apply
> >>> the analysis or not.
> >>>
> >>> It will include "multiple previews". Every result can be saved as an
> image
> >>> and set of parameters for future use in additional "preview windows",
> next
> >>> choose from group of possible parameters that which is most suitable.
> >>> Also, changing the extend of sample area will be available "on the
> fly".
> >>>
> >>> Parameters that shall to be shown are:
> >>> * network (vector) + optionally (order + elementary basins +
> >>> distance/elevation)
> >>>
> >>> Parameters to change:
> >>> * threshold
> >>> * Montgomery exponent
> >>> * SFD treshold
> >>>
> >>> Optionally:
> >>> * Flow accumulation map
> >>> * Map of depressions
> >>>
> >>> The advantage of such a graphical interface is to allow the user to
> have a
> >>> simple approach to a sophisticated thing like hydrology. Many
> hydrologists
> >>> use other GIS suites because they simply don't know or don't know how
> to use
> >>> r.stream*. I believe that such a GUI could improve the user approach to
> >>> hydrological analysis in GRASS.
> >>>
> >>> My tentative of timeline is the following:
> >>>
> >>> 2 weeks: design interface based on other similar software
> >>> 3 weeks - midterm goal: get a preview widget working in grass7
> >>> 3 weeks: add functionality and documentation
> >>> 1 week: testing
> >>> final goal: working GUI for grass7
> >>
> >> I could be co-mentor for this project (wxGUI part), anyone interested
> >> to mentor this project from hydrological modeling point of view?
> >>
> > I could co-mentor the hydrological component.
> >
> > Markus M
> > ___
> > SoC mailing list
> > s...@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/soc
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Ossim mentor application

[Massimo Di Stefano]

Hi,
my name is Massimo Di Stefano, I wold like to make myself available as a
mentor for the Ossim project. and provide help as co-menthor for the project 
related to grass, qgis and otb.

I started my collaboration with the Ossim-dev team some years ago and thanks
to a Google Summer of Code experience 2 years ago, since then i continued to 
work on my gsoc project PlanetSasha [1] 
as part of the ossim project (it is a pyqt based app that uses grass analisys 
support system and ossimplanet as map-canvas, sort of "gis 3d app").

For this summer of code we're thinking about the idea to develop a python
interface for ossim (re-using code from the already done java-swig interface, 
or using other tools as sip) 
as GRASS, QGIS, GDAL already have a python interface the interaction between 
this tools can be greatly improved 
exposing the OSSIM and OSSIMPlanet api  to the python language.

The python bindings resulting from this gsoc idea will be used to write a 
toolbox based on the  ossim function as an extension to grass and qgis for 
image analisys
while the python bindings for the ossimplanet api will be used to extend the 
planetsasha functionalities inside the respective grass and qgis plug-in.

So the idea is dedicated to the Ossim project but the benefit will be shared 
along several OSGeo projects like Grass and Qgis.

I registered myself on the google summer of code web-site and added a
general description of the idea on the respective wiki pages :

http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2011_Ideas
http://trac.osgeo.org/ossim/wiki/WikiStart


Thanks,

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

Re: [SoC] Re: [GRASS-dev] SoC proposal

[Helena Mitasova]

that is right, Helena

On Apr 5, 2011, at 2:37 PM, Martin Landa wrote:


Hi,

2011/4/5 Helena Mitasova :
I can co-mentor as well - this could be another strong project by a  
student with excellent qualifications,
Martin can you please add it to the ideas page - perhaps under  
raster so that we have everything in one place?


I think wxGUI section is more suitable for this topic. Added [1], feel
free to extend this idea.

Martin

[1] http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2011#wxGUI

--
Martin Landa  * http://geo.fsv.cvut.cz/~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: [SoC] Re: [GRASS-dev] SoC proposal

[Martin Landa]

Hi,

2011/4/5 Helena Mitasova :
> I can co-mentor as well - this could be another strong project by a student 
> with excellent qualifications,
> Martin can you please add it to the ideas page - perhaps under raster so that 
> we have everything in one place?

I think wxGUI section is more suitable for this topic. Added [1], feel
free to extend this idea.

Martin

[1] http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2011#wxGUI

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

Re: [SoC] Re: [GRASS-dev] SoC proposal

[Jarekj Jasiewicz]

On 04/05/2011 11:40 AM, Helena Mitasova wrote:

I can co-mentor as well - this could be another strong project by a student 
with excellent qualifications,
Martin can you please add it to the ideas page - perhaps under raster so that 
we have everything in one place?


Helena

On Apr 5, 2011, at 10:43 AM, Markus Metz wrote:


On Tue, Apr 5, 2011 at 4:37 PM, Martin Landa  wrote:

Hi,

2011/3/31 Margherita Di Leo:

I am willing to participate as student to GSoC with a GRASS GIS related
project.
I'm a third year PhD student and my main research interests lie in
hydrological modeling coupled with GIS.
My idea is the following: recently, in GRASS GIS new modules suitable for
hydrological analysis have been developed, r.stream*. I tested it and found
very complete and useful, I currently use it for hydrological analysis and
develop python scripts using it.
My idea for GSoC is to develop a sophisticated Graphical User Interface in
wxpython for r.stream*.
GIMP users may know the Filter Pack, that allow to see the preview of the
effects over an image. I imagine the r.stream* GUI something like that, in
which it's possible to see rapidly on a small portion of the area of
interest the result of the hydrological analysis, and then decide if apply
the analysis or not.

It will include "multiple previews". Every result can be saved as an image
and set of parameters for future use in additional "preview windows", next
choose from group of possible parameters that which is most suitable.
Also, changing the extend of sample area will be available "on the fly".

Parameters that shall to be shown are:
* network (vector) + optionally (order + elementary basins +
distance/elevation)

Parameters to change:
* threshold
* Montgomery exponent
* SFD treshold

Optionally:
* Flow accumulation map
* Map of depressions

The advantage of such a graphical interface is to allow the user to have a
simple approach to a sophisticated thing like hydrology. Many hydrologists
use other GIS suites because they simply don't know or don't know how to use
r.stream*. I believe that such a GUI could improve the user approach to
hydrological analysis in GRASS.

My tentative of timeline is the following:

2 weeks: design interface based on other similar software
3 weeks - midterm goal: get a preview widget working in grass7
3 weeks: add functionality and documentation
1 week: testing
final goal: working GUI for grass7

I could be co-mentor for this project (wxGUI part), anyone interested
to mentor this project from hydrological modeling point of view?


I could co-mentor the hydrological component.

Markus M
___
SoC mailing list
s...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/soc

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

and of course I would be a co-mentor of this project
Jarek
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [SoC] Re: [GRASS-dev] SoC proposal

[Helena Mitasova]

I can co-mentor as well - this could be another strong project by a student 
with excellent qualifications,
Martin can you please add it to the ideas page - perhaps under raster so that 
we have everything in one place?


Helena 

On Apr 5, 2011, at 10:43 AM, Markus Metz wrote:

> On Tue, Apr 5, 2011 at 4:37 PM, Martin Landa  wrote:
>> Hi,
>> 
>> 2011/3/31 Margherita Di Leo :
>>> I am willing to participate as student to GSoC with a GRASS GIS related
>>> project.
>>> I'm a third year PhD student and my main research interests lie in
>>> hydrological modeling coupled with GIS.
>>> My idea is the following: recently, in GRASS GIS new modules suitable for
>>> hydrological analysis have been developed, r.stream*. I tested it and found
>>> very complete and useful, I currently use it for hydrological analysis and
>>> develop python scripts using it.
>>> My idea for GSoC is to develop a sophisticated Graphical User Interface in
>>> wxpython for r.stream*.
>>> GIMP users may know the Filter Pack, that allow to see the preview of the
>>> effects over an image. I imagine the r.stream* GUI something like that, in
>>> which it's possible to see rapidly on a small portion of the area of
>>> interest the result of the hydrological analysis, and then decide if apply
>>> the analysis or not.
>>> 
>>> It will include "multiple previews". Every result can be saved as an image
>>> and set of parameters for future use in additional "preview windows", next
>>> choose from group of possible parameters that which is most suitable.
>>> Also, changing the extend of sample area will be available "on the fly".
>>> 
>>> Parameters that shall to be shown are:
>>> * network (vector) + optionally (order + elementary basins +
>>> distance/elevation)
>>> 
>>> Parameters to change:
>>> * threshold
>>> * Montgomery exponent
>>> * SFD treshold
>>> 
>>> Optionally:
>>> * Flow accumulation map
>>> * Map of depressions
>>> 
>>> The advantage of such a graphical interface is to allow the user to have a
>>> simple approach to a sophisticated thing like hydrology. Many hydrologists
>>> use other GIS suites because they simply don't know or don't know how to use
>>> r.stream*. I believe that such a GUI could improve the user approach to
>>> hydrological analysis in GRASS.
>>> 
>>> My tentative of timeline is the following:
>>> 
>>> 2 weeks: design interface based on other similar software
>>> 3 weeks - midterm goal: get a preview widget working in grass7
>>> 3 weeks: add functionality and documentation
>>> 1 week: testing
>>> final goal: working GUI for grass7
>> 
>> I could be co-mentor for this project (wxGUI part), anyone interested
>> to mentor this project from hydrological modeling point of view?
>> 
> I could co-mentor the hydrological component.
> 
> Markus M
> ___
> SoC mailing list
> s...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/soc

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

[GRASS-dev] Re: [GRASS GIS] #1235: ERROR: G_getenv(): Variable LOCATION_NAME not set

[GRASS GIS]

#1235: ERROR: G_getenv(): Variable LOCATION_NAME not set
-+--
 Reporter:  apgis|   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.1
Component:  LibGIS   | Version:  unspecified  
 Keywords:  wingrass |Platform:  MSWindows XP 
  Cpu:  Unspecified  |  
-+--

Comment(by marisn):

 Please check Your paths for presence of non-latin letters. I get same
 error because my username under Windows is "Māris" (see other issues for
 details).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [SoC] Re: [GRASS-dev] SoC proposal

[Markus Metz]

On Tue, Apr 5, 2011 at 4:37 PM, Martin Landa  wrote:
> Hi,
>
> 2011/3/31 Margherita Di Leo :
>> I am willing to participate as student to GSoC with a GRASS GIS related
>> project.
>> I'm a third year PhD student and my main research interests lie in
>> hydrological modeling coupled with GIS.
>> My idea is the following: recently, in GRASS GIS new modules suitable for
>> hydrological analysis have been developed, r.stream*. I tested it and found
>> very complete and useful, I currently use it for hydrological analysis and
>> develop python scripts using it.
>> My idea for GSoC is to develop a sophisticated Graphical User Interface in
>> wxpython for r.stream*.
>> GIMP users may know the Filter Pack, that allow to see the preview of the
>> effects over an image. I imagine the r.stream* GUI something like that, in
>> which it's possible to see rapidly on a small portion of the area of
>> interest the result of the hydrological analysis, and then decide if apply
>> the analysis or not.
>>
>> It will include "multiple previews". Every result can be saved as an image
>> and set of parameters for future use in additional "preview windows", next
>> choose from group of possible parameters that which is most suitable.
>> Also, changing the extend of sample area will be available "on the fly".
>>
>> Parameters that shall to be shown are:
>> * network (vector) + optionally (order + elementary basins +
>> distance/elevation)
>>
>> Parameters to change:
>> * threshold
>> * Montgomery exponent
>> * SFD treshold
>>
>> Optionally:
>> * Flow accumulation map
>> * Map of depressions
>>
>> The advantage of such a graphical interface is to allow the user to have a
>> simple approach to a sophisticated thing like hydrology. Many hydrologists
>> use other GIS suites because they simply don't know or don't know how to use
>> r.stream*. I believe that such a GUI could improve the user approach to
>> hydrological analysis in GRASS.
>>
>> My tentative of timeline is the following:
>>
>> 2 weeks: design interface based on other similar software
>> 3 weeks - midterm goal: get a preview widget working in grass7
>> 3 weeks: add functionality and documentation
>> 1 week: testing
>> final goal: working GUI for grass7
>
> I could be co-mentor for this project (wxGUI part), anyone interested
> to mentor this project from hydrological modeling point of view?
>
I could co-mentor the hydrological component.

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

Re: [GRASS-dev] SoC proposal

[Martin Landa]

Hi,

2011/3/31 Margherita Di Leo :
> I am willing to participate as student to GSoC with a GRASS GIS related
> project.
> I'm a third year PhD student and my main research interests lie in
> hydrological modeling coupled with GIS.
> My idea is the following: recently, in GRASS GIS new modules suitable for
> hydrological analysis have been developed, r.stream*. I tested it and found
> very complete and useful, I currently use it for hydrological analysis and
> develop python scripts using it.
> My idea for GSoC is to develop a sophisticated Graphical User Interface in
> wxpython for r.stream*.
> GIMP users may know the Filter Pack, that allow to see the preview of the
> effects over an image. I imagine the r.stream* GUI something like that, in
> which it's possible to see rapidly on a small portion of the area of
> interest the result of the hydrological analysis, and then decide if apply
> the analysis or not.
>
> It will include "multiple previews". Every result can be saved as an image
> and set of parameters for future use in additional "preview windows", next
> choose from group of possible parameters that which is most suitable.
> Also, changing the extend of sample area will be available "on the fly".
>
> Parameters that shall to be shown are:
> * network (vector) + optionally (order + elementary basins +
> distance/elevation)
>
> Parameters to change:
> * threshold
> * Montgomery exponent
> * SFD treshold
>
> Optionally:
> * Flow accumulation map
> * Map of depressions
>
> The advantage of such a graphical interface is to allow the user to have a
> simple approach to a sophisticated thing like hydrology. Many hydrologists
> use other GIS suites because they simply don't know or don't know how to use
> r.stream*. I believe that such a GUI could improve the user approach to
> hydrological analysis in GRASS.
>
> My tentative of timeline is the following:
>
> 2 weeks: design interface based on other similar software
> 3 weeks - midterm goal: get a preview widget working in grass7
> 3 weeks: add functionality and documentation
> 1 week: testing
> final goal: working GUI for grass7

I could be co-mentor for this project (wxGUI part), anyone interested
to mentor this project from hydrological modeling point of view?

Martin

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

Re: [GRASS-dev] GSOC: ideas

[Martin Landa]

Hi,

2011/3/31 Wolf Bergenheim :
> On Wed, Mar 30, 2011 at 13:23, Luca Delucchi  wrote:
>>
>> 2) from the GRASS GSOC ideas WMS and/or TiledMapService and/or WMS-T
>> layer support, is there someone interested to do the mentor?
>>
>
> I like this idea, and would be interested in metoring, but I might be a bit
> busy during the summer, so I'd like to have a co-mentor, if possible.
> Especially the WMS / WMS-T parts.

if needed I would be also co-mentor for this project.

Martin

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

Re: [GRASS-dev] Release 6.4.1

[Martin Landa]

Hi,

2011/4/1 Markus Neteler :
>> dear GRASS devs, I would vote for releasing 6.4.1 within few days,
>> max. one week. RC2 has been released in March 17, some bugs has been
>> fixed since RC2. Currently we have two blockers [1], both going to be
>> closed.
>
> I am +1 on this.

perfect, currently we are waiting only for one blocker [1].

Martin

[1] http://trac.osgeo.org/grass/ticket/1335

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

[GRASS-dev] Re: [GRASS GIS] #1340: wxGUI uses improper .grassrc syntax and may cause .grassrc file corruption

[GRASS GIS]

#1340: wxGUI uses improper .grassrc syntax and may cause .grassrc file 
corruption
--+-
  Reporter:  marisn   |   Owner:  martinl
  Type:  defect   |  Status:  closed 
  Priority:  blocker  |   Milestone:  6.4.1  
 Component:  wxGUI| Version:  svn-releasebranch64
Resolution:  fixed|Keywords:  g.gisenv   
  Platform:  Unspecified  | Cpu:  Unspecified
--+-
Changes (by martinl):

  * status:  assigned => closed
  * resolution:  => fixed


Comment:

 Closing the ticket. Please feel free to re-open if needed.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] v.buffer2 issues

[Markus Metz]

On Tue, Apr 5, 2011 at 9:40 AM, Maris Nartiss  wrote:
> Hello,
> I'm totally lost in v.buffer/2 issues. I recompiled v.buffer and
> v.buffer2 on 6.5 and was trying out different use cases from trac. All
> of them where working fine with v.buffer2. Old v.buffer was still
> failing with landcover dataset.

Hmph. Updated v.buffer indeed fails with spearfish landcover map.

> I had not tested attribute based
> buffering, as it should not be hard to fix buffering by attribute if
> in general it works fine.
>
Buffering by attributes is now working in both versions. Both versions
still have different problems with generating and cleaning buffers.

> Can anyone give me sample data that triggers failure of v.buffer2?
>
E.g. in nc_spm with roadsmajor:

v.buffer2 input=roadsmajor@PERMANENT output=roadsmajor_buf2_2000 distance=2000

fails, but works fine with updated v.buffer

v.buffer input=roadsmajor@PERMANENT output=roadsmajor_buf1_2000 distance=2000

v.parallel2 has more issues than v.buffer2 (see tickets #1231 and
#1244). According to the relevant thread in the grass-dev ml [1], I
got the impression that Rosen Matev was aware of the problem with
parallel lines, but did not get around to fix it [2] (last mail of
[1]).

Markus M

[1] http://thread.gmane.org/gmane.comp.gis.grass.devel/27534/
[2] http://article.gmane.org/gmane.comp.gis.grass.devel/28445
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.buffer2 issues

[Moritz Lennert]

On 05/04/11 09:40, Maris Nartiss wrote:

Hello,
I'm totally lost in v.buffer/2 issues. I recompiled v.buffer and
v.buffer2 on 6.5 and was trying out different use cases from trac. All
of them where working fine with v.buffer2. Old v.buffer was still
failing with landcover dataset. I had not tested attribute based
buffering, as it should not be hard to fix buffering by attribute if
in general it works fine.



AFAICT both now work fine in the cited test cases, but v.buffer is way 
faster than v.buffer2. Try buffering the railroads layer in the nc_spm 
location.


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

[GRASS-dev] v.buffer2 issues

[Maris Nartiss]

Hello,
I'm totally lost in v.buffer/2 issues. I recompiled v.buffer and
v.buffer2 on 6.5 and was trying out different use cases from trac. All
of them where working fine with v.buffer2. Old v.buffer was still
failing with landcover dataset. I had not tested attribute based
buffering, as it should not be hard to fix buffering by attribute if
in general it works fine.

Can anyone give me sample data that triggers failure of v.buffer2?

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