[mapserver-dev] Re: [gdal-dev] Padding/spacing in mysql
driveroutput
Even Rouault
even.rouault at mines-paris.org
Wed Apr 22 14:15:50 EDT 2009
Done as #2985. Patch attached
Le Wednesday 22 April 2009 16:52:48 Steve Lime, vous avez écrit :
> 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
More information about the mapserver-dev
mailing list