OGRFeature::GetFieldAsString default formatting problem

[szekerest@…]

OGRFeature::GetFieldAsString default formatting behaviour should be
reconsidered, since the current implementation results ugly string
representations for floating point values.

For example if the field width is 19 and the field precision is 9 (controlled by
the data source) and the field value is 23.0 the function returns 

"       23.000000000" 

instead of 

23

Formatting strings for numeric values should rather rely on the deafult
formatting specifications like "%g" for floats.

This problem is classified as crucial since Mapserver highly relies on this
issue when labelling features with their attributes. There is no chance to
change this behaviour from the Mapserver side till now. 


Tamas Szekeres

[warmerdam]

Tamas, 

I don't think the right solution is to add complication to 
GetFieldAsString().  Instead, I think mapogr.cpp should explicitly
format the numeric values itself rather than depend on the generic
GetFieldAsString() method.  

I'm going to close this bug here, but encourage you to open a
corresponding bug in the MapServer bugzilla. 

BTW, what rules are used for formatting numbers in other data
providers for MapServer? 

[szekerest@…]

Frank,

Actually what's the use of formatting floats with explicit size and precision, i
think it is more "complicated" than simply using the default formatting like %g.

Even the code could be more simple by commenting out (ogrfeature.cpp ln 1014,
1060) like:

/*if( poFDefn->GetWidth() != 0 )
        {
            sprintf( szFormat, "%%%d.%df",
                     poFDefn->GetWidth(), poFDefn->GetPrecision() );
        }
        else*/
            strcpy( szFormat, "%.16g" );

It would be a big deal to review the other providers, but for example sde uses
double2string, as

(mapstring.c ln 199)
char *double2string(double value) {
  char buffer[256]; /* plenty of space */

  sprintf(buffer, "%g", value);
  return(strdup(buffer));
}

The bug report targeting this issue has already exist at the Mapserver side:

http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1634

Steve is getting to grips with it.

It seems to be a makeshift to reparse and reformat an already formatted string
representation at the Mapserver side. It would be more convenient to pass it as
a numeric value.

Tamas