On mardi 20 juin 2017 19:35:47 CEST Travis Featherston wrote:
> I have 2 concurrent processes creating indexes on FileGDB tables. I
> expected to receive some sort of error or warning due to locking.
> Unfortunately, both processes complete without any message or error. The
> end result is that on
Matt,
> My actual problem is a bit more specific then being unable to open S3 files
> after upload. The actual problem is that within the same Python session, I
> can open a file off S3 with the vsis3 driver, but then if I upload a new
> file that previously did not exist (using boto3), gdal does
Thanks Even,
Disabling reading the directory is another work around for my use case as
well:
(GDAL_DISABLE_READDIR_ON_OPEN=TRUE)
On Wed, Jun 21, 2017 at 5:02 AM, Even Rouault
wrote:
> Matt,
>
>
>
> > My actual problem is a bit more specific then being unable to open S3
> files
>
> > after uploa
On mercredi 21 juin 2017 11:47:49 CEST Matt Hanson wrote:
> Thanks Even,
>
> Disabling reading the directory is another work around for my use case as
> well:
> (GDAL_DISABLE_READDIR_ON_OPEN=TRUE)
This can work, but will cause probing of lots of side-car files.
If you don't have any side-car fil
Yes, I just confirmed this same behavior happens in the 1.5 SDK through the
latest OSGeo4W install.
Is the special GetLayerDefinition the best way to check for successful
indexes?
On Wed, Jun 21, 2017 at 1:07 AM, Even Rouault
wrote:
> On mardi 20 juin 2017 19:35:47 CEST Travis Featherston wrote
actually, even more importantly the reason to drop this is because it is wrong
on linux. When building gdal it will link to a specific version of libproj (ex
libproj.so.3), with the current implementation, at runtime it will try to load
libproj.so. This does not existing in non -dev packages o
