> > > For the write part, a OGRSFDriver::GetSupportedEncodings() and > > OGRLayer::SetEncoding() could make sense (for the later, if it must be > > exposed at the datasource or layer level is an open point and a slight > > difference between yours and Gaige's approach) > > Is there a need for a per-layer approach to this? I've yet to see a > format that allowed different encodings in different layers. Although, > thinking about it, it might be a problem using some of the virtual data > sets, since they hide some of this.
Actually, I'm not confident that a standalone SetEncoding() method is appropriate. This should rather be an extra parameter (or a "stantardized" creation option) of CreateDataSource() , as drivers will often need that information at the very beginning to write the appropriate header (for example the encoding of a XML file) and you cannot sanely change encoding in the middle of writing a file... Also, when you create a non UTF-8 datasource, - is the data passed to the driver already encoded in the target encoding (a) - or is it in UTF-8 (b) and the driver is responsible to convert it to the target encoding. Approach (a) gives strong predictibility of which bytes go to the file and enable the user to control how he wants the data to be degraded. But the downside of it is is that it would lead to a weird behaviour for read/write datasources. When you read, you'd get data in UTF-8 (AFAIK all encodings can be losslessly transcoded to UTF-8. Correct me if I'm wrong), but when you write you pass it in encoding XXXX ... _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev