[GRASS5] d.what.rast & quantization

GRASS GIS GRASS GIS developer
1

Hi,

looking at d.what.rast, I see output like this:

d.what.rast

Buttons
Left: what's here
Right: quit

278786.03515625(E) 5232741.95078125(N)
elev in PERMANENT, quant (447)
elev in PERMANENT, actual (447.190521)

279031.25390625(E) 5233060.73515625(N)
elev in PERMANENT, quant (539)
elev in PERMANENT, actual (540.034363)

278700.20859375(E) 5235660.05390625(N)
elev in PERMANENT, quant (-557)
elev in PERMANENT, actual (-558.007324)

The quantization rule is not obvious to me, what's the
background to get such results?

Thanks

Markus

2

Markus,

is elev the result of v.surf.rst (or s.surf.rst)?
If yes, this seems to be rst problem - Susane Rizzolli has already reported it.
If you multiply the result by 1.0 in r.mapcalc, the quant is recomputed
and the result of query is correct.

rst calls quantize here - I did not have time to look at what quantize
actually does and why are the min and max values done like this,
rst was updated for FP support while FP support was still under development
so quant might have changed and this is now producing wrong result.
G_quantize_fp_map_range (params->elev, mapset,
                              (DCELL) zminac - 0.5, (DCELL) zmaxac + 0.5,
                            (CELL) (zminac - 0.5), (CELL) (zmaxac + 0.5));
It might have been there for years, but nobody is probably using the quant result,
so there were no compliants

Helena

Markus Neteler wrote:

Hi,

looking at d.what.rast, I see output like this:

d.what.rast

Buttons
Left: what's here
Right: quit

278786.03515625(E) 5232741.95078125(N)
elev in PERMANENT, quant (447)
elev in PERMANENT, actual (447.190521)

279031.25390625(E) 5233060.73515625(N)
elev in PERMANENT, quant (539)
elev in PERMANENT, actual (540.034363)

278700.20859375(E) 5235660.05390625(N)
elev in PERMANENT, quant (-557)
elev in PERMANENT, actual (-558.007324)

The quantization rule is not obvious to me, what's the
background to get such results?

Thanks

Markus

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

3

On Sun, Feb 27, 2005 at 05:19:50PM -0500, Helena wrote:

Markus,

is elev the result of v.surf.rst (or s.surf.rst)?
If yes, this seems to be rst problem - Susane Rizzolli has already reported
it.

Ah, didn't know that. Yes, it's v.surf.rst from current CVS.
Thanks for your quick reply.

If you multiply the result by 1.0 in r.mapcalc, the quant is recomputed
and the result of query is correct.

rst calls quantize here - I did not have time to look at what quantize
actually does and why are the min and max values done like this,
rst was updated for FP support while FP support was still under development
so quant might have changed and this is now producing wrong result.
G_quantize_fp_map_range (params->elev, mapset,
                             (DCELL) zminac - 0.5, (DCELL) zmaxac + 0.5,
                           (CELL) (zminac - 0.5), (CELL) (zmaxac + 0.5));
It might have been there for years, but nobody is probably using the quant
result, so there were no compliants

Would be nice to get it fixed. Maybe Glynn with his insights has
a suggestion?

Markus

Helena

Markus Neteler wrote:
>Hi,
>
>looking at d.what.rast, I see output like this:
>
>d.what.rast
>
>Buttons
> Left: what's here
> Right: quit
>
>278786.03515625(E) 5232741.95078125(N)
>elev in PERMANENT, quant (447)
>elev in PERMANENT, actual (447.190521)
>
>279031.25390625(E) 5233060.73515625(N)
>elev in 5(E) 5232741.95078125(N)
>elev in PERMANENT, quant (447)
>elev in PERMANENT, actual (447.190521)
>
>279031.25390625(E) 5233060.73515625(N)
>elev in PERMANENT, quant (539)
>elev in PERMANENT, actual (540.034363)
>
>278700.20859375(E) 5235660.05390625(N)
>elev in PERMANENT, quant (-557)
>elev in PERMANENT, actual (-558.007324)
>
>The quantization rule is not obvious to me, what's the
>background to get such results?
>
>Thanks
>

4

I have been testing nviz using grass6 updated today and I noticed few problems:

- label and legend do not redraw, Bob, are you around to check that, it used to work
- nviz does not load vector points when given on command line or when called
   from GIS manager - it gives error "no lines fileneame found...."
   it is possible to load the points in nviz through "vector points" panel,
   so it is not critical, but it may be confusing to users.
- the mkdspf pannel should be removed - it does nothing

Helena

5

Hi Helena,

I took a quick look at grass6.0 / nviz. It appears that in visulaization/nviz/src/draw.c "GS_draw_all_list();" has been commented out. This is found in the function "Ndraw_all_cmd". The legend, labels, and North Arrow are all handled by this function. If you un-comment it, The above features should be automatically re-drawn.

--
Bob

Helena wrote:

I have been testing nviz using grass6 updated today and I noticed few problems:

- label and legend do not redraw, Bob, are you around to check that, it used to work
- nviz does not load vector points when given on command line or when called
  from GIS manager - it gives error "no lines fileneame found...."
  it is possible to load the points in nviz through "vector points" panel,
  so it is not critical, but it may be confusing to users.
- the mkdspf pannel should be removed - it does nothing

Helena

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

6

Bob Covill wrote:

Hi Helena,

I took a quick look at grass6.0 / nviz. It appears that in visulaization/nviz/src/draw.c "GS_draw_all_list();" has been commented out. This is found in the function "Ndraw_all_cmd". The legend, labels, and North Arrow are all handled by this function. If you un-comment it, The above features should be automatically re-drawn.

yes, that fixed it!
Can you please submit the change to CVS so that it is fixed
in the release too?

thank you,

Helena

--
Bob

Helena wrote:

I have been testing nviz using grass6 updated today and I noticed few problems:

- label and legend do not redraw, Bob, are you around to check that, it used to work
- nviz does not load vector points when given on command line or when called
  from GIS manager - it gives error "no lines fileneame found...."
  it is possible to load the points in nviz through "vector points" panel,
  so it is not critical, but it may be confusing to users.
- the mkdspf pannel should be removed - it does nothing

Helena

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

7

On Sun, 27 Feb 2005, Markus Neteler wrote:

On Sun, Feb 27, 2005 at 05:19:50PM -0500, Helena wrote:
> Markus,
>
> is elev the result of v.surf.rst (or s.surf.rst)?
> If yes, this seems to be rst problem - Susane Rizzolli has already reported
> it.

Ah, didn't know that. Yes, it's v.surf.rst from current CVS.
Thanks for your quick reply.

> If you multiply the result by 1.0 in r.mapcalc, the quant is recomputed
> and the result of query is correct.
>
> rst calls quantize here - I did not have time to look at what quantize
> actually does and why are the min and max values done like this,
> rst was updated for FP support while FP support was still under development
> so quant might have changed and this is now producing wrong result.
> G_quantize_fp_map_range (params->elev, mapset,
> (DCELL) zminac - 0.5, (DCELL) zmaxac + 0.5,
> (CELL) (zminac - 0.5), (CELL) (zmaxac + 0.5));
> It might have been there for years, but nobody is probably using the quant
> result, so there were no compliants

Would be nice to get it fixed. Maybe Glynn with his insights has
a suggestion?

There is code in src/rastput.c (after line 160) and R/rast.put.R (after
line 39) in the R GRASS package that puts quantization in place for layers
being written to GRASS. The default is to use about 20 "pretty" intervals,
but other schemes can be imposed by the user. I seem to remember that
setting it up was not as simple as I had expected. Getting the colours and
interval labels right seemed to matter - since nobody has complained since
2003, I guess it isn't too badly broken (on 5.4).

Roger

Markus

> Helena
>
>
> Markus Neteler wrote:
> >Hi,
> >
> >looking at d.what.rast, I see output like this:
> >
> >d.what.rast
> >
> >Buttons
> > Left: what's here
> > Right: quit
> >
> >278786.03515625(E) 5232741.95078125(N)
> >elev in PERMANENT, quant (447)
> >elev in PERMANENT, actual (447.190521)
> >
> >279031.25390625(E) 5233060.73515625(N)
> >elev in 5(E) 5232741.95078125(N)
> >elev in PERMANENT, quant (447)
> >elev in PERMANENT, actual (447.190521)
> >
> >279031.25390625(E) 5233060.73515625(N)
> >elev in PERMANENT, quant (539)
> >elev in PERMANENT, actual (540.034363)
> >
> >278700.20859375(E) 5235660.05390625(N)
> >elev in PERMANENT, quant (-557)
> >elev in PERMANENT, actual (-558.007324)
> >
> >The quantization rule is not obvious to me, what's the
> >background to get such results?
> >
> >Thanks
> >

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no

8

On Sun, Feb 27, 2005 at 08:17:13PM -0400, Bob Covill wrote:

Hi Helena,

I took a quick look at grass6.0 / nviz. It appears that in
visulaization/nviz/src/draw.c "GS_draw_all_list();" has been commented
out. This is found in the function "Ndraw_all_cmd". The legend, labels,
and North Arrow are all handled by this function. If you un-comment it,
The above features should be automatically re-drawn.

Thanks for the quick help, I have uncommented the function in CVS.
Please test...

Markus

--
Bob

Helena wrote:
>I have been testing nviz using grass6 updated today and I noticed few
>problems:
>
>- label and legend do not redraw, Bob, are you around to check that, it
>used to work
>- nviz does not load vector points when given on command line or when
>called
> from GIS manager - it gives error "no lines fileneame found...."
> it is possible to load the points in nviz through "vector points" panel,
> so it is not critical, but it may be confusing to users.
>- the mkdspf pannel should be removed - it does nothing
>
>Helena
>
>
>
>
>_______________________________________________
>grass5 mailing list
>grass5@grass.itc.it
>http://grass.itc.it/mailman/listinfo/grass5
>
>

--
Markus Neteler <neteler itc it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

9

On Sun, Feb 27, 2005 at 05:19:50PM -0500, Helena wrote:

Markus,

is elev the result of v.surf.rst (or s.surf.rst)?
If yes, this seems to be rst problem - Susane Rizzolli has already reported
it.
If you multiply the result by 1.0 in r.mapcalc, the quant is recomputed
and the result of query is correct.

rst calls quantize here - I did not have time to look at what quantize
actually does and why are the min and max values done like this,
rst was updated for FP support while FP support was still under development
so quant might have changed and this is now producing wrong result.
G_quantize_fp_map_range (params->elev, mapset,
                             (DCELL) zminac - 0.5, (DCELL) zmaxac + 0.5,
                           (CELL) (zminac - 0.5), (CELL) (zmaxac + 0.5));
It might have been there for years, but nobody is probably using the quant
result, so there were no compliants

Helena,

I tried to remove these 0.5 offsets, also commented the entire function call.
The results are still as indicated below (so the G_quantize_fp_map_range does
nothing?). Maybe we are looking in the wrong place?

Markus

Markus Neteler wrote:
>Hi,
>
>looking at d.what.rast, I see output like this:
>
>d.what.rast
>
>Buttons
> Left: what's here
> Right: quit
>
>278786.03515625(E) 5232741.95078125(N)
>elev in PERMANENT, quant (447)
>elev in PERMANENT, actual (447.190521)
>
>279031.25390625(E) 5233060.73515625(N)
>elev in PERMANENT, quant (539)
>elev in PERMANENT, actual (540.034363)
>
>278700.20859375(E) 5235660.05390625(N)
>elev in PERMANENT, quant (-557)
>elev in PERMANENT, actual (-558.007324)
>
>The quantization rule is not obvious to me, what's the
>background to get such results?
>
>Thanks
>
> Markus
>
>_______________________________________________
>grass5 mailing list
>grass5@grass.itc.it
>http://grass.itc.it/mailman/listinfo/grass5

10

On Sun, Feb 27, 2005 at 06:00:55PM -0500, Helena wrote:

I have been testing nviz using grass6 updated today and I noticed few
problems:

- label and legend do not redraw, Bob, are you around to check that, it
used to work

solved.

- nviz does not load vector points when given on command line or when called
  from GIS manager - it gives error "no lines fileneame found...."
  it is possible to load the points in nviz through "vector points" panel,
  so it is not critical, but it may be confusing to users.

Probably we have to have two parameters to load vector maps on CMD line?

- the mkdspf pannel should be removed - it does nothing

I have removed it, but don't know if I have to modify
scripts/tclIndex
as well. Please suggest (or, better fix directly in CVS).

Then, what about
src/mkdspf_iso_surface.c
src/mkdspf_main.c

? To be removed as well?

Markus