Hi all,
Over the last couple of months, I've been receiving emails from the
gdal-dev list with a significant delay, with emails from threads sometimes
arriving out of order.
For example, in the recent thread on Java bindings, the email headers show
the following;
Tom's initial email was delayed
> Middle ground: Make the download/installation of the SWIG bindings opt-in
only. We could at least track the number of users who go to the trouble of
downloading it.
I suspect those numbers are already (mostly) there, as most users of the
bindings likely don't download and compile GDAL themselves
Hi Jukka,
Those are errors from your the Windows command prompt. You will need to
escape or enclose some special characters like the ampersands.
On Thu, 21 Nov 2024, 14:15 Rahkonen Jukka via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:
> Hi,
>
>
>
> The examples in https://gdal.org/en/latest/dr
Hi Howard,
> To my eye, that means our respondent pool is strongly tilted toward
power users and developers, as I would expect a much larger mix of Windows
users.
Where has the survey been announced? I've only seen it on this list, which
is explicitly for "developers using and building GDAL/OGR"
And I'll highlight that the separate `geometry` and `bbox` fields in the
STAC item do explicitly have to be projected in WGS84 (as required by the
GeoJSON spec):
https://github.com/radiantearth/stac-spec/blob/master/item-spec/item-spec.md#geometry
(Although I suspect the original mistake was takin
lly need
>> to have the right file size, it will just check we don't try to read beyond
>> at some points, so unlimited is OK. In other situations/drivers, the exact
>> value could be needed.
>>
>> But they should really fix their servers
>>
>> Even
>>
>>
CURL_USE_HEAD=[YES/NO]:
> Defaults to YES. Controls whether to use a HEAD request when opening a
> remote URL.”
>
>
>
> -Jukka Rahkonen-
>
>
>
> *Lähettäjä:* gdal-dev *Puolesta *Daniel
> Evans via gdal-dev
> *Lähetetty:* tiistai 10. syyskuuta 2024 16.57
> *Vastaano
Hi all,
I am attempting to read a dataset via /vsicurl/ where I believe the server
is incorrectly returning `content-length: 0` in response to HEAD requests.
This causes GDAL to believe it's a zero-length file, and it therefore can't
be read.
If I download the file via HTTP GET, it's valid, and G
Hi Even,
Firstly, I'll state my bias as someone involved in the production of
thermal MWIR EO data (3.5-5um) - unsurprisingly, I'd like some
classification that fits my data :-)
> classifications...
The NIR - SWIR - MWIR - LWIR classification scheme is by far the most
common I've encountered in
I would presume that Javier is intending to use one of the several Complex
data types that GDAL supports natively - CInt16, CInt32, CFloat32, CFloat64.
It seems that VRTs appear to have the capability to create a complex band
from two separate bands, and vice versa - the "complex", "imag", and "re
the PG connection string…
>
> Best regards,
>
> Robin
>
> On 2 July 2024 at 17:08:18, Daniel Evans (daniel.fred.ev...@gmail.com)
> wrote:
>
> Hi Robin,
>
> Is this a shell issue, rather than a GDAL one? The dollar sign makes me
> suspect that a Unix shell is inte
Hi Robin,
Is this a shell issue, rather than a GDAL one? The dollar sign makes me
suspect that a Unix shell is interpreting "robin$42" as "the string 'robin'
and the value of variable $42" before it gets into GDAL. My terminal would
interpret it as the following:
$ echo robin$42
robin
and I'd nee
; .80...90...100 - done.
> GDAL: GDALClose(srtm_12_05.tif, this=0x5584b5c522a0)
> GDAL: Flushing dirty blocks:
> 0...10...20...30...40...50...60...70...80...90...100 - done.
> GDAL: GDALClose(output_gdal38.tiff, this=0x5584b5c4c950)
> GDAL: GDALClose(../manyPts4000_SRTM_test_NptRPC.tiff, th
Hi Nathan,
My initial suspicion might just be that the scaling the data provider did
to go from the raw data to a human-eye-friendly RGB composite isn't the
conversion you're assuming.
I know that with the data I regularly work with, it may be provided as
Uint16, but the data range doesn't extend
ts. What command did you use to include the DEM?
>
> If there has been a fix between 3.6 and 3.8.3 that helps with this, then
> I'm happy to try it. I'll give that a look too.
>
> thanks!
> Joe
> --
> *From:* Daniel Evans
> *Sent:* Th
Hi Joe,
Trying your commands with GDAL 3.8.3, the results don't seem to be as bad
as what you're reporting - I don't see big strips missing. Adding in the
DEM file as Even mentioned, it seems to be doing what I'd expect (the
correction isn't "right" because of the georeferencing offset, but it's
d
Is it worth moving this in-depth discussion to a PR or similar for the new
driver?
My thinking is that a lengthy discussion on memory leak detection
techniques in C++, how to run tests in Python, etc., aren't topics relevant
to most GDAL mailing list subscribers.
Cheers,
Daniel
On Wed, 6 Mar 202
Agree with Kurt - it's always struck me as a little surprising that it was
optional. There's also not very much of a Python stack you can build that
involves GDAL but doesn't pull in Numpy through another dependency, as Even
said.
I would've thought that in any constrained environment where GDAL i
Hi Even,
> With virtualization, it is hard to guarantee that other things happening
on the host running the VM might not interfer. Even locally on my own
machine, I initially saw strong variations in timings
The advice I've come across for benchmarking is to use the minimum time
from the set of r
Hi Even,
This sounds a sensible change, for the reasons outlined in your first
paragraph. When first making contributions, I think I was caught out
by this arrangement in just about all of the ways you mention!
To play devil's advocate, were there any (perceived) benefits to this
arrangement when
> Additionally, these loops fix the order that the checks are made, and bugs
> can hide in test order dependency.
As we're on the topic of pytest, I'll mention fixtures as a handy
feature for test setup: https://docs.pytest.org/en/6.2.x/fixture.html
I discovered a while back that some parts of t
Hi Michael,
The idea of a two-image build like this is explicitly to create a Runner
without all the compile dependencies, reducing the amount of baggage that
users of the Docker image end up having. That's why it doesn't copy over
all the dependencies for compilation, as you note! One of the down
Similar thoughts here, too. Thinking particularly of the Docker image, the
main use case for them is ensuring a reproducible build on the user's side.
Those using the `latest` tag (indicating they're not so bothered about
versions) will start building with 3.6.1 automatically anyway. Those who
have
Hi Marcin,
For writing the data to an S3 bucket, two options come to mind:
1) Write directly from GDAL, using the /vsis3/ virtual file system
2) Write the data locally from GDAL, and then copy to S3 using another
Python library (e.g. boto3, s3fs) or the AWS CLI
Option 2 is quite widely adopted.
(To follow my own advice, I've tried with a fresh environment with GDAL
3.4.1 and Python 3.9!)
On Mon, 10 Oct 2022 at 09:02, Daniel Evans
wrote:
> Hi Jukka,
>
> Can you, or the original poster, give some more information on what Python
> and GDAL versions you're using th
Hi Jukka,
Can you, or the original poster, give some more information on what Python
and GDAL versions you're using that cause trouble? I've not immediately hit
404 errors on trying - with CPL_DEBUG=ON, I can see GDAL successfully
opening tiles (HTTP 206).
With something like 13,000 tiles in a si
the zip file or do I use
> some other tool for that?
>
> On Tue, Sep 6, 2022 at 10:50 AM Daniel Evans
> wrote:
>
>> Hi Sharon,
>>
>> I think all you need to do is define the path to open as:
>>
>> '/vsizip//parks-and-recreation-feature-map-d.zip/
Hi Sharon,
I think all you need to do is define the path to open as:
'/vsizip//parks-and-recreation-feature-map-d.zip/parks-and-recreation-feature-map/parks-and-recreation-feature-map.shp'
i.e. defining the filepath as:
/vsizip//
When the zip contains only a single (shape)file at the top level
on my end meant the DEBUG log messages were being discarded when I thought
they weren't.
Regards,
Daniel
On Wed, 6 Jul 2022 at 18:55, Even Rouault
wrote:
> Daniel,
>
> https://github.com/OSGeo/gdal/pull/6028 should help, but with the
> restriction indicated in the commit message
Hi,
I'm trying to diagnose some issues with accessing remote datasets in GDAL -
I believe the problem is unrelated to GDAL itself, but it's proving hard to
debug.
By enabling CPL_CURL_VERBOSE, I can see that the server is kicking back a
400 Bad Request status, but the debug output doesn't include
Hi Kavitha,
I doubt the answer has changed since your last email to the list on the
topic (on 8 April).
The answer was that you should be able to enable these compiler features
when compiling from source yourself, as well as a report that GDAL has been
known to compile successfully with SSP. If y
x files
> is not an option because there are many and they are supplied by clients
> and regularly updated.
>
> Regards,
> Dirk
>
> On Tue, Mar 29, 2022 at 10:06 AM Daniel Evans
> wrote:
>
>> Hi Dirk,
>>
>> > I do notice when I open the file in exce
Hi Dirk,
> I do notice when I open the file in excel and select everything, the
eight column in the file is empty but also gets selected.
It looks like that's the key here.
The code you identified gets hit if GDAL encounters a row with more
populated columns than the previous one, and if the pro
Another +1 here. As far as I understand, the only real point of the COG
driver is to be a quick way to get some sensible defaults for GeoTIFF
format, and compression is definitely one such sensible default.
Also, the COG spec's example GDAL command includes `-co COMPRESS=LZW`,
which might be anoth
I'll leave suggestions on diagnosing and fixing PROJ DLL/Databases to others -
I've little knowledge on the matter, especially in regards to Conda and
Windows. There might be something to Paul's points about the packages coming
from different channels; I believe this can cause trouble with Conda
ouble,double,double)
OSRCoordinateTransformationShadow::TransformPoint(double
[4],double,double,double,double)
(I suspect the error might originate from SWIG being unable to match the call
for a None/null object, rather than a CoordinateTransform?)
Dr Daniel Evans
Software Developer
e: daniel.ev
amp;argout[2] );
}
https://github.com/OSGeo/gdal/blob/master/gdal/swig/python/extensions/osr_wrap.cpp#L4422
I’ll admit none of that particularly helps solve the issue beyond saying “I
think it should work”, though!
Dr Daniel Evans
Software Developer
e: daniel.ev...@jbarisk.com
t: +44 (0
to always use AddPoint_2D when dealing with 2D geometries?
Dr Daniel Evans
Software Developer
e: daniel.ev...@jbarisk.com
t: +44 (0)1756 799919
www.jbarisk.com
All JBA Risk Management's email messages contain confidential information and
are intended only for the individual(s) named. If
/gdal/tree/release/3.1/gdal/swig/python
(Alternatively, I’d argue it wouldn’t be too hard to do some global search and
replace for “import gdal”->”from osgeo import gdal”, using your IDE or some
command line tools, but I presume you’re not tempted by that idea!)
Dr Daniel Evans
Software
it compared to the pre-compiled packages from other sources. Will those changes
affect those distributions, too?)
Dr Daniel Evans
Software Developer
e: daniel.ev...@jbarisk.com
t: +44 (0)1756 799919
www.jbarisk.com
All JBA Risk Management's email messages contain confidential informatio
-6.37%
13
3355401
-6.36%
14
3354678
-6.34%
15
3353801
-6.31%
16
3083731
2.25%
17
3142331
0.39%
18
3147466
0.23%
19
3146084
0.28%
20
3146548
0.26%
21
3145580
0.29%
22
3142972
0.37%
Table generated from output of `zstd -b1 -e22`, “zstd command line interface
64-bits v1.4.7”.
Dr Daniel Evans
27;t choose the transform our users want automatically. I've not been able
to answer their queries regarding what transformation GDAL has chosen when we
create a CoordinateTransformation object.
Dr Daniel Evans
Software Developer
[JBA COVID-19
statement]<https://www.jbagroup.co.uk/sites/www.jbagro
tml#afda4d86428c1c533449ae6a69cdf430d
Is the error message being cleared incorrectly?
Dr Daniel Evans
Software Developer
[JBA COVID-19
statement]<https://www.jbagroup.co.uk/sites/www.jbagroup.co.uk/files/documents/15-030%20JBA%20Business%20Continuity%20Briefing%20-%20Latest.pdf
Thanks Even. From a bit of testing, I can see the time scaling linearly with
the requested number of threads despite inputting only 9 pixels, so I suspect
that feature is newer than 3.0.4. I'll have a look in the changelogs and keep
it in mind.
Dr Daniel Evans
Software Developer
From:
s, even
if it won't find work for them. It's therefore up to the user (me!) to measure
and work out where the best performance comes from - and blindly throwing in
NUM_THREADS=ALL_CPUS is not always a good tactic.
Dr Daniel Evans
Software Developer
From: Daniel Evans
Sent: 06 October
GDAL 3.0.4)
Dr Daniel Evans
Software Developer
[JBA COVID-19
statement]<https://www.jbagroup.co.uk/sites/www.jbagroup.co.uk/files/documents/15-030%20JBA%20Business%20Continuity%20Briefing%20-%20Latest.pdf>
T +44 (0) 1756 799919
www.jbarisk.com<http://www.jbarisk.com>
[V
e spotted a few similar examples before - usually typos that went unnoticed
for a long time, but a few cases like this.
Dr Daniel Evans
Software Developer
From: gdal-dev On Behalf Of Jon Morris
Sent: 08 June 2020 11:00
To: Even Rouault ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Segmen
Thanks Even.
Apparently I managed to reply to Even directly, not to the mailing list, which
I've now copied back in.
From: Even Rouault
Sent: 28 April 2020 12:53
To: Daniel Evans
Subject: Re: [gdal-dev] GDAL 3.1.0 RC1 available
Daniel,
issue confirmed. Spotted to
https://githu
Given the filesize of the original raster, I suspect it’s mostly empty, and so
I’d suggest also specifying:
-co “SPARSE_OK=TRUE”
That instructs GDAL to avoid writing any data at all where the entirety of a
tile is nodata, rather than writing a (compressed) block of nodata values.
However, the
iner I was hoping for. Thanks!
Dr. Daniel Evans
Software Developer
-Original Message-
From: Even Rouault
Sent: 05 March 2020 16:01
To: gdal-dev@lists.osgeo.org
Cc: Daniel Evans
Subject: Re: [gdal-dev] Importing ESRI (EPSG?) 102008 in GDAL 3.x/PROJ 6
Daniel,
> While upgrading some
story of the custom fork of GDAL we're moving away from
isn't well documented)
Dr. Daniel Evans
Software Developer
Skype
T +44 (0) 1756 799919
www.jbarisk.com<http://www.jbarisk.com>
[Visit our website]<http://www.jbarisk.com>
[http://www.jbagroup.co.uk/imgstore/JBA-Ema
riginal Message-
From: gdal-dev On Behalf Of Mateusz Loskot
Sent: 06 February 2020 12:28
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] WGS84 -> WGS84 transform flips axes
On Thu, 6 Feb 2020 at 13:20, Daniel Evans wrote:
>
> > Try https://gdal.org/tutorials/osr_api_tut.html#crs-an
ing on how an SRS
has been used.
Dr. Daniel Evans
Software Developer
Skype
T +44 (0) 1756 799919
www.jbarisk.com<http://www.jbarisk.com>
[Visit our website]<http://www.jbarisk.com>
[http://www.jbagroup.co.uk/imgstore/JBA-Email-Sig-Icons-LINKEDIN.png] <>
[Follow us on Tw
hange to this value in this circumstance intentional? If so, does it
mean that I have to repeatedly enforce the axis mapping strategy, because I
don't know whether it will have been modified or not, depending on the
provenance of the SRS object?
Dr. Daniel Evans
Software Developer
Sk
=ogr.wkbPolygon)
projFromLayer = layer.GetSpatialRef()
xform = osr.CoordinateTransformation(projection, projFromLayer)
xform.TransformPoint(1.0, 0.0)
# Outputs (0.0, 1.0, 0.0)
xform_no_layer = osr.CoordinateTransformation(projection, projection)
xform_no_layer.TransformPoint(1.0, 0.0)
# Outputs (1.0
imported = osr.SpatialReference();
>>> from_proj_reimported.ImportFromWkt(from_proj.ExportToWkt())
>>> to_proj_reimported = osr.SpatialReference();
>>> to_proj_reimported.ImportFromWkt(to_proj.ExportToWkt())
>>> new_xform = osr.CoordinateTransformation(from_proj_
aniel
-Original Message-
From: Even Rouault
Sent: 28 January 2020 12:03
To: gdal-dev@lists.osgeo.org
Cc: Daniel Evans
Subject: Re: [gdal-dev] GDAL_FORCE_CACHING - alters results?
On mardi 28 janvier 2020 11:49:01 CET Daniel Evans wrote:
> Hi all,
>
> I've recently tried enabling the
Hi all,
I've recently tried enabling the GDAL_FORCE_CACHING option, and found it gives
some significant improvements to TIFF/VRT read speeds.
However, using GDAL 2.3.0, I've now found that when reading large VRTs, I can
sometimes get subtly different values - up to about 1% summed difference ac
ay to optimise GDAL so that queries of files on the mounted
network storage are more efficient?
Dr. Daniel Evans
Software Developer
Skype
T +44 (0) 1756 799919
www.jbarisk.com<http://www.jbarisk.com>
[Visit our website]<http://www.jbarisk.com>
[http://www.jbagroup.co.uk/imgstore/JB
Hello,
I recently submitted a pull request against GDAL that adds an option that
causes GDALComputeProximity to take into account areas of no data within
the input raster and updates gdal_proximity.py with a -use_nodata flag.
This pull request is here https://github.com/OSGeo/gdal/pull/49
Is this
60 matches
Mail list logo
