Re: [GRASS-dev] does GRASS 7 for Mac compile yet?

[epi]

i'm trying to debug the build of GRASS 7 on mac OSX 10.8.x in 64 bit with WX 
2.9.x

After commenting the check for wx version i got the GUI start, some worning :

###
GRASS 7.0.svn (spearfish60):~ > 
/usr/local/grass-7.0.svn/etc/gui/wxpython/wxgui.py:54: wxPyDeprecationWarning: 
Call to deprecated item 'InitAllImageHandlers'. 
  wx.InitAllImageHandlers()
/usr/local/grass-7.0.svn/etc/gui/wxpython/gui_core/goutput.py:230: 
wxPyDeprecationWarning: Call to deprecated item 'SetVirtualSizeHints'. 
  outputSizer.SetVirtualSizeHints(self.panelOutput)
###


the Window Manager seems to work properly (i cal load a layer Rast/Vect in the 
lkayer tree, the shell also pront out the log of commands nicely)
but i can't display layers (both Vector and Raster are not displayed).
Commenting  this 2 line in madisp.py :

359 #self.PrepareDC(dc)
519 #self.PrepareDC(dc)

i got the Raster map displaying properly

but no vector, the error is in a missed Cairo Driver :


/usr/local/grass-7.0.svn/etc/gui/wxpython/gui_core/ghelp.py:
608: wxPyDeprecationWarning: Call to deprecated item
'InitAllImageHandlers'.
  wx.InitAllImageHandlers()
Command 'd.vect map=archsites@PERMANENT
type=point,line,area,face' failed
Details: Unknown display driver 
Command 'd.vect map=archsites@PERMANENT
type=point,line,area,face' failed
Details: Unknown display driver 


I wasn't able to get the cairo driver working during the Make step, it shows 
the error at the end of the log [1]
about a missed arch ... but i guess ... I have everything built as --universal

In doubt I rebuilt fontconfig and cairo and checked the relative architecture :

lipo -info /usr/local/Cellar/cairo/1.12.12/lib/cairo/libcairo-trace.0.dylib 
/usr/local/Cellar/cairo/1.12.12/lib/libcairo-gobject.2.dylib 
/usr/local/Cellar/cairo/1.12.12/lib/libcairo-script-interpreter.2.dylib 
/usr/local/Cellar/cairo/1.12.12/lib/libcairo.2.dylib 
Architectures in the fat file: 
/usr/local/Cellar/cairo/1.12.12/lib/cairo/libcairo-trace.0.dylib are: i386 
x86_64 
Architectures in the fat file: 
/usr/local/Cellar/cairo/1.12.12/lib/libcairo-gobject.2.dylib are: i386 x86_64 
Architectures in the fat file: 
/usr/local/Cellar/cairo/1.12.12/lib/libcairo-script-interpreter.2.dylib are: 
i386 x86_64 
Architectures in the fat file: 
/usr/local/Cellar/cairo/1.12.12/lib/libcairo.2.dylib are: i386 x86_64 
epi:~ epi$ 


/usr/local/Cellar/fontconfig/2.10.91/bin/fc-cache:Mach-O universal binary 
with 2 architectures
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-cache (for architecture i386):  
Mach-O executable i386
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-cache (for architecture x86_64):
Mach-O 64-bit executable x86_64
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-cat:  Mach-O universal binary 
with 2 architectures
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-cat (for architecture i386):
Mach-O executable i386
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-cat (for architecture x86_64):  
Mach-O 64-bit executable x86_64
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-list: Mach-O universal binary 
with 2 architectures
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-list (for architecture i386):   
Mach-O executable i386
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-list (for architecture x86_64): 
Mach-O 64-bit executable x86_64
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-match:Mach-O universal binary 
with 2 architectures
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-match (for architecture i386):  
Mach-O executable i386
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-match (for architecture x86_64):
Mach-O 64-bit executable x86_64
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-pattern:  Mach-O universal binary 
with 2 architectures
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-pattern (for architecture i386):
Mach-O executable i386
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-pattern (for architecture x86_64):  
Mach-O 64-bit executable x86_64
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-query:Mach-O universal binary 
with 2 architectures
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-query (for architecture i386):  
Mach-O executable i386
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-query (for architecture x86_64):
Mach-O 64-bit executable x86_64
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-scan: Mach-O universal binary 
with 2 architectures
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-scan (for architecture i386):   
Mach-O executable i386
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-scan (for architecture x86_64): 
Mach-O 64-bit executable x86_64
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-validate: Mach-O universal binary 
with 2 architectures
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-validate (for architecture i386):   
Mach-O executable i386
/usr/local/Cellar/fontconfig/2.10.91/bin/fc-validate (for architecture 
x86_64):Mach-O 64-bit executable x86_64



They are multi-arch, but unlucky i still have the same error in cairod

Re: [GRASS-dev] [GRASS-SVN] r54852 - grass/trunk/lib/gis/colors

[Markus Neteler]

I asked because it does not exist in any other table.

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

Re: [GRASS-dev] [GRASS-SVN] r54852 - grass/trunk/lib/gis/colors

[Hamish]

Markus Neteler wrote:
> > Modified:
> >    grass/trunk/lib/gis/colors/srtm_plus
> > Log:
> > update to srtm_plus colorable
> ...
> > +default 255:255:255
> 
> Usually there is not "default" specified, should it be there
> or not?


Hi Markus,

I believe it does serve a purpose, perhaps when the color table
is based on fixed values instead of %, and does not extend far
enough to cover the range of the data, but the values are not
null either? In that case the default is white so the above may
be redundant.


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

[GRASS-dev] grass gis modules as keywords for LaTeX' "listings" package

[Nikos Alexandris]

Talking about colors and appearances,

I'd like to create a complete list of "grass-gis" keywords to use along
with the listings LaTeX package. It certainly would make LaTeX
documentation on grass-gis stuff look nice(r).

In doing that, I am testing by using a small set of grass-gis commands and
custom variable names defined as otherkeywords.  It is, more or less,
successfully.  However, I currently face one problem: using something like
"e=" as a keyword, will match the end of every parameter that ends in
"e=", e.g. "title=" and colorised (the end, not the complete parameter) as
instructed.

Anyone interested in such a list and how it can be used within LaTeX
documents?

Thank you, Nikos

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

Re: [GRASS-dev] grass wiki main page & colorbrewer tool

[Nikos Alexandris]

Hamish wrote:

> Hi Nikos,

Hi :-)

> I see you are looking at cleaning up the main page of the
> grass wiki.

Yes -- seeking for some Designer touch on it :-p

> fyi I'd previously done some experimentation mixing different
> "heath-like" box-group colors to make it more interesting, see:
>http://grasswiki.osgeo.org/wiki/Main_Page_color_test
> maybe it helps.

Yes, it (will) help(s) already. I am aware of the page.

Thank you, N

> ps- if anyone at the sprint is looking for a nice task, building
> a wxPy color wizard around the ColorBrewer tables might be fun:
>   http://colorbrewer2.org/

Maybe NikosV is interested? Cc-ed this post to him.

> I've got their data reduced to some csv text files from a past
> attempt, and AFAIR the licensing on those was compatible w/ GPL.
> (it's worth looking that up again, but I wouldn't have bothered
> starting on it if it wasn't) I think QGIS has something similar
> already?

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

Re: [GRASS-dev] GRASS 7: Potential ctype issue? "Could not parse macro"

[Glynn Clements]

Markus Neteler wrote:

> I just recompiled G7 and saw this one:
> Warning: Could not parse macro "#define serialize_int32_le(buf,x) do {
> ( buf ) [ i0 ] = ( ( x ) >> i0 ) & i255 ; ( buf ) [ i1 ] = ( ( x ) >>
> i8 ) & i255 ; ( buf ) [ i2 ] = ( ( x ) >> i16 ) & i255 ; ( buf ) [ i3
> ] = ( ( x ) >> i24 ) & i255 ; } while ( i0 )"
> Warning: Could not parse macro "#define serialize_int32_be(buf,x) do {
> ( buf ) [ i0 ] = ( ( x ) >> i24 ) & i255 ; ( buf ) [ i1 ] = ( ( x ) >>
> i16 ) & i255 ; ( buf ) [ i2 ] = ( ( x ) >> i8 ) & i255 ; ( buf ) [ i3
> ] = ( ( x ) >> i0 ) & i255 ; } while ( i0 )"

> Anything serious (esp. "Could not parse macro") or can it be happily ignored?

This is not new, and it can be ignored.

ctypes tries to convert macro definitions to either variables or
functions, but there are limits to what it can handle. Specifically,
the macro body must be either empty, a type name, or a constant
expression.

So e.g. the deserialize_int32_le and deserialize_int32_be macros in
gis.h get converted to Python functions in gis.py, but the
corresponding serialize macros can't be handled as their bodies are
statements rather than constant expressions, and so no equivalents
exist in the generated gis.py file.

I doubt that anyone would actually want to use these macros from
Python anyhow. The struct, ctypes or numpy modules would be more
appropriate.

The warnings can be avoided by guarding the macro definitions with
"#ifndef CTYPESGEN".

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

Re: [GRASS-dev] [GRASS GIS] #1736: wxNVIZ volume display crashes Mac

[GRASS GIS]

#1736: wxNVIZ volume display crashes Mac
---+
 Reporter:  cmbarton   |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.3
Component:  wxGUI  | Version:  svn-releasebranch64  
 Keywords: |Platform:  MacOSX   
  Cpu:  OSX/Intel  |  
---+

Comment(by cmbarton):

 There are never any error messages because this is not a normal GRASS
 module that goes through the GRASS error system. It simply crashes then
 entire interface. The native error system says that the crash starts at
 gvl_write_char. In the GRASS debug output, the second case crashes after
 the "initialize OK" line.

 If you compare the two debug outputs above, gvl_align_char allocates
 enough memory for a resolution of 2 (100 > 349308) but runs twice and
 allocates 2 chunks in the second case.

 gvl_align_data correctly allocates the needed memory in both cases now.

 I'm hoping that this is enough to suggest a fix.

 Michael

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] a minor but annoying bug just discovered with switching mapsets

[Glynn Clements]

Michael Barton wrote:

> I just realized that if you change to a new mapset using g.mapset
> and then quit (properly), the mapset you changed to with g.mapset
> appears as locked the next time you try to open it. This is in
> trunk, but may affect other versions.

It affects every version since the lock file was moved from $HOME to
the mapset directory (r12779) and g.mapset was added (r12822), between
5.4.0 and 6.0.0beta1.

The startup script creates the .gislock file in the initial mapset
directory. After the session shell terminates, it removes the lock
file which it created.

g.mapset creates a lock file in the new mapset directory and removes
the lock file from the old mapset directory.

For 7.0, I suggest updating the global "lockfile" variable in
lib/init/grass.py based upon the contents of the $GISRC file after the
session (shell, GUI, batch job) has finished.

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

[GRASS-dev] Ignored enhancements

[Seth Price]

A while ago I made some simple, but significant, enhancements and submitted 
them to trac. They haven't been picked up, so I wanted to point them out so 
someone can commit them before they diverge from the trunk.

http://trac.osgeo.org/grass/ticket/1624

This has had some activity recently, but it's status is still "new" and it 
isn't in trunk.

http://trac.osgeo.org/grass/ticket/1575

~Seth


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

[GRASS-dev] GRASS 7: Potential ctype issue? "Could not parse macro"

[Markus Neteler]

Hi,

I just recompiled G7 and saw this one:

...
Status: Preprocessing /tmp/tmpkUdn5x.h
Status: gcc -E  -D_FILE_OFFSET_BITS=64
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-D__GLIBC_HAVE_LONG_LONG -U __GNUC__ -dD "-Dinline=" "-D__inline__="
"-D__extension__=" "-D_Bool=uint8_t" "-D__const=const" "-D__asm__(x)="
"-D__asm(x)=" "-DCTYPESGEN=1" /tmp/tmpkUdn5x.h
Status: Preprocessing /tmp/tmpAnzlUs.h
Status: gcc -E  -D_FILE_OFFSET_BITS=64
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-D__GLIBC_HAVE_LONG_LONG -U __GNUC__ -dD "-Dinline=" "-D__inline__="
"-D__extension__=" "-D_Bool=uint8_t" "-D__const=const" "-D__asm__(x)="
"-D__asm(x)=" "-DCTYPESGEN=1" /tmp/tmpAnzlUs.h
Status: Preprocessing /tmp/tmpgQrOVu.h
Status: gcc -E  -D_FILE_OFFSET_BITS=64
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-D__GLIBC_HAVE_LONG_LONG -U __GNUC__ -dD "-Dinline=" "-D__inline__="
"-D__extension__=" "-D_Bool=uint8_t" "-D__const=const" "-D__asm__(x)="
"-D__asm(x)=" "-DCTYPESGEN=1" /tmp/tmpgQrOVu.h
Status: Parsing /tmp/tmpgQrOVu.h
Status: Parsing /tmp/tmpAnzlUs.h
Status: Processing description list.
Status: Processing description list.
Status: Writing to OBJ.x86_64-unknown-linux-gnu/dbmi.py.
Status: Wrapping complete.
sed -f fix.sed OBJ.x86_64-unknown-linux-gnu/dbmi.py >
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/etc/python/grass/lib/dbmi.py
Warning: Member "from" of Struct "DateTime" has been renamed to
"_from" because it has the same name as a Python keyword.
Warning: Member "def" of Struct "Option" has been renamed to "_def"
because it has the same name as a Python keyword.
Warning: Could not parse macro "#define serialize_int32_le(buf,x) do {
( buf ) [ i0 ] = ( ( x ) >> i0 ) & i255 ; ( buf ) [ i1 ] = ( ( x ) >>
i8 ) & i255 ; ( buf ) [ i2 ] = ( ( x ) >> i16 ) & i255 ; ( buf ) [ i3
] = ( ( x ) >> i24 ) & i255 ; } while ( i0 )"
Warning: Could not parse macro "#define serialize_int32_be(buf,x) do {
( buf ) [ i0 ] = ( ( x ) >> i24 ) & i255 ; ( buf ) [ i1 ] = ( ( x ) >>
i16 ) & i255 ; ( buf ) [ i2 ] = ( ( x ) >> i8 ) & i255 ; ( buf ) [ i3
] = ( ( x ) >> i0 ) & i255 ; } while ( i0 )"
Status: Writing to OBJ.x86_64-unknown-linux-gnu/gis.py.
Status: Wrapping complete.
...

Anything serious (esp. "Could not parse macro") or can it be happily ignored?

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

Re: [GRASS-dev] [GRASS GIS] #1615: Regression - v.transform fails to create a 3D map, crashes on Windows

[GRASS GIS]

#1615: Regression - v.transform fails to create a 3D map, crashes on Windows
--+-
  Reporter:  marisn   |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  major|   Milestone:  6.4.3
 Component:  Vector   | Version:  6.4.2
Resolution:  fixed|Keywords:   
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by mmetz):

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


Comment:

 Replying to [comment:22 hellik]:
 >
 > p.s. tested today osgeo4w-wingrass6.4.3svn-r52935 several times, no
 crash, no coormismatch, correct 3D output
 >
 Seems to be fixed, closing ticket.

 Markus M

-- 
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] #1865: WinGrass v.buffer memory issue

[GRASS GIS]

#1865: WinGrass v.buffer memory issue
-+--
 Reporter:  feppink  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.3
Component:  Vector   | Version:  6.4.3 RCs
 Keywords:   |Platform:  MSWindows 7  
  Cpu:  x86-64   |  
-+--

Comment(by mmetz):

 Replying to [comment:1 feppink]:
 > Additional info: I specify no other options for v.buffer apart from the
 units for the major axis. Memory issue starts occurring during "Breaking
 boundaries".

 If possible, try GRASS 7, because v.buffer only works correctly in GRASS 7
 and vector memory consumption is much less.

 Can you make the input vector map available and post the exact command
 used to calculate buffers?

 Markus M

-- 
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] #1855: error using GRASS v.net

[GRASS GIS]

#1855: error using GRASS v.net
--+-
  Reporter:  dof1985  |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  critical |   Milestone:  6.4.3
 Component:  Vector   | Version:  6.4.3 RCs
Resolution:  wontfix  |Keywords:  network  
  Platform:  MSWindows 7  | Cpu:  x86-64   
--+-
Changes (by mmetz):

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


Comment:

 Replying to [comment:1 dof1985]:
 > '''Update:'''
 >
 > After a long consulation with a generous user from GRASS community, I
 still havn't came to a solution. I've tried on two computers with WIN 7 as
 operation system, the following GRASS versions: 6.4.2 (through QGIS and
 without the plugin), 6.4.3 RCs, 7.0.0
 >
 > For the first two I have received the same error, for version 7 I didn't
 recieve the error but the process have never finished. On the other hand,
 my helper managed to complete it in seconds using my files.
 >
 > Can the problem have something to do with windows 7, some background or
 system process, or so? Should I install any extention or plugin in order
 to run network analysis programs on win 7?

 There are currently problems with the database communication in GRASS 7 on
 windows. The reported bug does not appear in GRASS 7, but the respective
 differences (spatial index) can not be backported for compatibility
 reasons.

 Closing the ticket as wontfix for GRASS 6.

 Markus M

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] another minor annoyance sort of bug

[Maris Nartiss]

JFYI
There is a bug for it: http://trac.osgeo.org/grass/ticket/1814

Maris.

2013/2/4 Markus Metz :
> On Mon, Feb 4, 2013 at 7:38 AM, Michael Barton  wrote:
>> I've noticed this before but hesitated to mention it. But still it's kind of
>> weird.
>>
>> If you run g.mlist (at least run through the GUI) you get messages like this
>> sent to the terminal
>>
>> GRASS_INFO_WARNING(14538,1): Illegal filename . Character <*> not
>> allowed.
>>
>> But of course the whole idea of g.mlist is to let you use characters like
>> "*"
>>
>> g.mlist works fine. It just generates these bogus warnings.
>
> These bogus warnings don't come from the module, they come from the
> wxGUI. Similar for multiple inputs, there the GUI complains about ","
> being an illegal character. I am not sure if the GUI should do option
> checking itself, the parser is doing that anyway.
>
> Markus M
> ___
> 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] another minor annoyance sort of bug

[Markus Metz]

On Mon, Feb 4, 2013 at 7:38 AM, Michael Barton  wrote:
> I've noticed this before but hesitated to mention it. But still it's kind of
> weird.
>
> If you run g.mlist (at least run through the GUI) you get messages like this
> sent to the terminal
>
> GRASS_INFO_WARNING(14538,1): Illegal filename . Character <*> not
> allowed.
>
> But of course the whole idea of g.mlist is to let you use characters like
> "*"
>
> g.mlist works fine. It just generates these bogus warnings.

These bogus warnings don't come from the module, they come from the
wxGUI. Similar for multiple inputs, there the GUI complains about ","
being an illegal character. I am not sure if the GUI should do option
checking itself, the parser is doing that anyway.

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

Re: [GRASS-dev] [GRASS GIS] #1736: wxNVIZ volume display crashes Mac

[GRASS GIS]

#1736: wxNVIZ volume display crashes Mac
---+
 Reporter:  cmbarton   |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.3
Component:  wxGUI  | Version:  svn-releasebranch64  
 Keywords: |Platform:  MacOSX   
  Cpu:  OSX/Intel  |  
---+

Comment(by mmetz):

 Replying to [comment:22 cmbarton]:
 > The Apple error report shows a crash after gvl_write_char, also in
 gvl_calc.c. Here is the last part of the GRASS Debug output for changing
 resolution from 3 to 2 (no crash) and 2 to 1 (crash).
 >
 {{{

 CHANGING RESOLUTION FROM 3 TO 2. OK

 D3/5: GS_get_zrange(): min=-0.09 max=22.33
 D3/5: GS_get_zrange(): min=-0.09 max=22.33
 D3/5: gvl_write_char(): reallocate memory for pos : 0 to : 100 B
 D3/5: gvl_align_data(): reallocate memory finally to : 349308 B
 D5/5: gvld_isosurf():
 D5/5:   start : gvl: jr_7408MR_2m_t70@test3d isosurf : 0

 D3/5: GS_get_zrange(): min=-0.09 max=22.33
 D3/5: GS_get_zrange(): min=-0.09 max=22.33
 D5/5:   intialize OK
 D5/5:   end : isosurf : 0 datalength : 349308 B

 D3/5: GS_done_draw
 D3/5: GS_done_draw

 CHANGING RESOLUTION FROM 2 TO 1. CRASH

 D3/5: GS_get_zrange(): min=-0.09 max=22.33
 D3/5: GS_get_zrange(): min=-0.09 max=22.33
 D3/5: gvl_write_char(): reallocate memory for pos : 0 to : 100 B
 D3/5: gvl_write_char(): reallocate memory for pos : 100 to : 200 B
 D3/5: gvl_align_data(): reallocate memory finally to : 1840605 B
 D5/5: gvld_isosurf():
 D5/5:   start : gvl: jr_7408MR_2m_t70@test3d isosurf : 0

 D3/5: GS_get_zrange(): min=-0.09 max=22.33
 D3/5: GS_get_zrange(): min=-0.09 max=22.33
 D5/5:   intialize OK

 }}}

 There is no error message, everything seems to be ok.

 Markus M

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] i.segment at Community Sprint

[Moritz Lennert]

On 02/02/13 17:37, Markus Metz wrote:

On Sat, Feb 2, 2013 at 12:56 PM, Moritz Lennert
  wrote:

Markus and Yann,

If you have the time it might be a great opportunity to use the community
sprint to get i.segment from the addons to trunk. What do you think ?


I would prefer i.segment.xl for speed reasons and memory control, but
the shape functionality in i.segment would need to be ported to
i.segment.xl first.


I meant i.segment in a global sens, not distinguishing .xl, so that's 
perfectly fine with me.


Eric, any chance for you to look at integrating your work on shapes into 
i.segment.xl ?


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

Re: [GRASS-dev] [GRASS-SVN] r54852 - grass/trunk/lib/gis/colors

[Markus Neteler]

Hi,

On Sat, Feb 2, 2013 at 11:26 PM,   wrote:
> Author: cmbarton
> Date: 2013-02-02 14:26:41 -0800 (Sat, 02 Feb 2013)
> New Revision: 54852
>
> Modified:
>grass/trunk/lib/gis/colors/srtm_plus
> Log:
> update to srtm_plus colorable
...
> +default 255:255:255

Usually there is not "default" specified, should it be there or not?

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