Greg,
an I wonder if this file (in some VFS?) has an associated mode? I would
sort of expect openssl to error if the private key file were readable by
group or other, and I don't understand this filefromstring big. (I get
the concept; I just have no idea how it works.)
The file is indeed
Even Rouault writes:
>> FAILED gdrivers/eedai.py::test_eedai_GOOGLE_APPLICATION_CREDENTIALS - assert
>> ...
> Not sure what happens here. Probably some harden configuration of
> openssl that rejects the private key ? Apparently it fails on Mac too
> from
>
Greg,
FAILED ogr/ogr_gmt.py::test_ogr_gmt_2 - AssertionError: assert 1 == 0
Hopefully https://github.com/OSGeo/gdal/pull/4424 might help
FAILED gcore/cog.py::test_cog_small_world_to_web_mercator - assert [26228, 22...
Was fixed in master 3.4.0 dev per
Thanks for all the hints so far about tests. With the fopen/fread fix
(locally applied to 3.3.2rc3), and rtree added in to sqlite3 (which I'm
calling a bug in my world), I am down to:
FAILED ogr/ogr_gmt.py::test_ogr_gmt_2 - AssertionError: assert 1 == 0
FAILED
Even Rouault writes:
>> What's wrong with just always doing the stat?
> Nothing, but just one extra system call in a performance critical path.
OK - but do you really think that in an entire sequence of
fopen/fread/prcoess-data that one more stat (which will be cached w.r.t
the inode read in
What's wrong with just always doing the stat?
Nothing, but just one extra system call in a performance critical path.
Or, if it's really important to avoid the stat, put the code that makes
beyond-POSIX assumptions under #ifdef linux. Then we'd have code that
is in general correct, and
Even Rouault writes:
>> As I read the spec, it is a violation to return NULL when the first
>> argument is a directory and the second is r or rb. A test program
>> succeeds in calling fopen on . with rb, on both NetBSD and macOS 10.13.
>
> It is not clear for me. There's a mention that opening
Le 01/09/2021 à 21:22, Greg Troxel a écrit :
Looking into the avc failure, I find
$ ogrinfo ogr/data/avc/testavc/testavc/
INFO: Open of `ogr/data/avc/testavc/testavc/'
using driver `AVCBin' successful.
1: ARC (Line String)
2: LAB (Point)
But if I leave off the trailing / I get a
Looks like a lot of this the rtree module in sqlite3, which seems to
think telling you to go back and rebuild something with different
non-default options is a reasonable approach :-(
sqlite3 with rtree support is a requirement for GeoPackage and Spatialite.
I had not previously grasped
>> Looking into the avc failure, I find
>>
>> $ ogrinfo ogr/data/avc/testavc/testavc/
>> INFO: Open of `ogr/data/avc/testavc/testavc/'
>>using driver `AVCBin' successful.
>> 1: ARC (Line String)
>> 2: LAB (Point)
>>
>> But if I leave off the trailing / I get a failure to find a driver. A
Even Rouault writes:
>> and now have a test run that shows:
>>
>>= 312 failed, 6939 passed, 1489 skipped, 2 xfailed, 2 warnings in 746.96s
>> (0:12:26) =
>>
>> which seems quite good overall.
>
> For a reasonably well setup environment, you should not get more than
> a handful of failures.
and now have a test run that shows:
= 312 failed, 6939 passed, 1489 skipped, 2 xfailed, 2 warnings in 746.96s
(0:12:26) =
which seems quite good overall.
For a reasonably well setup environment, you should not get more than a
handful of failures. 312 definitely indicates something
This message is not a request to hold 3.3.2. At this point, I don't
have any basis to believe that there's anything wrong with gdal, and I
haven't previously run the tests.
Thanks to Robert and Even for explaining about the test infrastructure.
I've addressed a few things
- packaging
Do you have any idea why the differences exist? Is it worth investigating?
Quite likely subtle differences in behavior of the JPEG compression
library. Mine on ubuntu 20.04 is libjpeg-turbo 2.0.3 with IJG libjpeg 8
ABI. I presume if you built if from source and linked it against GDAL,
Even,
Do you have any idea why the differences exist? Is it worth investigating?
On Wed, Apr 28, 2021 at 8:35 AM Even Rouault
wrote:
> Andew,
>
> visually the difference between your image and the one generated on my PC
> are almost indistinguishable (no spatial shift at least). Please submit
Andew,
visually the difference between your image and the one generated on my
PC are almost indistinguishable (no spatial shift at least). Please
submit a PR adding your checksums as alternate accepted ones. You may
just remove the "if sys.platform == 'darwin'" case. Hopefully adding
your
Here is the output tif file along with the command and its terminal output.
On Tue, Apr 27, 2021 at 3:02 PM Even Rouault
wrote:
>
> Le 27/04/2021 à 20:49, Andrew Bell a écrit :
>
>
>
> On Tue, Apr 27, 2021 at 2:27 PM Even Rouault
> wrote:
>
>> Andrew,
>>
>> This could be due to the PROJ
Le 27/04/2021 à 20:49, Andrew Bell a écrit :
On Tue, Apr 27, 2021 at 2:27 PM Even Rouault
mailto:even.roua...@spatialys.com>> wrote:
Andrew,
This could be due to the PROJ version, but as I'm running with 8.0
too (and one of the CI config runs PROJ master), I suspect you
On Tue, Apr 27, 2021 at 2:27 PM Even Rouault
wrote:
> Andrew,
>
> This could be due to the PROJ version, but as I'm running with 8.0 too
> (and one of the CI config runs PROJ master), I suspect you just need to
> install the "conus" grid for NAD27 to WGS84 transformations into
>
Andrew,
This could be due to the PROJ version, but as I'm running with 8.0 too
(and one of the CI config runs PROJ master), I suspect you just need to
install the "conus" grid for NAD27 to WGS84 transformations into
{proj_prefix}/share/proj . Unpack
Hi,
I'm having a few test failures with gdal master on OSX. They seem related
to transformations. I notice that the CI build is using PROJ 7.1. I'm
linking PROJ 8.0. An example failure follows. Can this be explained by PROJ
versions or are there other issues that I might need to investigate?
21 matches
Mail list logo
