osgeo / libgeotiff Goto Github PK

Official repository of the libgeotiff project

HTML 48.24% CSS 0.50% Shell 0.37% CMake 1.07% Makefile 0.32% C 21.39% M4 1.28% Roff 0.31% Rich Text Format 26.10% Pawn 0.41%

geotiff library geospatial gis

libgeotiff's Introduction

libgeotiff

This library is designed to permit the extraction and parsing of the "GeoTIFF" Key directories, as well as definition and installation of GeoTIFF keys in new files. More information about GeoTIFF specifications, projection codes and use can be found here. Information on the mailing list and archived SVN repository can be found here

Archived releases can be found on the GitHub releases page or the OSGeo archive page

To ask questions and to follow release announcements, subscribe at the mailing list.

You can also report issues (do not use issue tracker for questions)

Dependencies

LibTIFF

PROJ

SQLite3, as a dependency of PROJ

Compilation Instructions

libgeotiff supports out of tree builds.

Linux

cd libgeotiff
./autogen.sh
./configure
make dist
tar xvzf libgeotiff*.tar.gz
cd libgeotiff*
mkdir build_autoconf
cd build_autoconf
CFLAGS="-Wall -Wextra -Werror" ../configure
make -j3
make check
cd ..
mkdir build_cmake
cd build_cmake
cmake -DCMAKE_C_COMPILER_LAUNCHER=ccache -DCMAKE_C_FLAGS="-Wall -Wextra -Werror" ..
make -j3

Windows

libgeotiff should work with the Visual Studio toolchain. See .appveyor.yml for example.

cd libgeotiff
mkdir build && cd build
cmake -G "%VS_FULL%" .. -DBUILD_SHARED_LIBS=ON -DCMAKE_BUILD_TYPE=Release  -DCMAKE_C_FLAGS="/WX" -DCMAKE_CXX_FLAGS="/WX"  -DCMAKE_INSTALL_PREFIX="%BUILD_FOLDER%/install" -DPROJ_INCLUDE_DIR="%BUILD_FOLDER%/install/include" -DPROJ_LIBRARY="%BUILD_FOLDER%/install/lib/proj.lib" -DCMAKE_TOOLCHAIN_FILE=c:/projects/libgeotiff/vcpkg/scripts/buildsystems/vcpkg.cmake

cmake --build . --config Release --target install

Testing

There are two demonstration test programs makegeo and listgeo that create and list-out the GeoTIFF tags and keys associated with a small TIFF file, as well as a full-featured utility called geotifcp. These will all be built in the bin/ directory as a matter of course, though may require modification if you are not using LibTIFF, as they make explicit calls to LibTIFF for opening the files and setting the tags.

To run them simply call:

./makegeo

./listgeo newgeo.tif

to generate and list an example GeoTIFF file. To see the geotifcp utility in action, first call:

listgeo newgeo.tif > metadata.txt

to create a GeoTIFF metadata file metadata.txt, and then

geotifcp -g metadata.txt newgeo.tif newer.tif

to copy the TIFF file newgeo.tif to newer.tif, using the GeoTIFF metadata as stored in metadata.txt. See docs/manual.txt for further uses of geotifcp.

To convert a projection metafile, an ESRI world file, and a raw TIFF file into a GeoTIFF file do something like the following:

tiffcp -g metadata.txt -e abc.tfw abc.tif geo_abc.tif

License

Credits

This library was originally written by Niles Ritter (also the primary author of the GeoTIFF specification).
Eric Brown of Universal Systems, who contributed a bug fix to GTIFPCSToImage().
Safe Software who supported by upgrade to use the EPSG 6.2.2 database for libgeotiff 1.2.0.
Many others who contributed before it occured to me to maintain credits.

libgeotiff's People

Contributors

Stargazers

Watchers

Forkers

rouault ajolma cgx-group hongbowei algunenano jangeofan jmckenna duzhigang2018 lsxinh2 junjie2008v kubaszostak winbuilds oss-qm matzeri magicpixel-dev pwernette baazigar007 gajgeospatial fivitti qing666888 jkrollpq tyronebj terkwood shenyczz crghilardi agr shenjianzi redeom fralaz1971 longervision a0x8o lych venabled raoufriahi vb6hobbyst7 opengisch gaoshuai preetkhaturia yunqian236 googleol dg0yt isabella232 zeratal ashlinrichardson baptistapedro jscheumann klose28 koordinates warlock8hz cnheider lushangkun akheg olegzhavoronkov tomleelive caiohamamura cai880210 koobin mechanicalsoftworks schwehr sebastic bodyakho wolfi-chainguard-demo xifeng205 8502596 luoxz-ai

libgeotiff's Issues

License cleanup?

Referring to https://github.com/OSGeo/libgeotiff/blob/5d6619c1168845c5bd77686f01e197a82854cbf1/libgeotiff/LICENSE

For the code outside of cmake macros, can we standardize on the exact text of https://spdx.org/licenses/MIT.html ?

The x style license text is vague and bit of trouble.

This is also vague and confusing. Can we make it all MIT? Folks could then go back in the git history if they want to get to a public domain version.

All the source code in this toolkit are either in the public domain, or under an X style license.

Thoughts? @warmerdam @rouault

Also, I don't know Niles D. Ritter. Do we have current contact info?

cc: @teeler

1.6.0: test suite is failing

+ cd libgeotiff-1.6.0
+ /usr/bin/make -O -j48 V=1 VERBOSE=1 check
Making check in libxtiff
make[1]: Nothing to be done for 'check'.
Making check in .
Making check in bin
make[1]: Nothing to be done for 'check'.
Making check in man
Making check in man1
make[2]: Nothing to be done for 'check'.
make[2]: Nothing to be done for 'check-am'.
Making check in cmake
make[1]: Nothing to be done for 'check'.
Making check in test
/usr/bin/make  check-local
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/libgeotiff-1.6.0/test'
../test/testlistgeo ../bin/listgeo
============================================
Running ../test/testlistgeo using ../bin/listgeo:
============================================
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
diff testlistgeo_out with testlistgeo_out.dist
--- testlistgeo_out     2021-03-26 20:16:43.122509207 +0000
+++ testlistgeo_out.dist.tmp    2021-03-26 20:16:43.117509197 +0000
@@ -1566,6 +1566,9 @@
    ProjFalseEastingGeoKey: 649328.000000 m
    ProjFalseNorthingGeoKey: 665262.000000 m
 GCS: 4258/ETRS89
+Datum: 6258/European Terrestrial Reference System 1989
+Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
+Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
 Projection Linear Units: 9001/metre (1.000000m)

 Corner Coordinates:
@@ -1616,6 +1619,9 @@
    ProjFalseEastingGeoKey: 649328.000000 m
    ProjFalseNorthingGeoKey: 665262.000000 m
 GCS: 4258/ETRS89
+Datum: 6258/European Terrestrial Reference System 1989
+Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
+Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
 Projection Linear Units: 9001/metre (1.000000m)

 Corner Coordinates:
@@ -1744,6 +1750,9 @@
    ProjFalseEastingGeoKey: 4321000.000000 m
    ProjFalseNorthingGeoKey: 3210000.000000 m
 GCS: 4258/ETRS89
+Datum: 6258/European Terrestrial Reference System 1989
+Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
+Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
 Projection Linear Units: 9001/metre (1.000000m)

 Corner Coordinates:
@@ -1790,6 +1799,9 @@
    ProjFalseEastingGeoKey: 4321000.000000 m
    ProjFalseNorthingGeoKey: 3210000.000000 m
 GCS: 4258/ETRS89
+Datum: 6258/European Terrestrial Reference System 1989
+Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
+Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
 Projection Linear Units: 9001/metre (1.000000m)

 Corner Coordinates:

PROBLEMS HAVE OCCURRED
test file testlistgeo_out saved

Test failures with PROJ 9.3.0

The Debian package build fails with PROJ 9.3.0-rc1:

--- testlistgeo_out     2023-08-29 03:55:10.645106504 +0000
+++ testlistgeo_out.dist.tmp    2023-08-29 03:55:10.641106501 +0000
@@ -1822,8 +1822,8 @@
    ProjNatOriginLongGeoKey: 0.000000 (  0d 0' 0.00"E)
    ProjFalseEastingGeoKey: 0.000000 m
    ProjFalseNorthingGeoKey: 0.000000 m
-GCS: 10346/NSIDC Authalic Sphere
-Datum: 1360/NSIDC International 1924 Authalic Sphere
+GCS: 4053/Unspecified datum based upon the International 1924 Authalic Sphere
+Datum: 6053/Not specified (based on International 1924 Authalic Sphere)
 Ellipsoid: 7057/International 1924 Authalic Sphere (6371228.00,6371228.00)
 Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
 Projection Linear Units: 9001/metre (1.000000m)

PROBLEMS HAVE OCCURRED
test file testlistgeo_out saved

gdal nodata

Can somebody explain to me why the latest release no longer supports the gdal nodata tag?

geotiff-config.cmake lacks several things

See OSGeo/gdal#5341 for details

Configure fails because it does not find libz although --with-libz is given.

When libz is not where it normally would be, configure fails testing libtiff because it does not find libz.so.

Adding LIBS="-L${with_zip}/lib -lz $LIBS" to line 143 in configure.ac fixes the problem.

configure:15019: checking for TIFFOpen in -ltiff
configure:15044: gcc -o conftest -g -O2 -O3 -DNDEBUG   conftest.c -ltiff -lm -L/home/ajolma/iptim/server/parts/tiff/lib -ltiff -lz -lm   >&5
/usr/bin/ld: cannot find -lz
collect2: error: ld returned 1 exit status

vs after the fix

configure:15061: checking for TIFFOpen in -ltiff
configure:15086: gcc -o conftest -g -O2 -O3 -DNDEBUG   conftest.c -ltiff -lm -L/home/ajolma/iptim/server/parts/tiff/lib -ltiff -L/home/ajolma/iptim/server/parts/zlib/lib -lz -lz -lm   >&5
configure:15086: $? = 0
configure:15095: result: yes

proj_uom_get_info_from_database: unit of measure not found

I've upgraded to GDAL 3.0.4 and libgeotiff 5.0.1 (packages from Ubuntu 18.04 LTS to 20.04 LTS) and all my software that uses OGRSpatialReference to perform coordinate transformation on GeoTIFF data sets is now broken.
Basically when opening a data set (also via gdalinfo)
I get:
proj_create_from_database: prime meridian not found
proj_uom_get_info_from_database: unit of measure not found

I've cloned the latest source and built libgeotiff myself. Now on version 5.1.0 I get only:
proj_uom_get_info_from_database: unit of measure not found

so still unable to use the conversion functionalities.

heres the output of gdalinfo for this issue (with 5.1.0) (color palette is removed for convenience)

Driver: GTiff/GeoTIFF Files: gbr_lfc-day_gsgs_20130919_lcc.tif Size is 18004, 24604 proj_uom_get_info_from_database: unit of measure not found Coordinate System is: PROJCRS["Lambert Conformal Conic; WGS84; WGS84", BASEGEOGCRS["WGS_1984", DATUM["World Geodetic System 1984", ELLIPSOID["WGS 84",6378137,298.257223563, LENGTHUNIT["metre",1]], ID["EPSG",6326]], PRIMEM["Greenwich",0, ANGLEUNIT["unknown",0.0174532925199433]]], CONVERSION["Lambert Conic Conformal (2SP)", METHOD["Lambert Conic Conformal (2SP)", ID["EPSG",9802]], PARAMETER["Latitude of false origin",54.375, ANGLEUNIT["degree",0.0174532925199433], ID["EPSG",8821]], PARAMETER["Longitude of false origin",-3.3, ANGLEUNIT["degree",0.0174532925199433], ID["EPSG",8822]], PARAMETER["Latitude of 1st standard parallel",57.3333333333333, ANGLEUNIT["degree",0.0174532925199433], ID["EPSG",8823]], PARAMETER["Latitude of 2nd standard parallel",49.3333333333333, ANGLEUNIT["degree",0.0174532925199433], ID["EPSG",8824]], PARAMETER["Easting at false origin",0, LENGTHUNIT["metre",1], ID["EPSG",8826]], PARAMETER["Northing at false origin",0, LENGTHUNIT["metre",1], ID["EPSG",8827]]], CS[Cartesian,2], AXIS["easting",east, ORDER[1], LENGTHUNIT["metre",1, ID["EPSG",9001]]], AXIS["northing",north, ORDER[2], LENGTHUNIT["metre",1, ID["EPSG",9001]]]] Data axis to CRS axis mapping: 1,2 Origin = (-354481.960000000020955,661473.700000000069849) Pixel Size = (50.000000000000000,-50.000000000000000) Metadata: AREA_OR_POINT=Area TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) TIFFTAG_XRESOLUTION=254 TIFFTAG_YRESOLUTION=254 Image Structure Metadata: COMPRESSION=LZW INTERLEAVE=BAND Corner Coordinates: Upper Left ( -354481.960, 661473.700) ( 9d39'44.27"W, 60d10'13.56"N) Lower Left ( -354481.960, -568726.300) ( 8d 9'41.01"W, 49d 8'45.62"N) Upper Right ( 545718.040, 661473.700) ( 6d27'33.75"E, 59d58'40.26"N) Lower Right ( 545718.040, -568726.300) ( 4d10' 5.65"E, 48d59'51.66"N) Center ( 95618.040, 46373.700) ( 1d48'37.91"W, 54d47' 0.74"N)

Support button is not placed perfectly in the website

Before

After solving the issue

Local-directory -I flags mis-passed in Makefile.am

Building libgeotiff-1.6.0 on OS X 10.13:

$ CPPFLAGS=-I/sw/include LDFLAGS=-L/sw/lib ./configure --prefix=/sw --with-zip=/usr/include --with-jpeg=/sw --disable-doxygen-doc
[...]
  zlib support......: yes
  jpeg support......: yes
  TIFF support......: yes
    -INCLUDE .......: -I/sw/include
    -PREFIX ........: 
  PROJ support......: yes
    -INCLUDE .......: 
  LIBS.....................: -L/sw/lib -ljpeg -lz -lm -L/sw/lib  -L/sw/lib -ltiff -L/sw/lib -lproj
$ make
[...]
make[2]: Entering directory '/sw/build.build/libgeotiff5-1.6.0-1/libgeotiff-1.6.0/bin'
gcc -DHAVE_CONFIG_H -I. -I..   -Os -I/sw/include -I../  -I./.. -I./../libxtiff -I/sw/include -DHAVE_TIFF=1  -g -O2 -O3 -DNDEBUG -MT geotifcp.o -MD -MP -MF .deps/geotifcp.Tpo -c -o geotifcp.o geotifcp.c
[...]
/bin/sh ../libtool  --tag=CC   --mode=link gcc -I../  -I./.. -I./../libxtiff -I/sw/include -DHAVE_TIFF=1  -g -O2 -O3 -DNDEBUG  -L/sw/lib -o geotifcp geotifcp.o ../libgeotiff.la -L/sw/lib -ljpeg -lz -lm -L/sw/lib  -L/sw/lib -ltiff -L/sw/lib -lproj

The weird is that there are -I flags going to the linker. The bug is "-I/sw/include -I../ -I./.. -O../../libxtiff", which causes build failure because externally installed headers will be found in preference to ones in the source distro. Local -I should always come before any global/external ones. The same thing happens for all compiling in bin/ and the top-level dir.

All of this is because Makefile.am are passing local -I via AM_CFLAGS instead of AM_CPPFLAGS. "CFLAGS" is the "C compiler" (.c→.o and linking), whereas "CPPFLAGS" is "the →.o stage".

Unable to configure using PROJ 9.0.0

I am attempting to build from source on RHEL 8.5, linking to my compiled version of libtiff (4.3) and PROJ (9.0.0). However, when I try to configure the installer using --with-proj pointing to my version of PROJ 9, I am getting the error:

./configure --prefix=/data/software/geotiff/1.7.1-gcc850 --with-proj=/data/software/proj/9.0.0 --with-libtiff=/data/software/libtiff/4.3.0 --with-zlib --with-jpeg

the error

checking for PROJ >= 6 library... checking for proj_create_from_wkt in -lproj... no
checking for proj_create_from_wkt in -lproj... no
checking for internal_proj_create_from_wkt in -lproj... no
checking for internal_proj_create_from_wkt in -lproj... no
checking for internal_proj_create_from_wkt in -linternalproj... no
checking for internal_proj_create_from_wkt in -linternalproj... (cached) no
configure: error: PROJ 6 symbols not found

But if I link to an older PROJ, 7.0.0

./configure --prefix=/data/software/geotiff/1.7.1-gcc850 --with-proj=/data/software/proj/7.0.0 --with-libtiff=/data/software/libtiff/4.3.0 --with-zlib --with-jpeg

it configures fine

libgeotiff configuration summary:

  Version..................: 1.7.1
  Installation directory...: /data/software/geotiff/1.7.1-gcc850
  C compiler...............: gcc -g -O2 -O3 -DNDEBUG
  Debugging support........:

  zlib support......: yes
  jpeg support......: yes
  TIFF support......: yes
    -INCLUDE .......: -I/data/software/libtiff/4.3.0/include
    -PREFIX ........:
  PROJ support......: yes
    -INCLUDE .......:  -I/data/software/proj/7.0.0/include
  LIBS.....................: -L/data/software/proj/7.0.0/lib -lproj -L/data/software/libtiff/4.3.0/lib -ltiff -ljpeg -lz -lm

  libgeotiff - http://trac.osgeo.org/geotiff

I am not really sure what might be causing the error in this case. Any help would be appreciated! Thanks

appveyor cmake install trouble

I'm seeing a CMake install error on the appveyor builds. I tried downloading the zip on my local linux machine and I can and I can do a unzip -l on it, but I don't know what specifically is wrong.

Build started
Fetching repository commit (836[2](https://ci.appveyor.com/project/OSGeo/libgeotiff/builds/48299944/job/wolns9jbx3gkjw4g#L2)a69)...OK
Total: 4 MB in [3](https://ci.appveyor.com/project/OSGeo/libgeotiff/builds/48299944/job/wolns9jbx3gkjw4g#L3)25 files
echo build_script
build_script
set "BUILD_FOLDER=%APPVEYOR_BUILD_FOLDER:\=/%"
if "%platform%" == "x6[4](https://ci.appveyor.com/project/OSGeo/libgeotiff/builds/48299944/job/wolns9jbx3gkjw4g#L4)" SET VS_FULL=%VS_VERSION% Win64
if "%platform%" == "x86" SET VS_FULL=%VS_VERSION%
echo "%VS_FULL%"
"Visual Studio 1[5](https://ci.appveyor.com/project/OSGeo/libgeotiff/builds/48299944/job/wolns9jbx3gkjw4g#L5) Win[6](https://ci.appveyor.com/project/OSGeo/libgeotiff/builds/48299944/job/wolns9jbx3gkjw4g#L6)4"
git clone https://github.com/microsoft/vcpkg
Cloning into 'vcpkg'...
Updating files: 100% (10[7](https://ci.appveyor.com/project/OSGeo/libgeotiff/builds/48299944/job/wolns9jbx3gkjw4g#L7)43/10743), done.
cd vcpkg
bootstrap-vcpkg.bat
Downloading https://github.com/microsoft/vcpkg-tool/releases/download/2023-09-15/vcpkg.exe -> C:\projects\libgeotiff\vcpkg\vcpkg.exe... done.
Validating signature... done.
vcpkg package management program version 2023-09-15-ac02a9f660977426b[8](https://ci.appveyor.com/project/OSGeo/libgeotiff/builds/48299944/job/wolns9jbx3gkjw4g#L8)ec63[9](https://ci.appveyor.com/project/OSGeo/libgeotiff/builds/48299944/job/wolns9jbx3gkjw4g#L9)2919fbb1d51b[10](https://ci.appveyor.com/project/OSGeo/libgeotiff/builds/48299944/job/wolns9jbx3gkjw4g#L10)998
See LICENSE.txt for license information.
Telemetry
---------
vcpkg collects usage data in order to help us improve your experience.
The data collected by Microsoft is anonymous.
You can opt-out of telemetry by re-running the bootstrap-vcpkg script with -disableMetrics,
passing --disable-metrics to vcpkg on the command line,
or by setting the VCPKG_DISABLE_METRICS environment variable.
Read more about vcpkg telemetry at docs/about/privacy.md
set PATH=%CD%;%PATH%
cd ..
vcpkg install tiff:"%platform%"-windows
Computing installation plan...
A suitable version of cmake was not found (required v3.27.1) Downloading portable cmake 3.27.1...
Downloading cmake...
https://github.com/Kitware/CMake/releases/download/v3.27.1/cmake-3.27.1-windows-i386.zip->C:\projects\libgeotiff\vcpkg\downloads\cmake-3.27.1-windows-i386.zip
Downloading https://github.com/Kitware/CMake/releases/download/v3.27.1/cmake-3.27.1-windows-i386.zip
Extracting cmake...
'CMake' failed while extracting C:\projects\libgeotiff\vcpkg\downloads\cmake-3.[27](https://ci.appveyor.com/project/OSGeo/libgeotiff/builds/48299944/job/wolns9jbx3gkjw4g#L27).1-windows-i[38](https://ci.appveyor.com/project/OSGeo/libgeotiff/builds/48299944/job/wolns9jbx3gkjw4g#L38)6.zip.

Can't build

Can't go to "libgeotiff".
Please change build instructions to cd libgeotiff/libgeotiff.

Can't run ./configure --with-proj=.... : bash: ./configure: No such file or directory

doc directory may be incorrectly installed in CMAKE_INSTALL_PREFIX

In line 287-290 of the top level CMakeLists.txt, the install command for the documents directory is hard-coded to the relative path "doc".

# Install doc files
INSTALL(FILES
    AUTHORS ChangeLog COPYING INSTALL LICENSE README README_BIN README.WIN
    DESTINATION doc)
#    DESTINATION ${GEOTIFF_DATA_DIR}/doc)

If a user (like myself) is building libgeotiff by itself via the ExternalPackage_Add command, and only building libgeotiff, this has the effect of installing "doc" in the directory defined by CMAKE_INSTALL_PREFIX, instead of CMAKE_INSTALL_PREFIX/share. I believe this is caused byt the SOURCE_SUBDIR line being necessary to let CMake know where to look for the CMakeLists.txt file.

It looks like this was supported at one time, but now it's commented out. Was that a mistake/typo? In any case, it would seem like a good idea to have the installation directory modifiable by the user.

For reference: This is the command used for building libgeotiff.so from the tarball. (My md5 is different from the release due to the xz repackaging.)

ExternalProject_Add(geotiff
	URL  ${CMAKE_CURRENT_SOURCE_DIR}/libgeotiff-1.5.1.tar.xz
	URL_MD5 bfd2bd41c36c78fcbf0fbe2eddf34bb4
	PREFIX ${CMAKE_CURRENT_BINARY_DIR}/libgeotiff
--->	SOURCE_SUBDIR libgeotiff
	INSTALL_DIR ${CMAKE_INSTALL_PREFIX}
	CMAKE_ARGS -DCMAKE_PREFIX_PATH=<INSTALL_DIR>
	    -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>
	    -DCMAKE_INSTALL_LIBDIR=<INSTALL_DIR>/lib			   	   
            -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}				  
	    -DBUILD_PROJ=TRUE
	    -DPROJ_TESTS=OFF
	    -DENABLE_LTO=ON
	    -DWITH_JPEG=TRUE			  
	LOG_CONFIGURE 1
	LOG_BUILD 1
	LOG_INSTALL 1
)

Test failures on non-amd64 architectures

The libgeotiff 1.5.1 Debian package failed to build on most non-amd64 architectures due to test failures, see:

https://buildd.debian.org/status/package.php?p=libgeotiff&suite=experimental

arm64, armel, armhf, mips, mips64el, mipsel, ppc64el, s390x, hppa, ppc64, riscv64, sparc64:

============================================
Running ../test/testlistgeo using ../bin/listgeo:
============================================
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
diff testlistgeo_out with testlistgeo_out.dist
--- testlistgeo_out	2019-04-01 19:17:58.480341513 +0000
+++ ../test/testlistgeo_out.dist	2019-03-25 15:31:36.000000000 +0000
@@ -221,11 +221,11 @@
 Projection Linear Units: 9036/kilometre (1000.000000m)
 
 Corner Coordinates:
-Upper Left    (  440720.000, 3751320.000)  (2147483647d2147483647'  inf"E,2147483647d2147483647'  inf"N)
-Lower Left    (  440720.000, 3751260.000)  (2147483647d2147483647'  inf"E,2147483647d2147483647'  inf"N)
-Upper Right   (  440780.000, 3751320.000)  (2147483647d2147483647'  inf"E,2147483647d2147483647'  inf"N)
-Lower Right   (  440780.000, 3751260.000)  (2147483647d2147483647'  inf"E,2147483647d2147483647'  inf"N)
-Center        (  440750.000, 3751290.000)  (2147483647d2147483647'  inf"E,2147483647d2147483647'  inf"N)
+Upper Left    (  440720.000, 3751320.000)  (-2147483648d-2147483648'  inf"E,-2147483648d-2147483648'  inf"N)
+Lower Left    (  440720.000, 3751260.000)  (-2147483648d-2147483648'  inf"E,-2147483648d-2147483648'  inf"N)
+Upper Right   (  440780.000, 3751320.000)  (-2147483648d-2147483648'  inf"E,-2147483648d-2147483648'  inf"N)
+Lower Right   (  440780.000, 3751260.000)  (-2147483648d-2147483648'  inf"E,-2147483648d-2147483648'  inf"N)
+Center        (  440750.000, 3751290.000)  (-2147483648d-2147483648'  inf"E,-2147483648d-2147483648'  inf"N)
 
 Testing listgeo ../test/data/ProjectedCSTypeGeoKey_28191_cassini_soldner.tif
 Geotiff_Information:

PROBLEMS HAVE OCCURRED
test file testlistgeo_out saved

i386:

============================================
Running ../test/testlistgeo using ../bin/listgeo:
============================================
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
diff testlistgeo_out with testlistgeo_out.dist
--- testlistgeo_out	2019-04-01 19:45:33.009738947 +0000
+++ ../test/testlistgeo_out.dist	2019-03-25 15:31:36.000000000 +0000
@@ -1429,7 +1429,7 @@
 Projection = 17515 (South African Survey Grid zone 15)
 Projection Method: CT_TransvMercator_SouthOrientated
    ProjNatOriginLatGeoKey: 0.000000 (  0d 0' 0.00"N)
-   ProjNatOriginLongGeoKey: 15.000000 ( 15d 0' 0.00"E)
+   ProjNatOriginLongGeoKey: 15.000000 ( 14d60' 0.00"E)
    ProjScaleAtNatOriginGeoKey: 1.000000
    ProjFalseEastingGeoKey: 0.000000 m
    ProjFalseNorthingGeoKey: 0.000000 m
@@ -1791,7 +1791,7 @@
 PCS = 3410 (NSIDC EASE-Grid Global)
 Projection = 19869 (US NSIDC Equal Area global projection)
 Projection Method: CT_CylindricalEqualArea
-   ProjStdParallel1GeoKey: 30.000000 ( 30d 0' 0.00"N)
+   ProjStdParallel1GeoKey: 30.000000 ( 29d60' 0.00"N)
    ProjNatOriginLongGeoKey: 0.000000 (  0d 0' 0.00"E)
    ProjFalseEastingGeoKey: 0.000000 m
    ProjFalseNorthingGeoKey: 0.000000 m

PROBLEMS HAVE OCCURRED
test file testlistgeo_out saved

Readme step provides error

For Linux builds, the README.md gives the following steps:

cd libgeotiff
mkdir build && cd build
./autogen.sh

However, autogen.sh does not exist in the newly-created build/ directory (and running ../autogen.sh complains about missing files). Is mkdir build && cd build unnecessary (or did I just set something up incorrectly)?

pre-compiled geotifcp.exe

Would it be possible to include a pre-compiled geotifcp.exe for those of that don't have access the Visual Studio and just want to use the exe to create geotifs?

Fixing wrong eol

In openSUSE packaging we used to have this bash part to fix utf-8 and wrong eol in source code.

for f in `find . -type f` ; do
        if file $f | grep -q ISO-8859 ; then
                echo "Fix encoding for $f"
                set -x
                iconv -f ISO-8859-1 -t UTF-8 $f > ${f}.tmp && \
                        mv -f ${f}.tmp $f
                set +x
        fi
        if file $f | grep -q CRLF ; then
                echo "Fix line ends for $f"
                set -x
                sed -i -e 's|\r||g' $f
                set +x
        fi
done

While checking 1.5.0 future release I picked still some files that should be fixed

Fix line ends for ./cmake/FindGeoTIFF.cmake
+ sed -i -e 's|\r||g' ./cmake/FindGeoTIFF.cmake

Fix line ends for ./cmake/FindPROJ.cmake
+ sed -i -e 's|\r||g' ./cmake/FindPROJ.cmake

Fix line ends for ./cmake/geo_config.h.in
+ sed -i -e 's|\r||g' ./cmake/geo_config.h.in

Fix line ends for ./bin/CMakeLists.txt
+ sed -i -e 's|\r||g' ./bin/CMakeLists.txt

Fix line ends for ./libxtiff/CMakeLists.txt
+ sed -i -e 's|\r||g' ./libxtiff/CMakeLists.txt

If PR are allowed now here directly I should be able to send it.

Re-add GTIFDeaccessCSV and SetCSVFilenameHook

https://lists.osgeo.org/pipermail/geotiff/2019-March/000853.html

Provide a libgeotiff-config

Each OS will install libgeotiff headers to a different locations:

/usr/include/geotiff
/usr/include/libgeotiff
...

So it is hard and non-reliable to create a proper configure file to link to libgeotiff and its headers.

The reliable way would be to provide a libgeotiff-config binary to allow cross-platform compilation, just like geos and gdal.

Would it be feasible or is there a better way to link to libgeotiff that I'm missing?

Feature request: Support TIFF tags 42112 (0xa480) and 42113 (0xa481)

Now these are reported as:

TIFFReadDirectory: Warning, Unknown field with tag 42112 (0xa480) encountered.
TIFFReadDirectory: Warning, Unknown field with tag 42113 (0xa481) encountered.

These are GDAL_METADATA and GDAL_NODATA according to:

https://www.awaresystems.be/imaging/tiff/tifftags/gdal_metadata.html

https://www.awaresystems.be/imaging/tiff/tifftags/gdal_nodata.html

I use geotiff 1.5.1-2 on Ubuntu 20.04.2 LTS.

libgeotiff build fails with proj 6.2

libgeotiff fails to build with proj 6.2. I have shown the relevant section of the build log below. I am building libgeotiff using ./configure; make.

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I./libxtiff -I/gnu/store/xadnwgnpxwji8790ckh1swm8282zkl9q-proj-6.2.0/include -DHAVE_LIBPROJ=1 -DHAVE_PROJECTS_H=1 -I/gnu/store/9y286xq1m1aa78hhr48ln5mn2gahrbp3-libtiff-4.0.10/include -DHAVE_TIFF=1 -DCSV_DATA_DIR=\"/gnu/store/49afx1rq91lm0l279lrim3hlwz19pk2g-libgeotiff-1.4.3/share/epsg_csv\" -g -O2 -O3 -DNDEBUG -MT geo_strtod.lo -MD -MP -MF .deps/geo_strtod.Tpo -c geo_strtod.c -o geo_strtod.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I./libxtiff -I/gnu/store/xadnwgnpxwji8790ckh1swm8282zkl9q-proj-6.2.0/include -DHAVE_LIBPROJ=1 -DHAVE_PROJECTS_H=1 -I/gnu/store/9y286xq1m1aa78hhr48ln5mn2gahrbp3-libtiff-4.0.10/include -DHAVE_TIFF=1 -DCSV_DATA_DIR=\"/gnu/store/49afx1rq91lm0l279lrim3hlwz19pk2g-libgeotiff-1.4.3/share/epsg_csv\" -g -O2 -O3 -DNDEBUG -MT geotiff_proj4.lo -MD -MP -MF .deps/geotiff_proj4.Tpo -c geotiff_proj4.c  -fPIC -DPIC -o .libs/geotiff_proj4.o
In file included from geotiff_proj4.c:1377:0:
/gnu/store/xadnwgnpxwji8790ckh1swm8282zkl9q-proj-6.2.0/include/proj_api.h:37:2: error: #error 'To use the proj_api.h you must define the macro ACCEPT_USE_OF_DEPRECATED_PROJ_API_H'
 #error 'To use the proj_api.h you must define the macro ACCEPT_USE_OF_DEPRECATED_PROJ_API_H'
  ^~~~~
make[2]: *** [Makefile:761: geotiff_proj4.lo] Error 1
make[2]: Leaving directory '/tmp/guix-build-libgeotiff-1.4.3.drv-0/libgeotiff-1.4.3'
make[1]: *** [Makefile:848: all-recursive] Error 1
make[1]: Leaving directory '/tmp/guix-build-libgeotiff-1.4.3.drv-0/libgeotiff-1.4.3'
make: *** [Makefile:605: all] Error 2

Thank you for your time! :-)

listgeo reports incorrect corner coordinates if RasterPixelIsPoint is set

listgeo currently treats all GeoTIFFs as if the RasterPixelIsArea is set, leading to incorrectly reported corner coordinates if RasterPixelIsPoint is set instead. It should report them as specified here.

Example:

I created a rasterized sample data in WGS 84, where the coordinates pixel center of the top left corner are exactly (-81.38, -0.04) and the ones of the bottom right pixel center are (-68.65, -18.45). listgeo reports the following:

Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
      ModelTiepointTag (2,3):
         0                 0                 0                
         -81.38            -0.04             0                
      ModelPixelScaleTag (1,3):
         0.0212520868113522 0.0307345575959933 0                
      End_Of_Tags.
   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeGeographic
      GTRasterTypeGeoKey (Short,1): RasterPixelIsPoint
      GeographicTypeGeoKey (Short,1): GCS_WGS_84
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      End_Of_Keys.
   End_Of_Geotiff.

GCS: 4326/WGS 84
Datum: 6326/World Geodetic System 1984
Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
Projection Linear Units: User-Defined (1.000000m)

Corner Coordinates:
Upper Left    (-81.3800000,-0.0400000)
Lower Left    (-81.3800000,-18.4807346)
Upper Right   (-68.6287479,-0.0400000)
Lower Right   (-68.6287479,-18.4807346)
Center        (-75.0043740,-9.2603673)

The reported upper left coordinate is exactly the model tie point, and all the other corners are offset by one pixel.

For comparison, here the corners reported by gdalinfo:

Corner Coordinates:
Upper Left  ( -81.3906260,  -0.0246327)
Lower Left  ( -81.3906260, -18.4653673)
Upper Right ( -68.6393740,  -0.0246327)
Lower Right ( -68.6393740, -18.4653673)
Center      ( -75.0150000,  -9.2450000)

Notes

the tests currently contains only images with RasterPixelIsArea, none with RasterPixelIsPoint
GDAL changed their behaviour a while ago, see here

s/PROJ_INCLUDE_DIR/PROJ_INCLUDE_DIRS

Recent versions of PROJ (like the 9.2.0 I'm currently using) isn't exposing PROJ_INCLUDE_DIR but PROJ_INCLUDE_DIRS in the CMake configuration exported.

I'm not sure how multiple versions of PROJ should be handled if retro-compatibility with PROJ 6 is still desired and supported.

Is there a GeoKey for epsg number or proj4string?

HI,

(Sorry this is not an issue but a question..)

I want to use PROJ to re-project some .tiff layers, And there are so many geoKeys to define the projection. wouldn't be enough just to give the epsg number or a proj4 string that PROJ could deal with it?

Regards and thanks for all your work!

libxtiff is installed indivisually? independently?

libgeotiff installation does NOT contain libxtiff.

So, should I install libxtiff independently ?

Cheers
Pei

testlistgeo fails on i386

The Debian package build for Debian unstable failed on i386:

../test/testlistgeo ../bin/listgeo
============================================
Running ../test/testlistgeo using ../bin/listgeo:
============================================
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
diff testlistgeo_out with testlistgeo_out.dist
--- testlistgeo_out	2023-12-01 07:31:18.538597302 +0000
+++ testlistgeo_out.dist.normalized	2023-12-01 07:31:18.538597302 +0000
@@ -732,7 +732,7 @@
 Projection = 8440 (Laborde Grid (Greenwich))
 Projection Method: CT_ObliqueMercator_Laborde
    ProjCenterLatGeoKey: -18.900000 ( 18d54' 0.00"S)
-   ProjCenterLongGeoKey: 46.437229 ( 46d26'14.03"E)
+   ProjCenterLongGeoKey: 46.437229 ( 46d26'14.02"E)
    ProjAzimuthAngleGeoKey: 18.900000 ( 18d54' 0.00"N)
    ProjScaleAtCenterGeoKey: 0.999500
    ProjFalseEastingGeoKey: 400000.000000 m
PROBLEMS HAVE OCCURRED
test file testlistgeo_out saved

Full buildlog

testlistgeo fails with PROJ 8.0.0

testlistgeo fails with PROJ 8.0.0:

make[3]: Entering directory '/build/libgeotiff-1.6.0/test'
../test/testlistgeo ../bin/listgeo
============================================
Running ../test/testlistgeo using ../bin/listgeo:
============================================
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
diff testlistgeo_out with testlistgeo_out.dist
--- testlistgeo_out     2021-02-21 07:01:34.961336363 +0000
+++ testlistgeo_out.dist.tmp    2021-02-21 07:01:34.957336392 +0000
@@ -1566,6 +1566,9 @@
    ProjFalseEastingGeoKey: 649328.000000 m
    ProjFalseNorthingGeoKey: 665262.000000 m
 GCS: 4258/ETRS89
+Datum: 6258/European Terrestrial Reference System 1989
+Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
+Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
 Projection Linear Units: 9001/metre (1.000000m)

 Corner Coordinates:
@@ -1616,6 +1619,9 @@
    ProjFalseEastingGeoKey: 649328.000000 m
    ProjFalseNorthingGeoKey: 665262.000000 m
 GCS: 4258/ETRS89
+Datum: 6258/European Terrestrial Reference System 1989
+Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
+Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
 Projection Linear Units: 9001/metre (1.000000m)

 Corner Coordinates:
@@ -1744,6 +1750,9 @@
    ProjFalseEastingGeoKey: 4321000.000000 m
    ProjFalseNorthingGeoKey: 3210000.000000 m
 GCS: 4258/ETRS89
+Datum: 6258/European Terrestrial Reference System 1989
+Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
+Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
 Projection Linear Units: 9001/metre (1.000000m)

 Corner Coordinates:
@@ -1790,6 +1799,9 @@
    ProjFalseEastingGeoKey: 4321000.000000 m
    ProjFalseNorthingGeoKey: 3210000.000000 m
 GCS: 4258/ETRS89
+Datum: 6258/European Terrestrial Reference System 1989
+Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
+Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
 Projection Linear Units: 9001/metre (1.000000m)

 Corner Coordinates:

PROBLEMS HAVE OCCURRED
test file testlistgeo_out saved

make[3]: *** [Makefile:540: check-local] Error 100
make[3]: Leaving directory '/build/libgeotiff-1.6.0/test'

CI caught this too:

https://travis-ci.com/github/OSGeo/libgeotiff/jobs/454302672

Random Assertion error

Hi,

I am working on a project to build a dataset by vectorizing small portions of some rasters, doing calculations over them and delivering a pickle file. I have been using the multiprocessing library from python and it works in random ways, and I mean random not by having an error linked to an specific datapoint.

This message appears randomly and it leads to an slow deadlock of my multiprocessing pool (it could appear between 3 to 6 times when processing 700k datapoints):
python /tmp/build/80754af9/geotiff_1590596112627/work/geo_normalize.c:1456: GTIFGetProjTRFInfoEx: Assertion `pszMethodCode' failed.
If im lucky enough that the error does not pop (it happens with the same dataset) the code will execute completely

for me it is odd that the `pszMethodCode' is between different quotation marks

I use anaconda and tried on python 3.7 and 3.8 environments, my main libraries are geopandas, shapely and rasterio

libgeotiff 1.7.0 - No libgeotiff.so.5 file after running make install

Hello,

I am building/compiling on a linux redhat machine using cmake 3.20.
After running make install , I only see lib/libgeotiff.a , but I dont see the shader object libgeotiff.so.

Any thoughts on what am I missing in the build process?

Thanks

testlistgeo failure with PROJ 6.2.0

As reported by Peter Michael Green in Debian Bug #939399:

Hi, libgeotiff just failed to build in raspbian bullseye with the following message.

============================================
Running ../test/testlistgeo using ../bin/listgeo:
============================================
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
diff testlistgeo_out with testlistgeo_out.dist
--- testlistgeo_out    2019-09-04 06:58:26.979704475 +0000
+++ ../test/testlistgeo_out.dist    2019-09-04 06:57:50.000000000 +0000
@@ -1697,11 +1697,11 @@
     Keyed_Information:
        GTModelTypeGeoKey (Short,1): ModelTypeProjected
        GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
-      ProjectedCSTypeGeoKey (Short,1): Code-3035 (ETRS89-extended / LAEA Europe)
+      ProjectedCSTypeGeoKey (Short,1): Code-3035 (ETRS89 / LAEA Europe)
        End_Of_Keys.
     End_Of_Geotiff.
-PCS = 3035 (ETRS89-extended / LAEA Europe)
+PCS = 3035 (ETRS89 / LAEA Europe)
  Projection = 19986 (Europe Equal Area 2001)
  Projection Method: CT_LambertAzimEqualArea
     ProjCenterLatGeoKey: 52.000000 ( 52d 0' 0.00"N)

PROBLEMS HAVE OCCURRED
test file testlistgeo_out saved

It also failed in the same way on the Debian reproducible builds site for bullseye armhf. The reproducible builds site has not yet tested it on other architectures in bullseye. It seems to be fine in unstable.

test/testlistgeo_out.dist may need to become a template to handle different output depending on which version of PROJ it was built with.

Home page misconfigured

The README points to WWW web page at http://geotiff.osgeo.org/

Navigating to that address in a web browser ends up with a page that says the following.

Welcome to nginx!

If you see this page, the nginx web server is successfully installed and working. Further configuration is required.

last three releases cannot be built...

When I try to follow your build instructions I get:

./configure --prefix=/usr/local/libgeotiff-1.4.3 && make
bash: ./configure: No such file or directory

That's because you allowed github to package your build, and github does not know how to deal with autoconf.

Instead, do a "make dist" and then upload the tarballs it creates to the github release page.

Transparency

It would appear libgeotiff does not support transparency in TIFF files when converting them to a GeoTiff. I have tested creating a GeoTiff from a Tiff both with and without a transparent background and QGIS will happily read the Geotiff with a solid background but cannot read the one with a transparent background.

Configure script not finding dependencies as static libraries

I'm building libgeotiff in an environment with only static libraries. Therefore, libproj needs to be linked with -lproj -lsqlite3 and libtiff needs to be linked as follows:

pkg-config --libs-only-l --static libtiff-4
#  -ltiff -ljpeg -lz

When I run ./configure --enable-static --disable-shared --with-proj it errors like so:

checking for PROJ >= 6 library... checking for proj_create_from_wkt in -lproj... no
checking for internal_proj_create_from_wkt in -lproj... no
checking for internal_proj_create_from_wkt in -linternalproj... no
configure: error: PROJ 6 symbols not found

From configure.log I see the configure test fails because:

It tries to link to libproj.a with the C linker instead of C++ (lots of undefined stdc++ errors)
It is not using -lsqlite3

I was able to work around it like so:

export LIBS="-lsqlite3 -lstdc++"
./configure --enable-static --disable-shared --with-proj

How the configure script succeeds, and I am able to build libgeotiff.a however the build fails when it needs to link to libtiff:

libtool: link: x86_64-w64-mingw32-gcc -I../../libgeotiff-1.5.1 -I../../libgeotiff-1.5.1/libxtiff -DHAVE_TIFF=1 -march=x86-64 -mtune=generic -O2 -pipe -O3 -DNDEBUG -pipe -o applygeo.exe applygeo.o -pipe  ../.libs/libgeotiff.a -lproj -lsqlite3 -ljpeg -lz -lstdc++ -ltiff
C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../lib/libtiff.a(tif_jpeg.o):(.text+0x244): undefined reference to `jpeg_std_error'
C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../lib/libtiff.a(tif_jpeg.o):(.text+0x2a3): undefined reference to `jpeg_CreateDecompress'
C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../lib/libtiff.a(tif_jpeg.o):(.text+0x375): undefined reference to `jpeg_abort'
... + 100+ more like this

The problem is that it need to link to libtiff using -ltiff -ljpeg -lz instead of -ltiff. However I cannot work around these by adding them to LIBS because it seems the configure script is explicitly stripping -ltiff from LIBS and then putting it back at the end (but -ljpeg and -lz need to appear after -ltiff in the linker flags)

I was able to work around it like so:

sed -i.bak "s/-ltiff/$(pkg-config --libs-only-l --static libtiff-4)/g" configure

Then it builds 🎉 But it's all a bit hacky of course. The configure script could be improved by:

Trying to link libproj using -lproj -lsqlite3 using the c++ linker
Trying to link libtiff using pkg-config --libs --static libtiff-4

Thanks! Not super urgent (I have workarounds).

1.5.1 does not build in separate dir from source

The default build on Cygwin package tool is to have separate directory for source and build and 1.5.1 does not support it.

The attached patch allows to build on a separate directory from source, amend the test output to avoid spurious errors and add the needed "undefined" for cygwin and other similar system.

libgeotiff-1.5.1-1.src.patch.gz

after that, the test output is just due to minor nomenclature difference on my system

--- testlistgeo_out     2020-02-06 05:54:08.880564500 +0100
+++ /cygdrive/d/cyg_pub/devel/libgeotiff/libgeotiff-1.5.1-1.x86_64/src/libgeotiff-1.5.1/test/testlistgeo_out.dist       2019-03-25 16:31:36.000000000 +0100
@@ -1697,11 +1697,11 @@
    Keyed_Information:
       GTModelTypeGeoKey (Short,1): ModelTypeProjected
       GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
-      ProjectedCSTypeGeoKey (Short,1): Code-3035 (ETRS89-extended / LAEA Europe)
+      ProjectedCSTypeGeoKey (Short,1): Code-3035 (ETRS89 / LAEA Europe)
       End_Of_Keys.
    End_Of_Geotiff.

-PCS = 3035 (ETRS89-extended / LAEA Europe)
+PCS = 3035 (ETRS89 / LAEA Europe)
 Projection = 19986 (Europe Equal Area 2001)
 Projection Method: CT_LambertAzimEqualArea
    ProjCenterLatGeoKey: 52.000000 ( 52d 0' 0.00"N)

Issue building with Visual Studio 2019

Good day.

Since i have been unable to locate version 2017 of Visual Studio for download anymore
I had to grab 2019 Community edition instead.

Having issues with compiling though, and wondering if this is due to the lack of defining in appveyor.yml?

VS 2015

VS_VERSION: Visual Studio 14
APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2015
platform: x86

VS 2017

VS_VERSION: Visual Studio 15
APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2017
platform: x64

Been on Linux for ages, and not really familiar with Visual Studio, neither do i have much experience with CMake to be honest, so i am quite lost, with trying to build on/for Windows.

Use libgeotiff to change or delete GeoTiff-TAGs

Dear community,

I'm using Linux Lubuntu 18.04 with exiftool command line and python libraries in order to modify TIFF-Tags of a land cover classification GeoTIFF-file.
I wonder if using libgeotiff can make a difference. So far, I don't even know how to start using it, since I haven't found very telling examples for my specific task (change or delete GeoTiff-TAGs).

As the Python libraries

import exifread
import PIL
import tifffile as tf
from skimage.external import tifffile as sk_tf

don't even list the GeoTiff tags, since they are "blind on that eye", I found that exiftool lists, but cannot change them.

The output of my example file, using exiftool in the terminal, is:
Input:
exiftool -D -G -a -u -U -f "newfile.tif"
Output:

[ExifTool]          - ExifTool Version Number         : 10.80
[File]              - File Name                       : newfile.tif
[File]              - Directory                       : .
[File]              - File Size                       : 1503 kB
[File]              - File Modification Date/Time     : 2019:12:19 17:32:17+01:00
[File]              - File Access Date/Time           : 2019:12:19 17:32:17+01:00
[File]              - File Inode Change Date/Time     : 2019:12:19 17:32:17+01:00
[File]              - File Permissions                : rw-rw-r--
[File]              - File Type                       : TIFF
[File]              - File Type Extension             : tif
[File]              - MIME Type                       : image/tiff
[File]              - Exif Byte Order                 : Little-endian (Intel, II)
[File]              - Current IPTC Digest             : 79ffcf282ca6974ff99640a7421b40b7
[EXIF]            256 Image Width                     : 1148
[EXIF]            257 Image Height                    : 1337
[EXIF]            258 Bits Per Sample                 : 8
[EXIF]            259 Compression                     : Uncompressed
[EXIF]            262 Photometric Interpretation      : RGB Palette
[EXIF]            273 Strip Offsets                   : (Binary data 1390 bytes, use -b option to extract)
[EXIF]            274 Orientation                     : Horizontal (normal)
[EXIF]            277 Samples Per Pixel               : 1
[EXIF]            278 Rows Per Strip                  : 7
[EXIF]            279 Strip Byte Counts               : (Binary data 954 bytes, use -b option to extract)
[EXIF]            282 X Resolution                    : 1
[EXIF]            283 Y Resolution                    : 1
[EXIF]            284 Planar Configuration            : Chunky
[EXIF]            296 Resolution Unit                 : None
[EXIF]            305 Software                        : IMAGINE TIFF Support.Copyright 1991 - 1999 by ERDAS, Inc. All Rights Reserved.@(#)$RCSfile: etif.c $ $Revision: 1.11 $ $Date$
[EXIF]            320 Color Map                       : (Binary data 1536 bytes, use -b option to extract)
[EXIF]            339 Sample Format                   : Unsigned
[EXIF]          33550 Pixel Scale                     : 30 30 0
[EXIF]          33922 Model Tie Point                 : 0 0 0 1514925 1583985 0
[IPTC]             25 Keywords                        : word
[IPTC]              0 Application Record Version      : 4
[GeoTiff]           1 Geo Tiff Version                : 1.1.0
[GeoTiff]        1024 GT Model Type                   : Projected
[GeoTiff]        1025 GT Raster Type                  : Pixel Is Area
[GeoTiff]        1026 GT Citation                     : IMAGINE GeoTIFF Support.Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved.@(#)$RCSfile: egtf.c $ $Revision: 1.11.2.3 $ $Date: 2004/11/24 09:12:56EST $.Projection Name = USA_Contiguous_Albers_Equal_Area_Conic_USGS_version.Units = meters.GeoTIFF Units = meters
[GeoTiff]        2048 Geographic Type                 : NAD83
[GeoTiff]        3072 Projected CS Type               : User Defined
[GeoTiff]        3073 PCS Citation                    : IMAGINE GeoTIFF Support.Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved.@(#)$RCSfile: egtf.c $ $Revision: 1.11.2.3 $ $Date: 2004/11/24 09:12:56EST $.Projection = Albers Conical Equal Area
[GeoTiff]        3074 Projection                      : User Defined
[GeoTiff]        3075 Proj Coord Trans                : Albers Equal Area
[GeoTiff]        3076 Proj Linear Units               : Linear Meter
[GeoTiff]        3078 Proj Std Parallel 1             : 29.5
[GeoTiff]        3079 Proj Std Parallel 2             : 45.5
[GeoTiff]        3081 Proj Nat Origin Lat             : 23
[GeoTiff]        3082 Proj False Easting              : 0
[GeoTiff]        3083 Proj False Northing             : 0
[GeoTiff]        3088 Proj Center Long                : -96
[Composite]         - Image Size                      : 1148x1337
[Composite]         - Megapixels                      : 1.5

Now, I'd like to change/delete the GeoTiff-TAG "Projection", which throws the following warning message without changing anything:
Input:
exiftool "-Projection=" "newfile.tif"
Output:
Warning: Sorry, Projection is not writable. Nothing to do.

Next, I found the following documentation of this very webpage:
https://exiftool.org/TagNames/GeoTiff.html

It states, among other details, the following:

GeoTIFF tags are not writable individually, but they may be copied en mass via the block tags GeoTiffDirectory, GeoTiffDoubleParams and GeoTiffAsciiParams.

Is there any possibility to change/rename/delete a GeoTiff-TAG of choice via command line tolls such as libgeotiff, exiftools (as stated above in my attempt), or gdal etc.?
I'm quite desparate already, since I've invested a lot of time in finding a possiblity, but so far no avail.

Thanks in advance for helping me out.
Kind regards,
Andreas

#define exported in geo_config.h conflict with other packages such as GDAL

[13:54] <runette> rouault[m] as discussed elsewhere - I have been trying to get the cmake build working on local Mac and Windows machines and I seem to have a few problems that I am trying to get past one by one. On Mac - using dependencies loaded from Conda (I don't have brew installed) the generate phase seems to work fine but I get this error messge when building
[13:54] <runette> :
[13:54] <runette> In file included from /Users/paulharwood/documents/GitHub/gdal/frmts/pds/vicardataset.cpp:44:
[13:54] <runette> In file included from /Users/paulharwood/opt/miniconda3/envs/gdal/include/geotiff.h:52:
[13:54] <runette> #define HAVE_STRING_H
[13:54] <runette>         ^
[13:54] <runette> #define HAVE_STRING_H 1
[13:54] <runette> Any ideas?
[13:54] <runette> That snippet should have been
[13:54] <runette> `In file included from /Users/paulharwood/documents/GitHub/gdal/frmts/pds/vicardataset.cpp:44:
[13:54] <runette> In file included from /Users/paulharwood/opt/miniconda3/envs/gdal/include/geotiff.h:52:
[13:55] <runette> #define HAVE_STRING_H
[13:55] <runette>         ^
[13:55] <runette> #define HAVE_STRING_H 1`
[13:56] <runette> "/Users/paulharwood/documents/GitHub/gdal-build/port/cpl_config.h:78:9: note: previous definition is here
[13:56] <runette> #define HAVE_STRING_H 1"
[13:58] <even> runette: it is just a warning, not an error ?
[14:02] <even> I presume the geo_config.h from your libgeotiff must come from a libgeotiff CMake build since it has just #define HAVE_STRING_H with a libgeotiff autoconf build, it is #define HAVE_STRING_H 1
[14:03] <even> it is annoying that we export such stuff from both GDAL and libgeotiff. That should be fixed in both ideally
[14:04] <runette> It is an error - Libera was swallowing the lien - it was "/Users/paulharwood/opt/miniconda3/envs/gdal/include/geo_config.h:8:9: error: 'HAVE_STRING_H' macro redefined [-Werror,-Wmacro-redefined]"
[14:04] <even> or have it prefixed with GDAL_ or LIBGEOTIFF_
[14:04] <even> yes, if you build with -Werror. Without it, that should build despite the warning
[14:05] <runette> I will try that - thanks
[14:05] <even> as a workaround, can you try manually to edit  /Users/paulharwood/opt/miniconda3/envs/gdal/include/geotiff.h to add a " 1" at the end of the offending #define

tiffcp options

Hello, i went thru the steps and at last step where it said tiffcp -g -e
The current version of tiffcp i have on my box is version 4.1.0. There is no -g or -e option.
What is a tiffcp function does? How do I re-create a new tiff from the original tiff with the strip tags.

thank you for your support

Fails to build with PROJ 9.1.1 due to test failures

libgeotiff fails to build with PROJ 9.1.1 RC1 due to test failures:

--- testlistgeo_out     2022-11-26 07:39:54.481662170 +0000
+++ testlistgeo_out.dist.tmp    2022-11-26 07:39:54.481662170 +0000
@@ -300,9 +300,9 @@
 Projection Linear Units: 9001/metre (1.000000m)
 
 Corner Coordinates:
-Upper Left    (  440720.000, 3751320.000)  ( 40d47'28.08"E, 64d13'29.56"N)
+Upper Left    (  440720.000, 3751320.000)  ( 40d47'28.08"E, 64d13'29.57"N)
 Lower Left    (  440720.000, 3751260.000)  ( 40d47'27.69"E, 64d13'27.64"N)
-Upper Right   (  440780.000, 3751320.000)  ( 40d47'32.51"E, 64d13'29.39"N)
+Upper Right   (  440780.000, 3751320.000)  ( 40d47'32.51"E, 64d13'29.40"N)
 Lower Right   (  440780.000, 3751260.000)  ( 40d47'32.12"E, 64d13'27.47"N)
 Center        (  440750.000, 3751290.000)  ( 40d47'30.10"E, 64d13'28.52"N)
 
@@ -349,9 +349,9 @@
 Projection Linear Units: 9001/metre (1.000000m)
 
 Corner Coordinates:
-Upper Left    (  440720.000, 3751320.000)  ( 40d47'28.08"E, 64d13'29.56"N)
+Upper Left    (  440720.000, 3751320.000)  ( 40d47'28.08"E, 64d13'29.57"N)
 Lower Left    (  440720.000, 3751260.000)  ( 40d47'27.69"E, 64d13'27.64"N)
-Upper Right   (  440780.000, 3751320.000)  ( 40d47'32.51"E, 64d13'29.39"N)
+Upper Right   (  440780.000, 3751320.000)  ( 40d47'32.51"E, 64d13'29.40"N)
 Lower Right   (  440780.000, 3751260.000)  ( 40d47'32.12"E, 64d13'27.47"N)
 Center        (  440750.000, 3751290.000)  ( 40d47'30.10"E, 64d13'28.52"N)
 

PROBLEMS HAVE OCCURRED
test file testlistgeo_out saved

Fails to build with PROJ 9.3.1

The build fails due to test failures:

 17s ============================================
 17s Running ./test/testlistgeo using /usr/bin/listgeo:
 17s ============================================
 18s proj_create: unrecognized format / unknown name
 18s proj_create: unrecognized format / unknown name
 18s proj_create: unrecognized format / unknown name
 18s proj_create: unrecognized format / unknown name
 18s proj_create: unrecognized format / unknown name
 18s proj_create: unrecognized format / unknown name
 18s proj_create: unrecognized format / unknown name
 18s proj_create: unrecognized format / unknown name
 18s proj_create: unrecognized format / unknown name
 18s proj_create: unrecognized format / unknown name
 18s diff testlistgeo_out with testlistgeo_out.dist
 18s --- testlistgeo_out	2023-11-27 08:07:23.249185027 +0000
 18s +++ testlistgeo_out.dist.normalized	2023-11-27 08:07:23.245184941 +0000
 18s @@ -103,7 +103,7 @@
 18s     End_Of_Geotiff.
 18s  
 18s  PCS = 32064 (NAD27 / BLM 14N (ftUS))
 18s -Projection = 15914 (BLM zone 14N (US survey foot))
 18s +Projection = 15914 (BLM zone 14N (US survey feet))
 18s  Projection Method: CT_TransverseMercator
 18s     ProjNatOriginLatGeoKey: 0.000000 (  0d 0' 0.00"N)
 18s     ProjNatOriginLongGeoKey: -99.000000 ( 99d 0' 0.00"W)
 18s @@ -248,7 +248,7 @@
 18s     End_Of_Geotiff.
 18s  
 18s  PCS = 32064 (NAD27 / BLM 14N (ftUS))
 18s -Projection = 15914 (BLM zone 14N (US survey foot))
 18s +Projection = 15914 (BLM zone 14N (US survey feet))
 18s  Projection Method: CT_TransverseMercator
 18s     ProjNatOriginLatGeoKey: 0.000000 (  0d 0' 0.00"N)
 18s     ProjNatOriginLongGeoKey: -99.000000 ( 99d 0' 0.00"W)
 18s @@ -536,7 +536,7 @@
 18s     End_Of_Geotiff.
 18s  
 18s  PCS = 6808 (NAD83(CORS96) / Oregon Columbia River West zone (m))
 18s -Projection = 6753 (Oregon Columbia River West zone (meter))
 18s +Projection = 6753 (Oregon Columbia River West zone (meters))
 18s  Projection Method: CT_ObliqueMercator
 18s     ProjCenterLatGeoKey: 45.916667 ( 45d55' 0.00"N)
 18s     ProjCenterLongGeoKey: -123.000000 (123d 0' 0.00"W)
 18s 
 18s PROBLEMS HAVE OCCURRED
 18s test file testlistgeo_out saved

Wrong epsg number in pcs

Wrong geotiff keyed information

I am using listgeo and geotifcp to edit keyed information in geotiff raster files.
I have a problem with Poland_CS2000 zones 7 and 8, the assigned georeferences from the gtf file show mixed information for zone 7 and 8.

Example:

Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
ModelTiepointTag (2,3):
0 0 0
7572000 5544500 0
ModelPixelScaleTag (1,3):
0.05 0.05 0
End_Of_Tags.
Keyed_Information:
GTModelTypeGeoKey (Short,1): ModelTypeProjected
GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
GTCitationGeoKey (Ascii,14): "GCS_ETRS_1989"
GeographicTypeGeoKey (Short,1): GCS_EUREF89
GeogAngularUnitsGeoKey (Short,1): Angular_Degree
GeogEllipsoidGeoKey (Short,1): Ellipse_GRS_1980
GeogSemiMajorAxisGeoKey (Double,1): 6378137
GeogSemiMinorAxisGeoKey (Double,1): 6356752.31
GeogInvFlatteningGeoKey (Double,1): 298.257222
ProjectedCSTypeGeoKey (Short,1): PCS_ETRS89_Poland_CS2000_zone_8
PCSCitationGeoKey (Ascii,28): "ETRS89_Poland_CS2000_zone_7"
ProjLinearUnitsGeoKey (Short,1): Linear_Meter
ProjNatOriginLongGeoKey (Double,1): 21
ProjNatOriginLatGeoKey (Double,1): 0
ProjFalseEastingGeoKey (Double,1): 7500000
ProjFalseNorthingGeoKey (Double,1): 0
ProjScaleAtNatOriginGeoKey (Double,1): 0.999923
End_Of_Keys.
End_Of_Geotiff.
PCS = 2178 (ETRS89 / Poland CS2000 zone 7)
Projection = 18307 (Poland CS2000 zone 7)
Projection Method: CT_TransverseMercator
ProjNatOriginLatGeoKey: 0.000000 ( 0d 0' 0.00"N)
ProjNatOriginLongGeoKey: 21.000000 ( 21d 0' 0.00"E)
ProjScaleAtNatOriginGeoKey: 0.999923
ProjFalseEastingGeoKey: 7500000.000000 m
ProjFalseNorthingGeoKey: 0.000000 m
GCS: 4258/ETRS89
Datum: 6258/European Terrestrial Reference System 1989
Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/ 0d 0' 0.00"E)
Projection Linear Units: 9001/metre (1.000000m)
Corner Coordinates:
Upper Left ( 7572000.000, 5544500.000)
Lower Left ( 7572000.000, 5544000.000)
Upper Right ( 7572800.000, 5544500.000)
Lower Right ( 7572800.000, 5544000.000)
Center ( 7572400.000, 5544250.000)

In addition for zone 8 value for ProjectedCSTypeGeoKey (Short,1): Unknown-2179
I need "PCS_ETRS89_Poland_CS2000_zone_8"

I looked into source files and found epsg_pcs.inc with values:

ValuePair(PCS_ETRS89_Poland_CS2000_zone_5,2176)
ValuePair(PCS_ETRS89_Poland_CS2000_zone_6,2177)
ValuePair(PCS_ETRS89_Poland_CS2000_zone_7,2177)
ValuePair(PCS_ETRS89_Poland_CS2000_zone_8,2178)

Poland_CS2000_zone_7 has epsg: 2178, and Poland_CS2000_zone_8 2179. I've changed it and recompiled but still have this problem.

Could you figure out where is the problem?

Thank you.

"failed to read anything"

I'm trying to do something I thought would be very simple. I'm trying to use listgeo to pull the geo information out of a tiff, modify it and add it to another tiff.

listgeo results in a dump that has correct information.

For the sake of simplicity, I modify a single character in a GPS coordinate and then try to apply it back onto the tiff. When I do this I get several errors saying "geo_print.c DefaultRead failed to read anything"

Error linking TIFF on Ubuntu

I use libgeotiff 1.5.1 and libtiff 4.0.10.
To build everything I use CMake and make.

TIFF:
cmake -G 'Unix Makefiles' ../../ -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/home/nikita/OSG/test_osg/install/libtiff/Release -DZLIB_INCLUDE_DIR=/home/nikita/OSG/test_osg/install/zlib/Release/include/ -DZLIB_LIBRARY_RELEASE=/home/nikita/OSG/test_osg/install/zlib/Release/lib/libz.so -DJPEG_INCLUDE_DIR=/home/nikita/OSG/test_osg/install/libjpeg/Release/include/ -DJPEG_LIBRARY=/home/nikita/OSG/test_osg/install/libjpeg/Release/lib/libjpeg.so

libgeotiff:
cmake -G 'Unix Makefiles' ../../ -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/home/nikita/OSG/test_osg/install/libgeotiff/Release -DWITH_UTILITIES=OFF -DWITH_JPEG=ON -DWITH_TIFF=ON -DWITH_ZLIB=ON -DPROJ_INCLUDE_DIR=/home/nikita/OSG/test_osg/install/proj/Release/include/ -DPROJ_LIBRARY=/home/nikita/OSG/test_osg/install/proj/Release/lib/libproj.so -DZLIB_INCLUDE_DIR=/home/nikita/OSG/test_osg/install/zlib/Release/include/ -DZLIB_LIBRARY_RELEASE=/home/nikita/OSG/test_osg/install/zlib/Release/lib/libz.so -DJPEG_INCLUDE_DIR=/home/nikita/OSG/test_osg/install/libjpeg/Release/include/ -DJPEG_LIBRARY=/home/nikita/OSG/test_osg/install/libjpeg/Release/lib/libjpeg.so -DTIFF_INCLUDE_DIR=/home/nikita/OSG/test_osg/install/libtiff/Release/include/ -DTIFF_LIBRARY_RELEASE=/home/nikita/OSG/test_osg/install/libtiff/Release/lib/libtiff.so

And while configuring CMake for geotiff I get the following error:

Found TIFF: /home/nikita/OSG/test_osg/install/libtiff/Release/lib/libtiff.so.5.4.0 (found version "4.0.10") 
CMake Error at CMakeLists.txt:182 (MESSAGE):
  Failed to link with libtiff - TIFFOpen function not found

The same sources on Windows with CMake and MSVC 2015 are built properly with no errors.

Windows compilation gives error

Im getting a few errors and not sure if the build notes a clear enough.

Severity Code Description Project File Line Suppression State
Error CMake Error at C:\Users\DAVID\Source\Repos\libgeotiff\libgeotiff\CMakeLists.txt:133 (MESSAGE):
Failed to detect PROJ >= 6 GeoTIFF C:\Users\DAVID\Source\Repos\libgeotiff\libgeotiff\CMakeLists.txt 133

This occurs after installing PROJ.

Also after running

C:\Users\DAVID\source\repos\libgeotiff\libgeotiff\build>cmake -G "Visual Studio 16 2019" .. -DBUILD_SHARED_LIBS=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS="/WX" -DCMAKE_CXX_FLAGS="/WX" -DCMAKE_INSTALL_PREFIX="C:/Users/DAVID/source/repos/libgeotiff/libgeotiff/build/install" -DPROJ_INCLUDE_DIR="C:/Users/DAVID/source/repos/libgeotiff/libgeotiff/build/install/include" -DPROJ_LIBRARY="C:/Users/DAVID/source/repos/libgeotiff/libgeotiff/build/install/lib/proj.lib" -DCMAKE_TOOLCHAIN_FILE=C:/projects/vcpkg/scripts/buildsystems/vcpkg.cmake

I get the error:

-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19042.
CMake Deprecation Warning at CMakeLists.txt:15 (CMAKE_MINIMUM_REQUIRED):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.

Update the VERSION argument value or use a ... suffix to tell
CMake that the project does not need compatibility with older versions.

CMake Deprecation Warning at CMakeLists.txt:58 (cmake_policy):
The OLD behavior for policy CMP0022 will be removed from a future version
of CMake.

The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.

CMake Deprecation Warning at CMakeLists.txt:59 (cmake_policy):
The OLD behavior for policy CMP0042 will be removed from a future version
of CMake.

-- Found PROJ: C:/Users/DAVID/source/repos/libgeotiff/libgeotiff/build/install/lib/proj.lib
CMake Error at C:/Program Files/CMake/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find TIFF (missing: TIFF_LIBRARY TIFF_INCLUDE_DIR)
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
C:/Program Files/CMake/share/cmake-3.21/Modules/FindTIFF.cmake:124 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
C:/projects/vcpkg/scripts/buildsystems/vcpkg.cmake:786 (_find_package)
CMakeLists.txt:171 (FIND_PACKAGE)

CMake Warning (dev) in C:/Program Files/CMake/share/cmake-3.21/Modules/FindTIFF.cmake:
Policy CMP0011 is not set: Included scripts do automatic cmake_policy PUSH
and POP. Run "cmake --help-policy CMP0011" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.

The included script

C:/Program Files/CMake/share/cmake-3.21/Modules/FindTIFF.cmake

affects policy settings. CMake is implying the NO_POLICY_SCOPE option for
compatibility, so the effects are applied to the including context.
Call Stack (most recent call first):
C:/projects/vcpkg/scripts/buildsystems/vcpkg.cmake:786 (_find_package)
CMakeLists.txt:171 (FIND_PACKAGE)
This warning is for project developers. Use -Wno-dev to suppress it.

-- Configuring incomplete, errors occurred!
See also "C:/Users/DAVID/source/repos/libgeotiff/libgeotiff/build/CMakeFiles/CMakeOutput.log".
See also "C:/Users/DAVID/source/repos/libgeotiff/libgeotiff/build/CMakeFiles/CMakeError.log".

Vulnerabilities

I have found an Out-Of-Bound Read; potential vulnerabilities. Do you have somewhere else you wish them to be reported for fixing?

pkg-config incompletely called in configure

On OS X 10.13 libgeotiff-1.6.0:

./configure --prefix=/sw --with-zip=/usr/include --with-jpeg=/sw --with-libtiff=/sw --disable-doxygen-doc
[...]
checking for PROJ >= 6 library... checking for PROJ... no
checking for proj_create_from_wkt in -lproj... yes
checking proj.h usability... yes
checking proj.h presence... yes
checking for proj.h... yes
configure: proj.h found

But I do have proj.pc and pkg-config can find it normally. Instead, there's a flaw in how PKG_CHECK_MODULES is being called. There are several previous PKG_CHECK_MODULES that are not being called due to the --with-* for their libs. So this is the first P_C_M that is called but not the first in the ./configure script. As a result, some initialization that the autotools do for "the first P_C_M in configure.ac" are not run. It's exactly the bug described at https://autotools.io/pkgconfig/pkg_check_modules.html section 3.4, and the fix described there works for me.

Adding

PKG_PROG_PKG_CONFIG0

to the "Checks for programs" block gives me:

checking for PROJ >= 6 library... checking for proj... yes
checking proj.h usability... yes
checking proj.h presence... yes
checking for proj.h... yes
configure: proj.h found

1.5.1: test suite is failing

+ /usr/bin/make -O -j48 V=1 VERBOSE=1 check
Making check in libxtiff
make[1]: Nothing to be done for 'check'.
Making check in .
Making check in bin
make[1]: Nothing to be done for 'check'.
Making check in man
Making check in man1
make[2]: Nothing to be done for 'check'.
make[2]: Nothing to be done for 'check-am'.
Making check in cmake
make[1]: Nothing to be done for 'check'.
Making check in test
/usr/bin/make  check-local
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/libgeotiff-1.5.1/test'
../test/testlistgeo ../bin/listgeo
============================================
Running ../test/testlistgeo using ../bin/listgeo:
============================================
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
proj_create: unrecognized format / unknown name
diff testlistgeo_out with testlistgeo_out.dist
--- testlistgeo_out     2020-02-28 08:15:20.916206096 +0000
+++ ../test/testlistgeo_out.dist        2019-03-25 15:31:36.000000000 +0000
@@ -1697,11 +1697,11 @@
    Keyed_Information:
       GTModelTypeGeoKey (Short,1): ModelTypeProjected
       GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
-      ProjectedCSTypeGeoKey (Short,1): Code-3035 (ETRS89-extended / LAEA Europe)
+      ProjectedCSTypeGeoKey (Short,1): Code-3035 (ETRS89 / LAEA Europe)
       End_Of_Keys.
    End_Of_Geotiff.

-PCS = 3035 (ETRS89-extended / LAEA Europe)
+PCS = 3035 (ETRS89 / LAEA Europe)
 Projection = 19986 (Europe Equal Area 2001)
 Projection Method: CT_LambertAzimEqualArea
    ProjCenterLatGeoKey: 52.000000 ( 52d 0' 0.00"N)

PROBLEMS HAVE OCCURRED
test file testlistgeo_out saved

Encoded projection using GTIFSetFromProj4 are specified as USER-DEFINED

I am willing to write down geotiff files.

For instance, i'd like to encode the projection info EPSG:25831.

In order to write down the projection in the geotiff, I am using GTIFSetFromProj4(gtif, proj4String).

In order to use this method, I first convert EPSG:25831 to it's proj4 equivalent via the method proj_as_proj_string (proj library)

This convert EPSG:25831 to +proj=utm +zone=32 +datum=WGS84 +units=m +no_defs +type=crs

The encoded information are the following;:

Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
      ModelTiepointTag (2,3):
         0                 0                 0
         571239.5625       4845679           0
      ModelPixelScaleTag (1,3):
         2                 2                 0
      End_Of_Tags.
   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeProjected
      GeographicTypeGeoKey (Short,1): User-Defined
      GeogGeodeticDatumGeoKey (Short,1): User-Defined
      GeogEllipsoidGeoKey (Short,1): Ellipse_GRS_1980
      ProjectedCSTypeGeoKey (Short,1): User-Defined
      ProjectionGeoKey (Short,1): User-Defined
      ProjCoordTransGeoKey (Short,1): CT_TransverseMercator
      ProjLinearUnitsGeoKey (Short,1): Linear_Meter
      ProjNatOriginLongGeoKey (Double,1): 3
      ProjNatOriginLatGeoKey (Double,1): 0
      ProjFalseEastingGeoKey (Double,1): 500000
      ProjFalseNorthingGeoKey (Double,1): 0
      ProjScaleAtNatOriginGeoKey (Double,1): 0.9996
      End_Of_Keys.
   End_Of_Geotiff.

Unfortunately, in QGIS (my version is QGIS 3.6), the detected CRS is a "generated CRS" and not "EPSG:25831".

What I am doing wrong? Most of the time, our user will choose the projection from the EPSG database, so I always have the EPSG code available if needed.

I am using proj7 and libgeotiff 6.0.