Op wo 17 jul. 2019 om 17:57 schreef Even Rouault
> > I did some more investigation, and it seems like the threading is
> > indeed not the issue.
> > The issue seems to be that the geotiff library also creates proj
> > contexts and these contexts do not have
> > the search paths that are passed to
> I did some more investigation, and it seems like the threading is
> indeed not the issue.
> The issue seems to be that the geotiff library also creates proj
> contexts and these contexts do not have
> the search paths that are passed to the OSRGetProjTLSContext call.
Should be fixed per
https://
On Wed, Jul 17, 2019 at 3:14 PM Even Rouault wrote:
>
> On mercredi 17 juillet 2019 14:52:55 CEST Dirk Vanden Boer wrote:
> > After migrating to gdal 3 I'm having problems performing coordinate
> > transformations in a multi-threaded application.
> >
> > My proj.db is in a nonstandard location so
Hi
Looking at gdalinfo there is a parameter to get json output
(https://gdal.org/programs/gdalinfo.html#cmdoption-gdalinfo-json) and reading
this https://trac.osgeo.org/gdal/wiki/rfc44_gdalinfoxml it was proposed that
this would be implemented to ogrinfo as well. Looking at the docs I do not se
On mercredi 17 juillet 2019 14:52:55 CEST Dirk Vanden Boer wrote:
> After migrating to gdal 3 I'm having problems performing coordinate
> transformations in a multi-threaded application.
>
> My proj.db is in a nonstandard location so I call the
> OSRSetPROJSearchPaths once on the main thread befor
After migrating to gdal 3 I'm having problems performing coordinate
transformations in a multi-threaded application.
My proj.db is in a nonstandard location so I call the
OSRSetPROJSearchPaths once on the main thread before the call to
GDALAllRegister()
I can do coordinate transformations on my m
Hi Even,
Thanks for checking it out. I have a hard time seeing the joys of closed source
software, but I continue to be tied to it and all its frustrations.
There definitely is something going on with the SRS even though OGR reports it
as being the same:
>>> l2 = ds.GetLayerByIndex(0)
>>> p2 =
Casper,
I can reproduce. I tried a few things (including adding at hand definitions
for MOrigin, MScale, MPrecision and LatestWKID that appear in the XML
definition of the existing layer & feature dataset), but without success. It
appears this is specific to creating the layer with FEATURE_DATA
Hi all,
I am trying to create a layer in an existing feature dataset in an existing
File Geodatabase (FileGDB, not Open) using python and GDAL/OGR from OSGeo.
The layout of the FileGDB is:
MyData.gdb
Data
Polygon
The following is my code attempt:
>>> from osgeo import ogr
>>> d