Re: [gdal-dev] CMake: undefined reference to symbol dlerror

Le 29/04/2022 à 11:30, Javier Jimenez Shaw a écrit : We have a link problem on Linux when using GDAL transiently. If we link the unit tests for a library which depends on GDAL, i.e. an executable which transiently depends on GDAL through our library, we get the following linker error: /usr/b

Re: [gdal-dev] Hints that a raster band represents a DEM?

Hi Nyall, you didn't miss anything. There's no standardized metadata to figure out if a band is DEM. A few drivers (at least USGSDEM, DTED, SRTMHGT, BLX, BT, Leveller, Terragen, SIGDEM, HF2) convey exclusively height related data, but most others can convey anything, often without a distincti

Re: [gdal-dev] About COG with multiple bands

Javier, up to now, GDAL has restricted the COG definition to pixel interleaved organization, a bit artificially admittedly. This issue was recorded in https://github.com/opengeospatial/CloudOptimizedGeoTIFF/issues/3 . There's no way to efficiently extract a subset of bands with pixel interlea

[gdal-dev] Motion: adopt GDAL 3.4.3 RC2

Hi, Motion: Adopt GDAL 3.4.3 RC2 as final 3.4.3 release Starting with my +1 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

Re: [gdal-dev] default for RelativeToVRT field

Michael, Or is it just a matter of forcing an input path to be absolute? for regular use cases (ie VRT name not set to empty), you might not even been able to do that in master since https://github.com/OSGeo/gdal/commit/6d7001656d06af138f8e46ff1651056626db11e8 which tries to write relative

Re: [gdal-dev] Issues in Raster Resampling

Mike, if you look at the nodata value set on 2015_daytime_mean_clip.tif, it is at 3.3995214436425e+38, and not at nan. If you add the srcNodata=math.nan argument to gdal.Warp(), this will fix your issue. Even Le 23/04/2022 à 06:40, Chao Li a écrit : Dear Gdal Developer, Thank you for

Re: [gdal-dev] BAG CRS

e with a CRS provided through the GetProjection()/SetProjection() API of GDAL, a fix would be welcome. If it is the user who provides WKT2 with a manual VAR_VERT_WKT option, then I'd say it is their responsibility to provide the right value. Even Le 22/04/2022 à 18:35, Vautour, André

Re: [gdal-dev] BAG CRS

André, I don't confirm this trying: $ gdal_translate autotest/gcore/data/byte.tif byte.bag $ gdalinfo byte.bag -mdd xml:BAG | grep PROJCS     PROJCS["NAD27 / UTM zone 11N",GEOGCS["NAD27",DATUM["North_American_Datum_1927",SPHEROID["Clarke 1866",6378206.4,294.978698213898,AUTHORITY["EPS

[gdal-dev] GDAL 3.4.3 RC2 available (Re: GDAL 3.4.3 RC1 available)

I've tagged an RC2 whose only change is in the gdal-grass plugin (backport of https://github.com/OSGeo/gdal/pull/5503) Hence only its corresponding archive is updated: https://download.osgeo.org/gdal/3.4.3/gdal-grass-3.4.3rc2.tar.gz Even Le 22/04/2022 à 11:32, Even Rouault a écrit : H

[gdal-dev] GDAL 3.4.3 RC1 available

Hi, I have prepared a GDAL/OGR 3.4.3 release candidate. Pick up an archive among the following ones (by ascending size):   https://download.osgeo.org/gdal/3.4.3/gdal-3.4.3rc1.tar.xz   https://download.osgeo.org/gdal/3.4.3/gdal-3.4.3rc1.tar.gz   https://download.osgeo.org/gdal/3.4.3/gdal343rc1.z

Re: [gdal-dev] GeoParquet / GeoArrow docs

done Le 20/04/2022 à 10:50, Stephen Knox a écrit : Just looked at the docs since the GeoParquet pull request was merged. (https://gdal.org/drivers/vector/parquet.html) Wondering if might be useful to add that the Parquet and Arrow Drivers are only present since version 3.5. I know it's experi

Re: [gdal-dev] Using a custom operation with osr.CoordinateTransformation

Hi, looking at https://github.com/OSGeo/PROJ/blob/master/data/sql/other_transformation_custom.sql should give you good hints on how to add custom transformations, here under a PROJ authority If you want to create your own authority, you'll also need to do similar steps as the ones dones for

Re: [gdal-dev] -if netCDF fails to read Matlab .mat files

Le 18/04/2022 à 20:50, Joaquim Manuel Freire Luís a écrit : Strange, I don’t see an HDF5 driver in my list of drivers but I do include it in the GDAL build. Misconfigured / non-detected dependency then $ gdalinfo "NETCDF:"U.mat ERROR 4: NETCDF:U.mat: No such file or directory gdalinfo f

Re: [gdal-dev] -if netCDF fails to read Matlab .mat files

Joaquim, https://www.loc.gov/preservation/digital/formats/fdd/fdd000440.shtml mentions HDF5, but I don't know if it is HDF5-only or the HDF5 profile of netCDF 4. From my tests trying to simulate the situation (I don't have a .mat file handy), - if it is netCDF 3 file (non-HDF5), the netCDF

Re: [gdal-dev] Add coded field domains to file geodatabase

It turns out that I needed that feature, hence https://github.com/OSGeo/gdal/pull/5620 Le 11/04/2022 à 19:33, Even Rouault a écrit : Adam, I've just clarified the doc to explain that it is read-only for the FileGDB driver. The FileGDB SDK itself seems to have support for writing too

Re: [gdal-dev] GetProjectionRef returns invalid projection

operations. Set GTIFF_SRS_SOURCE configuration option to EPSG to use official parameters (overriding the ones from GeoTIFF keys), or to GEOKEYS to use custom values from GeoTIFF keys and drop the EPSG code. LOCAL_CS["WGS 84 / Pseudo-Mercator",UNIT["metre",1,AUTHORITY["E

Re: [gdal-dev] GetProjectionRef returns invalid projection

Frank, please provide a link to such file Even Le 15/04/2022 à 13:27, Frank Hübenthal a écrit : I use GDAL C++ to load GeoTIFF files. Since I moved to GDAL 3.4 I have problems to get the projection string from some (not all) of these GeoTIFF files. With GDAL 3.2 still something like this was

Re: [gdal-dev] GDALWarpAppOptionsNew and GDALWarp usage?

Sean, This looks fine, except for the argv[0] value, "lolwut". What is that supposed to be ? I assume GDALWarpAppOptionsNew() fails on that and returns NULL. The obvious demo for using GDALWarp() is the gdalwarp binary itself: https://github.com/OSGeo/gdal/blob/master/apps/gdalwarp_bin.cpp

Re: [gdal-dev] Add coded field domains to file geodatabase

Adam, I've just clarified the doc to explain that it is read-only for the FileGDB driver. The FileGDB SDK itself seems to have support for writing too, but this isn't implemented in the driver currently. Left as an exercise to the contributor as one says. Even Le 11/04/2022 à 19:13, adamg

[gdal-dev] CMake: add a GDAL_USE_INTERNAL_LIBS=ON/OFF/WHEN_NO_EXTERNAL variable [was Re: zlib vulnerability CVE-2018-25032 affecting GAL]

https://github.com/OSGeo/gdal/pull/5594 should hopefully make everybody happy (if such a thing is possible) Le 07/04/2022 à 15:08, Greg Troxel a écrit : Even Rouault writes: Most GDAL binary distributions don't use that internal copy but the external zlib library provided by the oper

Re: [gdal-dev] zlib vulnerability CVE-2018-25032 affecting GAL

Internal zlib copy in GDAL master will be updated to 1.2.12 per https://github.com/OSGeo/gdal/pull/5588 Most GDAL binary distributions don't use that internal copy but the external zlib library provided by the operating system / distribution channel. Le 07/04/2022 à 12:24, prashanti seri a é

Re: [gdal-dev] HAVE_XLOCALE_H -vs- GDAL_HAVE_XLOCALE_H

Javier, could you rename GDAL_HAVE_XLOCALE_H to HAVE_XLOCALE_H, at the minimum in the places where it is used in https://github.com/OSGeo/gdal/commit/d83a9f58acb and https://github.com/OSGeo/gdal/commit/ab9386760f60e6a312d8418737b5fd94dd7adccb. (I don't think it must be used elsewhere) As f

Re: [gdal-dev] CMake - cross compiling - Python

t a branch) .___ ._ ..._ .. . ._. .___ .. __ . _. . __..  ... ._ .__ Entre dos pensamientos racionales hay infinitos pensamientos irracionales. On Wed, 6 Apr 2022 at 17:47, Even Rouault wrote: But maybe there is a better solution. If that is Ok for you, I can create a PR. sounds good, but also move t

Re: [gdal-dev] CMake - cross compiling - Python

But maybe there is a better solution. If that is Ok for you, I can create a PR. sounds good, but also move the "option(BUILD_PYTHON_BINDINGS "Build Python bindings" ON)" from swig/CMakeLists.txt to top CMakeLists.txt, just before testing it -- http://www.spatialys.com My software is free, bu

Re: [gdal-dev] Create COG jpeg tiles with JFIF APPn markers

Jose, Those tiles contain normal JPEG markers (SOI, SOF0, DQT) but no JFIF marker (APP/n/) is added. How can I ensure adding this JFIF marker? you can't, unless you're ready to patch the JPEG codec in libtiff to do that I should point to https://www.awaresystems.be/imaging/tiff/specification/

Re: [gdal-dev] GDAL warp tutorial question (C vs. C++)

Le 05/04/2022 à 01:28, Michael Sumner a écrit : Hello, the warp tutorial  needs at least inclusion of "cpl_conv.h" for CPLMalloc to work. https://gdal.org/tutorials/warp_tut.html But, I'd like to ask why it uses the style of the C examples (as per the Raster API tutorial https://gdal.org/tu

Re: [gdal-dev] Memory allocation issues on Android 11+ and scudo

sers' ARM64 bits (Samsung S21). My feeling is that it is connected to ARM 64 architecture. Thanks again, more later hopefully. Philippe. *From:* Even Rouault *Sent:* Monday, March 28, 2022 3:24 PM *To:* Philippe Lelong; gdal-dev@li

Re: [gdal-dev] GDAL 3.4.2: gdalbuildvrt band selection bug

Pete, ouch, confirmed, and fix queued in https://github.com/OSGeo/gdal/pull/5547 . And the commit you mention was indeed the culprit. Potential workarounds (besides generating the VRT on GDAL <= 3.4.0) - if using gdalbuildvrt on a single source, you could just use "gdal_translate sen2_20210

Re: [gdal-dev] Trouble reprojecting feature that crosses antimeridian

Was a bug. Fix queued in https://github.com/OSGeo/gdal/pull/5543 Le 29/03/2022 à 22:30, Robin Wilson a écrit : Hi, I’ve been running into problems creating STAC items for images that cross the antimeridian. The geometries for the images are coming out as spanning the width of the whole world

Re: [gdal-dev] Errors when reading large xlsx files

Le 29/03/2022 à 20:29, Dirk Vanden Boer a écrit : > The effect will at least be to ignore any rows for which this message was raised - the function is unconditionally exited after the error is raised, before a new feature is added to the current layer. So do I understand correctly that for fi

Re: [gdal-dev] The Not Rocket Science Rule Of Software Engineering

Le 29/03/2022 à 14:45, Andrew C Aitchison a écrit : I have been reading The Not Rocket Science Rule Of Software Engineering https://graydon2.dreamwidth.org/1597.html which is:    automatically maintain a repository of code    that always passes all the tests Does https://github.com/OSG

Re: [gdal-dev] Band names when raster stacking

Known issue: https://github.com/OSGeo/gdal/issues/3627 Le 28/03/2022 à 16:08, volkan yazici a écrit : Hi, I use this code for raster stacking: outvrt = ('result/raster_stack_vrt.tif') outtif = ('result/raster_stack.tif') tifs = glob.glob('data/*.tif') outds = gdal.BuildVRT(outvrt, tifs, separa

Re: [gdal-dev] Memory allocation issues on Android 11+ and scudo

Hi, didn't hear about Scudo before, but it seems it is a LLVM side project: https://llvm.org/docs/ScudoHardenedAllocator.html So perhaps you could build and use it on Linux as shown in https://llvm.org/docs/ScudoHardenedAllocator.html#library Besides a potential bug in the allocator, it mig

Re: [gdal-dev] About bug fix / patch release policy for older GDAL versions (setuptools >= 58.0 and GDAL <3.3 compatibility issues)

test something else, please let me know! Looking forward for the release on the pypi.org <http://pypi.org>. Thank you again!! Regards, Snehal On Fri, Mar 25, 2022 at 1:45 PM Even Rouault wrote: ok, I missed this was on the pypi package. I've tried to make a patch

Re: [gdal-dev] About bug fix / patch release policy for older GDAL versions (setuptools >= 58.0 and GDAL <3.3 compatibility issues)

e repo and there is no issue with that). Hope I am not missing something obvious here. Please let me know. Thank you again! Regards, Snehal On Fri, Mar 25, 2022 at 12:29 PM Sebastiaan Couwenberg wrote: On 3/25/22 12:07, Even Rouault wrote: > what you discuss here is all about

Re: [gdal-dev] About bug fix / patch release policy for older GDAL versions (setuptools >= 58.0 and GDAL <3.3 compatibility issues)

Snehal, what you discuss here is all about the patch & backport policy of the Debian GDAL package. You can try to file a bug to Debian and point to the patch you'd want to see backported, but I can't promise if there would be interest in their maintenance team to create an updated package wit

Re: [gdal-dev] [PROJ] OGRCreateCoordinateTransformation()

Le 24/03/2022 à 18:36, Erixen Cruz a écrit : PROJ4_GRIDS provided a way to specify exactly which geoid file(s) to use.  Some vertical datums, such as NAVD88, only have a single EPSG code for multiple geoids – what’s the replacement for PROJ4_GRIDS in PROJ9?  If I could switch t

Re: [gdal-dev] OGRCreateCoordinateTransformation()

would be similar to WKT1 PROJ4_GRIDS. Thanks, steve *From:* Even Rouault *Sent:* Wednesday, March 23, 2022 6:06 PM *To:* Steve Riddell ; gdal-dev@lists.osgeo.org *Subject:* Re: OGRCreateCoordinateTransformation() Steve, you may try PR https://github.com/OSGeo/PROJ/pull/3126 or https://github

Re: [gdal-dev] RFC for the new cloud credentials framework in PR 5463 and 5390?

y can maintain their own maps of credentials or roles to resources, so I guess this feature is mainly for command line users? Do command line users do this kind of thing enough to warrant a new framework? On Thu, Mar 24, 2022 at 8:45 AM Even Rouault wrote: Sean, I saw them as busine

Re: [gdal-dev] RFC for the new cloud credentials framework in PR 5463 and 5390?

Sean, I saw them as business-as-usual enhancements not impacting the software in fundamental ways. I'm not sure what I would put in a RFC that is not in their commit message. Maybe I don't understand what your concern is. Even Le 24/03/2022 à 15:28, Sean Gillies a écrit : Hi all, The inten

Re: [gdal-dev] GDAL 3.5.0alpha1 available

Bas, given that autoconf support for GDAL will remain in 3.5.0, we can keep things unchanged for now in frmts/grass/GNUmakefile if the driver remains in-tree. Once autoconf support for GDAL is gone, indeed the simplification of your patch could be done. But the status of last discussions is

Re: [gdal-dev] GDAL 3.5.0alpha1 available

Hi Sandro, I gave it a spin for Fedora: - Does not build against JasPer-3.0.2: there are two signature mismatches: Jasper support will be dropped soon (see https://github.com/OSGeo/gdal/pull/5269). You should rather use the JP2OpenJPEG driver using libopenjp2 from https://github.com/uclou

Re: [gdal-dev] OGRCreateCoordinateTransformation()

peline\     +step +proj=axisswap +order=2, 1\     +step +proj=unitconvert +xy_in=deg +xy_out=rad\     +step +inv +proj=vgridshift +grids=HT2_0.gtx +multiplier=1\     +step +proj=tmerc +lat_0=49.351346659616 +lon_0=-123.20266499149 +k=1\     +x_0=15307.188

Re: [gdal-dev] Motion (V2): remove and deprecate a few drivers

n that batch of removal, have been paid for at some point. That's not a criterion by itself to keep them 15 years after if no one is willing to keep up with their overhead and can justify they are still relevant. Cheers Joaquim -Original Message- From: gdal-dev On Behalf Of Even R

Re: [gdal-dev] Motion (V2): remove and deprecate a few drivers

lieve they will ultimately go to the rm -rf road too. Even Le 04/03/2021 à 17:32, 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, HT

Re: [gdal-dev] Moving GDAL GRASS driver in a dedicated repository ?

number of projects use the GDAL GRASS driver. Feedback from any affected projects would be helpful. Markus M On Thu, Nov 18, 2021 at 7:13 PM Even Rouault wrote: Hi, (writing to both GDAL and GRASS lists) Working on the transition to CMake as the GDAL build system, the particular

Re: [gdal-dev] GDAL 3.5.0alpha1 available

Le 22/03/2022 à 19:10, Sebastiaan Couwenberg a écrit : On 3/21/22 19:14, Even Rouault wrote: Other things you spotted ? A bunch of new data (and one ini) files, Those new data files are intended. I assume you're refering to drivers.ini ? This is intended too. and some helper scripts

Re: [gdal-dev] Is PAM always used before GeoTIFF tags?

Jukka, Le 22/03/2022 à 12:56, Rahkonen Jukka (MML) a écrit : Hi, See this question https://gis.stackexchange.com/questions/426418/create-rectified-geotiff-given-aux-xml-produced-from-arcgis? The GeoTIFF driver documentation https://gdal.org/drivers/raster/gtiff.html#georeferencing says abo

Re: [gdal-dev] GDAL 3.5.0alpha1 available

most idiomatic way to cross-compile for Android) Even Le 21/03/2022 à 00:05, Even Rouault a écrit : Hi, As discussed a few weeks ago, here's a GDAL 3.5.0alpha1 snapshot, mostly for the sake of exercising the new CMake build system (thanks to all early testers and contributors!). The li

Re: [gdal-dev] GDAL 3.5.0alpha1 available

Le 21/03/2022 à 18:39, Sebastiaan Couwenberg a écrit : Quite a lot of new files which suggests that CPACK_SOURCE_IGNORE_FILES needs more work. CPack hasn't been used at all to generate the tarball. This is the traditionnal mkgdaldist.sh script. I suspect this comes from gdal/ content having

Re: [gdal-dev] Why does ogrinfo use backtics in the output?

Hi Jukka, those backtics are there from day one: https://github.com/OSGeo/gdal/commit/3359e3f9f2b1d4c1197ab14395efe652eded37da . I suppose this is just for aesthetics. I assume this should be fine to change that to single quotes (although some downstream consumers that would dump ogrinfo outp

[gdal-dev] GDAL 3.5.0alpha1 available

Hi, As discussed a few weeks ago, here's a GDAL 3.5.0alpha1 snapshot, mostly for the sake of exercising the new CMake build system (thanks to all early testers and contributors!). The libtool numbers have *not* been updated (I believe they are still the same as the 3.3.0 release). This is not

Re: [gdal-dev] OGRCreateCoordinateTransformation()

Steve, Fix in PROJ queued in https://github.com/OSGeo/PROJ/pull/3123 The complexity of dealing with legacy features TOWGS84[] and PROJ4_GRIDS is highly stressing PROJ pipeline computation engine. Using the plain EPSG codes  EPSG:4955 -> EPSG:4617+5713 would be much preferable here Even Le

Re: [gdal-dev] CI status - passing on all platforms?

Le 18/03/2022 à 19:16, Greg Troxel a écrit : After fixing a shellcheck style nit, I force-pushed again and Ubuntu 18.04 32bit failed: https://github.com/gdt/gdal/runs/5600578897?check_suite_focus=true with final output === short test summary info =

Re: [gdal-dev] Translate HDF MODIS subdataset get dimensions wrong

You could certainly do that with the -array switch of https://gdal.org/programs/gdalmdimtranslate.html using a view expression that does subsetting (https://gdal.org/api/gdalmdarray_cpp.html#_CPPv4NK11GDALMDArray7GetViewERKNSt6stringE . similar to numpy slicing/indexing syntax) Use https://gd

Re: [gdal-dev] regular grid longlat netcdf without crs meta

Michael, Le 15/03/2022 à 06:06, Michael Sumner a écrit : Hi, these files don't present to GDAL with a CRS, but it seems not out of place to assume that they can use 'oSRS.SetWellKnownGeogCS("WGS84")', when no other indication is found and there are dimensions 'lon,lat' or 'longitude,latitude

Re: [gdal-dev] CMake and internal json-c

Hi, if you define both GDAL_USE_JSONC=ON and GDAL_USE_JSONC_INTERNAL=ON, the use of the internal variant will take precedence. It would be a good contribution to mention that in https://gdal.org/build_hints.html Technically, the report is correct: external json-c has been found. But it is no

Re: [gdal-dev] CMake and unexpected driver

Javier, GDAL_USE_ICONV=ON // otherwise it does not compile in Ubuntu 20.04 Fixed per https://github.com/OSGeo/gdal/commit/b183f2d9eb6c9dd7eefde194ced26d1913c06820 GDAL_USE_EXPAT=ON GDAL_USE_TIFF=ON GDAL_USE_GEOTIFF=ON GDAL_USE_JPEG=ON GDAL_USE_ZLIB=ON As you can see, PNG is not enabled. Actual

[gdal-dev] libgeotiff 1.7.1 is released

Hi, Source packages can be found at: http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.1.tar.gz http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.1.zip News is: * geotiff.h: more precise signature for GTIFDirectoryInfo() * applygeo.c/geotifcp.c: use uint16/32_t instead of

[gdal-dev] GDAL 3.4.2 is released

Hi, On behalf of the GDAL/OGR development team, I am pleased to announce the release of the GDAL/OGR 3.4.2 bug fix version. Consult the release notes for the list of issues addressed :   https://github.com/OSGeo/gdal/blob/v3.4.2/gdal/NEWS.md The sources are available at:     https://download.

Re: [gdal-dev] Motion: promote GDAL 3.4.2 RC2

Motion passed with +1 from PSC members JukkaR, HowardB, MateuszL and myself Le 10/03/2022 à 08:41, Even Rouault a écrit : Hi, Motion: Adopt GDAL 3.4.2 RC2 as final 3.4.2 release Starting with my +1 Even -- http://www.spatialys.com My software is free, but my time generally not

[gdal-dev] libgeotiff 1.7.1 rc2 available

http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.1rc2.tar.gz http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.1rc2.zip Even Le 08/03/2022 à 17:05, Even Rouault a écrit : Hi, I've prepared a libgeotiff 1.7.1 release candidate. http://download.osgeo.org/geotiff/libgeotiff/

[gdal-dev] Motion: promote GDAL 3.4.2 RC2

Hi, Motion: Adopt GDAL 3.4.2 RC2 as final 3.4.2 release Starting with my +1 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

Re: [gdal-dev] GDAL 3.4.2 RC2 available

Le 09/03/2022 à 20:53, Jeff McKenna a écrit : Thanks Even.  RC2 works well on Windows in the MS4W build environment. The only issue was that I had to re-apply the patch for Poppler 22.x (this is the known issue of course, that is well discussed https://lists.osgeo.org/pipermail/gdal-dev/2022-M

[gdal-dev] libgeotiff 1.7.1 release candidate

Hi, I've prepared a libgeotiff 1.7.1 release candidate. http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.1rc1.tar.gz http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.1rc1.zip I'll promote it to final later this week if nothing serious is reported on it before. News is:

[gdal-dev] GDAL 3.4.2 RC2 available

https://download.osgeo.org/gdal/3.4.2/gdalautotest-3.4.2rc2.zip GDAL-GRASS plugin:   https://download.osgeo.org/gdal/3.4.2/gdal-grass-3.4.2.tar.gz The NEWS file is here :   https://github.com/OSGeo/gdal/blob/v3.4.2RC2/gdal/NEWS.md Even Le 07/03/2022 à 12:26, Even Rouault a écrit : Hi, I have prepared a

[gdal-dev] GDAL 3.4.2 RC1 available

Hi, I have prepared a GDAL/OGR 3.4.2 release candidate. Pick up an archive among the following ones (by ascending size):   https://download.osgeo.org/gdal/3.4.2/gdal-3.4.2rc1.tar.xz   https://download.osgeo.org/gdal/3.4.2/gdal-3.4.2rc1.tar.gz   https://download.osgeo.org/gdal/3.4.2/gdal342rc1.z

Re: [gdal-dev] Attempting a coherent CMAKE problem report from a git clone- steps taken

Le 05/03/2022 à 06:30, chris english a écrit : Kai, Rebuilt Geos with your insight, and two spaces between all -D entries, including eliminating MrSid that was complied under gcc 521 or so and might likely cause problems, using GDAL build hints , and we have

Re: [gdal-dev] CMAKE poppler c++17

| Thereafter, MrSid driver cratered on some 2004 Lizardtech defines in lt_platform.h that defined possible GCC compilers topping out at <= 5 (rather than a future unimaginable 9 or 12). Removing a desire for MrSid, in this instance through ccmake, That's completely unrelated to building GDAL t

Re: [gdal-dev] CMAKE [ 89%] Built target gcore_mdreader *** target pattern contains no '%'

In some circumstances, stale CMake cache variables of previous failed builds remain, and make it hard to do new builds even after having correcting the error. You can solve this by removing CMakeCache.txt to have a clean cmake run. Le 04/03/2022 à 01:40, chris english a écrit : This subject l

Re: [gdal-dev] crunch lib

Can you be more explicit of what does not work exactly ? - I've just tried https://github.com/DaemonEngine/crunch and it does build, but doesn't install headers or a library file, so can't be easily used by GDAL - I've just tried successfully the build instructions at https://gdal.org/driver

Re: [gdal-dev] VRT dataset to text in-memory?

Michael, yes you can get the VRT XML text with: poVRTDS->GetMetadata("xml:VRT")[0] If you can submit a pull request documenting that, that would be welcome Even Le 03/03/2022 à 11:14, Michael Sumner a écrit : Hello, reading the raster VRT tutorial https://gdal.org/drivers/raster/vrt.html#cr

Re: [gdal-dev] gdal-utils: understanding the __main__ pattern

Matt, Le 04/03/2022 à 23:19, Matt Wilkie a écrit : Hello folks who know about the python script construction :) The pattern used in all of the python scripts under swig/python/gdal-utils is foreign to me. Can someone explain what's going on and why it's used? (or point to where this has been

Re: [gdal-dev] how to build netCDF driver plugin

- The filename is case sensitive: it must be gdal_netCDF.so/dll since the registration function is called GDALRegister_netCDF() - You need to set the GDAL_DRIVER_PATH environment variable to point to the directory where the driver is - You might find it easier when using master to use CMake: 

Re: [gdal-dev] OGREnvelope: add == and != comparison operators

Andrew, we have already suppression for such warning for the IsInit() method #ifdef HAVE_GCC_DIAGNOSTIC_PUSH #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wfloat-equal" #endif     /** Return whether the object has been initialized, that is, is non empty */     int  IsInit() const

Re: [gdal-dev] using the docker images: updating?

You're root by default inside the container when using docker with standard invokation, so no need of sudo Le 22/02/2022 à 15:31, Matt Wilkie a écrit : When using the docker images, particularly 'osogeo/gdal' from docker hub, sudo isn't available. How does one `apt update` etc? thanks! _

Re: [gdal-dev] "tolerance condition error" on reprojecting natural earth data to webmercator (3857)

This dataset includes latitude up to 90 degree north, which projects to infinity in EPSG:3857. You should use the -clipsrc option of ogr2ogr to for example cut at 85 degree Le 21/02/2022 à 10:14, Adam Akhtar via gdal-dev a écrit : Hi, I'm getting a "tolerance condition error" when trying to r

Re: [gdal-dev] docker images and gdal versions

Le 20/02/2022 à 20:10, Even Rouault a écrit : Matt, Le 20/02/2022 à 16:59, Matt Wilkie a écrit : I've been hearing of Docker for some time but haven't really tried to use it until this weekend. I'm early in the journey but I begin to see what the fuss is about. A quick ques

Re: [gdal-dev] docker images and gdal versions

Matt, Le 20/02/2022 à 16:59, Matt Wilkie a écrit : I've been hearing of Docker for some time but haven't really tried to use it until this weekend. I'm early in the journey but I begin to see what the fuss is about. A quick question: what gdal version(s) should I see when pulling the image nam

Re: [gdal-dev] Use GitPod for GDAL?

Matt, you need to install the "libproj-dev" package. Looking at the CI build recipees is a source of good hints in general: https://github.com/OSGeo/gdal/blob/6e6aff451dbcde450f051bff2f2e75ce6a4a3e6f/.github/workflows/cmake_builds.yml#L38 (this one has pretty much all the pre packaged dependen

Re: [gdal-dev] Gdal_translate into HDF4 fails

if you gdal_translate -of netCDF -co FORMAT=NC4 , the resulting netCDF file will actually be a HDF5 file (with netCDF "decorations"): - https://gdal.org/drivers/raster/netcdf.html#creation-options - https://www.unidata.ucar.edu/software/netcdf/docs/interoperability_hdf5.html Le 18/02/2022 à

Re: [gdal-dev] Gdal_translate into HDF4 fails

yes, this is sluggish . I just converted a 18002x22000 byte 3-band dataset in 28 minutes. Le 18/02/2022 à 13:44, Rahkonen Jukka (MML) a écrit : More information, probably it does not fail but it is extremely slow. After 15 minutes I am now at this stage gdal_translate -of HDF4Image 3band.ti

Re: [gdal-dev] [geos-devel] GEOS Maintenance Grant

attract directed funding in GEOS. The GEOS PSC will be responsible for coordinating work tasks, rates, and development timelines. Howard Butler or Even Rouault of the GDAL NumFocus liaison team will coordinate dispersement as directed by the GEOS PSC and NumFocus rules. >

Re: [gdal-dev] Adding OSGEO4W and gisinternals docs in install doc?

Excellent, so gisinternals qualifies for being mentioned. Le 17/02/2022 à 20:23, Tamas Szekeres a écrit : Currently the refactor is used in the build system. That is now working for quire some time so that it will be promoted to be the main branch. Best regards, Tamas Even Rouault ezt

Re: [gdal-dev] Adding OSGEO4W and gisinternals docs in install doc?

ding how to obtain them from the source repositories. The makefile also contains the necessary tweaks that had to be applied in a dependency if that required for a successful build. Best regards, Tamas Even Rouault ezt írta (időpont: 2022. febr. 17., Cs, 17:29):

Re: [gdal-dev] Adding OSGEO4W and gisinternals docs in install doc?

Thomas, One criterion currently for inclusion is: "In this section we list a number of the binary distributions of GDAL all of which should have fully reproducible open source build recipes." I've not evaluated what the current situation of OSGeo4W or gisinternals is regarding this, especial

Re: [gdal-dev] Matching ESRI projection/transformations using GDAL/OSR

Hi, I am attempting to project and transform geometry using OSR.  The projection/transformation is from ITRF2014 via Proj4 string to NAD83(CSRS)v7 (EPSG:8255).  My problem is that I need the transformation output to match the output I receive when transforming the geometry in ESRI using the

Re: [gdal-dev] GDAL COG random fringe on zoom levels

Hi Craig, fix queued in https://github.com/OSGeo/gdal/pull/5313 Even Le 17/12/2021 à 23:25, Craig Bruce a écrit : I tried to submit this issue on GitHub, but it wouldn't let me press the Submit button and wouldn't tell me why not. ## Expected behavior and actual behavior. The generation of

Re: [gdal-dev] Overcome Tiff limitation 32 KB

Le 16/02/2022 à 15:22, Lorenzo Di Giacomo a écrit : Hi devs, with the gdal 3.4.x is there a way to overcome the limitation of having more than 32KB of metadata in a GeoTiff file (aka using a different writing method for TIFF)? Thanks all! No, this is ticketed in https://github.com/OSGeo/gdal/is

Re: [gdal-dev] Strange (expected?) behaviour exporting multipart geometry to ESRI Shapefile format

Andrea, your [2] link contains the shapefile, not the GeoPackage file. That said I've tried replicated using https://github.com/qgis/QGIS/files/8058606/Issue47288_Polygons_GPKG.zip from the QGIS ticket and converting it to shapefile. The issue here is that the original geometry is not (consid

Re: [gdal-dev] GEOS Maintenance Grant

I motion to provide the GEOS PSC with a $50,000 USD grant to address performance, API, and other work that does not attract directed funding in GEOS. The GEOS PSC will be responsible for coordinating work tasks, rates, and development timelines. Howard Butler or Even Rouault of the GDAL

Re: [gdal-dev] Corrupted geopackage

I would just suggest using ogr2ogr to generate a new 'clean' GPKG file from the corrupted one. This will not recover lost data, but at least you'll get something sane. Well I should say "structurally" sane. depending on how the corruption happened you could get also get corrupted content in the

Re: [gdal-dev] GDAL, Proj and cacert

Hi, - What would be nice would be an explicit way of setting the default for PROJ. Since version 7 - PROJ has an ini file but it does not seem to include the cacert file. I can see why that might be seen as being a potential security hole - although I would point out that the ini file DOES a

Re: [gdal-dev] gdal-utils: Testing?

Le 12/02/2022 à 05:25, Matt Wilkie a écrit : Hi, Is there a way to run autotests/pytest only for gdal-utils, you meant autotest/pyscripts, right ? or only those tests that involve a certain folder tree? good question. The logic to locate the .py scripts is in get_py_script() function of auto

Re: [gdal-dev] GDAL, Proj and cacert

Le 11/02/2022 à 18:24, Paul Harwood a écrit : I have an application that uses GDAL with Proj Networking set on. This is a cross platform application. It works on some platforms but on mac (for instance) I get runtime errors like this GDAL failure (1) PROJ: Cannot open https://cdn.proj.org/u

Re: [gdal-dev] cmake status update - 99% good news!

Kai, there's a point I had in mind regarding your mention of static builds but forgot to mention. I consider GDAL static builds as inferior in term of capabilities compared to dynamic builds because: - they don't allow to have GDAL drivers built as plugins : due to the design of GDAL drivers

Re: [gdal-dev] Issue with resampling algorithm in gdal_array.DatasetReadAsArray python wrapper function

yte, ColorInterp=Red   Description = Red   Overviews: 95900x62066, 47950x31033, 23975x15516, 11987x7758, 5993x3879, 2996x1939, 1498x969, 749x484, 374x242 Band 2 Block=256x256 Type=Byte, ColorInterp=Green   Description = Green   Overviews: 95900x62066, 47950x31033, 23975x15516, 11987x7758, 5993x3879, 2996

Re: [gdal-dev] Issue with resampling algorithm in gdal_array.DatasetReadAsArray python wrapper function

Miguel, I am trying to use the gdal_array.DatasetReadAsArray function to extract a window from a 3B gtif file by indicating the dataset, the upper left corner image coordinates, the window size (256x256) at actual scale in the dataset, the desired buffer size (larger than actual size 341x341

Re: [gdal-dev] Encoding in single transaction shp to PG

Matteo, you can define open options for each source layer in a VRT: https://github.com/OSGeo/gdal/blob/c03502bc9eb5f8c9b25a8d0de06e009bf9756548/data/ogrvrt.xsd#L66 Even Le 10/02/2022 à 11:46, matteo a écrit : Hi all, I've set up a QGIS Processing script that uses GdalUtils that takes a vrt

Re: [gdal-dev] Access violation OGRSpatialReference.importFromESRI() in GDAL304.dll

RTF(antastic)M :-) ==> https://gdal.org/doxygen/classOGRSpatialReference.html#af91af2639702e2793daf93ffe231b577 : Parameters papszPrj NULL terminated list of strings containing the definition. So change your code to something like:   char apszPrj[2];   char* s = proj.GetBuffer();   a

<    6   7   8   9   10   11   12   13   14   15   >