[GRASS-dev] g.extension does not find any extension to install

[Pierre Roudier]

Hi,

No add-on seems to9 be available to my system when trying to use the
g.extension command:

GRASS 7.0.svn (NZTM2000):~ > g.extension -l
svnurl=https://svn.osgeo.org/grass/grass-addons
Fetching list of modules from GRASS-Addons SVN (be patient)...
GRASS 7.0.svn (NZTM2000):~ >

Therefore, it is not possible to install any:

GRASS 7.0.svn (NZTM2000):~ > g.extension -s
svnurl=https://svn.osgeo.org/grass/grass-addons extension=wx.psmap
Fetching 'wx.psmap' from GRASS-Addons SVN (be patient)...
svn: URL 'https://svn.osgeo.org/grass/grass-addons/wx/wx.psmap' doesn't exist
ERROR: GRASS Addons 'wx.psmap' not found in repository
GRASS 7.0.svn (NZTM2000):~ >

If that's of any use, I'm running the last grass70 SVN version, on a
Linux x86_64 platform. But I suspect this is related to the proxy of
my institute, despite I got it specified in the HTTP_PROXY envvar, and
in my ~/.subversion/servers file.

Cheers,

Pierre

-- 
Scientist
Landcare Research, New Zealand
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #1338: Text doesn't display for d.legend and d.barscale

[GRASS GIS]

#1338: Text doesn't display for d.legend and d.barscale
+---
 Reporter:  snorfalorpagus  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  critical|   Milestone:  7.0.0
Component:  Display | Version:  svn-trunk
 Keywords:  cairo, fonts|Platform:  MacOSX   
  Cpu:  OSX/Intel   |  
+---
Changes (by hamish):

  * keywords:  cairo => cairo, fonts


Comment:

 For me in grass7 on linux, by default GRASS_FONT (shell enviro variable)
 is not set by default, but text does display using what I guess would be
 cairo's fat/smoothed version of GRASS's romans.

 setting the font manually with `export GRASS_FONT="Times New Roman:Bold
 Italic"` on the command line successfully changes the font. (viewing with
 `qiv -eT map.png&`)

 If I set the font to something not on the `d.fontlist` list (e.g. "Times
 New Roman" instead of "Times_New_Roman", no text is drawn and I get this
 warning:

 {{{
 WARNING: Unable to open font map
  '/usr/local/src/grass/svn/trunk/dist.x86_64-unknown-linux-
 gnu/fonts/.hmp':
  No such file or directory. Try running 'g.mkfontcap -o'
 }}}

 (path to stroke fonts, but there is no (null).hmp file)

 ... I assume that's just the last test-for-font code it gets to, but the
 main point of this comment is that this warning message or the font tests
 could be improved.

 n.b. d.font erases the map.png, but I guess that's just because I haven't
 set GRASS_PNG_READ etc.


 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Re: [GRASS GIS] #1338: Text doesn't display for d.legend and d.barscale

[GRASS GIS]

#1338: Text doesn't display for d.legend and d.barscale
+---
 Reporter:  snorfalorpagus  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  critical|   Milestone:  7.0.0
Component:  Display | Version:  svn-trunk
 Keywords:  cairo   |Platform:  MacOSX   
  Cpu:  OSX/Intel   |  
+---

Comment(by snorfalorpagus):

 GRASS_FONT is not set. The romans font does appear to be installed:

 /Applications/GRASS-7.0.app/Contents/MacOS/fonts/romans.hmp

 I tried setting it to italicc, but no change.

 When I start GRASS, I get these warnings. I'm not sure if it's related. It
 happens right when the GUI starts. Everything else seems to function OK.

 {{{
 Launching 'wxpython' GUI in the background, please wait...
 GRASS 7.0.svn (hydro52021):~ > Tue Mar 29 18:46:08 Snorfalorpagus-
 MBP-15.local Python[1091] : kCGErrorIllegalArgument:
 CGSGetWindowBounds: NULL window
 Tue Mar 29 18:46:08 Snorfalorpagus-MBP-15.local Python[1091] :
 kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as
 they are logged.
 Tue Mar 29 18:46:08 Snorfalorpagus-MBP-15.local Python[1091] :
 CGContextRestoreGState: invalid context 0x0
 Tue Mar 29 18:46:08 Snorfalorpagus-MBP-15.local Python[1091] :
 CGContextRestoreGState: invalid context 0x0
 Tue Mar 29 18:46:08 Snorfalorpagus-MBP-15.local Python[1091] :
 CGContextRestoreGState: invalid context 0x0
 Tue Mar 29 18:46:08 Snorfalorpagus-MBP-15.local Python[1091] :
 CGContextRestoreGState: invalid context 0x0
 Tue Mar 29 18:46:08 Snorfalorpagus-MBP-15.local Python[1091] :
 CGContextRestoreGState: invalid context 0x0
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Re: [GRASS GIS] #1338: Text doesn't display for d.legend and d.barscale

[GRASS GIS]

#1338: Text doesn't display for d.legend and d.barscale
+---
 Reporter:  snorfalorpagus  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  critical|   Milestone:  7.0.0
Component:  Display | Version:  svn-trunk
 Keywords:  cairo   |Platform:  MacOSX   
  Cpu:  OSX/Intel   |  
+---

Comment(by glynn):

 Replying to [comment:1 martinl]:
 > I guess you are using cairo driver, so it will be bug in cairo display
 driver.

 FWIW, it works from the command line on Linux.

 My first guess would be something related to the font, e.g. the font
 hasn't been set, or is set to a font which doesn't exist. If GRASS_FONT is
 set (at all), it overrides the default "romans" stroke font.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Interested in parallelization of GRASS

[Glynn Clements]

Markus Metz wrote:

> The segment lib implementation in trunk is considerably faster than in
> 6.x, but not as efficient as the caching method of r.proj. Some
> reasons why the segment library is slower than the caching code in
> r.proj are 1) write support in the segment lib, 2) flexible data
> storage size in the segment lib, 3) flexible tile size in the segment
> lib, 4) bad abuse of the segment library, e.g. in r.los.

The main factors for performance are whether the tile size is fixed at
compile time and whether it's known (at compile time) to be a power of
two.

It wouldn't be particularly hard to structure the r.proj tile cache
code such that the tile size can be set by the module, so long as it's
set at compile time. Allowing the tile size to be set at run time
incurs an inevitable performance penalty.

The power-of-two constraint needn't be enforced by the code. The
shifts and masks could be replaced by multiplication, division and
modulo; any modern compiler will optimise these back to shifts and
masks if the tile size is a compile-time constant which is a power of
two.

OTOH, I'm not sure there's any benefit to relaxing the requirement. 
Some modules may be less efficient if the tile size is significantly
too small or too large, but being off by a factor of sqrt(2) shouldn't
be an issue.

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

[GRASS-dev] Re: [GRASS GIS] #1338: Text doesn't display for d.legend and d.barscale

[GRASS GIS]

#1338: Text doesn't display for d.legend and d.barscale
+---
 Reporter:  snorfalorpagus  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  critical|   Milestone:  7.0.0
Component:  Display | Version:  svn-trunk
 Keywords:  cairo   |Platform:  MacOSX   
  Cpu:  OSX/Intel   |  
+---

Comment(by snorfalorpagus):

 The cairo library I have installed (for which GRASS was compiled against)
 is the binary from:

 http://www.kyngchaos.com/software/frameworks

 "v1.10.2-1"

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Re: [GRASS GIS] #1310: Browse button in WxPython GUIs (for scripts) does not provide a correct file path for WinGRAS

[GRASS GIS]

#1310: Browse button in WxPython GUIs (for scripts) does not provide a correct
file path for WinGRAS
--+-
 Reporter:  katrineggert1980  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  critical  |   Milestone:  6.4.1
Component:  Bash  | Version:  6.4.1 RCs
 Keywords:  winGRASS  |Platform:  MSWindows XP 
  Cpu:  Unspecified   |  
--+-
Changes (by martinl):

  * component:  wxGUI => Bash


Comment:

 Changing compoment to `Bash`.

 Running from msys

 {{{
 r.out.xyz input=elevation out=C:\Temp\x.txt
 }}}

 create `Tempx.txt` in C drive.

 {{{
  r.out.xyz input=elevation out="C:\Temp\x.txt"
 }}}

 works as expected.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Re: [GRASS GIS] #1338: Text doesn't display for d.legend and d.barscale

[GRASS GIS]

#1338: Text doesn't display for d.legend and d.barscale
+---
 Reporter:  snorfalorpagus  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  critical|   Milestone:  7.0.0
Component:  Display | Version:  svn-trunk
 Keywords:  cairo   |Platform:  MacOSX   
  Cpu:  OSX/Intel   |  
+---
Changes (by martinl):

  * keywords:  => cairo
  * priority:  normal => critical


Comment:

 I guess you are using cairo driver, so it will be bug in cairo display
 driver.

-- 
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] #1338: Text doesn't display for d.legend and d.barscale

[GRASS GIS]

#1338: Text doesn't display for d.legend and d.barscale
+---
 Reporter:  snorfalorpagus  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  7.0.0
Component:  Display | Version:  svn-trunk
 Keywords:  |Platform:  MacOSX   
  Cpu:  OSX/Intel   |  
+---
 The legend and barscale display, but the associated text (5km, etc) does
 not. Running GRASS 7.0 (svn-trunk) compiled myself (see configure
 attached). I don't have this issue with the binaries for 6.4.1. Text added
 with the 'add text' option displays normally. See attached screenshot. No
 error text is reported (the ... in the console in the screenshot was from
 previous commands).

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Re: [GRASS GIS] #1310: Browse button in WxPython GUIs (for scripts) does not provide a correct file path for WinGRAS

[GRASS GIS]

#1310: Browse button in WxPython GUIs (for scripts) does not provide a correct
file path for WinGRAS
--+-
 Reporter:  katrineggert1980  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  critical  |   Milestone:  6.4.1
Component:  wxGUI | Version:  6.4.1 RCs
 Keywords:  winGRASS  |Platform:  MSWindows XP 
  Cpu:  Unspecified   |  
--+-

Comment(by martinl):

 Replying to [comment:18 katrineggert1980]:
 > Ok it makes some sense. If I try to run anything on Msys the \ are
 ignored. So this can be a possible solution.
 > But my question is, why C Modules accepts "\" and Scripts don't.

 Because C modules don't use Bash for parsing the arguments. I would say
 rather *Bash* scripts, Python scripts haven't such problem.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Re: [GRASS GIS] #1310: Browse button in WxPython GUIs (for scripts) does not provide a correct file path for WinGRAS

[GRASS GIS]

#1310: Browse button in WxPython GUIs (for scripts) does not provide a correct
file path for WinGRAS
--+-
 Reporter:  katrineggert1980  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  critical  |   Milestone:  6.4.1
Component:  wxGUI | Version:  6.4.1 RCs
 Keywords:  winGRASS  |Platform:  MSWindows XP 
  Cpu:  Unspecified   |  
--+-

Comment(by katrineggert1980):

 Ok it makes some sense. If I try to run anything on Msys the \ are
 ignored. So this can be a possible solution.
 But my question is, why C Modules accepts "\" and Scripts don't.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Error with r.to.vect- Solved?

[António Rocha]

Hello Markus
Thanks.
Just one final question: Is there a way to know which is the limit for 
vector? My idea is to check if raster, to be converted, is too big to be 
converted before I try to convert?

THanks




Markus Neteler wrote:

Hi António
(cc Martin)

you can get winGRASS 7 here:
http://wingrass.fsv.cvut.cz/grass70/

but I dunno if LFS is enabled in that built. Maybe Martin
can tell us.

cheers
Markus

2011/3/29 António Rocha :
 

Hi Markus

The problem is that I'm running in Windows and in GRASS6.4.0stable 
release.

So, there is no solution for Windows?
Thanks
Antonio

Markus Neteler wrote:
   

2011/3/29 António Rocha :

 

Hello Markus
Unfortunely, I get this error when I run other datasets. In this 
case, a

landCover with all CELLS and spatial resolution of 30. The problem is
that
North carolina sample is too small.
r.to.vect -v input=FULL@PERMANENT output=FULL feature=area
I get this:
Default driver / database set to:
driver: dbf
database: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/
Extracting areas...
Building topology for vector map ...
R4243000ERROR: G_realloc: unable to allocate 16976004 bytes at
struct_alloc.c:133



You mean that it is too big :)
The file in question is lib/vector/diglib/struct_alloc.c

Please try GRASS 7 instead of GRASS 6 which offers large file support
for vector data (to some extent).

You need to configure it with this options
 --enable-largefile  enable support for large files (LFS)

and compile it. Or use the weekly Linux binary snapshot which
has LFS enabled.

Markus





  







__ Information from ESET NOD32 Antivirus, version of virus signature 
database 5995 (20110329) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


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

Re: [GRASS-dev] Error with r.to.vect- Solved?

[Markus Neteler]

2011/3/29 António Rocha :
> Hello Markus
> Unfortunely, I get this error when I run other datasets. In this case, a
> landCover with all CELLS and spatial resolution of 30. The problem is that
> North carolina sample is too small.
> r.to.vect -v input=FULL@PERMANENT output=FULL feature=area
> I get this:
> Default driver / database set to:
> driver: dbf
> database: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/
> Extracting areas...
> Building topology for vector map ...
> R4243000ERROR: G_realloc: unable to allocate 16976004 bytes at
> struct_alloc.c:133

You mean that it is too big :)
The file in question is lib/vector/diglib/struct_alloc.c

Please try GRASS 7 instead of GRASS 6 which offers large file support
for vector data (to some extent).

You need to configure it with this options
  --enable-largefile  enable support for large files (LFS)

and compile it. Or use the weekly Linux binary snapshot which
has LFS enabled.

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

Re: [GRASS-dev] Error with r.to.vect- Solved?

[António Rocha]

Hello Markus
Unfortunely, I get this error when I run other datasets. In this case, a 
landCover with all CELLS and spatial resolution of 30. The problem is 
that North carolina sample is too small.

r.to.vect -v input=FULL@PERMANENT output=FULL feature=area
I get this:
Default driver / database set to:
driver: dbf
database: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/
Extracting areas...
Building topology for vector map ...
R4243000ERROR: G_realloc: unable to allocate 16976004 bytes at 
struct_alloc.c:133


It has created a vector but I cannot display and I cannot use v.info (it 
says that I need to build topology).

And If I try to build topology I get and error and before this warning:
Coor files of vector map  is larger 
than it should be (241464079 bytes excess)


So my questions are:
1- Is any fix for this?
2- If not, is there any defined limit for a raster in order to be 
converted to vector?


Thanks
Antonio

Markus Neteler wrote:

2011/3/23 António Rocha :
  

A couple of months ago I sent a few messages regarding a memorry error with
r.to.vect (it was allocating to many information and data). My question is,
sicne r.to.vect was not updated, is there any raster or vector lib update
that had any impact on this?



Did you post a test case? Best done with the North Carolina sample
data set. Otherwise it is hard to replicate...

Markus





  




__ Information from ESET NOD32 Antivirus, version of virus signature 
database 5995 (20110329) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


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