Hello,
now, for Layer.GetName() I need to use:
Encoding.UTF8.GetString(Encoding.Default.GetBytes(layer.GetName()));
to have correct characters.
Is it a subject of this issue?
Ivo.
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-GDAL-OGR-C-wrapper-and-UTF8
Hi Frank,
it’s nice to hear that the intention/plan is to have a consistent encoding
for all strings.
When I did my own C# wraps of the C API to circumvent the problem with the
current C# wrapper I did some experimenting.
Although you wouldn't normally have any non ASCII characters in WKT strings
On Wed, Apr 3, 2013 at 12:54 PM, Tamas Szekeres wrote:
> Frank,
>
> We seem to consider only a subset of the parameters (filenames and fileds)
> that should be utf8 encoded. But it seems that's not enough. For example
> treating fields as utf8 would also require to modify SetAttibuteFilter to
> p
s. It simplifies logic
>> greatly.
>>
>> If the underlying data store is using Windows-1252 encoding internally,
>> that
>> should be handled and abstracted out by the driver itself (by doing the
>> conversions into utf8), not the bindings.
>>
>> My two
indows-1252 encoding internally,
> that
> should be handled and abstracted out by the driver itself (by doing the
> conversions into utf8), not the bindings.
>
> My two cents,
>
> - Ragi
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.n6.nabbl
bstracted out by the driver itself (by doing the
conversions into utf8), not the bindings.
My two cents,
- Ragi
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/gdal-dev-GDAL-OGR-C-wrapper-and-UTF8-tp5044028p5044395.html
Sent from the GDAL - Dev mailing list a
Tamas,
If you don't mind me asking, what exactly is your plan?
Are you planning to just fix the methods related to setting and getting of
feature string attributes or are you planning to use UTF8 encoding for other
methods too?
This is a very delicate problem, because if we assume that an unmana
That would great Tamas, Thanks.
And Thanks to Ragi for you input.
I had a look at you workaround, but I think your ghetto fix is not quite correct.
The C# wrapper interprets the unmanaged string as being ANSI encoded, which changes the bytes of the string when converting from ANSI to UTF16 an
> --
> View this message in context:
> http://osgeo-org.1560.n6.nabble.com/gdal-dev-GDAL-OGR-C-wrapper-and-UTF8-tp5044028p5044112.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-de
the
ticket and I would happy to elaborate more if needed.
- Ragi
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/gdal-dev-GDAL-OGR-C-wrapper-and-UTF8-tp5044028p5044112.html
Sent from the GDAL - Dev mailing list archive at Nabble.
Thanks for the quick reply.
Let's back up a bit. Just take the following two methods of the Feature class
in the OGR wrapper:
public string GetFieldAsString(int id);
public void SetField(int id, string value);
For these two the wrapper also uses no special encoding, which means that ANSI
is use
2013/4/2 Dennis Gocke
> Hi,
>
> I have a few questions regarding the C# wrapper and UTF8 encoded strings.
>
>
> This is mostly an issue when working with OGR. If I understand correctly
> strings are supposed to be encoded in UTF8 internally. Some drivers might
> not follow that rule, but most do,
Hi,
I have a few questions regarding the C# wrapper and UTF8 encoded strings.
This is mostly an issue when working with OGR. If I understand correctly
strings are supposed to be encoded in UTF8 internally. Some drivers might not
follow that rule, but most do, is that correct?
The problem tha
13 matches
Mail list logo
