"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 didnt 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 dont 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:[email protected]] Sent: 2009-04-19 4:24 AM To: [email protected] 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 part of a mapserver installation. > > 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
