Merci Even,
I can confirm that the workaround you suggested works correctly.
>From the performance I was getting beforehand, I strongly believe that the
mixup happening on the overview levels was causing my hat/lr dataset to
never be used at all.
Thank you for the quick response,
Thomas
On Mon,
Hi list,
I'm experimenting with the GTI driver and hitting an issue when trying to
add overviews.
I'm compiling a large number of adjacent non-overlapping tiles, each of
which has is own bundled overviews:
gdalinfo /*snip*/tile-1377-471.tif
Size is 32768, 32768
Origin =
All OK with https://github.com/airbusgeo/godal 's test suite, with changes
that did have to be made to account for the default gtiff mask band
handling (I believe this change should have been kept back until 4.0. I am
not asking for it to be reverted)
regards,
TB
On Mon, Apr 22, 2024 at 2:12 PM
I have a side-question concerning the update-in-place behavior of the gtiff
driver in this case: given that a compressed strile will nearly always be
smaller after this update (due to better compression ratios on the uniform
area), will libtiff overwrite the previous strile in place also, or will
> I don't like that the behaviour of a command line depends on the
> configuration of the user (that is usually not aware of). So a command that
> works for me doesn't work for you. That is bad.
>
+1
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
Le ven. 8 mars 2024, 17:42, Even Rouault a
écrit :
> Thomas,
> >
> > my number 1 requirement would be that the rewrite not cause any
> > backwards compatibility issues compared to today's argument handling.
> > I suspect many users are calling the gdal utilities through scripts
> > and it would
Hi Even,
my number 1 requirement would be that the rewrite not cause any backwards
compatibility issues compared to today's argument handling. I suspect many
users are calling the gdal utilities through scripts and it would be a pain
to have to update those when upgrading gdal.
a nice to have
Hi Sean,
I believe/recall this is very driver dependent. Some drivers will look for
their sidecars in the provided sibling files list returned by
VSISiblingFiles, whereas others will unconditionally try to open well-known
sidecar names they will have computed from their own name. IIRC I added
doc update PR in https://github.com/OSGeo/gdal/pull/9220
On Fri, Feb 9, 2024 at 3:38 PM Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS
AND APPLICATIONS INC] wrote:
> We can work with the Uint16 case. These dtype limitations should be
> listed on the gtiff docs presumably.
>
>
>
&
JXL in tiff should support the 2 band case correctly. What is not supported
here is the int16 datatype. Only uint8, uint16 and float32 are supported.
TB
On Fri, Feb 9, 2024 at 3:32 PM Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS
AND APPLICATIONS INC] via gdal-dev wrote:
> We are trying to
could you share the output of "gdalinfo in.tif" please?
On Fri, Feb 9, 2024 at 3:32 PM Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS
AND APPLICATIONS INC] via gdal-dev wrote:
> We are trying to convert a 2 band int16 ZSTD compressed geotiff to JXL
> compression. However for each band the
Ferdinand,
(re-adding gdal-dev after having exchanged off-list)
For your image with FIRST_COL set, you MUST use a gdal with
https://github.com/OSGeo/gdal/pull/7653 included. The initial
implementation in 5725 was incorrect in two ways: firstly
ImagetoGround_Validity_Domain.* is informative only,
this is one of the reasons we built https://github.com/airbusgeo/cogger
(supposing you are creating a tiled tif): first create your tif with your
usual gdal tooling , unconditionally setting bigtiff=yes, and then as a
postprocessing step run cogger on the resulting file. You'll get a COG
which
There are only very specific cases where it would be valid to directly copy
overview tiles, namely if both image sizes are an exact power of 2. I'll
let Even contradict me if I'm wrong, but I highly doubt that what you are
trying to do is possible.
regards,
Thomas
Le jeu. 6 oct. 2022, 05:58, Ian
> I can't see real advantages in keeping the 3 build systems longer than
> strictly needed
>
fully agree, there's no advantage in delaying shipping if it's ready
--
thomas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
This is mostly likely due to an issue with your dimap. The dimap
driver correctly handles the geotransform for ortho images, or RPCs
for primary images in all cases I have encountered.
regards,
thomas
On Fri, Oct 22, 2021 at 10:31 AM GUIMMARA, Sébastien via gdal-dev
wrote:
>
> Hello,
>
>
>
>
onf and apt install autoconf2.69
regards,
On Thu, Oct 7, 2021 at 10:01 AM thomas bonfort wrote:
>
> we seem to be using deprecated autoconf macros. It should work if you
> downgrade autoconf to version 2.69 on your system. I'll look into
> fixing our autoconf.ac syntax in a coming
we seem to be using deprecated autoconf macros. It should work if you
downgrade autoconf to version 2.69 on your system. I'll look into
fixing our autoconf.ac syntax in a coming PR.
regards,
Thomas
On Thu, Oct 7, 2021 at 9:53 AM APM wrote:
>
> Dear List,
>
>
> if I try to compile gdal, I got an
you need to use /vsicurl/ :
gdalinfo
/vsicurl/https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
--
thomas
On Tue, Oct 5, 2021 at 5:12 PM Joaquim Manuel Freire Luís wrote:
>
> Hi,
>
>
>
> I’ve read a lot of the docs, tried many
> And really, I should make those smaller. I know that some of the required
> formats are required mostly for autotest. I'd be be interested in working on
> getting the minimum footprint down once things are switched to CMake.
The autotools build already supports minimal builds, with the list
Here's a working c version:
https://gist.github.com/tbonfort/1e8630cf4b9bc82471c164e422c1cce7
On Tue, Jul 13, 2021 at 2:55 PM thomas bonfort wrote:
>
> https://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg36305.html
> :)
>
> On Tue, Jul 13, 2021 at 2:53 PM Javier Jimenez
ere already a C/C++ API?
>
> Cheers,
> Javier
> .___ ._ ..._ .. . ._. .___ .. __ . _. . __.. ... ._ .__
> Entre dos pensamientos racionales
> hay infinitos pensamientos irracionales.
>
>
>
> On Tue, 13 Jul 2021 at 14:15, thomas bonfort wrote:
>>
>> J
Javier,
You can use https://github.com/airbusgeo/cogger#advanced to do that,
provided that you have an internally tiled geotiff.
--
thomas
On Tue, Jul 13, 2021 at 2:04 PM Even Rouault wrote:
>
> Javier,
>
> You can use the "NONE" resampling method in BuildOverviews() or gdaladdo to
> create
You can open the DIM_*.XML files with gdal, those are the useful ones.
--
Thomas
On Fri, Jul 9, 2021 at 9:38 PM wrote:
>
> Hi,
>
>
>
> The DIMAP driver page lists names of the index files to look at. I don’t have
> any of these filenames in our SPOT6 folder tree. Is the driver description
>
cogger v0.0.5 now supports .ovr external overviews. It will automatically
set the output cog to bigtiff if required, so your use-case should now be
covered.
--
Thomas
Le lun. 14 juin 2021 à 22:12, a écrit :
> > You can create external overviews with the -ro switch
>
> Yeah, I have those. I
Your initial test.tif file needs to be a bigtiff, i.e. have been
created with -co "BIGTIFF=YES". you can then drop the bigtiff config
arguments of your gdaladdo call.
--
thomas
On Wed, Jun 9, 2021 at 5:39 PM wrote:
>
> I am getting tiff file size exceeded error but am using bigtiff creation
>
Yes, it must be internal
Le mar. 8 juin 2021 à 21:21, a écrit :
> Thanks Thomas.
>
>
>
> Does cogger need a mask band to be internal as well, and not a sidecar
> file?
>
>
>
> -Mat
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
Matt,
In the general case, cogger supports a tiff with internal overviews, i.e.
without a .tif.ovr sidecar file. The advanced usecase which takes multiple
files is a remnant of the time when gdaladdo was much slower than
successive runs of "gdal_translate -outsize 50% 50%", or for when you need
ompressed methods such as
>> JPEG or WebP, cogger will avoid adding any new loss.
>>
>> Le 04/06/2021 à 18:28, thomas bonfort a écrit :
>>
>> I haven't extensively used -of COG (the cogger code actually predates the
>> cog driver) but iirc there are at lea
I haven't extensively used -of COG (the cogger code actually predates the
cog driver) but iirc there are at least some cases where it uses an
intermediate file, which would imply that cogger does offer some speedups.
I'll let Even confirm...
Regards,
Thomas
Le ven. 4 juin 2021 à 18:14, a écrit :
Hello gdal,
We're releasing two projects on github under an Apache-2.0 licence
which may be of interest to the GDAL community.
The first one, https://github.com/airbusgeo/cogger is a lightweight
geotiff to COG converter that reshuffles the bytes of a tiled geotiff
to make it cloud compatible.
It's known regression, see https://github.com/OSGeo/gdal/issues/3782
--
thomas
On Tue, May 4, 2021 at 10:42 AM Javier Jimenez Shaw
wrote:
> Hi
>
> I am trying to compile the new release 3.3.0 in Ubuntu 18.04 with the
> option "--without-geos".
>
> The message is this:
>
> GEOS support disabled
FWIW +1 from a non PSC member
Thomas
Le jeu. 4 mars 2021 à 17:33, Even Rouault a
écrit :
> Hi,
>
> Updating my yesterday motion with the feedback received (only second
> bullet updated with a more restricted set of drivers)
>
> Motion:
>
> - remove the vector drivers BNA, AeronavFAA, HTF,
Hi Sean,
To give my personal experience:
Does it work?
>
> It drove exactly 0 leads to me
Is it kept up to date or does it get stale?
>
> I don't think it has ever been updated since it was put into place. I
should remove myself from the list as I don't provide such services anymore.
Does the
On Tue, Jan 12, 2021 at 11:36 PM Even Rouault
wrote:
>
> The issue with esoteric/legacy drivers is not that much maintenance of the
> actual code of the drivers, in the sense of dealing with bug reports,
> questions, etc. (pretty sure they are none for the ones I listed). Most of
> them must
Conor,
I suspect that you should add an
extern "C" {
void GDALRegisterMe();
}
line at the beginning of your cpp file.
--
Thomas
On Tue, Jan 12, 2021 at 12:56 PM Conor McIndoe
wrote:
> Hello developers,
>
> I am just learning the ropes with GDAL so apologies if some of this is
> quite far off.
; seems like the WEBP compression produces smaller file sizes than JPEG, but
> how does it look speed-wise regarding decompression?
>
> Thanks,
>
> Andreas
>
> On 2020-10-09 15:33, thomas bonfort wrote:
>
> You might need to compile with gdal's internal libtiff so that w
You might need to compile with gdal's internal libtiff so that webp-in-tif
support is enabled (i.e. the system libtiff might not have webp support).
Also note you should probably be adding "-co TILED=YES" to your translate
command.
On Fri, Oct 9, 2020 at 3:07 PM Andreas Neumann wrote:
> Hi,
>
>
Thank you Even for the prompt reply.
I'll have a look into the vrt workaround, in my case the deformations
aren't enormous so applying a buffer at vrt creation time would probably be
sufficient provided the overviews are taken into account.
However for the computesourcewindow proposition which I'd
I'm trying to warp/extract a webmercator tile from a large +proj=ortho
image. The issue is that the further I move away from the center of the
image the quality of the output result degrades. This seems to be due to
which overview is being selected from the source image.
input image created with
Jon,
This issue is probably related to https://github.com/OSGeo/gdal/issues/1244
and was fixed in 2.4.4
--
Thomas
Le lun. 24 févr. 2020 à 05:46, Jon Seymour a écrit :
> G'day,
>
> I am trying to get to the bottom of some errors I have been experiencing
> with gdal 2.4.2 + Python 3 running in a
Hi Even,
Thanks for the extensive research you have put into this.
As a very general remark, this proposal seems to focus on minimizing the
bandwidth from the cog storage to the consumer, whereas I'd argue that
there are a broad range of usages where the consumer is in the same cloud
region as the
for the sake of clarity, I think I should rename the --disable-all-drivers
flag to --disable-all-optional-drivers ...
thomas
Le ven. 1 févr. 2019 à 20:58, thomas bonfort a
écrit :
> hi,
>
> Le ven. 1 févr. 2019 à 20:39, Andrew C Aitchison
> a écrit :
>
>> On Fri, 1 F
hi,
Le ven. 1 févr. 2019 à 20:39, Andrew C Aitchison a
écrit :
> On Fri, 1 Feb 2019, Even Rouault wrote:
>
> > (Re-adding the list)
> >
> >>> Is the split in 2 directories for aesthetic reasons, or because it
> makes
> >>> the
> >>> conditional compiling logic easier ?
> >>
> >> The latter. I'd
Le ven. 1 févr. 2019 à 18:10, Even Rouault a
écrit :
> (Re-adding the list)
>
> > > Is the split in 2 directories for aesthetic reasons, or because it
> makes
> > > the
> > > conditional compiling logic easier ?
> >
> > The latter. I'd like to avoid modifying the cpp files themselves to add
> >
Following #1250 [1] that allows deactivating drivers at configure time,
in the interest of cutting down on compile time, generated binary size and
surface of attack in case of flaws, I would like to propose to be able to
split the frmts/raw directory in 2.
raw/ would only contain rawdataset.cpp|h
Salut Even,
Thanks for the quick answer. Sorry I forgot to mention I was using gdal
2.3.2 and proj 4.9.3. I'll upgrade to 5.1.0!
Regards,
Thomas
On Fri, Nov 9, 2018 at 3:27 PM Even Rouault
wrote:
> Salut Thomas,
>
> I don't get any warning with GDAL 2.3.2 and PROJ 5.1.0. While
> investigating,
Hi,
I'm trying to warp an extract of a epsg:3857 tiled layer to a local
transverse mercator projection.
osm.xml:
https://a.tile.openstreetmap.org/${z}/${x}/${y}.png
-20037508.34
20037508.34
20037508.34
-20037508.34
18
1
1
top
EPSG:3857
256
256
3
5
I then run an extract over a 200 meter
48 matches
Mail list logo
