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

[Hamish]

> Markus Neteler <neteler at fbk.eu>:
> > Once
> > http://trac.osgeo.org/grass/ticket/1
> > is fixed, we could release 6.3.0 officially.

I would like to wait to look more at the r.out.gdal null data issue and
the latest d.vect default render mode changes before releasing 6.3.0. 
Also it would be nice to have v.buffer finally fixed but I don't think
anyone is working on that. It's a bit embarassing to have such bugs in
a flagship module.



Martin Landa  wrote:
> it should be fixed now in trunk (since I don't know g.setproj, please
> take a look), I left the ticket open since I am not sure if we can
> uncomment ch1903 item in lib/gis/datumtransform.table.
> 
> See diff (sorry, I didn't split the patch, next time...:-)
> 
> http://trac.osgeo.org/grass/changeset/29468
> 
> @@ -455,5 +455,7 @@
>  		/* don't ask, use the default */
> 
> -		if (G_strcasecmp(desc->type, "float") == 0) {
> +		if (G_strcasecmp(desc->type, "float") == 0 ||
> +		    G_strcasecmp(desc->type, "lat") == 0 ||
> +		    G_strcasecmp(desc->type, "lon") == 0) {
>  		    sprintf(tmp_buff, "%.10f", parm->deflt);
>  		    G_set_key_value(desc->key, tmp_buff, out_proj_keys);

would you explain the logic of the fix? it is not obvious to me, but
superficially lat,lon seems outside the set of float,int. I am trying
to understand if this is a proper fix or a hack which works around a
corner case. ie it may be a fix, but is it the right one?
(nice to put such logic as comment in the code or svn commit message)


thanks,
Hamish



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping