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

[Glynn Clements]

Hamish 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)

lat and lon parameters are floats, but they are given a different type
so that interactive input is parsed using G_scan_{easting,northing}
rather than sscanf("%lf").

Defaults are always parsed as floats, and lat/lon values are always
written to the PROJ_INFO file as floats, so the code to handle
defaults for lat/lon would be identical to that for float.

None of the parameters which use the other two types (bool and zone)
have defaults, so there's no need to handle those cases. If they were
to have defaults, they would need special treatment, as the zone and
the south flag are stored in the [DEFAULT_]WIND files as well as the
PROJ_INFO file.

-- 
Glynn Clements <glynn at gclements.plus.com>