Re: [GRASS-dev] r.hazard.flood is not running in windows7( Grass 6.5)

[Margherita Di Leo]

Hi Swapan,


On Sun, Jul 20, 2014 at 10:47 PM, Swapan Ghosh  wrote:

> Dear all,
>
> I succesfully the module r.hazards.flood.py in windows xp but fail in
> windows 7.
>

how does it fail? do you get any error messages? do you have the
dependencies installed (r.area) ?
which revision of grass are you using?
standalone or osgeo4w?
have you tried also running it on grass 6.4.4 and/or nightly build 7.0.0?

Please let us know.

cheers,
madi



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

Re: [GRASS-dev] r.hazard.flood is not running in windows7( Grass 6.5)

[Helmut Kudrnovsky]

SWAPAN GHOSH wrote
> Dear all,
> 
> I succesfully the module r.hazards.flood.py in windows xp but fail in
> windows 7.
> 
> Please help me.
> 
> Regards,
> 
> Swapan Ghosh
> 
> ___
> grass-dev mailing list

> grass-dev@.osgeo

> http://lists.osgeo.org/mailman/listinfo/grass-dev

please provide more information how and what fails?

did you set the region right, e.g.

g.region -p -a rast=elevation@PERMANENT align=elevation@PERMANENT

tested here with

System Info
GRASS Version: 6.4.5svn 
GRASS SVN Revision: 61153   
GDAL/OGR: 1.11.0
PROJ4: Rel. 4.8.0, 6 March 2012 
Python: 2.7.4   
wxPython: 2.8.12.1  
Platform: Windows-Vista-6.0.6002-SP2 (OSGeo4W) 

(Mon Jul 21 11:47:06 2014)  
r.hazard.flood --verbose map=elevation@PERMANENT flood=FLOOD mti=MTI   
[...]
Done.
(Mon Jul 21 11:47:25 2014) Befehl ausgeführt (18 Sek)

System Info 
GRASS Version: 7.0.0svn 
GRASS SVN Revision: 61281   
Erstellungsdatum: 2014-07-21
Build Platform: i686-pc-mingw32 
GDAL/OGR: 1.11.0
PROJ.4: 4.8.0   
GEOS: 3.4.2 
SQLite: 3.7.17  
Python: 2.7.4   
wxPython: 2.8.12.1  
Platform: Windows-Vista-6.0.6002-SP2 (OSGeo4W)  

(Mon Jul 21 11:51:42 2014)  
r.hazard.flood --verbose map=elevation@PERMANENT flood=FLOOD mti=MTI
[...]
Done.
(Mon Jul 21 11:51:57 2014) Befehl ausgeführt (15 Sek)

r.hazard.flood in winGRASS6.4.5svn and winGRASS7.0.0svn works.



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/r-hazard-flood-is-not-running-in-windows7-Grass-6-5-tp5152002p5152074.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.hazard.flood is not running in windows7( Grass 6.5)

[Swapan Ghosh]

Actually, it needs external python installation.
I solve it...
but my question is that.why we need external py install.other
wise get the following message
[image: Inline image 1]

Regards,

Swapan Ghosh


On Mon, Jul 21, 2014 at 3:28 PM, Helmut Kudrnovsky  wrote:

> SWAPAN GHOSH wrote
> > Dear all,
> >
> > I succesfully the module r.hazards.flood.py in windows xp but fail in
> > windows 7.
> >
> > Please help me.
> >
> > Regards,
> >
> > Swapan Ghosh
> >
> > ___
> > grass-dev mailing list
>
> > grass-dev@.osgeo
>
> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>
> please provide more information how and what fails?
>
> did you set the region right, e.g.
>
> g.region -p -a rast=elevation@PERMANENT align=elevation@PERMANENT
>
> tested here with
>
> System Info
> GRASS Version: 6.4.5svn
> GRASS SVN Revision: 61153
> GDAL/OGR: 1.11.0
> PROJ4: Rel. 4.8.0, 6 March 2012
> Python: 2.7.4
> wxPython: 2.8.12.1
> Platform: Windows-Vista-6.0.6002-SP2 (OSGeo4W)
>
> (Mon Jul 21 11:47:06 2014)
> r.hazard.flood --verbose map=elevation@PERMANENT flood=FLOOD mti=MTI
> [...]
> Done.
> (Mon Jul 21 11:47:25 2014) Befehl ausgeführt (18 Sek)
>
> System Info
> GRASS Version: 7.0.0svn
> GRASS SVN Revision: 61281
> Erstellungsdatum: 2014-07-21
> Build Platform: i686-pc-mingw32
> GDAL/OGR: 1.11.0
> PROJ.4: 4.8.0
> GEOS: 3.4.2
> SQLite: 3.7.17
> Python: 2.7.4
> wxPython: 2.8.12.1
> Platform: Windows-Vista-6.0.6002-SP2 (OSGeo4W)
>
> (Mon Jul 21 11:51:42 2014)
> r.hazard.flood --verbose map=elevation@PERMANENT flood=FLOOD mti=MTI
> [...]
> Done.
> (Mon Jul 21 11:51:57 2014) Befehl ausgeführt (15 Sek)
>
> r.hazard.flood in winGRASS6.4.5svn and winGRASS7.0.0svn works.
>
>
>
> -
> best regards
> Helmut
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/r-hazard-flood-is-not-running-in-windows7-Grass-6-5-tp5152002p5152074.html
> Sent from the Grass - Dev mailing list archive at Nabble.com.
> ___
> 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] r.hazard.flood is not running in windows7( Grass 6.5)

[Helmut Kudrnovsky]

>Actually, it needs external python installation.
>I solve it...
>but my question is that.why we need external py install.other
wise get the following message

first, please don't use winGRASS 6.5, it's some kind of abandoned and not
meant for productive use. 

so try winGRASS 6.4.5svn (latest stable in the 6.4-series) or winGRASS
7.0.0svn (first stable in the 7.0-series) first before installing an
external python. 

an external python isn't normally necessary, but sometimes there are some
glitches with windows and python.

AFAICT the best thing is to use winGRASS within the OSGe4W-framework
(http://trac.osgeo.org/osgeo4w/).

for example the tests mentioned before by me are done in the
OSGe4W-framework without any external python installation.

in summary this isn't a r.hazard.flood issue, but a windows-python quirk ...



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/r-hazard-flood-is-not-running-in-windows7-Grass-6-5-tp5152002p5152094.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.hazard.flood is not running in windows7( Grass 6.5)

[Swapan Ghosh]

Dear all,

Thank you very much for the help.

Swapan


On Mon, Jul 21, 2014 at 4:29 PM, Helmut Kudrnovsky  wrote:

> >Actually, it needs external python installation.
> >I solve it...
> >but my question is that.why we need external py install.other
> wise get the following message
>
> first, please don't use winGRASS 6.5, it's some kind of abandoned and not
> meant for productive use.
>
> so try winGRASS 6.4.5svn (latest stable in the 6.4-series) or winGRASS
> 7.0.0svn (first stable in the 7.0-series) first before installing an
> external python.
>
> an external python isn't normally necessary, but sometimes there are some
> glitches with windows and python.
>
> AFAICT the best thing is to use winGRASS within the OSGe4W-framework
> (http://trac.osgeo.org/osgeo4w/).
>
> for example the tests mentioned before by me are done in the
> OSGe4W-framework without any external python installation.
>
> in summary this isn't a r.hazard.flood issue, but a windows-python quirk
> ...
>
>
>
> -
> best regards
> Helmut
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/r-hazard-flood-is-not-running-in-windows7-Grass-6-5-tp5152002p5152094.html
> Sent from the Grass - Dev mailing list archive at Nabble.com.
> ___
> 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 story movie

[Martin Landa]

Hi,

2014-07-15 20:31 GMT+02:00 "Peter Löwe" :
> the GRASS GIS Story has already been uploaded by someone to Youtube 
> (https://www.youtube.com/watch?v=U3Hf0qI4JLc). Uploading it a second time 
> won't do harm, but neither will solve some Youtube-related issues:

> Youtube does not allow for advanced search queries on the movies' content: 
> The version already available on Youtube can _not_ be found by the search 
> queries like "GRASS GIS William Shatner". Further, there is no proper way to 
> _cite_ the movie in a publication. In my feeling the movie has already become 
> a historical document for the OSGeo community. In the sense of information 
> preservation it would be good to have a version which long time preserved, 
> citable and fully searchable.

ah, it explains why I didn't find, I put link to [1]. BTW, the local
movie seems to be not playable (at least on my computer).

Martin

[1] 
http://grass.osgeo.org/HostedVideoAlbums/video/GRASS-History-The-GRASS-Story/15/

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

Re: [GRASS-dev] grass gis story movie

[Martin Landa]

Hi,

2014-07-19 20:02 GMT+02:00 Vaclav Petras :
> in case you don't know about this document:
>
> The Future of GRASS?
> http://www.tldp.org/HOWTO/GIS-GRASS/future.html

I add this link to [1]. Martin

[1] http://grass.osgeo.org/home/history/documents/

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

[GRASS-dev] PROJSHARE changed to /usr/share/proj from /usr/local/share/proj

[Markus Neteler]

Hi,

just FYI: since PROJ4.8 is now widely available and standard, I have
taken liberty to change configure[.in]
from
PROJSHARE=/usr/local/share/proj
to
PROJSHARE=/usr/share/proj

which results now in:
--with-proj-share=/usr/share/proj
being used by default.

Rationale:
This helps to avoid an ugly error message in the location wizard (EPSG
dialog) when GRASS wasn't explicitly compiled with --with-proj-share.

If no objections, I'll backport r61296 to relbr70.

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

Re: [GRASS-dev] grass gis story movie

[Markus Neteler]

On Mon, Jul 21, 2014 at 3:37 PM, Martin Landa  wrote:
...
> BTW, the local
> movie seems to be not playable (at least on my computer).

The reason might be that it is in MOV format.

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

Re: [GRASS-dev] [GRASS-SVN] r61282 - in grass/trunk: include/defs lib/raster3d lib/raster3d/test

[Vaclav Petras]

On Sun, Jul 20, 2014 at 9:56 AM, Sören Gebbert  wrote:

> 2014-07-20 6:06 GMT+02:00 Vaclav Petras :
> >
> > On Sat, Jul 19, 2014 at 8:02 PM,  wrote:
> >>
> >> Unfortunately changed the editor that i use the indention and converted
> >> all tabs into spaces at save time. Hence,
> >> the commit contains 95% tab to space conversion noise.
> >
> >
> > I would actually agree with the change. I think that the GRASS
> indentation
> > style is a bug since mixed tabs and spaces are enforced as a rule (not
> just
> > allowed). However, it was decided that it won't be fixed and that current
> > practice should be preserved. [1]
>
> Mixing tabs and spaces is really a mess. And i am part of the problem,
> since i am using several different computer for development and
> different editors, each with its own habits.
>
> > Fortunately, there is a script which can enforce the unusual indent style
> > [2]. And also `svn diff --ignore-space-change` for cases like this
> commit.
>
> Thank you for this hint, i will try to use it.
>

See also improved:

http://trac.osgeo.org/grass/wiki/Submitting/C#Indentation

And just as a reminder for others, for Python code, use pep8 directly for
new code. For existing code use:

http://trac.osgeo.org/grass/wiki/Submitting/Python#Style

  pep8 --config=tools/pep8config.txt directory_to_check
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r61280 - in grass/trunk/gui: icons/grass wxpython/lmgr

[Martin Landa]

Hi,

2014-07-19 19:18 GMT+02:00 Vaclav Petras :

> the right layer/item in layer manager layer tree, so I've just added new
> icons derived from the SVG version of current icons [1] which are contain
> only symbol for type of the layer and not unnecessary symbol for layer nor
> unwanted symbol for add.

nice.

> I'm not sure what to do with SVGs. Should I try to put them to OSGeo
> repository? Is creating ticket the right way?

probably to ask original author of the icons? Martin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PROJSHARE changed to /usr/share/proj from /usr/local/share/proj

[Martin Landa]

Hi,

2014-07-21 15:46 GMT+02:00 Markus Neteler :

> If no objections, I'll backport r61296 to relbr70.

+1 for backport. Martin

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

Re: [GRASS-dev] [GRASS GIS] #2371: Vector digitizer does not colourize isles correctly

[GRASS GIS]

#2371: Vector digitizer does not colourize isles correctly
---+
 Reporter:  huhabla|   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  minor  |   Milestone:  7.0.0
Component:  wxGUI  | Version:  svn-trunk
 Keywords:  digitizer,vector,topology  |Platform:  Linux
  Cpu:  x86-64 |  
---+
Changes (by martinl):

  * component:  Default => wxGUI


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] using rand(x,y) in r.mapcalc (grass7)

[Markus Neteler]

On Sun, Jul 6, 2014 at 12:25 AM, Glynn Clements
 wrote:
>> Glynn Clements  wrote:
...
> In ticket #2272, I attached a portable implementation of lrand48(). If
> desired, we could add this to libgis and use that in preference to any
> implementation-specific PRNG.

This would be excellent.

>>> If you want a different result each time, set GRASS_RND_SEED to a
>>> different value each time, e.g.

IMHO this is not intuitive at all. I would suggest to invert the
behaviour for GRASS 7:
- per default generate random numbers which differ,
- if the user needs reproducability, then have a env var to enable that.

> The main thing is that I believe that
> reproducibility should be the default.

I humbly disagree. This is not what the user expects. It is also the
opposite of how for example R behaves:

R
> runif(1)
[1] 0.5624295
> runif(1)
[1] 0.1683853

http://en.wikibooks.org/wiki/R_Programming/Random_Number_Generation#Seed
" If you want to perform an exact replication of your program, you
have to specify the seed using the function set.seed()."

> If people have to take explicit
> action to introduce randomness,

The problem is that most will not even realize the current behaviour of rand().

> they're more likely to consider the
> issues involved. If randomised seeds are the default, the lack of
> reproducibility may not be considered until it is too late.

The R community (and some users here) think the opposite... when you
ask for rand() then you expect a random number. Just to avoid this:
https://xkcd.com/221/

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

Re: [GRASS-dev] grass-dev Digest, Vol 101, Issue 50

[Michael Barton]

It is also on the GRASS for Mac site and runs fine.

http://grassmac.wikidot.com/downloads (bottom of the page)

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 Jul 21, 2014, at 7:08 AM, 
mailto:grass-dev-requ...@lists.osgeo.org>> 
mailto:grass-dev-requ...@lists.osgeo.org>> 
wrote:

From: Martin Landa mailto:landa.mar...@gmail.com>>
Subject: Re: [GRASS-dev] grass gis story movie
Date: July 21, 2014 at 6:37:51 AM MST
To: Peter Löwe mailto:peter.lo...@gmx.de>>
Cc: Markus Neteler mailto:markus.nete...@fmach.it>>, 
GRASS developers list 
mailto:grass-dev@lists.osgeo.org>>


Hi,

2014-07-15 20:31 GMT+02:00 "Peter Löwe" 
mailto:peter.lo...@gmx.de>>:
the GRASS GIS Story has already been uploaded by someone to Youtube 
(https://www.youtube.com/watch?v=U3Hf0qI4JLc). Uploading it a second time won't 
do harm, but neither will solve some Youtube-related issues:

Youtube does not allow for advanced search queries on the movies' content: The 
version already available on Youtube can _not_ be found by the search queries 
like "GRASS GIS William Shatner". Further, there is no proper way to _cite_ the 
movie in a publication. In my feeling the movie has already become a historical 
document for the OSGeo community. In the sense of information preservation it 
would be good to have a version which long time preserved, citable and fully 
searchable.

ah, it explains why I didn't find, I put link to [1]. BTW, the local
movie seems to be not playable (at least on my computer).

Martin

[1] 
http://grass.osgeo.org/HostedVideoAlbums/video/GRASS-History-The-GRASS-Story/15/

--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa

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

Re: [GRASS-dev] using rand(x,y) in r.mapcalc (grass7)

[Paulo van Breugel]

On 21-07-14 19:01, Markus Neteler wrote:

On Sun, Jul 6, 2014 at 12:25 AM, Glynn Clements
 wrote:

Glynn Clements  wrote:

...

In ticket #2272, I attached a portable implementation of lrand48(). If
desired, we could add this to libgis and use that in preference to any
implementation-specific PRNG.

This would be excellent.


If you want a different result each time, set GRASS_RND_SEED to a
different value each time, e.g.

IMHO this is not intuitive at all. I would suggest to invert the
behaviour for GRASS 7:
- per default generate random numbers which differ,
- if the user needs reproducability, then have a env var to enable that.


The main thing is that I believe that
reproducibility should be the default.

I humbly disagree. This is not what the user expects. It is also the
opposite of how for example R behaves:

R

runif(1)

[1] 0.5624295

runif(1)

[1] 0.1683853

http://en.wikibooks.org/wiki/R_Programming/Random_Number_Generation#Seed
" If you want to perform an exact replication of your program, you
have to specify the seed using the function set.seed()."


If people have to take explicit
action to introduce randomness,

The problem is that most will not even realize the current behaviour of rand().


they're more likely to consider the
issues involved. If randomised seeds are the default, the lack of
reproducibility may not be considered until it is too late.

The R community (and some users here) think the opposite... when you
ask for rand() then you expect a random number.
And not only the R community I am sure. In all statistical packages I 
have ever worked with  one can see the same behaviour, a random number 
is random (i.e., each time a different seed), unless the seed is 
explicitly defined by the user. And it seems to be the default behaviour 
by python/numpy:


>>> import numpy as np
>>> np.random.random()
0.8351426142559701
>>> np.random.random()
0.4813823441998394
>>> np.random.random()
0.7279314267025369


Just to avoid this:
https://xkcd.com/221/

Markus


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

Re: [GRASS-dev] [GRASS GIS] #2372: GRASS 7 on windows starts with minimized CMD window

[GRASS GIS]

#2372: GRASS 7 on windows starts with minimized CMD window
--+-
  Reporter:  marisn   |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  critical |   Milestone:  7.0.0
 Component:  Startup  | Version:  svn-releasebranch70  
Resolution:  fixed|Keywords:  wingrass 
  Platform:  MSWindows 8  | Cpu:  Unspecified  
--+-
Changes (by marisn):

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


Comment:

 Works as a charm. No more problems with multiple user accounts. Thank you!

-- 
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 7.0beta3 planning

[Markus Neteler]

On Fri, Jul 18, 2014 at 8:39 AM, Helmut Kudrnovsky  wrote:
>> what do you think about releasing beta3?
>
> have look in
> http://lists.osgeo.org/pipermail/grass-dev/2014-July/069983.html
>
> "[GRASS-dev] GRASS 7: g.gui.rlisetup
>
> [...]
> Backport of r60219 is needed.
> http://trac.osgeo.org/grass/changeset/60219";

Done in r61304.

> g.gui.rlisetup isn't starting in winGRASS7.0

Please test tomorrow's binary snapshot.

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

Re: [GRASS-dev] GRASS 7: g.gui.rlisetup

[Markus Neteler]

(for the record)

On Wed, Jul 9, 2014 at 4:48 PM, Anna Petrášová  wrote:
> On Wed, Jul 9, 2014 at 8:04 AM, Helmut Kudrnovsky  wrote:
>>

> Backport of r60219 is needed.
> http://trac.osgeo.org/grass/changeset/60219
...

Done in r61304.

BTW: I used the script:
[neteler@oboe grass70]$ ~/software/grass-addons/tools/svn7merge 60219

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

Re: [GRASS-dev] GRASS 7.0beta3 planning

[Markus Neteler]

On Fri, Jul 18, 2014 at 12:22 AM, Vaclav Petras  wrote:
> what do you think about releasing beta3?

Yes and no: it is time to do it but without the current blocker.

> The problems mentioned in this
> thread were fixed and fixes backported except for r60590 which is safe for
> GRASS by itself and thus can be safely backported now.
...
> r60590
> Add G_fatal_longjmp() (needed for QGIS)
> glynn
> include/defs/gis.h, lib/gis/error.c
> http://trac.osgeo.org/grass/changeset/60590

... if so, please do (someone) that.


> There is a lot of things in the tracker but they can be postponed I think:

It is important to make real issues either blocker or at least
critical to avoid that it slips through.

... I think we need to shift this listing either to a Wiki or to trac
bugs. It is not efficient to do it via email (let's use that for the
ping'ing).

Concerning the BAT file support, is that now in relbr7?

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

Re: [GRASS-dev] [GRASS-user] Broken r.stream.snap?

[Markus Neteler]

On Mon, Jul 14, 2014 at 12:05 PM, Johannes Radinger
 wrote:
> Hi,
>
> the module r.stream.snap which has been included now in the main code of
> GRASS 7 does not produce an output table which is linked to the output
> vector map.
>
> Can anyone reproduce that behavior?

Yes. There is simply no DB code in r.stream.snap...

Hope someone picks up bug report #2362.

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

Re: [GRASS-dev] [GRASS GIS] #2255: g.mlist warnings for layers found in other mapsets

[GRASS GIS]

#2255: g.mlist warnings for layers found in other mapsets
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…
  
 Type:  defect   |  Status:  new
  
 Priority:  normal   |   Milestone:  7.1.0  
  
Component:  LibRaster| Version:  unspecified
  
 Keywords:  g.mlist, d.rast.leg, d.rast  |Platform:  Unspecified
  
  Cpu:  Unspecified  |  
-+--
Changes (by neteler):

  * keywords:  g.mlist, d.rast.leg => g.mlist, d.rast.leg, d.rast


Comment:

 Replying to [comment:3 hcho]:
 > Fixed in r60261.

 (backported in r61040)

 Glynn posted some comments here:

 http://lists.osgeo.org/pipermail/grass-dev/2014-June/069628.html

-- 
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 7.0beta3 planning

[Vaclav Petras]

On Mon, Jul 21, 2014 at 5:23 PM, Markus Neteler  wrote:

> On Fri, Jul 18, 2014 at 12:22 AM, Vaclav Petras 
> wrote:
> > what do you think about releasing beta3?
>
> Yes and no: it is time to do it but without the current blocker.
>
> There is currently 10 blockers for 7.0 and 7.1, 3-5 are duplicates of
Python issue.

In addition to that. The g.list, g.mlist, g.remove and g.mremove chnages
are in fact blockers since they are changing API.

> There is a lot of things in the tracker but they can be postponed I think:

It is important to make real issues either blocker or at least
> critical to avoid that it slips through.
>
> ... I think we need to shift this listing either to a Wiki or to trac
> bugs. It is not efficient to do it via email (let's use that for the
> ping'ing).
>
> The query on Trac seems appropriate. We can add it to reports (as what?)
or you can put a query result to a page. Some pages are using it.

== List of tickets ==

[[TicketQuery(component=wxGUI&keywords=wxiclass&order=priority)]]

http://trac.osgeo.org/grass/wiki/wxGUIDevelopment/wxIClass#Listoftickets

http://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=milestone&col=status&col=type&col=priority&col=component&col=version&col=keywords&col=time&col=changetime&milestone=7.0.0&type=!enhancement

Concerning the BAT file support, is that now in relbr7?
>
> No, relbr7 is using the older workaround. And about BAT and Python in
general in trunk. I'm now confused about what was implemented and why.

Vaclav

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

Re: [GRASS-dev] [GRASS GIS] #1464: Bug on v.buffer

[GRASS GIS]

#1464: Bug on v.buffer
---+
  Reporter:  leonidas  |   Owner:  grass-dev@…  
  Type:  defect|  Status:  closed   
  Priority:  critical  |   Milestone:  7.0.0
 Component:  Vector| Version:  svn-trunk
Resolution:  fixed |Keywords:  v.buffer 
  Platform:  All   | Cpu:  All  
---+
Changes (by neteler):

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


Comment:

 Closing as fixed.

-- 
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] #1343: v.buffer2: difference between Linux 32bit and 64bit

[GRASS GIS]

#1343: v.buffer2: difference between Linux 32bit and 64bit
---+
  Reporter:  mmetz |   Owner:  grass-dev@…  
  Type:  defect|  Status:  reopened 
  Priority:  critical  |   Milestone:  6.4.5
 Component:  Default   | Version:  svn-develbranch6 
Resolution:|Keywords:  v.buffer 
  Platform:  Linux | Cpu:  x86-64   
---+
Changes (by neteler):

  * milestone:  7.0.0 => 6.4.5


Comment:

 Done in G7, downgrading to G6 where GEOS support was added in r59970.

 {{{
 # G6:
 v.buffer input=roadsmajor@PERMANENT output=roadsmajor_buf1_2000
 distance=1000
 }}}

 Appears to work, closing (reopen if not).

 Some fun performance comparison:
  * G6.4.svn: 43.19 sec
  * G7.0.svn:  7.59 sec

-- 
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] #1343: v.buffer2: difference between Linux 32bit and 64bit

[GRASS GIS]

#1343: v.buffer2: difference between Linux 32bit and 64bit
---+
  Reporter:  mmetz |   Owner:  grass-dev@…  
  Type:  defect|  Status:  closed   
  Priority:  critical  |   Milestone:  6.4.5
 Component:  Default   | Version:  svn-develbranch6 
Resolution:  fixed |Keywords:  v.buffer 
  Platform:  Linux | Cpu:  x86-64   
---+
Changes (by neteler):

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


-- 
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] #2103: Make SUBMITTING files more accessible

[GRASS GIS]

#2103: Make SUBMITTING files more accessible
--+-
  Reporter:  wenzeslaus   |   Owner:  grass-dev@…
  Type:  task |  Status:  closed 
  Priority:  normal   |   Milestone:  7.0.0  
 Component:  Docs | Version:  svn-trunk  
Resolution:  fixed|Keywords:  submitting, addons, doxygen
  Platform:  Unspecified  | Cpu:  Unspecified
--+-
Changes (by wenzeslaus):

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


Comment:

 * All `SUBMITTING` files were converted to Trac wiki:Submitting pages
 (r61014).
   - wiki:Submitting/General
   - wiki:Submitting/C
   - wiki:Submitting/Python
   - wiki:Submitting/wxGUI
   - wiki:Submitting/Docs
  * All RFC documents were also moved to Trac wiki:RFC pages (r60890).
  * `SUBMITTING` files in addons tracked in #2104.
  * The [source:grass/trunk/doc doc] directory remains unresolved.
  * Various files may stay in their plain text form and only in source
 code.
   - source:grass/trunk/AUTHORS
   - source:grass/trunk/COPYING
   - source:grass/trunk/GPL.TXT
   - source:grass/trunk/CHANGES (last change 8 year ago)
  * `README` files here and there in the source code probably don't need
 any markup or publication.

-- 
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] #2314: output r.out.xyz

[GRASS GIS]

#2314: output r.out.xyz
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…
  
 Type:  defect   |  Status:  new
  
 Priority:  normal   |   Milestone:  7.0.0  
  
Component:  Default  | Version:  svn-trunk  
  
 Keywords:  separator, pipe, r.out.xyz, r.stats  |Platform:  MSWindows 7
  
  Cpu:  All  |  
-+--

Comment(by wenzeslaus):

 Now relates to [http://lists.osgeo.org/pipermail/grass-
 dev/2014-July/069871.html discussion] ([http://osgeo-
 org.1560.x6.nabble.com/Re-GRASS-SVN-r60679-grass-trunk-lib-python-script-
 td5143645i20.html nabble) for r60679 because "`shell=True`" is used as a
 part of the proposed solution.

-- 
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] #2147: db.databases not working in GRASS 7

[GRASS GIS]

#2147: db.databases not working in GRASS 7
--+-
 Reporter:  cmbarton  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Database  | Version:  svn-trunk
 Keywords:  db.databases, sqlite  |Platform:  All  
  Cpu:  OSX/Intel |  
--+-

Comment(by wenzeslaus):

 Is something mentioned here still an issue?

 If unclear state of source code is the remaining issue (as suggested by
 last comments), please, check the file again. The best think to do is
 probably
 {{{
 cd db/drivers/sqlite
 svn status
 }}}

 However, `svn revert db/drivers/sqlite/listdb.c` and `svn up` and also
 `svn diff` and `svn info` can be useful too.

-- 
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] #1625: Disk performance degrades by several orders of magnitude on two processes

[GRASS GIS]

#1625: Disk performance degrades by several orders of magnitude on two processes
-+--
 Reporter:  sprice   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Default  | Version:  svn-trunk
 Keywords:   |Platform:  MacOSX   
  Cpu:  x86-64   |  
-+--

Comment(by wenzeslaus):

 Replying to [comment:4 hamish]:
 > is there anything to be done for this ticket? or is it just an
 observation?

 I don't know. Perhaps writing a a benchmark/test which will test/show that
 two processes in parallel behaves as expected.

-- 
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] #2017: ogsf compilation error

[GRASS GIS]

#2017: ogsf compilation error
---+
 Reporter:  martinl|   Owner:  grass-dev@…  

 Type:  defect |  Status:  new  

 Priority:  blocker|   Milestone:  7.0.0

Component:  Compiling  | Version:  svn-trunk

 Keywords:  libc, ogsf, libavutil, ffmpeg  |Platform:  Linux

  Cpu:  x86-64 |  
---+

Comment(by wenzeslaus):

 Replying to [comment:22 hamish]:
 > A reminder, ffmpeg is not used with trunk, only for creating animations
 directly in tcl/tk NVIZ in grass 6.
 >
 > suggest to remove it from libogsf and configure.in in trunk.
 >

 I removed ffmpeg in r61305. I've used `autoconf2.13`. Compilation after
 `make distclean` works.  wxNVIZ and `m.nviz.image` (and `g.gui.animation`)
 work.

 I updated [source:grass/trunk/REQUIREMENTS.html REQUIREMENTS.html] but I
 don't know what is appropriate update for the following files:
  * [source:grass/trunk/mswindows/osgeo4w/config.h.vc
 mswindows/osgeo4w/config.h.vc]
  * [source:grass/trunk/macosx/ReadMe.rtf macosx/ReadMe.rtf]
  * [source:grass/trunk/macosx/pkg/resources/ReadMe.rtf
 macosx/pkg/resources/ReadMe.rtf]

 I don't understand why, if I leave the parameters
 {{{
 --with-ffmpeg=no --with-ffmpeg-includes="/usr/include/libavcodec
 /usr/include/libavformat /usr/include/libswscale /usr/include/libavutil"
 }}}
 in my `./configure` call, no error is reported.

-- 
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] #1983: wingrass: permission denied to open grass70.py

[GRASS GIS]

#1983: wingrass: permission denied to open grass70.py
-+--
 Reporter:  mmetz|   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Installation | Version:  svn-trunk
 Keywords:  wingrass, installer  |Platform:  MSWindows 7  
  Cpu:  All  |  
-+--

Comment(by wenzeslaus):

 Continued in #2290. Please close afterwards in case that this is really a
 duplicate.

-- 
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] #2290: Wrong file permissions for grassXY.py on Windows (was: Grass not starting)

[GRASS GIS]

#2290: Wrong file permissions for grassXY.py on Windows (was: Grass not 
starting)
--+-
 Reporter:  dnewcomb  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  critical  |   Milestone:  7.0.0
Component:  Installation  | Version:  svn-releasebranch70  
 Keywords:  installation  |Platform:  MSWindows 7  
  Cpu:  x86-64|  
--+-
Changes (by wenzeslaus):

  * keywords:  => installation


Comment:

 Possible duplicate of #1983. Please continue discussion here.

-- 
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] #2099: G_OPT_M_COLR not recognized in Python script

[GRASS GIS]

#2099: G_OPT_M_COLR not recognized in Python script
-+--
 Reporter:  annakrat |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  LibGIS   | Version:  svn-trunk
 Keywords:  color table, parser  |Platform:  Linux
  Cpu:  Unspecified  |  
-+--

Comment(by wenzeslaus):

 `t.rast.colors --interface-description` seems to work. `... | grep null`
 gives nothing. `t.rast.colors --help` gives full output and no error:
 {{{
 Description:
 ...
 Keywords:
 ...
 Usage:
  t.rast.colors [-rwlngae] input=name [color=string] [raster=name]
[volume=name] [rules=name] [--help] [--verbose] [--quiet]

 Flags:
 ...
 Parameters:
 ...
 }}}

 Test script with `G_OPT_M_COLR` should be created.

-- 
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] #2292: compiling grass in windows 8

[GRASS GIS]

#2292: compiling grass in windows 8
---+
 Reporter:  neuba  |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  normal |   Milestone:  7.0.0
Component:  Packaging  | Version:  unspecified  
 Keywords:  wingrass   |Platform:  Unspecified  
  Cpu:  x86-64 |  
---+

Comment(by wenzeslaus):

 If this is really an issue, raise the priority to major.

 Also, neuba, if the files you attached contains a patch, please try to
 create a diff if possible, so your suggested update is immediately
 visible.

-- 
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] #353: r.texture: flags to method= option

[GRASS GIS]

#353: r.texture: flags to method= option
--+-
  Reporter:  hamish   |   Owner:  grass-dev@…  
  Type:  task |  Status:  closed   
  Priority:  trivial  |   Milestone:  7.0.0
 Component:  Raster   | Version:  svn-trunk
Resolution:  fixed|Keywords:  r.texture, interface 
  Platform:  All  | Cpu:  All  
--+-
Changes (by wenzeslaus):

  * keywords:  r.texture => r.texture, interface
  * status:  new => closed
  * resolution:  => fixed


Comment:

 The current r.texture in GRASS 7 has:
 {{{
 Usage:
  r.texture [-sa] input=name prefix=string [size=value]
[distance=value] [method=string[,string,...]] [--overwrite] [--help]
[--verbose] [--quiet]

 Flags:
   -s   Separate output for each angle (0, 45, 90, 135)
   -a   Calculate all textural measurements
  --o   Allow output files to overwrite existing files
  --h   Print usage summary
  --v   Verbose module output
  --q   Quiet module output

 Parameters:
  input   Name of input raster map
 prefix   Prefix for output raster map(s)
   size   The size of moving window (odd and >= 3)
  default: 3
   distance   The distance between two samples (>= 1)
  default: 1
 method   Textural measurement method
  options:
 asm,contrast,corr,var,idm,sa,se,sv,entr,dv,de,moc1,moc2
 }}}
 So, I guess that this is fixed. Multiple method is possible. GRASS 6 has
 the flags.

  * http://grass.osgeo.org/grass64/manuals/r.texture.html
  * http://grass.osgeo.org/grass70/manuals/r.texture.html

-- 
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] #1369: setPrompt: command not found in GRASS7-svn

[GRASS GIS]

#1369: setPrompt: command not found in GRASS7-svn
--+-
  Reporter:  moovida  |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  Startup  | Version:  svn-trunk
Resolution:  wontfix  |Keywords:   
  Platform:  Linux| Cpu:  Unspecified  
--+-
Changes (by wenzeslaus):

  * status:  new => closed
  * resolution:  => wontfix


Comment:

 Currently:
 {{{
 > echo $PROMPT_COMMAND
 grass_prompt
 }}}

 I think GRASS is not honoring the standard `.bashrc` in home by purpose if
 this is what are you trying to achieve. There are some discussion on
 mailing list about that.

 [GRASS-SVN] r61051 - grass/trunk/lib/init
  * http://lists.osgeo.org/pipermail/grass-dev/2014-July/069943.html
  * http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r61051-grass-trunk-
 lib-init-td5149672.html

 [GRASS-dev] Bash aliases in GRASS
  * http://lists.osgeo.org/pipermail/grass-dev/2013-February/061837.html
  * http://osgeo-org.1560.x6.nabble.com/Bash-aliases-in-GRASS-
 td5032707.html

 [GRASS-user] loss of bash aliases
  * http://lists.osgeo.org/pipermail/grass-user/2008-March/043806.html
  * http://osgeo-org.1560.x6.nabble.com/loss-of-bash-aliases-td3927364.html


 I think you need to use `~/.grass7/bashrc`. Citing from one of the
 discussions:

 > > So we have $LOCATION/.bashrc, ~/.grass7/bashrc, and ~/.grass.bashrc.
 Do they
 > > all have different purposes and are they documented clearly somewhere?
 > > (Huidae)
 > `.grass.bashrc` is related to GRASS 6. GRASS 7 stores environmental
 > variables in `~/.grass7/bashrc`. The init script in GRASS 7 also reads
 > `.grass.bashrc` for backward compatibility.
 > (Martin)

 I'm afraid that this is wontfix/invalid (feature, not a bug). Perhaps
 should be documented better. Feel free to suggest location and wording.

-- 
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] #278: wxGUI: don't allow for negative column number

[GRASS GIS]

#278: wxGUI: don't allow for negative column number
--+-
 Reporter:  msieczka  |   Owner:  martinl  
 Type:  defect|  Status:  assigned 
 Priority:  minor |   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  parser|Platform:  All  
  Cpu:  All   |  
--+-

Comment(by wenzeslaus):

 In GRASS, values `> 0` should be now specified in C as:
 {{{
 ...
 opt->options = "1-";
 }}}
 and in Python as:
 {{{
 ...
 #% options: 1-
 }}}

 So, v.in.ascii needs this fix, so that standard Parser mechanism is used
 instead of custom error handling.

 GUI now allows to input negative numbers but label contains "valid range
 1-" and Run gives an standard error message generated by module (parser):

 {{{
 ERROR: Value <-4> out of range for parameter 
 Legal range: 1-
 }}}

 GUI would not allow to input values out of range if both limits would be
 specified. GUI needs to be improved, so it can handle also range with min
 or max only.

 Modules using custom range handling, such as `v.in.ascii`, should be
 chanaged to use parser.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] pygrass vs grass python scripting library

[Paulo van Breugel]

I am trying to familiarize myself a bit with python scripting in GRASS. 
I am a bit confused about the different approaches that seem possible. 
More specifically, there is the pygrass 
(http://grasswiki.osgeo.org/wiki/Python/pygrass) and grass python 
scripting library (
http://grasswiki.osgeo.org/wiki/GRASS_Python_Scripting_Library). Is 
there somewhere a concise description explaining the difference between 
the two. And for writing python scripts (addons), which of these two are 
a better option to use (for somebody fairly familiar with GRASS, with 
some experience in writing shell or R scripts for GRASS, but with no 
experience at all with python).


Cheers,

Paulo


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