[GRASS-dev] Overlay grids and lines tool in gism fails to draw grid in map wi ndow

I'm having trouble getting the 'Overlay grids and lines' tool in gis.m to
draw a grid. No matter what the grid spacing is set to, or whether I choose
to draw a geographic grid or not, no grid draws.

Running the command from the CLI also falis to draw a grid:

# Geographic grid
d.grid -g size=00:00:01 origin=0,0 color=170:170:170 bordercolor=0:0:0
Segmentation fault

# UTM grid
d.grid size=2000 origin=0,0 color=170:170:170 bordercolor=0:0:0
Segmentation fault

Can anyone verify this problem? It's been persistent for weeks, despite
daliy cvs updates.

~ Eric.

Patton, Eric wrote:

# Geographic grid
d.grid -g size=00:00:01 origin=0,0 color=170:170:170 bordercolor=0:0:0
Segmentation fault

# UTM grid
d.grid size=2000 origin=0,0 color=170:170:170 bordercolor=0:0:0
Segmentation fault

Can anyone verify this problem? It's been persistent for weeks, despite
daliy cvs updates.

d.grid segfaults for me too if I use RGB triplets for color or
bordercolor. If I use names (blue, red etc.) it works.

Maciek

Patton, Eric wrote:

I'm having trouble getting the 'Overlay grids and lines' tool in gis.m to
draw a grid. No matter what the grid spacing is set to, or whether I choose
to draw a geographic grid or not, no grid draws.

Running the command from the CLI also falis to draw a grid:

# Geographic grid
d.grid -g size=00:00:01 origin=0,0 color=170:170:170 bordercolor=0:0:0 Segmentation fault

# UTM grid
d.grid size=2000 origin=0,0 color=170:170:170 bordercolor=0:0:0
Segmentation fault

Can anyone verify this problem? It's been persistent for weeks, despite
daliy cvs updates.

I can confirm the problem.

Moritz

Maciej Sieczka wrote:

Patton, Eric wrote:

# Geographic grid
d.grid -g size=00:00:01 origin=0,0 color=170:170:170 bordercolor=0:0:0 Segmentation fault

# UTM grid
d.grid size=2000 origin=0,0 color=170:170:170 bordercolor=0:0:0
Segmentation fault

Can anyone verify this problem? It's been persistent for weeks, despite
daliy cvs updates.

d.grid segfaults for me too if I use RGB triplets for color or
bordercolor. If I use names (blue, red etc.) it works.

Actually it works as long as the RGB values are 0 or 255. As soon as
they are something else it segfaults.

Moritz

Moritz Lennert wrote:

Maciej Sieczka wrote:

d.grid segfaults for me too if I use RGB triplets for color or
bordercolor. If I use names (blue, red etc.) it works.

Actually it works as long as the RGB values are 0 or 255. As soon as
they are something else it segfaults.

Hmm, for me it segfaults whatever the values, eg.:

$ d.grid size=2000 origin=0,0 bordercolor=1:1:1
Segmentation fault

Maciek

Maciej Sieczka wrote:

Moritz Lennert wrote:

> Maciej Sieczka wrote:

>> d.grid segfaults for me too if I use RGB triplets for color or
>> bordercolor. If I use names (blue, red etc.) it works.

> Actually it works as long as the RGB values are 0 or 255. As soon as
> they are something else it segfaults.

Hmm, for me it segfaults whatever the values, eg.:

$ d.grid size=2000 origin=0,0 bordercolor=1:1:1
Segmentation fault

d.grid calls D_parse_color() before calling R_open_driver(), which
won't work unless the colour is one of the predefined colours
(D_parse_color() allocates the specified colour within the driver then
returns the index of the allocated colour).

--
Glynn Clements <glynn@gclements.plus.com>

> $ d.grid size=2000 origin=0,0 bordercolor=1:1:1
> Segmentation fault

Glynn:

d.grid calls D_parse_color() before calling R_open_driver(), which
won't work unless the colour is one of the predefined colours
(D_parse_color() allocates the specified colour within the driver then
returns the index of the allocated colour).

fixed in CVS + 6.2-rel.

Hamish