[GRASS-dev] Re: [GRASS GIS] #72: PNG driver: boundary rendering is off by one pixel

2008-12-04 Thread GRASS GIS 
#72: PNG driver: boundary rendering is off by one pixel
--+-
  Reporter:  hamish   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  blocker  |   Milestone:  6.4.0
 Component:  default  | Version:  svn-develbranch6 
Resolution:   |Keywords:  d.vect, rendering, PNG_DRIVER
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Comment (by hamish):

 ... another thing I noticed in those screenshots is that 'd.text size=5'
 (percent) is different between 6.3.0 and 6.4svn for the same frame size.
 shrug.

 and of course width=2 covers up minor sins.


 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #72: PNG driver: boundary rendering is off by one pixel

2008-12-04 Thread GRASS GIS 
#72: PNG driver: boundary rendering is off by one pixel
--+-
  Reporter:  hamish   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  blocker  |   Milestone:  6.4.0
 Component:  default  | Version:  svn-develbranch6 
Resolution:   |Keywords:  d.vect, rendering, PNG_DRIVER
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Comment (by hamish):

 Replying to [comment:14 hamish]:
 > I ran some 'd.vect rend=' tests with the latest 6.4svn
 > (w/ Polygon.c commit). screenshots & scripts here:
 >   http://bambi/hamish/grass/bugs/d.vect/dec2008/

 ahem,

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


 'd.vect rend=g' seems to work ok with the PNG driver, due to thicker lines
 which cover up any gaps (trade one problem for another).


 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #72: PNG driver: boundary rendering is off by one pixel

2008-12-04 Thread GRASS GIS 
#72: PNG driver: boundary rendering is off by one pixel
--+-
  Reporter:  hamish   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  blocker  |   Milestone:  6.4.0
 Component:  default  | Version:  svn-develbranch6 
Resolution:   |Keywords:  d.vect, rendering, PNG_DRIVER
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Comment (by hamish):

 Replying to [comment:13 glynn]:
 > If you want quality, I would expect both the cairo and PS drivers
 > to produce better results overall than either PNG or XDRIVER.

 both are less WYSIWYG. Cairo thickens and antialiases lines, and PS driver
 in 6.4 is limited by 6.4, and needs to be passed through pstoimg or
 ghostscript to get the web/presentation image which has its own
 rasterization quirks.

 > You might also run into problems with the distinction between
 > polylines and multiple line segments (caps versus joins) being
 > visible.

 unrelated, but ps.map's region box command has that problem,
 obvious once you set the width a bit wider.



 I ran some 'd.vect rend=' tests with the latest 6.4svn (w/ Polygon.c
 commit). screenshots & scripts here:
  http://bambi/hamish/grass/bugs/d.vect/dec2008/

 {{{
 results for render mode trials 5 Dec 2008

 coastline
 =

 6.3.0
 -
 xdriver:   R, C perfect; G near perfect; D, L off (x+y)
 pngdriver: R, C off (x); G perfect; D off (y); L off(x+y)


 6.4.svn 20081205 (with Polygon.c patch)
 ---
 xdriver:   R, C, G perfect; D, L off (x+y)
 pngdriver: R, C off (x); G perfect; D, L off (x)
 gis.m: off (x)

 inter-version
 -
 xdriver-   results mostly unchanged (fixed 1 pixel in G)
 pngdriver- D,L slightly improved



 boxes
 =
 6.4svn xdriver: D, L off (x+y)
 6.4svn png driver: all look good.
 6.4svn gis.m: looks good
 }}}


 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #388: *.tcl installed as executable

2008-12-04 Thread GRASS GIS 
#388: *.tcl installed as executable
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  closed   
  Priority:  minor |   Milestone:  6.4.0
 Component:  Installation  | Version:  svn-develbranch6 
Resolution:  fixed |Keywords:  build install
  Platform:  Linux | Cpu:  Unspecified  
---+
Changes (by hamish):

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

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

[GRASS-dev] Re: [GRASS GIS] #388: *.tcl installed as executable

2008-12-04 Thread GRASS GIS 
#388: *.tcl installed as executable
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  minor |   Milestone:  6.4.0
 Component:  Installation  | Version:  svn-develbranch6 
Resolution:|Keywords:  build install
  Platform:  Linux | Cpu:  Unspecified  
---+
Comment (by hamish):

 Replying to [comment:1 glynn]:
 > I've changed gis.m/Makefile from $(INSTALL) to $(INSTALL_DATA)
 > in r34721. tksys.tcl is an executable script, so I explicitly
 > added execute permission for that file.

 thanks.


 > d.m would need something similar, if we're going to keep it.
 > Is there any reason to?

 Apparently some people prefer it. All the g.gui and init.sh stuff is set
 up to handle it well in a mixed environment; it doesn't hurt anything; and
 has taken minimal effort to maintain. So I'd say there's no reason to
 remove it.

 > Does it still work?

 yes, it works fine.


 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #388: *.tcl installed as executable

2008-12-04 Thread GRASS GIS 
#388: *.tcl installed as executable
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  minor |   Milestone:  6.4.0
 Component:  Installation  | Version:  svn-develbranch6 
Resolution:|Keywords:  build install
  Platform:  Linux | Cpu:  Unspecified  
---+
Comment (by glynn):

 Replying to [ticket:388 hamish]:

 > browsing through the Debian lintian package report for grass 6.2.3 I
 notice that the .tcl files installed in $(ETC)/dm/,gm/ are incorrectly
 given an executable bit in the file system.

 > some Makefile magic required..

 I've changed gis.m/Makefile from $(INSTALL) to $(INSTALL_DATA) in r34721.
 tksys.tcl is an executable script, so I explicitly added execute
 permission for that file.

 d.m would need something similar, if we're going to keep it. Is there any
 reason to? Does it still work?

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

[GRASS-dev] [GRASS GIS] #388: *.tcl installed as executable

2008-12-04 Thread GRASS GIS 
#388: *.tcl installed as executable
---+
 Reporter:  hamish |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect |  Status:  new  
 Priority:  minor  |   Milestone:  6.4.0
Component:  Installation   | Version:  svn-develbranch6 
 Keywords:  build install  |Platform:  Linux
  Cpu:  Unspecified|  
---+
 Hi,

 browsing through the Debian lintian package report for grass 6.2.3 I
 notice that the .tcl files installed in $(ETC)/dm/,gm/ are incorrectly
 given an executable bit in the file system.

 http://lintian.debian.org/maintainer/pkg-grass-
 [EMAIL PROTECTED]

 some Makefile magic required..


 Hamish

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

Re: [GRASS-dev] 6.4rc1

2008-12-04 Thread Hamish 
> > http://grass.osgeo.org/wiki/GRASS_6.4_Feature_Plan
> >* d.frame.split?
> >* r.colors.stddev?
> >* v.colors?
> 
> Yes, please v.colors - no opinion on the others.


I added them all.

d.frame.split: added as d.split.frame in 6.4 (only) as a replacement to
d.split. (for posterity's sake it's nice to have a more useful d.split
for xmons; didn't just expand that as option list was incompatible)
Curious about a grass 7 version using python and FRAME enviro var, but
I don't know much about either of those yet.

r.colors.stddev: the stand-out feature of this script is for differences
maps- it lets you tie the center of the colors scale at zero, even if +/-
sides are not balanced.


Hamish



  

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

[GRASS-dev] Re: [GRASS GIS] #344: TODO: move high priority incubated modules into main

2008-12-04 Thread GRASS GIS 
#344: TODO: move high priority incubated modules into main
--+-
  Reporter:  hamish   |   Owner:  grass-dev@lists.osgeo.org
  Type:  task |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  svn-develbranch6 
Resolution:   |Keywords:   
  Platform:  All  | Cpu:  All  
--+-
Comment (by hamish):

 update:

 {{{
 r.sun2, r.horizon added.
 v.buffer2, v.parallel2, v.delaunay2 added.
 r.watershed.fast merged.
 d.frame.split, r.colors.stddev, v.colors added.
 v.out.gpsbabel added.

 r.viewshed: code not ready yet?
 }}}

 TODO high priority:
  - v.out.ascii.db -> v.out.ascii C code

 TODO lower priority:
  - r.pack rewrite using method similar to r.convert (#84) + tar.gzip
  - put together a quick v.to.3d wrapper script

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