[GRASS5] Some problmes with Grass 5beta8 - d.rast, ps.map, d.what.x

tstrang tstrang at trytel.com
Thu Nov 23 20:34:21 EST 2000


Markus,

I've described a few problems I've been having that could reflect
issues with the Grass 5b8 code base. If any of these problems 
are due to procedural errors on my part please let me know.

ONE - Map production

I've been trying to import and rotate a previously orthorectified
image into a location. I am using grass5b8 compiled on a RH6.1 Linux
system with glibc-2.1.2

The process from stage 2) on was executed from tcltkgrass menus.

1) Large commercially rectified tiff format orthophoto was scaled so
   the pixel count as "distance" in the image was not much greater
   than the expected cell count once imported. Tiff converted to 24
   bit ppm using tifftopnm.

2) r.in.ppm - warning posted about colour level quantization.

3) r.support - changed header to roughly center the image in my
   location window by adding constant offsets to cell edge
   values. This way I could see that the import process worked and
   check image quality. Image imported OK with (expected) reduction in
   image quality from quantization and sampling.

4) i.group - group created with "un-rectified" orthophoto as sole file.

5) i.target - group for orthophoto chosen and target location and
   mapset picked.

6) i.points - set four ground control points, all I want to do is
   rotate the image and scale linearly - it is already an orthophoto
   against the same ground control data by a process outside GRASS.

               Analysis of control point registration

        error                      image              target
  #   col   row  target       east     north      east     north
  1   0.5  -0.2    0.5       9200.4   10363.6    9686.4   10095.3 
  2  -0.8   0.3    0.9       9430.7   10294.8    9890.0   10221.3 
  3   0.1  -0.1    0.1      10435.8   10316.1   10543.9   10988.4 
  4   0.2  -0.1    0.2       9337.5   10066.6   10000.0   10000.0 

  Overall rms error: 0.53

  BUG: Running i.points twice in a row in the same monitor created a
  permanent offset in the monitor window so that the second display of
  i.points' shifted right and down. In the first i.points session,
  this same horizontal shift showed up as partial clearing of the
  raster file selection menu before the raster was drawn, and
  manifested as a white box on the monitor obscuring the left side of
  the first (upper left) raster image. Also, the grey shadow of old
  zoom boxes begs a redraw command if not full backstore and redraw
  cycle to clean up the key raster image during a long session. This
  is why I saw the display problem, stopping and restarting i.points
  sessions simply to get a clean image. 

7) i.vpoints - ran as a check of my work so far, vector details for
   the location dropped right on top of the equivalent features in the
   imported orthophoto demonstrating the vector warping worked based
   on the POINTS file listed above.

8) i.rectify2 - selected a first order transformation and current
   region was big enough to hold the resultant image.

   Subject: i.rectify2
   ***********************************************
   Rectify [ortho.hill.ur at whole] (LOCATION a)
   into  [ortho.hill.r in whole] (LOCATION a)
   complete
   -----------------------------------------------
   1276 rows, 1316 cols (1679216 cells) completed in 1:34
   1071840.0 cells per minute  

9) r.support - headers for the "rectified" image showed reasonable
   values for the edges. Updating the stats segfaulted.

10) The region I've used for the project boundaries is 4000 by 4000,
    cell width and height is 1. The raster image should cover the
    middle 9th (ie center square of a #) for this region. Running
    d.rast for the newly rectified image, the background goes white
    until the top edge of the raster, then d.rast quietly dumps core,
    leaving the rest of the monitor default black. However, when I
    select any smaller region within the location (less than about
    540x 540) d.rast paints the correct piece of the raster image, and
    appropriate vector and sites drop on top of the image
    nicely. However, d.rast still drops core even after properly
    displaying the image. There appears to be a limit to what d.rast
    can do in scaling the image to a grass monitor of dimension 600 by
    600.

11) So I try to quietly get around this problem and get real work done
    :-) When I try to make a ps.map (new) in the hope of tileing a
    bunch of images together to get the overall image I desire with
    vector contours and sites over the raster image, all I get is the
    raster image. Without the raster I get all the other detail I
    want. Even with vector and site requests in the source file for
    ps.map, the order of execution is somewhat changed from that which
    I specify, resulting in unwanted over-drawing by lines I actually
    wanted as background to other detail.

So: What am I doing wrong? What is broken? 

A) Is d.rast broken with respect to scaling down larger raster images
into a monitor? Or is there some other problem I'm missing, presumably 
the r.support failure contributes but I don't know grass internals 
enought to sort it out.

B) Can one nail down the ps.map order of execution in any other way
than the order of the script file entries because they don't seem to
get passed through to the final product in the same sequence. This bug
severely hampers my ability to make beautiful maps with carefully 
thought out layering of information.


TWO - Querying withing tcltkgrass

I posted a request for fixing d.what.sites as it returns two identical
entries to the tcltk window, and saves them to file. A response was
made to the list that this is a feature not a bug. I cannot let this
pass as I find the behaviour of the command irksome. If I want fancy
redirection I'll build it in the command line with <>&tee etc. There is
always a nice terminal open when one runs Grass :-) To illustrate my
reason for calling this behaviour a bug I've tabulated the behaviour
of the whole d.what family as of 5b8 to show inconsistencies...


d.what.rast: 

1) Single-query-mode: Prints user-instructions and returns two unique
lines immediately on clicking with quantized and actual elevations.

2) Multi-query-mode: Prints user-instructions but then duplicates are
returned of each two line result. Every four clicks the
user-instruction repeats and also gets saved into files. 

Why not put the user-instruction stuff permanently as tcltk window
dressing as with other hints about appropriate behaviour/choices
instead of contaminating the output of a useful function forcing us to
filter off the stuff if we want to *use* the result? And no, I don't
what to run more filtering scripts than I have to :-)

d.what.vect:

1) Single-query-mode: Prints user-instructions and returns two
   lines. The top line has Northing and Easting or is it Easting and
   Northing. Vector and Site files swap the order - a little N or E
   would help me out here if standardization is impossible :-)

2) Multi-query mode: Prints user-instructions which as stated above
contaminate file - we don't need to know about mouse instructions
after the file is made :-). Shows results on click - very good for
user feedback that the routine works.

d.what.sites:

1) Single-query-mode: Fails to work and complains:  Sorry, <1> is not a
valid flag
This flag is common to the sister rast and vect commands.

2) Multi-query-mode: Prints sitefile header stuff, prints
   user-instructions, *does not* print out sites as clicked - only
   dumps them on right-click exiting the process. This is inconsistent
   with the other two commands and is not good gui :-) no feedback to
   user that the mouse is not malfunctioning.

So, this is the long version of my request for a bugfix on d.what.rast
and d.what.sites. Only d.what.rast multi-query-mode has the dubious
feature of duplicating your results to screen/file. All three
needlessly contaminate the output with gui instructions that should be
on the window as static text. d.what.sites single-query-mode is broken.

Thanks for your kind attention to my previous email.
 
Tom Strang
Conservation Scientist
Canadian Conservation Institute

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list