[GRASS-dev] things to do before the 6.3.0 release

[Hamish]

[problems with d.vect render modes]

Hamish, 1 Dec 2007:
> > I have now done some more tests.  Scripts for easy comparison
> > attached.
...
> > bonus problem:
> > I am not sure what's causing the frame breakage at the bottom of the
> > "D" frame.

example:
 http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_1_PNGdriver.png

> > I would blame d.frame.quarter math but
...
> > Perhaps it is d.resize or d.save? Resizing to the same dimensions as
> > the monitor was opened with (d.resize w=800 h=900) causes it to
> > happen. ?

Glynn:
> Sorry, I don't understand. Can you clarify?

It was an error in my 'd.frame.quarter -6' script which exposed a problem
with 'd.save -a'.

I had:
   d.frame -c frame=cuatro at=33.444,66.667,50,100

(.444 instead of .333) While it should have been off by only 0.111%,
d.save rounded 33.444 to "34". The "tres" frame next to it was created
with the correct at=33.333,... but d.save rounded that to "33". So after
'd.resize w= h=' with same dims as the orig xmon; or 'd.redraw -a' (same
thing, just checked into 6.3svn); or d.out.file with the PNG driver
(effectively the same thing, all depends on d.save output) the frame was
redrawn with the lower bound at 34% not 33%.

I am not sure if the monitor's pad saves int or FP. The 'd.frame -D'
debug info suggests int (pixel?); but d.frame seems to do the partial
conversion correctly:
  d.frame -c frame=cuatro5 at=33.555,66.667,50,100
  d.frame -c frame=cuatro7 at=33.777,66.667,50,100
  d.frame -c frame=cuatro9 at=33.999,66.667,50,100

so I guess it is a premature cast to int in d.save's math converting
while pixels to percents?

As the window will normally be bigger than 100x100 it makes sense that
d.save's manufactured d.frame calls should be greater precision than %d,
probably we should use at least %.3f to preserve the exact frame
placement. (as poster sized PS/PNG driver output may be bigger than
10000x10000)




but back to the d.vect rendering trials...

H:
> > The first is with spearfish's vector streams; adjusting 'd.vect
> > width='
..
> > XDRIVER: (for r,d,l width=1 polylines render poorly, as seem in
> > original examples from quoted link at the top of this email.
> >  http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_0_Xdriver.png
> >  http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_1_Xdriver.png
> > 
> > ok so that's the tiny gaps in lines for XDRIVER polylines with
> > width=1.
G:
> I can't reproduce this.

I get it consistently with 'd.vect streams width=1', any window size,
XDRIVER.

did you try with my render_trial_width.sh script?
 http://article.gmane.org/gmane.comp.gis.grass.devel/23649

> Does it occur with the PNG driver,

No, only the XDRIVER with 'd.vect width=1'

At the above URL dir compare
 dvect_render_0_PNGdriver.png
 dvect_render_1_PNGdriver.png
 dvect_render_0_Xdriver.png
 dvect_render_1_Xdriver.png

I just tested with latest svn, it's still there.

> or with a different X server?

You mean running GRASS over 'ssh -X' from another machine?
I haven't tried that yet.


> > next problem- r,d inverse fill a small bay upon zoom in.
> > Also, "l" in XDRIVER fill is badly broken. "g" is correct in all
> > cases. (the vector map for that section of coastline available upon
> > request)
> > http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_fill_Xdriver.png
> > http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_fill_PNGdriver.png
> 
> Please specify the region, so that I can attempt to reproduce this.

Ok, I'll have to crop out that bit of my coastline map for you.
(cropping made the problem go away, I'll send you the full map off-list)


H:
> > next problem- in the PNG driver for all rendering methods but "g" the
> > boundaries and fills don't line up. It's obvious if you look with
> > xmag.
> > http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_C_and_all_but_G_xmag_PNGdriver.png
> > http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_fill_PNGdriver.png
G:
> Okay, I think I know about this. Points and line vertices need to use
> floor(), while polygon vertices need round().
..
> Done.

XDRIVER: g,r,c are now correct, d,l still don't line up. (but in slightly
different ways)

PNG driver: only 'g' lines up correctly. 'c' isn't so bad, it looks ok in
the y, but off by one in the x (boundary line 1px to the right vs fill).
[exploring with xmag]

also lines are much coarser with the PNG driver vs. very clean the
XDRIVER.

examples taken today:  (in above URL dir)
 dvect_render_19test_PNGdriver.png
 dvect_render_19test_Xdriver.png

 
> > next problem- (xdriver) g & l methods don't line up:
> >  d.vect Coast_isl type=area color=red fcolor=220:220:220 render=g
> >  d.vect Coast_isl type=area color=blue fcolor=none render=l
> >  d.grid -n 1000
> >  http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/d_vect_gl_overlay.png
> 
> render=l selects culling, not clipping. It simply discards segments
> which are entirely outside the clip window. It relies upon the
> raster-level clip window (R_set_window()) being set appropriately,
> which isn't the case for d.vect at present.

No, I mean within the region frame. In d_vect_gl_overlay.png the blue
line is different than the red line, so it does not fully overlap/obscure
the red line underneath. Which method is more spatially accurate?


H:
> > and finally- "c" still has 1 pixel of white at the top and bottom of
> > the display:
> >  http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/
G: 
> I'll look into this later.
..
> This was caused by adding a clip margin so that thick lines didn't
> extend outside of the clip region.

That seems ok now, thanks.


 
> > > g should only be used if none of the others can be made to work.
> > 
> > currently 'g' is still the only one that works properly in all cases
> > for both XDRIVER and PNG driver.
..
> > Do you have any objections to using "g" as the default for the 6.3.0
> > release? (and leaving as-is [a work in progress] in 6.3.cvs)
> 
> Yes, as it only works with the raster drivers (and may not work right
> with the cairo driver if using anti-aliasing).

how about 'c' as the default for the 6.3.0 release then?
(if PNG driver boundary/fill line-up problem can be fixed)



thanks,
Hamish