I see that now in code. I added my own wrapper to parse the list, but there are two issues remaining: 1) efficiency - if a field must be read multiple times, string will have to be parsed multiple times, whereas if it were treated as integer list from the start, string parsing would be done once. This may not be much, but it adds up when thousands of features are processed. 2) it is impossible to define default behavior for integer list fields, because they self-identify as strings - i.e. even if I were to parse it in my code (which I do now), I have to know from another source whether the field is an integer list.
May be it coud be done as an option, controlled by flag to a class registrar (and default behavior be made as it was previously)? Frank Warmerdam wrote: > > Dear OGR User, > > It appears the S57 code deliberately treats list attributes as simple > strings. While this may have been a poor choice, I hesitate to change it > at this point for fear of breaking fragile software built on this driver > (notably the FME S-57 reader). > > My suggestion is that you fetch it as a string, and parse the integers > out yourself. > > Best regards, _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
