A couple of minutes ago, Mr Carl Reed, CTO at the Open Geospatial Consortium, posted the GeoTIFF project mailing list with message that may interest hundreds of thousands of users of geospatial raster data around the world. It is thread titled GeoTIFF and the OGC. Hot!
I’ve just submitted ticket to GeoTIFF Trac system with patch providing CMake build configuration for GeoTIFF library and utility programs.
#17 – CMake build configuration for GeoTIFF
It also includes FindGeoTIFF module for CMake users that need to determine availability of libgeotiff in their projects. Tests and improvements are welcome.
I have a not-so-small GeoTIFF raster dataset. Here is what GDAL has to say about it:
$ gdalinfo japan.tif
Driver: GTiff/GeoTIFF
Files: japan.tif
Size is 14000, 14000
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.2572235630016,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]
Origin = (137.386330630776030,38.325757833006122)
Pixel Size = (0.000256020461176,-0.000256020461176)
Metadata:
AREA_OR_POINT=Area
TIFFTAG_DOCUMENTNAME=ER Mapper 6.4
TIFFTAG_IMAGEDESCRIPTION=ER Mapper GeoTiff raster translator V1.0: Band 1 = Red, Band 2 = Green, Band 3 = Blue
TIFFTAG_SOFTWARE=ER Mapper 6.4
TIFFTAG_XRESOLUTION=0
TIFFTAG_YRESOLUTION=0
Image Structure Metadata:
COMPRESSION=LZW
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 137.3863306, 38.3257578) (137d23'10.79"E, 38d19'32.73"N)
Lower Left ( 137.3863306, 34.7414714) (137d23'10.79"E, 34d44'29.30"N)
Upper Right ( 140.9706171, 38.3257578) (140d58'14.22"E, 38d19'32.73"N)
Lower Right ( 140.9706171, 34.7414714) (140d58'14.22"E, 34d44'29.30"N)
Center ( 139.1784739, 36.5336146) (139d10'42.51"E, 36d32'1.01"N)
Band 1 Block=14000x20 Type=Byte, ColorInterp=Red
Band 2 Block=14000x20 Type=Byte, ColorInterp=Green
Band 3 Block=14000x20 Type=Byte, ColorInterp=Blue
I loaded it to PostGIS/WKT Raster table with regular blocking enabled in PostgreSQL 8.3 database running on Ubuntu 8.10 (32-bit) installed as a guest system under VirtualBox:
$ gdal2wktraster.py -r japan.tif -t japan_rb -o japan_rb.sql -k $ psql -d test -f japan_rb.sql
The loader generated output file japan_rb.sql of size of 1.1 GB and it makes 700 records (raster tiles or blocks) in the database. The disk usage reported for the raster table is:
sistest=# SELECT relfilenode, relpages FROM pg_class WHERE relname = 'japan_rb';
relfilenode | relpages
-------------+----------
71700 | 5
(1 row)
I run simple test query:
$ psql -d test test=# SET log_statement_stats TO 1; SET test=# SELECT rid FROM japan_rb WHERE RT_Width(rast) != 14000 OR RT_Height(rast) != 20; rid ----- (0 rows)
In the PostgreSQL log I got dumped a bunch of interesting statistics:
2009-03-27 15:23:38 GMT LOG: QUERY STATISTICS 2009-03-27 15:23:38 GMT DETAIL: ! system usage stats: ! 5.084838 elapsed 2.544159 user 2.468154 system sec ! [4.960310 user 5.204325 sys total] ! 0/0 [16/28160] filesystem blocks in/out ! 0/320190 [0/647479] page faults/reclaims, 0 [0] swaps ! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent ! 0/155 [9/327] voluntary/involuntary context switches ! buffer usage stats: ! Shared blocks: 74192 read, 0 written, buffer hit rate = 51.71% ! Local blocks: 0 read, 0 written, buffer hit rate = 0.00% ! Direct blocks: 0 read, 0 written
The virtual machine has assigned 1024 MB of RAM and one CPU Intel Xeon 3.2 GHz.
You are strongly welcome to share your comments?
Doing final tests of libLAS on Linux (Ubuntu 7.04), before Hobu will release 1.0.0, I attempted to build it with latest libgeotiff 1.2.5. I moved my fingers on keyboard and did ./configure && make, shortly then I saw strange looking error message:
/usr/bin/ld: makegeo: hidden symbol `__stack_chk_fail_local' in /usr/lib/libc_nonshared.a(stack_chk_fail_local.oS) is referenced by DSO /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status
Google is your friend, so in a few seconds I knew what’s going wrong. ./configure sets Makefile to call ld -shared. However, it does not work with GCC 4, because ld linker does not include all required references to other shared libraries. Simply, GCC linker driver seems to handle shared references better, than bare ld.
The conclusion is, that if you use GCC 4.x and you want to build libgeotiff, configure it this way:
./configure --with-ld-shared="gcc -shared"
Update July 31, 2008: Another solution is to add -fno-stack-protector option to CFLAGS and CXXFLAGS. Regarding Ubuntu Linux, this issue seems to be related to enabled SSP support (see also Ubuntu Wiki) available in GCC 4.1.
libgeotiff 1.2.5 has been released.
Libgeotiff is an open source library normally hosted on top of libtiff for reading, and writing GeoTIFF information tags.
As officially announced, the new version includes a few bug fixes and improvements, coordinate systems dictionaries have been updated to EPSG 6.17 dataset.
There is also a new feature called Simple Tags Interface to make it easier to use libgeotiff to process geotiff tags in other file format. This new interface is used in libLAS to support LAS files georeferencing.
Packages of libgeotiff 1.2.5 are hosted on OSGeo Download server:
http://download.osgeo.org/geotiff/libgeotiff/
A week ago, Frank Warmerdam proposed to make GeoTIFF a subproject of OSGeo MetaCRS project, because of a few reasons:
Motion: Libgeotiff as a MetaCRS sub-project was not waiting long and eventually has gained full acceptance from Project Steering Committee of MetaCRS, means passed.
Since July 28, 2008 GeoTIFF project is now a part of MetaCRS initiative lead by OSGeo community.