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
I think the trick there is that single quotes make most shells consider a
string verbatim - I'd forgotten that part! That's probably the more
desirable solution, actually.
Cheers,
Daniel
On Tue, 2 Jul 2024, 17:13 Robin Wilson, wrote:
> Hi,
>
> Hmm, I’m sure I tried escaping it before - but putt
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
Hi Joe,
Now you've pointed them out, I do see those little bits in the north east.
I hadn't zoomed in enough on the right area. Sadly, I've not much advice to
offer on whether it's expected, and/or how to avoid it.
(Apologies for the slow and unhelpful reply!)
Cheers,
Daniel
On Thu, 18 Apr 2024
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
Hi Joe,
My minimal change is just to add the missing "RPC_DEM=srtm_12_05.tif" and
remove the "RPC_HEIGHT=350". RPC_HEIGHT appears to override the use of any
supplied DEM, and the docs at least hint that this is the expected
behaviour.
```
gdalwarp --config CPL_DEBUG ON \
-t_srs EPSG:32610 \
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
19 matches
Mail list logo
