Proj4 undefined when loading own geotiff

[tammojan]

Describe the bug
On the online version app.geotiff.io , I tried to load my own GeoTIFF file. It does not show up on the map, and the console reports:

ERROR initializing GeoTIFFLayer ReferenceError: "proj4 is not defined"
    initProjector https://app.geotiff.io/bundle.js:82
    initialize https://app.geotiff.io/bundle.js:82
    leaflet 1.0.3/dist/leaflet.js:5
    createRaster https://app.geotiff.io/bundle.js:82
bundle.js:82:18650

TypeError: this._bounds is undefined bundle.js:82:19604

To Reproduce

1. Go to 'app.geotiff.io'
2. Fill in the URL https://raw.githubusercontent.com/tammojan/lofargeotiff/master/example.tiff
3. Click 'LOAD'
4. Open console and see errors

Expected behavior
A map shows up (somewhere in Germany)

Desktop (please complete the following information):

• OS: macos
• Browser: Firefox 73.0.1and Chrome 80.0.3987.132

Other context
There may be missing metadata in the GeoTIFF file, though it loads fine in QGIS. If there is something missing, I'd like to learn that so that I can improve the software that writes it.

[DanielJDufour]

Thanks for reporting this bug. I'll look into it ASAP.

[DanielJDufour]

Hi, @tammojan . There seems to be a few things going on. Here's the output when I run gdalinfo example.tiff:

Driver: GTiff/GeoTIFF
Files: example.tiff
Size is 150, 150
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["unknown",
        SPHEROID["WGS84",6378137,298.257223563]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433]]
Origin = (11.709118377901767,50.977990063336165)
Pixel Size = (0.000028465301026,0.000017983935742)
Metadata:
  AREA_OR_POINT=Area
  calibration_comment=Manually flagged: several
  calibration_date=20170403
  calibration_obsdate=201612271045
  caltable=caltables/CalTable-603-LBA_INNER-10_90.dat
  datafile=20170720_095816_mode_3_xst_sb297.dat
  extent_xyz=[-150, 150, -150, 150]
  frequency=58007812.5
  generated_with=lofarimaging v1.5.0
  height=1.5
  obsdate=2017-07-20 09:58:16
  pixels_per_metre=0.5
  station=DE603LBA
  subband=297
  TIFFTAG_DATETIME=2017-07-20 09:58:16
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  11.7091184,  50.9779901) ( 11d42'32.83"E, 50d58'40.76"N)
Lower Left  (  11.7091184,  50.9806877) ( 11d42'32.83"E, 50d58'50.48"N)
Upper Right (  11.7133882,  50.9779901) ( 11d42'48.20"E, 50d58'40.76"N)
Lower Right (  11.7133882,  50.9806877) ( 11d42'48.20"E, 50d58'50.48"N)
Center      (  11.7112533,  50.9793389) ( 11d42'40.51"E, 50d58'45.62"N)
Band 1 Block=150x6 Type=Float64, ColorInterp=Gray

GeoTIFF.io depends on georaster-layer-for-leaflet, which depends on georaster. Specifically, georaster looks for the GeographicTypeGeoKey or ProjectedCSTypeGeoKey in order to determine the projection. Running tiffdump example.tiff shows that neither appear to be set:

Magic: 0x4949 <little-endian> Version: 0x2a <ClassicTIFF>
Directory 0: offset 8 (0x8) next 0 (0)
ImageWidth (256) SHORT (3) 1<150>
ImageLength (257) SHORT (3) 1<150>
BitsPerSample (258) SHORT (3) 1<64>
Compression (259) SHORT (3) 1<1>
Photometric (262) SHORT (3) 1<1>
StripOffsets (273) LONG (4) 25<1451 8651 15851 23051 30251 37451 44651 51851 59051 66251 73451 80651 87851 95051 102251 109451 116651 123851 131051 138251 145451 152651 159851 167051 ...>
SamplesPerPixel (277) SHORT (3) 1<1>
RowsPerStrip (278) SHORT (3) 1<6>
StripByteCounts (279) LONG (4) 25<7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 ...>
PlanarConfig (284) SHORT (3) 1<1>
DateTime (306) ASCII (2) 20<2017-07-20 09:58:16\0>
SampleFormat (339) SHORT (3) 1<3>
34264 (0x85d8) DOUBLE (12) 16<2.84653e-05 0 0 11.7091 0 1.79839e-05 0 50.978 0 0 0 0 0 0 0 1>
34735 (0x87af) SHORT (3) 44<1 1 0 10 1024 0 1 2 1025 0 1 1 2048 0 1 32767 2049 34737 72 0 2050 0 1 32767 ...>
34736 (0x87b0) DOUBLE (12) 3<6.37814e+06 298.257 0>
34737 (0x87b1) ASCII (2) 73<GCS Name = WGS 84|Datum  ...>
42112 (0xa480) ASCII (2) 700<<GDALMetadata>\n  <Item n ...>

Based on the projection information visible, it seems that you are using EPSG 436 (https://epsg.io/4326). Is it possible for you to set GeographicTypeGeoKey to 4326?

If not, we will find another way to make this work for you :-)

[DanielJDufour]

Here's GeoTIFF spec for reference: http://geotiff.maptools.org/spec/geotiff6.html

[tammojan]

Thanks for looking into this! I created the GeoTiff with rasterio, using the example from the docs, in particular using crs='+proj=latlong'. Changing that to crs=rasterio.crs.CRS.from_epsg(4326) makes the map show up in geotiff.io.

There's still a slight problem (the map now shows up meters off, and upside down), but I can fix that by looking at the projection more carefully.

So this is not a geotiff.io bug, though maybe the error message could be slightly clearer.

[tammojan]

The updated geotiff is at here , the code that generates it is here. I'm not sure what I'm doing wrong, since the GeoTIFF shows up nicely in QGIS.

Running gdalinfo on the updated geotiff yields

Driver: GTiff/GeoTIFF
Files: results/20170720_095816_DE603LBA_SB297_nearfield_calibrated.tiff
Size is 150, 150
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 = (11.709118377901767,50.977990063336165)
Pixel Size = (0.000028465301026,0.000017983935742)
Metadata:
  AREA_OR_POINT=Area
  calibration_comment=Manually flagged: several
  calibration_date=20170403
  calibration_obsdate=201612271045
  caltable=caltables/CalTable-603-LBA_INNER-10_90.dat
  datafile=20170720_095816_mode_3_xst_sb297.dat
  extent_xyz=[-150, 150, -150, 150]
  frequency=58007812.5
  generated_with=lofarimaging v1.5.0
  height=1.5
  obsdate=2017-07-20 09:58:16
  pixels_per_metre=0.5
  station=DE603LBA
  subband=297
  TIFFTAG_DATETIME=2017-07-20 09:58:16
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  11.7091184,  50.9779901) ( 11d42'32.83"E, 50d58'40.76"N)
Lower Left  (  11.7091184,  50.9806877) ( 11d42'32.83"E, 50d58'50.48"N)
Upper Right (  11.7133882,  50.9779901) ( 11d42'48.20"E, 50d58'40.76"N)
Lower Right (  11.7133882,  50.9806877) ( 11d42'48.20"E, 50d58'50.48"N)
Center      (  11.7112533,  50.9793389) ( 11d42'40.51"E, 50d58'45.62"N)
Band 1 Block=150x6 Type=Float64, ColorInterp=Gray

and tiffdump says:

results/20170720_095816_DE603LBA_SB297_nearfield_calibrated.tiff:
Magic: 0x4949 <little-endian> Version: 0x2a <ClassicTIFF>
Directory 0: offset 8 (0x8) next 0 (0)
ImageWidth (256) SHORT (3) 1<150>
ImageLength (257) SHORT (3) 1<150>
BitsPerSample (258) SHORT (3) 1<64>
Compression (259) SHORT (3) 1<1>
Photometric (262) SHORT (3) 1<1>
StripOffsets (273) LONG (4) 25<1354 8554 15754 22954 30154 37354 44554 51754 58954 66154 73354 80554 87754 94954 102154 109354 116554 123754 130954 138154 145354 152554 159754 166954 ...>
SamplesPerPixel (277) SHORT (3) 1<1>
RowsPerStrip (278) SHORT (3) 1<6>
StripByteCounts (279) LONG (4) 25<7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 7200 ...>
PlanarConfig (284) SHORT (3) 1<1>
DateTime (306) ASCII (2) 20<2017-07-20 09:58:16\0>
SampleFormat (339) SHORT (3) 1<3>
34264 (0x85d8) DOUBLE (12) 16<2.84653e-05 0 0 11.7091 0 1.79839e-05 0 50.978 0 0 0 0 0 0 0 1>
34735 (0x87af) SHORT (3) 32<1 1 0 7 1024 0 1 2 1025 0 1 1 2048 0 1 4326 2049 34737 7 0 2054 0 1 9102 ...>
34736 (0x87b0) DOUBLE (12) 2<298.257 6.37814e+06>
34737 (0x87b1) ASCII (2) 8<WGS 84|\0>
42112 (0xa480) ASCII (2) 700<<GDALMetadata>\n  <Item n ...>

So there is still no reference to GeographicTypeGeoKey. This may be an issue with rasterio.

[DanielJDufour]

@tammojan , thanks for working with me and being so thorough!

I'll write a work around to handle the case when someone generates a GeoTIFF with crs='+proj=latlong' as it is probably a problem others will run into as well.

One first glance the gdalinfo and tiffdump outputs looks good. GeoTIFF Metadata is like an onion. It has a lot of layers. GeographicTypeGeoKey (2048) is found inside of tag 34735 and correctly sets the value to 4326.

GeoTIFF.io is flipping the geotiff because its dependency georaster assumes that the second value in pixel size is a negative number, which is more commonly seen.

Pixel Size = (0.000028465301026,0.000017983935742)

Here's gdalinfo of https://github.com/GeoTIFF/geotiff.io/blob/master/assets/data/example_4326.tif for reference:

Could you check something for me? Does the origin in Origin = (11.709118377901767,50.977990063336165) refer to the top left or bottom left of your GeoTIFF area? Normally it's top left, but I'm wondering if it's flipped because of the positive y value in pixel size.

On further research, it appears that your GeoTIFF is being created with a ModelTransformationTag
instead of ModelPixelScaleTag and ModelTiepointTag (http://geotiff.maptools.org/spec/geotiff2.6.html). Do you happen to know if rasterio supports writing GeoTIFFs with ModelPixelScaleTag and ModelTiepointTag instead of ModelTransformationTag? If you could write it this way, it should hopefully work.

In either case, the fix isn't too complicated but will require an update to http://github.com/geotiff/georaster. I've created an issue on that repo at : GeoTIFF/georaster#47.

Thank you very much for your patience and help discovering these bugs!

[tammojan]

Hi @DanielJDufour , thanks for the quick reply! To avoid confusion about up and down, here's a screenshot from QGIS that shows the correct overlay.

[tammojan]

The extents of the image are:

• lon_min: 11.70913261055228
• lon_max: 11.71340240570623
• lat_min: 50.97799905530404
• lat_max: 50.98069664566538

So (11.709118377901767,50.977990063336165) corresponds to the bottom left (not top left).