rl2tool EXPORT doesn't seem to work properly

[jose.che...@gmail.com]

I am using a Geotiff within sqlite including altitude data (DEM & type Int16).

I am following the tutorials.

The WMS service works fine, which means that the raster is well georreferenced, but when it comes to use the rl2tool EXPORT option

it produces an image but it does not have any spatial reference system within it. The original image (.tif) and the sqlite one are having the WGS84 (epsg:4326),

I thought that the exported images will keep that.

This is my code sentence:

rl2tool EXPORT -db GMTED2010.sqlite -cov southern_europe -outw 512 -outh 512 -res 0.002083333333333332 -cx 9.40 -cy 44.50 -dst italy.tif

Again, the image: Italy.tif is produced but any associated coordinate reference system.

If I try with the SQL function:

SELECT RL2_WriteGeoTiff('southern_europe','./Italy.tif', 512, 512, MakePoint(9.40, 44.50), 0.002083333333333332, 0.002083333333333332, 0, 'NONE');

The image is not a GeoTiff, also lacking of a coordinate system,

What am I missing?

Cheers,

Jose

[a.fu...@lqt.it]

On Tue, 10 Feb 2015 03:55:04 -0800 (PST), jose.che...@gmail.com
wrote:

> The image is not a GeoTiff, also lacking of a coordinate system,
>
> What am I missing?
>

Hi Jose,

I've tested your problem by using the current development version
(not yet released, but anyway publicly available from the Fossil
repository).

Both "rl2tool EXPORT ..." and "SELECT RL2_WriteGeoTiff(...)" do
actually output a genuine GeoTIFF file, as confirmed by standard
diagnostic tools:

tiffinfo report:
-------------------------------------------------------------------
TIFF Directory at offset 0x200008 (2097160)
Subfile Type: (0 = 0x0)
Image Width: 1024 Image Length: 1024
Tile Width: 256 Tile Length: 256
Resolution: 300, 300 pixels/inch
Bits/Sample: 16
Sample Format: signed integer
Compression Scheme: None
Photometric Interpretation: min-is-black
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 1
Planar Configuration: single image plane
Software: RasterLite-2
Tag 33550: 0.000833,0.000833,0.000000
Tag 33922: 0.000000,0.000000,0.000000,9.073504,42.926496,0.000000
Tag 34735: 1,1,0,2,1026,34737,7,0,2048,0,1,4326
Tag 34737: WGS 84|
-------------------------------------------------------------------


listgeo report:
-------------------------------------------------------------------
Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
ModelTiepointTag (2,3):
0 0 0
9.073504 46.765793 0
ModelPixelScaleTag (1,3):
0.000833 0.000833 0
End_Of_Tags.
Keyed_Information:
GTCitationGeoKey (Ascii,7): "WGS 84"
GeographicTypeGeoKey (Short,1): GCS_WGS_84
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)

Corner Coordinates:
Upper Left ( 9.074, 46.766)
Lower Left ( 9.074, 38.234)
Upper Right ( 9.926, 46.766)
Lower Right ( 9.926, 38.234)
Center ( 9.500, 42.500)
-------------------------------------------------------------------

it could well be that some bug affected the latest Release Candidate
(I've removed hundredth bugs during the latest months): anyway now
it seems to correctly work.

bye Sandro

[jose.che...@gmail.com]

Sandro,

If I type tiffinfo on the file:

effectively, at the end of the text it says:

Tag 34737: WGS 84|

But, if you upload that tiff using either ArcGIS or QGIS, i.e, it says that the reference system is missing, so not a Geotiff.

I am using the rl2tool from: http://www.gaia-gis.it/gaia-sins/rasterlite2-win-x86/rl2tool-1.0.0-rc0-win-x86.7z

Are the binaries files, like the one above, or the sources what you have corrected?,

[Jukka Rahkonen]

jose.che...@gmail.com wrote 2015-02-11 17:43:
> Sandro,
>
> If I type tiffinfo on the file:
>
> effectively, at the end of the text it says:
>
> Tag 34737: WGS 84|
>
> But, if you upload that tiff using either ArcGIS or QGIS, i.e, it says
> that the reference system is missing, so not a Geotiff.

Hi,

Could you place a sample tiff somewhere for downloading? The smaller the
better.

-Jukka Rahkonen-

[jose.che...@gmail.com]

Here you are:

https://www.dropbox.com/sh/97pah0oy3c3h3n2/AABrWobMs7q0iDeZ73rs4i8la?dl=0

[Jukka Rahkonen]

jose.che...@gmail.com kirjoitti 2015-02-11 18:48:
> Here you are:
>
> https://www.dropbox.com/sh/97pah0oy3c3h3n2/AABrWobMs7q0iDeZ73rs4i8la?dl=0

Hi,

The projection in that GeoTIFF is not complete for GDAL and it
recognizes the projection only as some local coordinate system. Here
below is gdalinfo from the original italy.tif and from a fixed copy I
made with gdalwarp with the attached command. There is also listgeo from
the both. Looks like rl2tool should write a bit more metadata or then
GDAL should be able to interpret the projection from less metadata than
it does now.

-Jukka Rahkonen-


gdalinfo italy.tif
Driver: GTiff/GeoTIFF
Files: italy.tif
Size is 512, 512
Coordinate System is:
LOCAL_CS["WGS 84",
UNIT["unknown",1]]
Origin = (8.866666666666667,45.033333333333331)
Pixel Size = (0.002083333333333,-0.002083333333333)
Metadata:
TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
TIFFTAG_SOFTWARE=RasterLite-2
TIFFTAG_XRESOLUTION=300
TIFFTAG_YRESOLUTION=300
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 8.8666667, 45.0333333)
Lower Left ( 8.8666667, 43.9666667)
Upper Right ( 9.9333333, 45.0333333)
Lower Right ( 9.9333333, 43.9666667)
Center ( 9.4000000, 44.5000000)
Band 1 Block=256x256 Type=Int16, ColorInterp=Gray

gdalwarp -of gtiff -s_srs epsg:4326 -t_srs epsg:4326 italy.tif
italy_fixed.tif
Creating output file that is 512P x 512L.
Processing input file italy.tif.
0...10...20...30...40...50...60...70...80...90...100 - done.

gdalinfo italy_fixed.tif
Driver: GTiff/GeoTIFF
Files: italy_fixed.tif
Size is 512, 512
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]
Origin = (8.866666666666667,45.033333333333331)
Pixel Size = (0.002083333333333,-0.002083333333333)
Metadata:
AREA_OR_POINT=Area
TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
TIFFTAG_SOFTWARE=RasterLite-2
TIFFTAG_XRESOLUTION=300
TIFFTAG_YRESOLUTION=300
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 8.8666667, 45.0333333) ( 8d52' 0.00"E, 45d 2' 0.00"N)
Lower Left ( 8.8666667, 43.9666667) ( 8d52' 0.00"E, 43d58' 0.00"N)
Upper Right ( 9.9333333, 45.0333333) ( 9d56' 0.00"E, 45d 2' 0.00"N)
Lower Right ( 9.9333333, 43.9666667) ( 9d56' 0.00"E, 43d58' 0.00"N)
Center ( 9.4000000, 44.5000000) ( 9d24' 0.00"E, 44d30' 0.00"N)
Band 1 Block=512x8 Type=Int16, ColorInterp=Gray


listgeo italy.tif

Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
ModelTiepointTag (2,3):
0 0 0

8.86666666666667 45.0333333333333 0
ModelPixelScaleTag (1,3):
0.00208333333333333 0.00208333333333333 0

End_Of_Tags.
Keyed_Information:
GTCitationGeoKey (Ascii,7): "WGS 84"
GeographicTypeGeoKey (Short,1): GCS_WGS_84
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)

Corner Coordinates:

Upper Left ( 8.867, 45.033)
Lower Left ( 8.867, 43.967)
Upper Right ( 9.933, 45.033)
Lower Right ( 9.933, 43.967)
Center ( 9.400, 44.500)

listgeo italy_fixed.tif

Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
ModelTiepointTag (2,3):
0 0 0

8.86666666666667 45.0333333333333 0
ModelPixelScaleTag (1,3):
0.00208333333333333 0.00208333333333333 0
End_Of_Tags.
Keyed_Information:
GTModelTypeGeoKey (Short,1): ModelTypeGeographic
GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
GeographicTypeGeoKey (Short,1): GCS_WGS_84
GeogCitationGeoKey (Ascii,7): "WGS 84"
GeogAngularUnitsGeoKey (Short,1): Angular_Degree
GeogSemiMajorAxisGeoKey (Double,1): 6378137
GeogInvFlatteningGeoKey (Double,1): 298.257223563

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)

Corner Coordinates:

Upper Left ( 8d52' 0.00"E, 45d 2' 0.00"N)
Lower Left ( 8d52' 0.00"E, 43d58' 0.00"N)
Upper Right ( 9d56' 0.00"E, 45d 2' 0.00"N)
Lower Right ( 9d56' 0.00"E, 43d58' 0.00"N)
Center ( 9d24' 0.00"E, 44d30' 0.00"N)

[Even Rouault]

Le mercredi 11 février 2015 18:49:04, Jukka Rahkonen a écrit :
> jose.che...@gmail.com kirjoitti 2015-02-11 18:48:
> > Here you are:
> >
> > https://www.dropbox.com/sh/97pah0oy3c3h3n2/AABrWobMs7q0iDeZ73rs4i8la?dl=0
>
> Hi,
>
> The projection in that GeoTIFF is not complete for GDAL and it
> recognizes the projection only as some local coordinate system. Here
> below is gdalinfo from the original italy.tif and from a fixed copy I
> made with gdalwarp with the attached command. There is also listgeo from
> the both. Looks like rl2tool should write a bit more metadata or then
> GDAL should be able to interpret the projection from less metadata than
> it does now.

The GeoTIFF keys of that file are certainly incomplete for "normal" GeoTIFF
readers, at least for all those based on libgeotiff.

Keyed_Information:
GTCitationGeoKey (Ascii,7): "WGS 84"
GeographicTypeGeoKey (Short,1): GCS_WGS_84
End_Of_Keys.

http://www.remotesensing.org/geotiff/spec/geotiff2.7.html#2.7.3 mentions in Step
2 that the GTModelTypeGeoKey should be read. In that case, it is missing and
should be set to ModelTypeGeographic.

A reader could presumably be enhanced to see that in that case only
GeographicTypeGeoKey is defined (GTCitationGeoKey is informational only so can
be considered as ignored), and thus assume GTModelTypeGeoKey=Geographic, but
that would be more a hack than anything else.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com

[a.fu...@lqt.it]

On Wed, 11 Feb 2015 19:11:31 +0100, Even Rouault wrote:
> Le mercredi 11 février 2015 18:49:04, Jukka Rahkonen a écrit :

Hi Even and Jukka,

many thanks for your very useful review; I strongly appreciated.

the real cause explaining why so many mandatory tags are badly missing
from the GeoTIFF expected declarations is rather simple to be
identified.

the RasterLite2 own implementation optimistically relies on libgeotiff
GTIFSetFromProj4(); anyway this function seems to export no GeoTIFF
declarations at all when processing any PROJ.4 string containing a
"latlong" or "longlat" item.
please examine the following code snippet:

from geotiff_proj4.c
------------------------------------------------------------
value = OSR_GSV(papszNV,"proj");

if( value == NULL )
{
OSRFreeStringList( papszNV );
return FALSE;
}

else if( EQUAL(value,"longlat") || EQUAL(value,"latlong") )
{
}

else if( EQUAL(value,"tmerc") )
{
GTIFKeySet(gtif, GTModelTypeGeoKey, TYPE_SHORT, 1,
ModelTypeProjected);
..... several further keys are exported .....
}
-----------------------------------------------------------

the "longlat" conditional branch is completely empty, and this
is completely different from any other branch ("tmerc", "utm" etc).

I'm not really sure if this puzzling finding should be considered
a libgeotiff bug or if GTIFSetFromProj4() is never expected to
generate a complete set of GeoTIFF definitions.

bye Sandro

[Even Rouault]

Le mercredi 11 février 2015 20:47:35, a.fu...@lqt.it a écrit :
> On Wed, 11 Feb 2015 19:11:31 +0100, Even Rouault wrote:
> > Le mercredi 11 février 2015 18:49:04, Jukka Rahkonen a écrit :
> Hi Even and Jukka,
>
> many thanks for your very useful review; I strongly appreciated.
>
> the real cause explaining why so many mandatory tags are badly missing
> from the GeoTIFF expected declarations is rather simple to be
> identified.

Sandro,

AFAIR, the spec is not so clear about what is mandatory or not, but following
the logic of the libgeotiff cookbook is a reasonable expectation.

>
> the RasterLite2 own implementation optimistically relies on libgeotiff
> GTIFSetFromProj4(); anyway this function seems to export no GeoTIFF
> declarations at all when processing any PROJ.4 string containing a
> "latlong" or "longlat" item.
> please examine the following code snippet:
>
> from geotiff_proj4.c
> ------------------------------------------------------------
> value = OSR_GSV(papszNV,"proj");
>
> if( value == NULL )
> {
> OSRFreeStringList( papszNV );
> return FALSE;
> }
>
> else if( EQUAL(value,"longlat") || EQUAL(value,"latlong") )
> {
> }
>
> else if( EQUAL(value,"tmerc") )
> {
> GTIFKeySet(gtif, GTModelTypeGeoKey, TYPE_SHORT, 1,
> ModelTypeProjected);
> ..... several further keys are exported .....
> }
> -----------------------------------------------------------
>
> the "longlat" conditional branch is completely empty, and this
> is completely different from any other branch ("tmerc", "utm" etc).
>
> I'm not really sure if this puzzling finding should be considered
> a libgeotiff bug or if GTIFSetFromProj4() is never expected to
> generate a complete set of GeoTIFF definitions.

This very much looks like a bug in GTIFSetFromProj4(). It is my feeling that
this function isn't used a lot by projects (for reference GDAL doesn't use
it). I can see that there are a bunch of more or less exotic projection
methods that are currently between #ifdef notdef / #endif.

Even