> Markus Neteler <[EMAIL PROTECTED]>: > > 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 _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
