>
> > 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
Even,
Thanks for bringing this to my attention. We're winding down a major
release here (hence my relative absence from the mailing list except as a
lurker with occasional comments), but this issue is one I wanted to revisit
this summer. Snips and comments below
On May 25, 2010, at 7:31
Even,
re use case 1) below. One instance where the raw data format might be
required is where that encoding contains characters that are not present in an
output encoding and specific action is to be taken to render such characters in
a transmittable form in the output character set.
Best
Alexander,
I'm cc'ing Gaige Paulsen as he proposed in
http://trac.osgeo.org/gdal/ticket/3403 a patch with a similar approach to
yours, that is to say provide a method at the OGRLayer level to return the
encoding.
The more I think to this issue the more I recognize that the "UTF-8 everywhere
i
Hi,
GIS-Lab community has worked on this and here is our results.
We develop a patch which add two methods GetEncoding and SetEncoding.
At this time only GetEncoding for shapefiles is realised. With this
methods programmer can get encoding programmatically. Patch
uploaded to the bugtracker: http:/
