[mapserver-dev] Re: [gdal-dev] Padding/spacing in mysql driveroutput

[Steve Lime]

Removing the padding would be consistent with the other drivers in
MapServer. I 
know the Xbase code removes all leading (and trailing) white space
regardless of
type. I'd file this as a bug and assign to the OGR component.

Steve

>>> Even Rouault <even.rouault at mines-paris.org> 04/21/09 1:35 PM >>>
CC'ing mapserver-dev as it is one potential place where this behaviour
could 
be changed.

After discussing this subject with Frank, it appears that the left
padding was 
added so that column oriented reports would line up nicely.
We are a bit shy to change this behaviour now in GDAL as some
applications may 
rely on it for pretty formatting.

For your use case, one solution would be to do the stripping in
mapserver 
itself (in mapogr.cpp). Currently it calls the OGR_F_GetFieldAsString(),

which is the function that adds the left padding for numeric fields with
a 
non zero width. A solution would be that mapserver checks the type of
the 
field, and if it is numeric (OFT_Integer or OFT_Real), it removes any
leading 
whitespace.

Le Sunday 19 April 2009 11:39:49 P.Romero, vous avez écrit :
>  "If you look at the first lines of your ogrinfo dump, you'll see that
the
> fields with left padding are declared in the form :
> lat: Real(22.0)"
>
> - Where is this information? I didn’t see it; How can I access it?
>
> "One possible workaround is that you change your MySQL table
definitions so
> that the columns are not of the form double(x,y) but just double."
>
> - AFAIK, I never set a precision value for double fields when the
tables
> were created; they were created simply as 'double'. I'll need to
> double-check this, but I honestly don’t believe that I set the
precision;
> perhaps MySQL defaults to '22' as the field size for doubles? I'll
need to
> look into this. Im hoping that I will, in fact, be able to adjust this
> within MySQL...
>
> I cant see any usefulness in this behavior; perhaps it would be worth
> considering as a 'feature request' to eliminate this extra spacing in
a
> future release?
>
> Thanks again for the help,
> P.Romero
> -----Original Message-----
> From: Even Rouault [mailto:even.rouault at mines-paris.org]
> Sent: 2009-04-19 4:24 AM
> To: gdal-dev at lists.osgeo.org
> Cc: P.Romero; Frank Warmerdam
> Subject: Re: [gdal-dev] Padding/spacing in mysql driver output
>
> Hi,
>
> this behaviour is not specific to the MySQL driver. When a field has a
> specified width and precision, it will get formatted according to it.
This
> behaviour was specifically introduced 10 years ago ! :
> http://trac.osgeo.org/gdal/changeset/745. So it looks like a behaviour
by
> design, although I'm not clear on its justification. Maybe Frank will
> remember ?
>
> If you look at the first lines of your ogrinfo dump, you'll see that
the
> fields with left padding are declared in the form :
> lat: Real(22.0)
>
> One possible workaround is that you change your MySQL table
definitions so
> that the columns are not of the form double(x,y) but just double.
>
> Another one, quite inelegant and possibly not performing well, is to
embed
> the content of your ovf file into another ovf file and use the CAST
> operator of OGR SQL (see http://gdal.org/ogr/ogr_sql.html)
>
> For example:
>
> <OGRVRTDataSource>
>     <OGRVRTLayer name="poly">
>         <SrcDataSource> <!-- here put your original OVF file, but
> XML-escaped -->
>             <OGRVRTDataSource>
>                 <OGRVRTLayer name="poly">
>                     <SrcDataSource>MYSQL:even</SrcDataSource>
>                     <SrcSQL>SELECT area FROM poly</SrcSQL>
>                 </OGRVRTLayer>
>             </OGRVRTDataSource>
>         </SrcDataSource>
> 	<!-- here cast every double field as float(1) -->
>         <SrcSQL>SELECT CAST(area as float(1)) FROM poly</SrcSQL>
>     </OGRVRTLayer>
> </OGRVRTDataSource>
>
> Best regards,
> Even
>
> Le Sunday 19 April 2009 09:32:31 P.Romero, vous avez écrit :
> > Hi,
> > Im new to this list.
> > I use ogr w/ the mysql driver as p> > Im having an issue with the formatting of numeric results that are
> > being returned from a mysql query.
> > It appears that values originating from 'double'-typed fields in the
> > MySQL database are showing up in ogr's output with a large amount of
> > 'blank space' left-padding.
> >
> > Here's an example of some output from running "ogrinfo -al
> > 'myQueryFile.ovf'":
> >
> > OGRFeature(mypoints):86
> >   max(recTS) (Integer) = 1240078380
> >   buoyName (String) = 51202
> >   lat (Real) =                     21
> >   lon (Real) =                   -158
> >   MAG (Real) =                    -371
> >   WDIR (Real) =                    -99
> >   WSPD (Real) =                    -99
> >   ADIR (Real) =                      81
> >   ts (DateTime) = 2009/04/04  0:43:00
> >   POINT (-157.680000000000007 21.420000000000002 0)
> >
> > In case my hotmail account mangles the above output, here is a
> > description of what is occuring:
> > Any value with a datatype of 'Real' (i.e., 'double' in MySQL) is
> > appearing with approx. 20 spaces of left-padding. However, other
> > datatypes are not showing this large padding.
> >
> > The extra spacing is also showing up in my mapserver ogr/mysql query
> > output; its unnecessary, unwanted, & unacceptable, so Id like to
remove
>
> it.
>
> > Is this spacing a bug, or by design?
> > How can I go about removing it from ogr's query results?
> >
> > Thanks in advance,
> > P.Romero
> >
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev


_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-dev