lnam_refs is truncated when converting from S57 data with ogr2ogr

[boatbeacon]

We are using the following command to convert from NOAA S57 ENC data to MySql using gdal-1.9.2 (same error on gdal-1.9.1)

ogr2ogr -gt 1024 -skipfailures -f MySQL MySQL:US5CA13M,host=localhost,user=auser,password=apasswrod US5CA13M.000 -append -lco SPATIAL_INDEX=YES BCNLAT

The conversion completes with the bcnlat table created and populated in MySql but the lnam_refs field (TEXT) is truncated to 16 Chars. I have logged the MySql queries from ogr2ogr and the Insert statement is the culprit - the lnam_refs field has been truncated to 16 characters '(2:02260FB4D3871' . It should have been something like '(2:02260FB5030B12D4,02260FB5030B12C6)' - e.g. a String list with two entries.

here is one of the queries from the log:-

INSERT INTO bcnlat (SHAPE , rcid, prim, grup, objl , rver, agen, fidn, fids, lnam, lnam_refs, ffpt_rind, bcnshp, catlam, colour, objnam, status, inform, scamin, sordat, sorind) VALUES (GeometryFromText('POINT (-122. 3853339 37.7784136)',1) , 14, 1, 2, 7, 1, 550, 263521035, 4835, '02260FB5030B12E3', '(2:02260FB4D3 871', '(2:2,2)', 5, 1, '4', 'South Beach Harbor South Entrance Light 1', '8', 'On breakwater', 119 999, '20010604', 'US,US,graph,Chart 18650')

The source data file US5CA15M.000 is too large to attach - it is available via ​http://epdemo.com/US5CA15M.000 . This problem is not specific to this file, it is found on all the NOAA S47 ENC translations we are performing.

I notice in that there was a similar bug http://trac.osgeo.org/gdal/ticket/681 from many years ago that was closed. The lnam_refs string in that bug report shows the same lnam_refs field truncation as we are seeing .

[warmerdam]

I believe the fundamental problem is that the MySQL OGR driver does not have handling for "string list" feature attributes so OGR autotranslates the field to a simple string which will inherently trucate long lists. Furthermore, it appears you are suffering from a small default size for text fields that don't have an explicit size which is further truncating things to 16 characters. So the work to be done would be in the MySQL driver.

Hmm, looking in the code unsupported fields, like string lists, are created as type "TEXT" which I'm getting the impression is supposed to be variable length so I'm not sure why things are getting truncated so much. I'm guessing '(2:02260FB4D3 871' is the field in question. Normally I would expect long string lists to get truncated around 72 characters and to end with "..." indicating incompleteness.

I don't have MySQL setup handily so I'm not likely to work on this issue in the short term.

[warmerdam]

Clearing milestone, unless there is someone willing to commit to doing the work.

[Even Rouault]

This is duplicate of #4951 that has been just fixed