Andrew,
interestingly adding the debug traces I suggested to you to the GDAL CI
MacOS 14 build witch no longer worked turns out to reveal the exact same
issue as yours! (funny that I didn't even consider doing that myself !
interesting case where helping others actually is helping oneself
On Tue, Apr 30, 2024 at 9:18 AM Even Rouault
wrote:
Even,
> Also try in a Python interpreter "from osgeo import gdal" to see if the
> exception is more verbose. If your GDAL lib links against libraries that
> are not in the default library search path, GDAL command line utilities
> might still
Andrew,
first, check that you can use the command line utilities like gdalinfo,
so you may need to adjust your PATH, DYLD_LIBRARY_PATH and GDAL_DATA.
The Bash script scripts/setdevenv.sh might help setting up stuff (not
totally sure if it works on Mac though).
Also try in a Python
Hi all,
I removed all files from the build and started over, building using the
same procedure that I used with the source from a couple of weeks ago
without problem and now I get the following error:
(gdal) [master] $ pytest -v autotest/utilities/test_gdal_viewshed.py
ImportError while loading
Andrew,
Perhaps you're running updated GDAL Python bindings against a libgdal
that hasn't been rebuilt recently? OSRIsDerivedProjected() has been
added recently both in libgdal and the bindings
Even
Le 29/04/2024 à 23:27, Andrew Bell via gdal-dev a écrit :
Hi,
I just merged master into my
Hi,
I just merged master into my branch and I'm now getting an error when
trying to run a test. If someone might know what happened, I'd appreciate a
tip.
(gdal) [master] $ pytest -v autotest/utilities/test_gdal_viewshed.py
ImportError while loading conftest
The last mail that I have received from the list is dated August 2, testing if
sending mail to the list succeeds.
-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
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?
GDAL_DATA is evaluated as the argument of fopen(), so if it is relative,
you need to be a current directory consistent with the relative path for
it to work. You'd generally want ot use an absolute path for GDAL_DATA
I see that in pytest.ini a commented line with #GDAL_DATA =
../gdal/data.
On Mon, Apr 26, 2021 at 10:44 AM Even Rouault
wrote:
> DGN writing indeeds need GDAL_DATA to be set and point to the directory
> that contains seed_2d.dgn
>
Is it the case that GDAL_DATA is relative to the directory containing the
test rather than the test driver directory (autotest)? Changing a
DGN writing indeeds need GDAL_DATA to be set and point to the directory
that contains seed_2d.dgn
You can source scripts/setdevenv.sh to set the appropriate environment
variables for a dev env.
Le 26/04/2021 à 16:38, Andrew Bell a écrit :
On Mon, Apr 26, 2021 at 10:18 AM Even Rouault
On Mon, Apr 26, 2021 at 10:18 AM Even Rouault
wrote:
> Andrew,
>
> you don't need to add autotest/ogr to GDAL_DATA.
>
> Normally this is done in autotest/pytest.ini
>
Thanks. I missed that.
> I suspect you don't have the pytest-env python module installed.
>
> You should probably just run:
>
>
Andrew,
you don't need to add autotest/ogr to GDAL_DATA.
ARCGEN is now a deprecated driver and must be explictly enabled with
GDAL_ENABLE_DEPRECATED_DRIVER_ARCGEN=YES env variable.
Normally this is done in autotest/pytest.ini
I suspect you don't have the pytest-env python module installed.
Hi,
I'm trying to run autotests and am failing to find data. For instance, I
get the error:
def test_ogr_arcgen_points():
ds = ogr.Open('data/arcgen/points.gen')
> assert ds is not None, 'cannot open dataset'
E AssertionError: cannot open dataset
E assert None is
On Thu, Jan 9, 2020 at 3:18 PM Even Rouault
wrote:
> Andrew,
>
> > Any ideas what might be going on or what I might look for to fix?
>
> Did you build GDAL yourself ? Check if you built against internal libtiff
> or
> not ? If you built against internal libtiff, make sure to use
>
Andrew,
> Any ideas what might be going on or what I might look for to fix?
Did you build GDAL yourself ? Check if you built against internal libtiff or
not ? If you built against internal libtiff, make sure to use
--with-rename-internal-libtiff-symbols to avoid any potential symbol clash
with
Hi Andrew,
Running the test under lldb will give you some leads. Within your activated
environment, so that "python" is the correct one:
$ lldb python
(lldb) run -m pytest /Users/acbell/gdal/autotest/gcore/tiff_ovr.py
On Thu, Jan 9, 2020 at 11:48 AM Andrew Bell
wrote:
> Hi,
>
> I'm getting
Hi,
I'm getting an abort when I run autotest on OSX:
gcore/tiff_ovr.py
..Fatal
Python error: Aborted
Current thread 0x7fff9465d380 (most recent call first):
File
On jeudi 21 février 2019 10:03:20 CET Andrew Bell wrote:
> Hi,
>
> I'm having an issue running autotest on Ubuntu 18.04. Ideas appreciated:
>
> ===
>
> acbell@ubuntu-gdal:~/gdal/autotest$ LD_LIBRARY_PATH=../gdal/.libs
> PYTHONPATH=../gdal/swig/python/build/lib.linux-x86_64-2.7 pytest
>
Hi,
I'm having an issue running autotest on Ubuntu 18.04. Ideas appreciated:
===
acbell@ubuntu-gdal:~/gdal/autotest$ LD_LIBRARY_PATH=../gdal/.libs
PYTHONPATH=../gdal/swig/python/build/lib.linux-x86_64-2.7 pytest
= test session starts
Mail test.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
al-dev@lists.osgeo.org
Subject: RE: [gdal-dev] Test Windows Build
Thank you, Jürgen! This is exactly what I was looking for.
Thank you,
Chris
-Original Message-
From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Jürgen
E. Fischer
Sent: Saturday, July 2, 2016 2:27 PM
To
Thank you, Jürgen! This is exactly what I was looking for.
Thank you,
Chris
-Original Message-
From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Jürgen
E. Fischer
Sent: Saturday, July 2, 2016 2:27 PM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Test Windows
Hi Christopher,
On Sat, 02. Jul 2016 at 11:47:35 -0600, Christopher McGeorge wrote:
> Hi. Could anyone please suggest a way, preferably one that I can automate,
> to verify that GDAL Windows builds were successful, such as by running one
> of the generated exe files in the apps folder?
Does
Hi. Could anyone please suggest a way, preferably one that I can automate,
to verify that GDAL Windows builds were successful, such as by running one
of the generated exe files in the apps folder?
Thank you,
Chris
---
This email has been checked for viruses by Avast antivirus software.
Hello :
(I dont know if this email are going to be accepted by the list manager. So,
this is a 'test' )
I have a question about gdal_warp and gdal_translate utilities.
I want to re-scale to 50% a serie of images.
I cannot use gdal_translate with % outsize parameters
gdal_translate -of
On Wed, Jan 12, 2011 at 6:30 PM, Antonio P aperezca...@yahoo.es wrote:
Hello :
(I dont know if this email are going to be accepted by the list manager. So,
this is a 'test' )
I have a question about gdal_warp and gdal_translate utilities.
I want to re-scale to 50% a serie of images.
I cannot
Hello again : ( I dont know if my question was sent to the list )
I cannot use gdal_translate with % outsize parameters :
gdal_translate -of JPEG -outsize 25% 25% DSC02699.jpg 02699.jpg
does nothing (I view the use options of gdal_translate, it seems as I
wrote a wrong
On 11-01-12 04:30 PM, Antonio P wrote:
Hello again : ( I dont know if my question was sent to the list )
Antonio,
I believe it already went through and there were some responses.
You can check the list archives after a bit to see if a message has
gone through.
I cannot use
49 matches
Mail list logo
