[gdal-dev] Issue (and suggested fix) compiling pdfium for GDAL

[FLOISSAC, Patrick via gdal-dev]

Hello,
I recently had to compile gdal 3.8 with pdfium support on an AlmaLinux 8 
platform and I struggled for a while with an unexpected issue that I could 
finally come up with.
I used the latest version of the build_linux.sh procedure provided by Even 
Rouault 
(https://github.com/rouault/pdfium_build_gdal_3_8/blob/master/build_linux.sh)

I explain below the issue and the fix.

The issue I faced:
- the build_linux.sh script clones depot_tools.git and then checkouts a 
specific commit (1c4052d88ac510a3db4351e52c088cac524c726c in the case of gdal 
3.8). The depot_tools repo is thus now in detached head on the 1c4052d8 commit.
- Up to now, everything is completely fine and the underlying intent of this 
checkout (freezing the content of depot_tool) became clear to me when I 
compared the 1c4052d8 commit date (2023/08/16) and the date of the current 
build_linux.sh script (commited the following day)
- But then, the build_linux.sh script launches the two following commands : 
'gclient config --unmanaged "$PDFIUM_URL"' and 'gclient sync --revision="$REV"'
- ... and these commands end with the following error: 
"depot_tools/update_depot_tools: line 149: goma_ctl: command not found"

After analysis, the issue comes from the fact that these gclient commands 
perform a change in the state of the depot_tools repo:
- before launching the gclient commands, this repo was, as said above, in 
detached head on the 1c4052d8 commit. In this state, the goma_ctl script exists 
in the depot_tools.
- after launching the gclient commands, the depo_tools repo is detached head, 
but at origin/main. And the goma_ctl script does not exist anymore.
- Looking to the commit history, it appears that goma_ctl was removed on 
2024/04/15 (commit "remove goma CIPD package").

The fix:
I tried to find a way to avoid depot_tools to be automatically updated and I 
finally found that setting the following variable before launching the 
build_linux.sh script did the trick:
DEPOT_TOOLS_UPDATE=0

Maybe this fix could be included in the several existing compilation procedures 
?
(I only used the one related to gdal 3.8 but I think that the same issue - and 
the same fix - might be applicable for the other versions).

Best regards,

Patrick Floissac
The information in this e-mail is confidential. The contents may not be 
disclosed or used by anyone other than the addressee. Access to this e-mail by 
anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and 
delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of 
this e-mail as it has been sent over public networks. If you have any concerns 
over the content of this message or its Accuracy or Integrity, please contact 
Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus 
scanning software but you should take whatever measures you deem to be 
appropriate to ensure that this message and any attachments are virus free.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Issue (and suggested fix) compiling pdfium for GDAL

[FLOISSAC, Patrick via gdal-dev]

Hello,
I recently had to compile gdal 3.8 with pdfium support on an AlmaLinux 8 
platform and I struggled for a while with an unexpected issue that I could 
finally come up with.
I used the latest version of the build_linux.sh procedure provided by Even 
Rouault 
(https://github.com/rouault/pdfium_build_gdal_3_8/blob/master/build_linux.sh).

I explain below the issue and the fix.

The issue I faced:
- the build_linux.sh script clones depot_tools.git and then checkouts a 
specific commit (1c4052d88ac510a3db4351e52c088cac524c726c in the case of gdal 
3.8). The depot_tools repo is thus now in detached head on the 1c4052d8 commit. 
- Up to now, everything is completely fine and the underlying intent of this 
checkout (freezing the content of depot_tool) became clear to me when I 
compared the 1c4052d8 commit date (2023/08/16) and the date of the current 
build_linux.sh script (commited the following day)
- But then, the build_linux.sh script launches the two following commands : 
'gclient config --unmanaged "$PDFIUM_URL"' and 'gclient sync --revision="$REV"' 
- ... and these commands end with the following error: 
"depot_tools/update_depot_tools: line 149: goma_ctl: command not found"

After analysis, the issue comes from the fact that these gclient commands 
perform a change in the state of the depot_tools repo:
- before launching the gclient commands, this repo was, as said above, in 
detached head on the 1c4052d8 commit. In this state, the goma_ctl script exists 
in the depot_tools.
- after launching the gclient commands, the depo_tools repo is detached head, 
but at origin/main. And the goma_ctl script does not exist anymore.
- Looking to the commit history, it appears that goma_ctl was removed on 
2024/04/15 (commit "remove goma CIPD package").

The fix:
I tried to find a way to avoid depot_tools to be automatically updated and I 
finally found that setting the following variable before launching the 
build_linux.sh script did the trick:
DEPOT_TOOLS_UPDATE=0

Maybe this fix could be included in the several existing compilation procedures 
?
(I only used the one related to gdal 3.8 but I think that the same issue - and 
the same fix - might be applicable for the other versions).

Best regards,

Patrick Floissac

The information in this e-mail is confidential. The contents may not be 
disclosed or used by anyone other than the addressee. Access to this e-mail by 
anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and 
delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of 
this e-mail as it has been sent over public networks. If you have any concerns 
over the content of this message or its Accuracy or Integrity, please contact 
Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus 
scanning software but you should take whatever measures you deem to be 
appropriate to ensure that this message and any attachments are virus free.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Issue (and suggested fix) compiling pdfium for GDAL

[Even Rouault via gdal-dev]

Patrick,

please create a pull request against 
https://github.com/rouault/pdfium_build_gdal_3_10 with your suggested 
fix (since that will be the repo that will serve as a start for next 
updates)


Even

Le 04/02/2025 à 15:44, FLOISSAC, Patrick via gdal-dev a écrit :


Hello,

I recently had to compile gdal 3.8 with pdfium support on an AlmaLinux 
8 platform and I struggled for a while with an unexpected issue that I 
could finally come up with.


I used the latest version of the build_linux.sh procedure provided by 
Even Rouault 
(https://github.com/rouault/pdfium_build_gdal_3_8/blob/master/build_linux.sh)


I explain below the issue and the fix.

The issue I faced:

- the build_linux.sh script clones depot_tools.git and then checkouts 
a specific commit (1c4052d88ac510a3db4351e52c088cac524c726c in the 
case of gdal 3.8). The depot_tools repo is thus now in detached head 
on the 1c4052d8 commit.


- Up to now, everything is completely fine and the underlying intent 
of this checkout (freezing the content of depot_tool) became clear to 
me when I compared the 1c4052d8 commit date (2023/08/16) and the date 
of the current build_linux.sh script (commited the following day)


- But then, the build_linux.sh script launches the two following 
commands : 'gclient config --unmanaged "$PDFIUM_URL"' and 'gclient 
sync --revision="$REV"'


- ... and these commands end with the following error: 
"depot_tools/update_depot_tools: line 149: goma_ctl: command not found"


After analysis, the issue comes from the fact that these gclient 
commands perform a change in the state of the depot_tools repo:


- before launching the gclient commands, this repo was, as said above, 
in detached head on the 1c4052d8 commit. In this state, the goma_ctl 
script exists in the depot_tools.


- after launching the gclient commands, the depo_tools repo is 
detached head, but at origin/main. And the goma_ctl script does not 
exist anymore.


- Looking to the commit history, it appears that goma_ctl was removed 
on 2024/04/15 (commit "remove goma CIPD package").


The fix:

I tried to find a way to avoid depot_tools to be automatically updated 
and I finally found that setting the following variable before 
launching the build_linux.sh script did the trick:


DEPOT_TOOLS_UPDATE=0

Maybe this fix could be included in the several existing compilation 
procedures ?


(I only used the one related to gdal 3.8 but I think that the same 
issue - and the same fix - might be applicable for the other versions).


Best regards,

Patrick Floissac

The information in this e-mail is confidential. The contents may not 
be disclosed or used by anyone other than the addressee. Access to 
this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus 
immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or 
completeness of this e-mail as it has been sent over public networks. 
If you have any concerns over the content of this message or its 
Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated 
virus scanning software but you should take whatever measures you deem 
to be appropriate to ensure that this message and any attachments are 
virus free.


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] no autodetect for ZARR output

[Laurențiu Nicola via gdal-dev]

Hi,

On Tue, Feb 4, 2025, at 13:56, Even Rouault via gdal-dev wrote:
> A PR to add .zarr as an extension for the Zarr driver ? Is it recommended by 
> the Zarr spec (can't find anything) or considered a best practice ? This 
> wasn't my impression, although that would certainly be desirable.

Their quickstart  uses 
.zarr as the extension and the v3 spec 
 says:

> When storing a Zarr hierarchy in a filesystem-like store (e.g. the local 
> filesystem or S3) as a sub-directory, it is recommended that the 
> sub-directory name ends with `.zarr` to indicate the start of a hierarchy to 
> users.

Laurentiu___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] no autodetect for ZARR output

[Even Rouault via gdal-dev]

Hi Michael,



 (I will PR to set extension metadata but wondered if this is a problem).
A PR to add .zarr as an extension for the Zarr driver ? Is it 
recommended by the Zarr spec (can't find anything) or considered a best 
practice ? This wasn't my impression, although that would certainly be 
desirable.


gdalmdimtranslate gdrivers/data/netcdf/srid.nc  
out.zarr  -co ARRAY:COMPRESS=ZSTD


| But in this case, nothing happens and  all is silent.

Fix or ticket about that welcome

Even

--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL-GRASS GIS driver 1.0.3 release candidate released

[Nicklas Larsson via gdal-dev]

GDAL-GRASS GIS driver 1.0.3rc2 is now released.

A single CMake fix is added since 1.0.3rc1,
see https://github.com/OSGeo/gdal-grass/releases/tag/1.0.3rc2.

The release can be downloaded from:

https://download.osgeo.org/gdal-grass/gdal-grass-1.0.3rc2.tar.gz

https://download.osgeo.org/gdal-grass/gdal-grass-1.0.3rc2.tar.gz.md5
https://download.osgeo.org/gdal-grass/gdal-grass-1.0.3rc2.tar.gz.sha256


After quite a generous test period for RC1, the final release is planned to
be released in 24-48 hours.

Best regards,
Nicklas



> On 17 Dec 2024, at 12:51, Nicklas Larsson via gdal-dev 
>  wrote:
> 
> The GDAL-GRASS driver 1.0.3rc1 release provides more than 25
> improvements and fixes with respect to the release 1.0.2.
> 
> Highlights:
> 
> - CMake support added
> - Autoconf configure updated to version 2.71, with a number of fixes
> - Migrate use of deprecated GDAL driver registration API
> - Remove use of obsolete CPL_CVSID() macro
> - CI supported tests and code formatted with ClangFormat
> 
> You are encouraged–in particular–to test the new CMake build, which
> is planned to replace Autotools build in future version 1.1.0 release.
> 
> More complete information on changes can be found at:
> 
> https://github.com/OSGeo/gdal-grass/releases/tag/1.0.3rc1
> 
> 
> The release can be downloaded from:
> 
> https://download.osgeo.org/gdal-grass/gdal-grass-1.0.3rc1.tar.gz
> 
> https://download.osgeo.org/gdal-grass/gdal-grass-1.0.3rc1.tar.gz.md5
> https://download.osgeo.org/gdal-grass/gdal-grass-1.0.3rc1.tar.gz.sha256
> 
> 
> Best regards,
> Nicklas
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Suggestion for generalization tools

[Even Rouault via gdal-dev]

Mihovil,

- Documentation of GDAL development processes: 
https://gdal.org/en/stable/development/index.html


- Sieve filter source code: 
https://github.com/OSGeo/gdal/blob/master/alg/gdalsievefilter.cpp


Even

Le 04/02/2025 à 21:52, Mihovil Rak via gdal-dev a écrit :


Hello GDAL Dev team,

As far as I know gdal_sieve is the only GDAL raster generalization 
tool and one of the few open source ones in general.


I would suggest to create a tool (or a few of them) that could use 
generalization alghoritms like expansion (dilation), shrinking 
(erosion), boundary smoothing, majority filtering, group segmentation 
and similar for classified raster images.


I have been using GDAL and developing GIS tools for a few years, and 
have been a GIS user for a few more, but I am not familiar with what 
the procedure is for building/suggesting new functionalities to the 
GDAL project.


Kind regards,

Mihovil


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Suggestion for generalization tools

[Mihovil Rak via gdal-dev]

Hello GDAL Dev team,

As far as I know gdal_sieve is the only GDAL raster generalization tool and one 
of the few open source ones in general.

I would suggest to create a tool (or a few of them) that could use 
generalization alghoritms like expansion (dilation), shrinking (erosion), 
boundary smoothing, majority filtering, group segmentation and similar for 
classified raster images.

I have been using GDAL and developing GIS tools for a few years, and have been 
a GIS user for a few more, but I am not familiar with what the procedure is for 
building/suggesting new functionalities to the GDAL project.

Kind regards,

Mihovil

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] no autodetect for ZARR output

[Michael Sumner via gdal-dev]

I can see that there's no calls to for the Zarr driver
'SetMetadataItem(GDAL_DMD_EXTENSION' or
'SetMetadataItem(GDAL_DMD_EXTENSIONS', but I wanted to ask about the
behaviour.

This makes sense to me:

gdal_translate gdrivers/data/netcdf/srid.nc out.zarr  -co COMPRESS=ZSTD
Output driver not found.

But in this case, nothing happens and  all is silent.  (I will PR to set
extension metadata but wondered if this is a problem).

gdalmdimtranslate gdrivers/data/netcdf/srid.nc out.zarr  -co
ARRAY:COMPRESS=ZSTD

Cheers, Mike




-- 
Michael Sumner
Research Software Engineer
Australian Antarctic Division
Hobart, Australia
e-mail: mdsum...@gmail.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev