thank Even, I convert the string in utf8 and then dump the feature to gdb,
then there is no messy code, all chinese character is right. thank you very
much !
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/how-to-set-filegdb-encoding-tp5180296p5180303.html
Sent from the
the dirver of shp file in ogr can support chinese character by setting
CPLSetConfigOption(SHAPE_ENCODING,);
how to set encoding about filegdb dirver to support chinese character.
now all the chinese character in the attribute field is messy code.
--
View this message in context:
Le mercredi 07 janvier 2015 09:41:35, wxx a écrit :
the dirver of shp file in ogr can support chinese character by setting
CPLSetConfigOption(SHAPE_ENCODING,);
how to set encoding about filegdb dirver to support chinese character.
now all the chinese character in the attribute field is messy
I created a gdb with filegdab api in gdal, then create an ogrlayer int gdb
by function CreateLayer(newlayername,spatial,geotype,option),
the thrid parameter geotype=wkbLinestring, after created the layer, I
get the layer geometry type by function layerGeoType=pLayer-getgeomtype();
but the
Le mercredi 07 janvier 2015 11:35:14, Rebecca a écrit :
I created a gdb with filegdab api in gdal, then create an ogrlayer int gdb
by function CreateLayer(newlayername,spatial,geotype,option),
the thrid parameter geotype=wkbLinestring, after created the layer, I
get the layer geometry type
I'm trying the C# bindings but keep running into problems.
I've made the sample project explained here:
http://vipassanaandenvironmentalinformatics.blogspot.nl/2013/03/getting-started-with-c-and-gdal.html
But when calling Gdal.AllRegister(); I get an exception saying it can't
find gdal_warp.dll.
Found the solution myself.
When I add the location of gdal as first to my path environment it is
working. So it seems my path is not correctly set for PInvoke.
It is working now.
I'm now working on getting my C# application run on Ubuntu with MONO. Also
a very interesting challenge ;)
Paul
I get ogrlayer from fielgdb , when I try to get the field information such as
field name, field width, field type, I found the field name and field type
is right , but field width is zero when the field type is OFTString.
Does the filegdb lost the field width information in gdal-filegdb?
Hi Mike
Thanks! That ticket is very insightful.
I'm not sure though if there is already an agreement there about the
best solution inside OGR code.
In the meantime: Am I correct that there's an immediate solution by
defining an query against table DipCategories of a FileGDB file with
ogr2ogr
OGR cannot create the PCIDSK polygon vector data, Found in the GDAL library
code is not achieved, I realize part of the code, surface vector data can
create PCIDSK type.
The modified code is as follows[ogrpcidsklayer.cpp file OGRErr
OGRPCIDSKLayer::SetFeature( OGRFeature *poFeature )]:
Le mercredi 07 janvier 2015 16:20:46, Stefan Keller a écrit :
Hi Mike
Thanks! That ticket is very insightful.
I'm not sure though if there is already an agreement there about the
best solution inside OGR code.
In the meantime: Am I correct that there's an immediate solution by
defining
2015-01-07 16:39 GMT+01:00 Even Rouault even.roua...@spatialys.com:
Hum I don't think so.
Ok. And what about accessing it with Python GDAL/OGR API?
--S.
P.S.
Anyway interesting small enhancement to potentially sponsor.
Right. Perhaps Esri could step in ;-)
2015-01-07 16:39 GMT+01:00 Even
Schmid,
If you file a ticket against libgeotiff (http://trac.osgeo.org/geotiff/)
capturing the details of the above discussion, I'll review and consider
reapplying the override.
I haven't looked into this issue in detail yet, but I'm concerned you want
to apply a particular transform to CH1903+
Even,
Thank you a lot for digging so deep. It seems indeed quite tricky.
I'm not sure if the intent was really to change the override with the
refactoring or if it is more or less accidental
I also realized that it was during a refactoring that this (and other)
overrides were removed. So I
14 matches
Mail list logo
