Re: [gdal-dev] GDAL 3.10.2 release candidate available
Hi, It's already been 10 days, but I'm only thanking you now. Even though I'm not the maintainer of GDAL on FreeBSD, as a member of the Desktop team—who has to deal with (and sometimes struggle with) libraries like Poppler—I can only thank you for thinking of us! Personally, it's always a pleasure to see software projects that don’t break with every new version and that apply patches with clean commits, like GDAL does. And now, we even get the release right away—what more could we ask for? Thank you for thinking of us! 🙏 Loïc, Le Mardi, Février 11, 2025 12:41 CET, Even Rouault via gdal-dev a écrit: Hi, I have prepared a GDAL/OGR 3.10.2 release candidate, slightly ahead of what was planned. The main trigger for it is the recent Poppler 25.02.00 release that breaks their C++ unstable API and require code changes on our side. So rather than letting each package maintainer cherry-picks the appropriate patch commit, let's issue a clean release. Pick up an archive among the following ones (by ascending size): https://download.osgeo.org/gdal/3.10.2/gdal-3.10.2rc1.tar.xz https://download.osgeo.org/gdal/3.10.2/gdal-3.10.2rc1.tar.gz https://download.osgeo.org/gdal/3.10.2/gdal3102rc1.zip A snapshot of the gdalautotest suite is also available: https://download.osgeo.org/gdal/3.10.2/gdalautotest-3.10.2rc1.tar.gz https://download.osgeo.org/gdal/3.10.2/gdalautotest-3.10.2rc1.zip The NEWS file is here: https://github.com/OSGeo/gdal/blob/v3.10.2RC1/NEWS.md Best regards, 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Zip-Compressed GeoJSON Files?
Revisiting our geo export options after several years and hit something weird. Testing with the command-line tools, this works... ogr2ogr -f "geojson" /vsigzip//path/to/output.geojson.gz This does not... ogr2ogr -f "geojson" /vsizip//path/to/output.geojson.zip It spits a ton of errors (attached) and while the zip file is created, it has no files in it. Am I doing something silly, or is this a bug? Does anyone really use or expect individually-zipped GeoJSON files anyway? This is with GDAL 3.7.3. We are updating to 3.11 so I'll try that too. -- Simon Eves Senior Rendering Engineer +1 (415) 902-1996 simon.e...@heavy.ai simon.eves@EVESPC2024:~/dumps/exports$ ogr2ogr -f "geojson" /vsizip/states_z.geojson.zip states_z.geojson ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip file or closed subfiles ERROR 6: VSIFWriteL() is not supported on main Zip fil
[gdal-dev] link error with MrSID and ECW
I am getting the following link errors when building my application in MSVC++:
1>gdal.lib(gdalallregister.cpp.obj) : error LNK2019: unresolved external symbol
_GDALRegister_ECW referenced in function
_GDALAllRegister@01>gdal.lib(gdalallregister.cpp.obj) : error LNK2019:
unresolved external symbol _GDALRegister_JP2ECW referenced in function
_GDALAllRegister@01>gdal.lib(gdalallregister.cpp.obj) : error LNK2019:
unresolved external symbol _GDALRegister_MrSID referenced in function
_GDALAllRegister@0
I am linking statically to GDAL built as a static library with vcpkg (which
builds without error). I am using a custom x86-windows.cmake file with vcpkg,
customized mainly to include MrSID and ECW functionality in GDAL. I have pasted
the cmake text at the bottom of this email.
>From what I can see in the GDAL code, it's behaving as if
>gdal/frmts/mrsid/mrsiddataset.cpp (which contains the function
>GDALRegister_MrSID) wasn't compiled into the library, yet the following code
>in frmts/gdalallregister.cpp was compiled.
#ifdef FRMT_mrsid GDALRegister_MrSID();#endif
Can you help me understand how this could happen? What actually controls
whether gdal/frmts/mrsid/mrsiddataset.cpp gets compiled into the library?
---x86-windows.cmake:
set(VCPKG_TARGET_ARCHITECTURE x86)set(VCPKG_CRT_LINKAGE
static)set(VCPKG_LIBRARY_LINKAGE static)set(VCPKG_BUILD_TYPE
release)set(ENV{CMAKE_WINDOWS_KITS_10_DIR} "C:\\Program Files (x86)\\Windows
Kits\\10")set(VCPKG_CMAKE_CONFIGURE_OPTIONS
"-DCMAKE_WINDOWS_KITS_10_DIR=C:\\Program Files (x86)\\Windows
Kits\\10")set(VCPKG_ENV_PASSTHROUGH CMAKE_WINDOWS_KITS_10_DIR)
# CMAKE_CURRENT_LIST_DIR is the triplets directory# such as
C:/Users/michael.katz/Documents/vcpkg/tripletsmessage( STATUS
"\n\n---CMAKE_CURRENT_LIST_DIR =
${CMAKE_CURRENT_LIST_DIR}\n\n" )
if (PORT MATCHES "gdal") string( CONCAT x "
\"-DMRSID_INCLUDE_DIR=${CMAKE_CURRENT_LIST_DIR}/../sdk/MrSID_DSDK-9.5.5.5244-win32-vc17/Raster_DSDK/include\""
"
\"-DMRSID_LIBRARY=${CMAKE_CURRENT_LIST_DIR}/../sdk/MrSID_DSDK-9.5.5.5244-win32-vc17/Raster_DSDK/lib/lti_dsdk.lib\""
" \"-DGDAL_USE_MRSID=ON\"" " \"-DFRMT_mrsid=ON\"" "
\"-DECW_INCLUDE_DIR=${CMAKE_CURRENT_LIST_DIR}/../sdk/ecw/Hexagon/ERDAS_ECW_JPEG_2000_SDK_5.5.0/Desktop_Read-Only/include\""
"
\"-DECW_LIBRARY=${CMAKE_CURRENT_LIST_DIR}/../sdk/ecw/Hexagon/ERDAS_ECW_JPEG_2000_SDK_5.5.0/Desktop_Read-Only/lib/vc141/Win32/NCSEcw.lib\""
" \"-DGDAL_USE_ECW=ON\"" " \"-DFRMT_ecw=ON\"" )
set(VCPKG_CMAKE_CONFIGURE_OPTIONS "${VCPKG_CMAKE_CONFIGURE_OPTIONS} ${x}" )
set(VCPKG_CXX_FLAGS "${VCPKG_CXX_FLAGS} -DFRMT_mrsid=ON") set(VCPKG_C_FLAGS
"${VCPKG_C_FLAGS} -DFRMT_mrsid=ON") set(VCPKG_CXX_FLAGS "${VCPKG_CXX_FLAGS}
-DFRMT_ecw=ON") set(VCPKG_C_FLAGS "${VCPKG_C_FLAGS} -DFRMT_ecw=ON")endif()
message( STATUS "\n\n---VCPKG_CMAKE_CONFIGURE_OPTIONS =
${VCPKG_CMAKE_CONFIGURE_OPTIONS}\n\n" )
message( STATUS "\n\n---FEATURES = ${FEATURES}\n\n" )
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Zip-Compressed GeoJSON Files?
Same with 3.10.1. On Fri, Feb 21, 2025 at 3:12 PM Simon Eves wrote: > Revisiting our geo export options after several years and hit something > weird. > > Testing with the command-line tools, this works... > > ogr2ogr -f "geojson" /vsigzip//path/to/output.geojson.gz > > This does not... > > ogr2ogr -f "geojson" /vsizip//path/to/output.geojson.zip > > It spits a ton of errors (attached) and while the zip file is created, it > has no files in it. > > Am I doing something silly, or is this a bug? > > Does anyone really use or expect individually-zipped GeoJSON files anyway? > > This is with GDAL 3.7.3. We are updating to 3.11 so I'll try that too. > > -- > Simon Eves > Senior Rendering Engineer > +1 (415) 902-1996 > simon.e...@heavy.ai > > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] link error with MrSID and ECW
IMO you ask for trouble when you manually inject -DFRMT_mrsid=ON into
CFLAGS and CXXFLAGS. This is CMake input ("ON"!). Let the configuration
do that for you. Did configuration successfully detect the dependency?
Check the config logs.
Kai
Am 22.02.25 um 05:15 schrieb Michael Katz via gdal-dev:
I am getting the following link errors when building my application in
MSVC++:
1>gdal.lib(gdalallregister.cpp.obj) : error LNK2019: unresolved
external symbol _GDALRegister_ECW referenced in function
_GDALAllRegister@0
1>gdal.lib(gdalallregister.cpp.obj) : error LNK2019: unresolved
external symbol _GDALRegister_JP2ECW referenced in function
_GDALAllRegister@0
1>gdal.lib(gdalallregister.cpp.obj) : error LNK2019: unresolved
external symbol _GDALRegister_MrSID referenced in function
_GDALAllRegister@0
I am linking statically to GDAL built as a static library with vcpkg
(which builds without error). I am using a custom x86-windows.cmake
file with vcpkg, customized mainly to include MrSID and ECW
functionality in GDAL. I have pasted the cmake text at the bottom of
this email.
From what I can see in the GDAL code, it's behaving as if
gdal/frmts/mrsid/mrsiddataset.cpp (which contains the function
GDALRegister_MrSID) wasn't compiled into the library, yet the
following code in frmts/gdalallregister.cpp was compiled.
#ifdef FRMT_mrsid
GDALRegister_MrSID();
#endif
Can you help me understand how this could happen? What actually
controls whether gdal/frmts/mrsid/mrsiddataset.cpp gets compiled into
the library?
---
x86-windows.cmake:
set(VCPKG_TARGET_ARCHITECTURE x86)
set(VCPKG_CRT_LINKAGE static)
set(VCPKG_LIBRARY_LINKAGE static)
set(VCPKG_BUILD_TYPE release)
set(ENV{CMAKE_WINDOWS_KITS_10_DIR} "C:\\Program Files (x86)\\Windows
Kits\\10")
set(VCPKG_CMAKE_CONFIGURE_OPTIONS
"-DCMAKE_WINDOWS_KITS_10_DIR=C:\\Program Files (x86)\\Windows Kits\\10")
set(VCPKG_ENV_PASSTHROUGH CMAKE_WINDOWS_KITS_10_DIR)
# CMAKE_CURRENT_LIST_DIR is the triplets directory
# such as C:/Users/michael.katz/Documents/vcpkg/triplets
message( STATUS "\n\n---CMAKE_CURRENT_LIST_DIR =
${CMAKE_CURRENT_LIST_DIR}\n\n" )
if (PORT MATCHES "gdal")
string(
CONCAT x
"
\"-DMRSID_INCLUDE_DIR=${CMAKE_CURRENT_LIST_DIR}/../sdk/MrSID_DSDK-9.5.5.5244-win32-vc17/Raster_DSDK/include\""
"
\"-DMRSID_LIBRARY=${CMAKE_CURRENT_LIST_DIR}/../sdk/MrSID_DSDK-9.5.5.5244-win32-vc17/Raster_DSDK/lib/lti_dsdk.lib\""
" \"-DGDAL_USE_MRSID=ON\""
" \"-DFRMT_mrsid=ON\""
"
\"-DECW_INCLUDE_DIR=${CMAKE_CURRENT_LIST_DIR}/../sdk/ecw/Hexagon/ERDAS_ECW_JPEG_2000_SDK_5.5.0/Desktop_Read-Only/include\""
"
\"-DECW_LIBRARY=${CMAKE_CURRENT_LIST_DIR}/../sdk/ecw/Hexagon/ERDAS_ECW_JPEG_2000_SDK_5.5.0/Desktop_Read-Only/lib/vc141/Win32/NCSEcw.lib\""
" \"-DGDAL_USE_ECW=ON\""
" \"-DFRMT_ecw=ON\""
)
set(VCPKG_CMAKE_CONFIGURE_OPTIONS
"${VCPKG_CMAKE_CONFIGURE_OPTIONS} ${x}" )
set(VCPKG_CXX_FLAGS "${VCPKG_CXX_FLAGS} -DFRMT_mrsid=ON")
set(VCPKG_C_FLAGS "${VCPKG_C_FLAGS} -DFRMT_mrsid=ON")
set(VCPKG_CXX_FLAGS "${VCPKG_CXX_FLAGS} -DFRMT_ecw=ON")
set(VCPKG_C_FLAGS "${VCPKG_C_FLAGS} -DFRMT_ecw=ON")
endif()
message( STATUS
"\n\n---VCPKG_CMAKE_CONFIGURE_OPTIONS =
${VCPKG_CMAKE_CONFIGURE_OPTIONS}\n\n" )
message( STATUS "\n\n---FEATURES = ${FEATURES}\n\n" )
___
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
