[GRASS-dev] [GRASS GIS] #2862: v.dissolve not working

[GRASS GIS]

#2862: v.dissolve not working
-+-
 Reporter:  AAHG |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.0.3
Component:  Vector   |Version:  svn-releasebranch70
 Keywords:  v.dissolve   |CPU:  x86-64
 Platform:  MSWindows 7  |
-+-
 I have pasted an example of the command and the error message below. It
 happens when used through qgis and also from the command line.

 ''"'""' is not recognized as an internal or external command operable
 program or batch file."''

 v.dissolve input=tmp1452500056273 column="Image"
 output=output7f1f14dcf1bb444c8fa4ba8d7074dbb8 --overwrite

--
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] #2862: v.dissolve not working

[GRASS GIS]

#2862: v.dissolve not working
-+-
  Reporter:  AAHG|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.3
 Component:  Vector  |Version:  svn-releasebranch70
Resolution:  |   Keywords:  v.dissolve
   CPU:  x86-64  |   Platform:  MSWindows 7
-+-

Comment (by mlennert):

 Replying to [ticket:2862 AAHG]:
 > I have pasted an example of the command and the error message below. It
 happens when used through qgis and also from the command line.

 You mean from the GRASS command line, i.e. without going through QGIS ?

 Could you please provide a reproducible example, ideally using the North
 Carolina demo data set ? 'tmp1452500056273' is not really something we can
 work with.

--
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] #1242: vector fills and line widths not displaying in latlon regions

[GRASS GIS]

#1242: vector fills and line widths not displaying in latlon regions
-+-
  Reporter:  cmbarton|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.3
 Component:  Display |Version:  svn-trunk
Resolution:  |   Keywords:  vector, display, d.vect,
   CPU:  |  d.northarrow
  Unspecified|   Platform:  Unspecified
-+-
Changes (by mlennert):

 * priority:  critical => normal


--
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 GRASS addons in R on Windows

[Helmut Kudrnovsky]

pvanbosgeo wrote
> In Windows running R from within GRASS (latter installed via OSGeo4W) 
> works fine, except that it can't seem to find the GRASS addons I 
> installed (with g.extension), not using rgrass7 nor directly using 
> system(). On Linux this is no problem, I can run any installed addon. 
> Any ideas how to solve this?

see also the discussion on GRASS Statistics mailing List




-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Using-GRASS-addons-in-R-on-Windows-tp5244240p5244505.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] release plan for 7.0.3

[Moritz Lennert]

On 10/01/16 20:39, Martin Landa wrote:

Hi,

2015-12-18 18:08 GMT+01:00 Martin Landa :

1) this weekend soft freeze starts
2) before the end of the year: hard freeze + RC1
3) around January 10: RC2
4) around January 14: 7.0.3


I would like to open discussion about releasing RC2 in the next few
days. Is there any blockers (at least trac shows none)? Note that
final release should come not longer that one week after RC2. Martin




Looking at critical bugs:

- https://trac.osgeo.org/grass/ticket/335

Is anyone looking at this ? Does anyone find this important ? Should it 
maybe be downgraded ?



- https://trac.osgeo.org/grass/ticket/1242

I've downgraded this as I don't find this critical.


- https://trac.osgeo.org/grass/ticket/1662

no idea

- https://trac.osgeo.org/grass/ticket/2252

Is there any SQL expert out there who could see if malicious use if 
possible ? If not, it seems to me more of a question of error handling, 
if yes, this definitely needs to be solved.



- https://trac.osgeo.org/grass/ticket/2300

Has anyone tested the patch in trunk a bit ? I think this would be good 
to have in 7.0.3 if possible.


- https://trac.osgeo.org/grass/ticket/2349

Is this stable enough for 7.0.x ? And is this really 'critical' ?


- https://trac.osgeo.org/grass/ticket/2531

I agree that v.parallel is basic functionality which should "just work", 
so in that sens this bug should be fixed. Does anyone have any pointers 
of where to look based on the initial assessment ?


- https://trac.osgeo.org/grass/ticket/2814

Noone except for the OP has been able to reproduce this at this stage.


Personally, I think that #2300 could probably be backported. I don't see 
how this can create any serious issues, but then again, that's probably 
just my lack of imagination ;-)


If possible, I think that #2252 and #2351 would also be great to have fixed.

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

Re: [GRASS-dev] Using GRASS addons in R on Windows

[Paulo van Breugel]

On Mon, Jan 11, 2016 at 10:29 AM, Helmut Kudrnovsky  wrote:

> pvanbosgeo wrote
> > In Windows running R from within GRASS (latter installed via OSGeo4W)
> > works fine, except that it can't seem to find the GRASS addons I
> > installed (with g.extension), not using rgrass7 nor directly using
> > system(). On Linux this is no problem, I can run any installed addon.
> > Any ideas how to solve this?
>
> see also the discussion on GRASS Statistics mailing List
>

Helmut, thanks for following this up. I am following the discussion there.
Not sure I can be of any help at this point; I am on Linux, but hit this
issue because I am helping out somebody on Windows. But if at some point
relevant I am glad to test.


>
>
>
>
> -
> best regards
> Helmut
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/Using-GRASS-addons-in-R-on-Windows-tp5244240p5244505.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] error in pygrass doc

[Luca Delucchi]

On 8 January 2016 at 17:21, Pietro  wrote:
> Hi Luca,
>

Hi all,

>
> please replace the example with enumerate.
>

done in r67547 and r67548

> All the best
>
> Pietro



-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #719: v.edit tool=break: breaking more then 6 coords and producing of an unexpected line

[GRASS GIS]

#719: v.edit tool=break:  breaking more then 6 coords and producing of an
unexpected line
--+---
  Reporter:  achim|  Owner:  martinl
  Type:  defect   | Status:  reopened
  Priority:  major|  Milestone:  7.0.3
 Component:  Vector   |Version:  7.0.2
Resolution:   |   Keywords:  v.edit tool=break
   CPU:  Unspecified  |   Platform:  Linux
--+---

Comment (by GG12345):

 Hello all and best wishes for 2016 !

 Any time for this bug ? Are there some tests I could do ?

 I was wondering if the region precision could be of any help for this, but
 if I read correctly in g.region manual, "Typically all raster and display
 modules are affected by the current region settings, but not vector
 modules. Some special modules diverge from this rule, for example raster
 import modules and v.in.region."
 Any clues ?

 Thanks,

 Cev.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] problem installing wx.metadata from g.extension

[Margherita Di Leo]

Hi,

I have problem installing wx.metadata via g.extension:

> g.extension wx.metadata
Fetching  from GRASS GIS Addons repository (be patient)...
Compiling...
Traceback (most recent call last):
  File
"/tmp/grass7-v-user-21088/tmpape9at/wx.metadata/scripts/g.gui.metadata",
line 45, in 
from mdpdffactory import PdfCreator
  File "../mdlib/mdpdffactory.py", line 13, in 
from reportlab.platypus import Paragraph, Image, Table
ImportError: No module named reportlab.platypus
make[1]: *** [g.gui.metadata.tmp.html] Error 1
Installing...
/usr/bin/install: cannot stat
‘/tmp/grass7-v-user-21088/tmpape9at/wx.metadata/docs/html/g.gui.metadata.html’:
No such file or directory
make[1]: *** [install] Error 1
make: *** [installsubdirs] Error 2
WARNING: Installation failed, sorry. Please check above error messages.

GRASS trunk installation updated today. ~/.grass7/addons was clean.
wx.metadata specific dependencies installed

Any pointers?
Thank you in advance

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

[GRASS-dev] r67535: pygrass: change dirname in set_path()

[Pietro]

Hi Martin,

I saw your recent comment in the set_path function:

{{{
# TODO: why dirname is checked first - the logic should be revised
# TODO  probably also 'path' should be also removed - it's used only by
#   compilation process for addons (see r.green for details)
}}}

'path' it is not used for compilation process for addons as you said.
'path' is used to run the code locally without compilation.

In this way it is possible to just unpack the module and call the
sub-modules locally,  compilation is not needed at all... This it is
particularly useful during the development phase but not only. It works
quite well also to overcome eventually g.extension problems.

Of course dirname must be checked before the default path, other wise it is
too late...

Any comments?

Have a nice day

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

Re: [GRASS-dev] [GRASS GIS] #719: v.edit tool=break: breaking more then 6 coords and producing of an unexpected line

[GRASS GIS]

#719: v.edit tool=break:  breaking more then 6 coords and producing of an
unexpected line
--+---
  Reporter:  achim|  Owner:  martinl
  Type:  defect   | Status:  reopened
  Priority:  major|  Milestone:  7.0.3
 Component:  Vector   |Version:  7.0.2
Resolution:   |   Keywords:  v.edit tool=break
   CPU:  Unspecified  |   Platform:  Linux
--+---

Comment (by mlennert):

 Looking at this briefly, wouldn't it be enough to port r58512 and r5851 to
 the grass7 branches ? The original fix was only applied to grass6.

--
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] #2861: Copy 'Windows batchfiles for use with R' (GRASS-R-integration) from source to PACKAGE_DIR\extrabin not done

[GRASS GIS]

#2861: Copy 'Windows batchfiles for use with R' (GRASS-R-integration) from 
source
to PACKAGE_DIR\extrabin not done
--+-
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.3
 Component:  Packaging|Version:  svn-releasebranch70
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  MSWindows 7
--+-

Comment (by hellik):

 Replying to [comment:1 martinl]:
 > Hopefully fixed in r67543 (trunk). Could you test the next builds of 7.1
 (2016/01/11)?

 tested with WinGRASS-7.1.svn-r67543-201-Setup-x86.exe. the files are there
 now.

 it should be backported.

 thanks

--
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] #2861: Copy 'Windows batchfiles for use with R' (GRASS-R-integration) from source to PACKAGE_DIR\extrabin not done

[GRASS GIS]

#2861: Copy 'Windows batchfiles for use with R' (GRASS-R-integration) from 
source
to PACKAGE_DIR\extrabin not done
--+-
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.3
 Component:  Packaging|Version:  svn-releasebranch70
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  MSWindows 7
--+-

Comment (by martinl):

 Replying to [comment:2 hellik]:
 > it should be backported.

 done in r67549. After testing next (2016/01/12) 703svn build (1,2) can be
 the ticket closed.

 (1) https://wingrass.fsv.cvut.cz/x86_64/grass70/

 (2) https://wingrass.fsv.cvut.cz/x86/grass70/

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] No interface description of modules (rgrass7)

[Helmut Kudrnovsky]

hi,

having a look into the source of the R-package rgrass7 [1] there are
mentioned some modules (g7) having no interface description:

--
parseGRASS <- function(cmd, legacyExec=NULL) {
bin_out_win <- c("d.colors.exe", "d.save.exe", "d.what.rast.exe",
  "d.what.vect.exe", "d.zoom.exe", "g.parser.exe", "gis.m.bat",
  "i.spectral.bat", "mkftcap.bat", "r.mapcalc.exe", "r.tileset.bat",
  "r3.mapcalc.exe", "v.in.gpsbabel.bat", "v.proj.exe")
if ((get("SYS", envir=.GRASS_CACHE) == "WinNat") && cmd %in%
bin_out_win)
stop(paste("No interface description:", cmd))
[...]
--

anyone any idea which can be removed from this list?

[1]
https://r-forge.r-project.org/scm/viewvc.php/pkg/rgrass7/R/xml1.R?view=markup&root=spgrass



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/No-interface-description-of-modules-rgrass7-tp5244541.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] problem installing wx.metadata from g.extension

[Margherita Di Leo]

Figured out I missed dependency python-reportlab. Not sure it's written
anywhere in https://grasswiki.osgeo.org/wiki/ISO/INSPIRE_Metadata_Support ,
I'm updating now the wiki page.

Thanks




On Mon, Jan 11, 2016 at 11:59 AM, Margherita Di Leo 
wrote:

> Hi,
>
> I have problem installing wx.metadata via g.extension:
>
> > g.extension wx.metadata
> Fetching  from GRASS GIS Addons repository (be patient)...
> Compiling...
> Traceback (most recent call last):
>   File
> "/tmp/grass7-v-user-21088/tmpape9at/wx.metadata/scripts/g.gui.metadata",
> line 45, in 
> from mdpdffactory import PdfCreator
>   File "../mdlib/mdpdffactory.py", line 13, in 
> from reportlab.platypus import Paragraph, Image, Table
> ImportError: No module named reportlab.platypus
> make[1]: *** [g.gui.metadata.tmp.html] Error 1
> Installing...
> /usr/bin/install: cannot stat
> ‘/tmp/grass7-v-user-21088/tmpape9at/wx.metadata/docs/html/g.gui.metadata.html’:
> No such file or directory
> make[1]: *** [install] Error 1
> make: *** [installsubdirs] Error 2
> WARNING: Installation failed, sorry. Please check above error messages.
>
> GRASS trunk installation updated today. ~/.grass7/addons was clean.
> wx.metadata specific dependencies installed
>
> Any pointers?
> Thank you in advance
>
> --
> Margherita Di Leo
>



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

Re: [GRASS-dev] [GRASS GIS] #2859: wxGUI Add web service layer: small (cosmetic changes) in the behavior of some gui wxWidgets

[GRASS GIS]

#2859: wxGUI Add web service layer: small (cosmetic changes) in the behavior of
some gui wxWidgets
--+--
  Reporter:  tmsz |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  trivial  |  Milestone:  7.0.4
 Component:  wxGUI|Version:  svn-releasebranch70
Resolution:   |   Keywords:  wxGUI, Add web service layer
   CPU:  All  |   Platform:  All
--+--
Changes (by annakrat):

 * milestone:  7.0.3 => 7.0.4


Comment:

 Thanks, I applied them to trunk, will backport to release branch for
 7.0.4. Please next time provide the patch without the whitespace changes.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] problem installing wx.metadata from g.extension

[Matej Krejci]

Hi Madi,
thanks for update wiki page, I have updated (r67551) dependency file for
checking dependency before installation.
ciao Matej

On Mon, Jan 11, 2016 at 2:43 PM Margherita Di Leo 
wrote:

> Figured out I missed dependency python-reportlab. Not sure it's written
> anywhere in https://grasswiki.osgeo.org/wiki/ISO/INSPIRE_Metadata_Support
> , I'm updating now the wiki page.
>
> Thanks
>
>
>
>
> On Mon, Jan 11, 2016 at 11:59 AM, Margherita Di Leo 
> wrote:
>
>> Hi,
>>
>> I have problem installing wx.metadata via g.extension:
>>
>> > g.extension wx.metadata
>> Fetching  from GRASS GIS Addons repository (be patient)...
>> Compiling...
>> Traceback (most recent call last):
>>   File
>> "/tmp/grass7-v-user-21088/tmpape9at/wx.metadata/scripts/g.gui.metadata",
>> line 45, in 
>> from mdpdffactory import PdfCreator
>>   File "../mdlib/mdpdffactory.py", line 13, in 
>> from reportlab.platypus import Paragraph, Image, Table
>> ImportError: No module named reportlab.platypus
>> make[1]: *** [g.gui.metadata.tmp.html] Error 1
>> Installing...
>> /usr/bin/install: cannot stat
>> ‘/tmp/grass7-v-user-21088/tmpape9at/wx.metadata/docs/html/g.gui.metadata.html’:
>> No such file or directory
>> make[1]: *** [install] Error 1
>> make: *** [installsubdirs] Error 2
>> WARNING: Installation failed, sorry. Please check above error messages.
>>
>> GRASS trunk installation updated today. ~/.grass7/addons was clean.
>> wx.metadata specific dependencies installed
>>
>> Any pointers?
>> Thank you in advance
>>
>> --
>> Margherita Di Leo
>>
>
>
>
> --
> Margherita Di Leo
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] problem installing wx.metadata from g.extension

[Martin Landa]

Hi,

2016-01-11 15:44 GMT+01:00 Matej Krejci :
> thanks for update wiki page, I have updated (r67551) dependency file for
> checking dependency before installation.

it would be nice to reduce number of dependencies for compiling to the
minimum. It's the reason why this extension is not available for
Windows [1]. Most of dependencies are need for running the tool but
for compiling. Now they are checked before compiling which should be
changed in the future.

Martin

[1] 
https://wingrass.fsv.cvut.cz/x86_64/grass71/addons/grass-7.1.svn/logs/wx.metadata.log

-- 
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] #719: v.edit tool=break: breaking more then 6 coords and producing of an unexpected line

[GRASS GIS]

#719: v.edit tool=break:  breaking more then 6 coords and producing of an
unexpected line
--+---
  Reporter:  achim|  Owner:  martinl
  Type:  defect   | Status:  reopened
  Priority:  major|  Milestone:  7.0.3
 Component:  Vector   |Version:  7.0.2
Resolution:   |   Keywords:  v.edit tool=break
   CPU:  Unspecified  |   Platform:  Linux
--+---

Comment (by neteler):

 Replying to [comment:20 mlennert]:
 > Looking at this briefly, wouldn't it be enough to port r58512 and r5851
 to the grass7 branches ? The original fix was only applied to grass6.

 Sure about r5851? One digit lost?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] release plan for 7.0.3

[Markus Neteler]

On Sun, Jan 10, 2016 at 8:39 PM, Martin Landa  wrote:
> Hi,
>
> 2015-12-18 18:08 GMT+01:00 Martin Landa :
>> 1) this weekend soft freeze starts
>> 2) before the end of the year: hard freeze + RC1
>> 3) around January 10: RC2
>> 4) around January 14: 7.0.3
>
> I would like to open discussion about releasing RC2 in the next few
> days. Is there any blockers (at least trac shows none)? Note that
> final release should come not longer that one week after RC2. Martin

Yes - and in 2-3 weeks there is OSGeoLive 9.5. Feature freeze in which
I would like to see 7.0.3

Markus



> --
> 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] #719: v.edit tool=break: breaking more then 6 coords and producing of an unexpected line

[GRASS GIS]

#719: v.edit tool=break:  breaking more then 6 coords and producing of an
unexpected line
--+---
  Reporter:  achim|  Owner:  martinl
  Type:  defect   | Status:  reopened
  Priority:  major|  Milestone:  7.0.3
 Component:  Vector   |Version:  7.0.2
Resolution:   |   Keywords:  v.edit tool=break
   CPU:  Unspecified  |   Platform:  Linux
--+---

Comment (by mlennert):

 Replying to [comment:21 neteler]:
 > Replying to [comment:20 mlennert]:
 > > Looking at this briefly, wouldn't it be enough to port r58512 and
 r5851 to the grass7 branches ? The original fix was only applied to
 grass6.
 >
 > Sure about r5851? One digit lost?

 Yes, sorry, this should have been r58512 and r58516 (as mentioned in
 earlier comments by Martin).

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] release plan for 7.0.3

[Moritz Lennert]

On 11/01/16 16:15, Markus Neteler wrote:

On Sun, Jan 10, 2016 at 8:39 PM, Martin Landa  wrote:

Hi,

2015-12-18 18:08 GMT+01:00 Martin Landa :

1) this weekend soft freeze starts
2) before the end of the year: hard freeze + RC1
3) around January 10: RC2
4) around January 14: 7.0.3


I would like to open discussion about releasing RC2 in the next few
days. Is there any blockers (at least trac shows none)? Note that
final release should come not longer that one week after RC2. Martin


Yes - and in 2-3 weeks there is OSGeoLive 9.5. Feature freeze in which
I would like to see 7.0.3


+1

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

Re: [GRASS-dev] Using GRASS addons in R on Windows

[Helmut Kudrnovsky]

pvanbosgeo wrote
> On Mon, Jan 11, 2016 at 10:29 AM, Helmut Kudrnovsky <

> hellik@

> > wrote:
> 
>> pvanbosgeo wrote
>> > In Windows running R from within GRASS (latter installed via OSGeo4W)
>> > works fine, except that it can't seem to find the GRASS addons I
>> > installed (with g.extension), not using rgrass7 nor directly using
>> > system(). On Linux this is no problem, I can run any installed addon.
>> > Any ideas how to solve this?
>>
>> see also the discussion on GRASS Statistics mailing List
>>
> 
> Helmut, thanks for following this up. I am following the discussion there.
> Not sure I can be of any help at this point; I am on Linux, but hit this
> issue because I am helping out somebody on Windows. But if at some point
> relevant I am glad to test.
> 
> 
>>
>>
>>
>>
>> -
>> best regards
>> Helmut
>> --
>> View this message in context:
>> http://osgeo-org.1560.x6.nabble.com/Using-GRASS-addons-in-R-on-Windows-tp5244240p5244505.html
>> Sent from the Grass - Dev mailing list archive at Nabble.com.
>> ___
>> grass-dev mailing list
>> 

> grass-dev@.osgeo

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

> grass-dev@.osgeo

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

See http://lists.osgeo.org/pipermail/grass-stats/2016-January/001621.html

a new rgrass7 version is now on CRAN, testing welcome 



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Using-GRASS-addons-in-R-on-Windows-tp5244240p5244583.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] problem installing wx.metadata from g.extension

[Paulo van Breugel]

On Mon, Jan 11, 2016 at 3:54 PM, Martin Landa 
wrote:

> Hi,
>
> 2016-01-11 15:44 GMT+01:00 Matej Krejci :
> > thanks for update wiki page, I have updated (r67551) dependency file for
> > checking dependency before installation.
>
> it would be nice to reduce number of dependencies for compiling to the
> minimum. It's the reason why this extension is not available for
> Windows [1]. Most of dependencies are need for running the tool but
> for compiling. Now they are checked before compiling which should be
> changed in the future.
>

In addition, the wx.metadata includes several distinct (imho) tools, most
notably g.gui.metadata and g.gui.cswbrowser. This means, I think, that if I
am interested in the first, I still need to make sure to have all the
dependencies of the latter. If that is true (and I am not sure), would it
be possible to make it separate installs?


>
> Martin
>
> [1]
> https://wingrass.fsv.cvut.cz/x86_64/grass71/addons/grass-7.1.svn/logs/wx.metadata.log
>
> --
> 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

[GRASS-dev] [GRASS GIS] #2863: executing r.in.wms module causes pop up python gui error dialog (python.exe stopped working)

[GRASS GIS]

#2863: executing r.in.wms module causes pop up python gui error dialog 
(python.exe
stopped working)
-+-
 Reporter:  tmsz |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  minor|  Milestone:
Component:  Raster   |Version:  7.0.2
 Keywords:  r.in.wms |CPU:  Unspecified
 Platform:  MSWindows 7  |
-+-
 I just discovered that executing r.in.wms module (with default WMS_GRASS
 driver) causes pop up python gui error dialog (python.exe stopped working)
 (affected is a wxGUI Add web service layer dialog, too). However r.in.wms
 module finished correctly. This behaviour I discovered on Windows OS only.

 {{{
 r.in.wms url=http://watzmann-geog.urz.uni-heidelberg.de/cached/osm
 output=wms_eu_hillshade layers=europe_wms:hs_srtm_europa
 }}}

 I debug r.in.wms module, and I find that behaviour cause
 src_band.ReadAsArray() method call (ReadAsArray() method from gdal python
 module), row 239 in the protected method _pct2rgb, class WMSDrv in the
 wms_drv.py module.

--
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] #2863: executing r.in.wms module causes pop up python gui error dialog (python.exe stopped working)

[GRASS GIS]

#2863: executing r.in.wms module causes pop up python gui error dialog 
(python.exe
stopped working)
--+-
  Reporter:  tmsz |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  minor|  Milestone:
 Component:  Raster   |Version:  7.0.2
Resolution:   |   Keywords:  r.in.wms
   CPU:  Unspecified  |   Platform:  MSWindows 7
--+-
Changes (by tmsz):

 * Attachment "r_in_wms.jpg" added.

 python gui error dialog (python.exe stopped working)

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2864: Add link to source code in the documentation pages.

[GRASS GIS]

#2864: Add link to source code in the documentation pages.
-+-
 Reporter:  pmav99   |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:  7.0.3
Component:  Docs |Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 I don't know how easy it is to implement this, but I think that it would
 be really helpful if the online documentation had links to the source
 code.

 E.g. To add a link in this
 [https://grass.osgeo.org/grass70/manuals/r.import.html page] to this
 
[https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_7_0/scripts/r.import
 one].

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Max Memory usage limit

[Panagiotis Mavrogiorgos]

Hi all,

Just out of curiosity, why is there an upper limit to the memory we can use
on operations like r.in.gdal?

with kind regards,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2854: results in winGRASS7 32bit vs 64bit: should they be identical?

[GRASS GIS]

#2854: results in winGRASS7 32bit vs 64bit: should they be identical?
-+-
  Reporter:  hellik  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.0.3
 Component:  Raster  |Version:  svn-releasebranch70
Resolution:  |   Keywords:
   CPU:  x86-64  |   Platform:  MSWindows 7
-+-

Comment (by glynn):

 Replying to [comment:7 neteler]:

 > Doesn't this qualify for "basically identical results as much as
 different architectures can achieve"?

 In theory, it should be possible to obtain identical results on any
 architecture using IEEE-754 floating-point for calculations using only +,
 -, *, / and sqrt() (no transcendental functions such as sin, cos, log,
 exp, etc). But that may have a noticeable performance cost (e.g. using
 -ffloat-store to discard excess precision, forgoing certain optimisations,
 etc).

 Regarding the use of an "epsilon":

 1. The accuracy of a floating-point value is proportional to its
 magnitude. For IEEE-754, FLT_EPSILON is ~1.192e-7 while DBL_EPSILON is
 ~2.22e-16. This represents the difference between 1.0 and the smallest
 distinct, representable value greater than 1.0.

 Consequently, it provides a measure of the worst-case rounding error for
 values between 1.0 (inclusive) and 2.0 (exclusive). For round-to-nearest,
 the worst-case rounding error will be plus or minus half that value. For
 larger or smaller values, the maximum rounding error will be scaled
 accordingly. I.e. a typical "tolerant comparison" would be along the lines
 of
 {{{
 if (fabs(a-b) < N * epsilon * max(fabs(a),fabs(b))) ...
 }}}

 2. Rounding error occurs at each stage in the computation. The expected
 absolute error for a complex calculation will be at least the sum of the
 absolute errors for the individual steps.

 3. When subtractions are involved, you can't rely upon the absolute error
 in the result being proportional to the magnitude of the result, as
 subtracting similar values will produce a result whose magnitude may be
 much smaller than either of the individual values, but whose absolute
 error is proportional to that of the individual values.

 (A concrete example of that last point is that a single-pass variance
 calculation using sum-of-squares minus sum-squared can yield a negative
 value for the variance if the deviations are small relative to the mean).

 4. Other common cases where the accuracy of the result can be far worse
 than that of intermediate results or the inputs include finding roots of
 high-degree polynomials
 ([https://en.wikipedia.org/wiki/Wilkinson's_polynomial an extreme
 example]) and acos(x) where x is close to 1.0 (as x tends to 1.0, the
 derivative of acos(x) tends to infinity while acos(x) itself tends to
 zero; the first magnifies the absolute error while the second further
 magnifies the relative error).

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] r.mapcalc: warning: field width should have type 'int', but argument has type 'yy_size_t'

[Glynn Clements]

Markus Neteler wrote:

> >> compiling relbranch70 (likely the same on trunk), I got
> >
> > Try r67518.
> 
> Issue gone, thanks.
> 
> I spotted another single one:
> 
> lib/db/sqlp/sqlp.tab.c

r67559

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

Re: [GRASS-dev] [GRASS GIS] #2845: Build failure with 7.0.3RC1 on Linux

[GRASS GIS]

#2845: Build failure with 7.0.3RC1 on Linux
-+-
  Reporter:  scimmia |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  blocker |  Milestone:  7.0.4
 Component:  Compiling   |Version:  unspecified
Resolution:  |   Keywords:  xml, toolboxes, Makefile, svnprop,
 |  wxGUI, releasing
   CPU:  x86-64  |   Platform:  Linux
-+-

Comment (by glynn):

 Replying to [comment:27 wenzeslaus]:

 > It's hard for me to tell what's right at this point but the `OBJ.*` are
 generated during compilation and ignored by `svn status`, so shouldn't be
 the desired behavior the same for all the generated files. Or should go
 all the generated files to `OBJ.*` dirs?

 That would be nice for various reasons, but isn't always practical.

 At present, if you build with e.g.
 {{{
 make 'OBJDIR=$(HOME)/grass_objdir/$(RELDIR)'
 }}}
 you still end up with the following files being created in the source
 tree:
 {{{
 lib/python/ctypes/ctypesgencore/*.pyc
 locale/scriptstrings/*_to_translate.c

 gui/wxpython/menustrings.py
 gui/wxpython/xml/menudata.xml
 gui/wxpython/xml/module_tree_menudata.xml
 lib/db/sqlp/sqlp.output
 lib/db/sqlp/sqlp.tab.c
 lib/db/sqlp/sqlp.tab.h
 lib/db/sqlp/sqlp.yy.c
 lib/python/script/setup.py.tmp
 man/build_html.pyc
 raster/r.mapcalc/mapcalc.output
 raster/r.mapcalc/mapcalc.tab.c
 raster/r.mapcalc/mapcalc.tab.h
 raster/r.mapcalc/mapcalc.yy.c
 }}}

 If we could get all of those to be created in $(OBJDIR), it would be
 possible to build GRASS from a read-only source tree, or run multiple
 builds in a single source tree without them interfering with each other,
 or clean up simply by "rm -rf"ing $(OBJDIR).

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] r.mapcalc: warning: field width should have type 'int', but argument has type 'yy_size_t'

[Markus Neteler]

On Mon, Jan 11, 2016 at 9:31 PM, Glynn Clements
 wrote:
>
> Markus Neteler wrote:
>
>> >> compiling relbranch70 (likely the same on trunk), I got
>> >
>> > Try r67518.
>>
>> Issue gone, thanks.
>>
>> I spotted another single one:
>>
>> lib/db/sqlp/sqlp.tab.c
>
> r67559

No more warnings also here, thanks.

Backported  in r67560.

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

Re: [GRASS-dev] [GRASS GIS] #2864: Add link to source code in the documentation pages.

[GRASS GIS]

#2864: Add link to source code in the documentation pages.
--+--
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.4
 Component:  Docs |Version:  svn-releasebranch70
Resolution:   |   Keywords:  open science, access
   CPU:  Unspecified  |   Platform:  Unspecified
--+--
Changes (by wenzeslaus):

 * keywords:   => open science, access
 * version:  unspecified => svn-releasebranch70
 * milestone:  7.0.3 => 7.0.4


Comment:

 Makes sense to me. For example [http://www.uoguelph.ca/~hydrogeo/Whitebox/
 Whitebox] has a ''View Code'' button in the
 [https://whiteboxgeospatial.wordpress.com/2014/05/04/so-what-exactly-is-
 open-access-software/ the GUI]:

 
[[Image(https://whiteboxgeospatial.files.wordpress.com/2014/05/whiteboxclumpdialog.png,
 90%)]]

 The documentations seems a better place but I can see a reason why they
 decided for GUI (similarly to ''Modify Help Entry'' button).

 For start you can try to add it to the footer of the manual page. The
 [source:grass/trunk/tools/mkhtml.py tools/mkhtml.py] is where it is
 implemented.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] problem installing wx.metadata from g.extension

[Vaclav Petras]

On Mon, Jan 11, 2016 at 9:54 AM, Martin Landa 
wrote:

> 2016-01-11 15:44 GMT+01:00 Matej Krejci :
> > thanks for update wiki page, I have updated (r67551) dependency file for
> > checking dependency before installation.
>
> it would be nice to reduce number of dependencies for compiling to the
> minimum. It's the reason why this extension is not available for
> Windows [1]. Most of dependencies are need for running the tool but
> for compiling. Now they are checked before compiling which should be
> changed in the future.



Agreed, there is an post about it here:

https://lists.osgeo.org/pipermail/grass-dev/2015-February/073734.html

There is now even more examples in addons how this can be done.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev