大地TIFF网格(GTG)

7.0 新版功能.

介绍

大地测量TIFF网格格式是根据 项目RFC 4:远程访问网格和GeoTIFF网格 . 它是TIFF和GeoTIFF格式的一个概要文件,用于满足大地测量网格的特定要求:水平偏移、垂直偏移、速度网格等。。。它还遵循 Cloud Optimized GeoTIFF 原则。

这样的网格可以在 CDN of GeoTIFF grids .

一般说明

指导以下要求和建议的一般原则是,PROJ和GDAL将正确识别文件,GDAL是检查此类网格文件的一种简单方法:

  • TIFF 6.0 基于(如果我们需要某一天来处理大于4GB的网格,可能是BigTIFF而不需要代码更改)

  • GeoTIFF 1.1 为了地理参考。geotiff1.1是一个最新的标准,与原始的geotiff1.0版本相比,它的向后兼容性非常好,因此对于那些没有正式兼容geotiff1.1的读者来说应该不会造成太大的麻烦。

  • CDN上托管的文件将使用GeoTIFF GeoKeys的地理二维CRS。该CRS旨在成为中定义的插值CRS OGC Abstract Specification Topic 2 ,即引用栅格值的CR。

    假设它们名义上与EPSG数据集相关 GeodeticCRSGeoKey 将用于存储CRS的EPSG代码。如果不能通过该密钥或其他地理密钥对CRS进行可靠编码,则 interpolation_crs_wkt 应使用随后详述的元数据项。

    该CRS通常是源CRS(对于地理到地理水平移动网格,或地理到垂直移动网格),但对于垂直到垂直CRS调整,这将是网格引用的地理CRS。在地理到垂直移动网格的一些非常罕见的情况下,插值CR可能是与源CR不同的地理CR(表示椭球体高度)。我们唯一想到的例子就是EPSG:7001“ETRS89到NAP高度(1)”转换,使用naptrans2008 VDatum网格,该网格引用了AmersfoortEPSG:4289ETRS89的。。。

    在读取端,PROJ将忽略该信息:CRS已经存储在grid转换表的sourceu CRS或interpolationu CRS列中。

    对于地理到垂直移动文件(geoid模型),GeoTIFF 1.1约定将用于存储 VerticalGeoKey 所以一个适用于WGS 84的大地水准面模型EPSG:4979威尔测地键=4326,垂直键=4979。

  • CDN上托管的文件将使用定义的GeoTIFF ModelTiepointTag and ModelPixelScaleTag TIFF标签用于存储左上角像素的坐标和像素的分辨率。在阅读端,它们是必需的,ModelTransformationTag将被忽略。

    备注

    关于反经络处理,存在多种可能性。我们不会试图对此进行标准化,CDN上托管的文件将使用靠近原始数据生产者的地理配准。例如,适用于连续美国的NOAA垂直网格的左上角经度可能超过180(为了与阿拉斯加网格保持一致,其原点<180),在Proj中的反子午线处理可能会有问题。本RFC并不试图特别解决它们,因为它们被认为与它所涵盖的主题是正交的,并且主要是实现问题。

  • CDN上托管的文件将使用 GTRasterTypeGeoKey =像素点约定。这是目前大多数现有网格格式使用的约定。请注意,GDAL通常使用PixelIsArea约定(但可以处理这两种约定),因此在打开.gsb或.gtx文件时显示的地理参考相对于原始网格文件中存储的坐标似乎有半个像素的偏移。在读取端,PROJ将接受这两种约定(对于等效的地理参照,PixelIsArea约定中原点的值向左上方向移动半个像素)。如果不存在此地理密钥,则为未指定的行为。

  • CDN上托管的文件将平铺,大概是256x256平铺(小于256x256的小网格将使用单个条带)。在读取端,PROJ将接受带有任何条带或平铺组织的TIFF文件。平铺通过指定TileWidth、TileHeight、tileoffset和TileByteCounts标记来表示。条带组织通过指定RowsPerStrip、StripByteCounts和stripfostates标记来表示。

  • CDN上托管的文件将使用 Compression =放气或LZW(待确定,可能与 Predictor =2或3)在读取端,PROJ将接受具有PROJ使用的libtiff构建所支持的任何压缩方法(适用于所考虑的数据类型和测光解释)的TIFF文件。当然,将支持未压缩的文件。

  • CDN上托管的文件将使用小端字节排序。在阅读方面,libtiff将透明地处理little-endian和big-endian排序。

  • CDN上托管的文件将使用PlanarConfiguration=Separate。后面一节中描述的工具将对块进行排序,以便给定位置所需的块彼此接近。在读取端,PROJ还将处理PlanarConfiguration=Contig。

  • CDN上托管的文件通常使用Float32(BitsPerSample=32和SampleFormat=IEEEFP)文件可以使用带符号的Int 16创建( BitsPerSample =16和 SampleFormat =INT)、无符号INT 16(BitsPerSample=16和SampleFormat=UINT)、有符号INT 32或无符号INT 32通常具有相关的比例/偏移。在读取端,也只支持这三种数据类型。

  • CDN上托管的文件将具有 PhotometricInterpretation =黑色。它将被假定,而在阅读端被忽略。

  • CDN上托管的文件名义上具有:

    • SamplesPerPixel =2表示水平移动网格,第一个采样是经度偏移,第二个采样是纬度偏移。

    • SamplesPerPixel=1表示垂直移动网格。

    • 对于结合水平和垂直调整的变形模型,SamplesPerPixel=3。

    即使对于目前确定的水平或垂直移动的需求,也可能存在更多的样本(例如表示不确定性),但项目将忽略这些样本。

    这个 ExtraSamples 标签的值应设置为SamplesPerPixel-1(给定适用于photometricinspretation=MinIsBlack的规则)

  • 这个 ImageDescription 标签可用于传达有关网格的名称、出处、版本和最后更新日期的额外信息。将在可能的情况下为CDN上托管的文件设置。被项目忽略。

  • 这个 Copyright 标签可以用来传达关于网格的版权和许可的额外信息。将在可能的情况下为CDN上托管的文件设置。被项目忽略。

  • 这个 DateTime 标签可用于传达文件已被创建或转换的日期。如果是文件转换,例如从NTv2转换,这将是执行转换的日期。这个 ImageDescription 但是,标签将包含从NTv2文件创建或更新的最新字段。将在可能的情况下为CDN上托管的文件设置。被项目忽略。

  • CDN上托管的文件将使用 GDAL_NODATA 标记对nodata/缺失值的值进行编码,当它应用于网格时。

    如果使用偏移和/或缩放,则在应用偏移和缩放之前,nodata值与原始值相对应。在该标签中找到的值(如果存在)将被接受(在当前项目代码使用nodata的范围内)。对于浮点数据,强烈建议编写器使用nodata的非有限值(+/-infinity,NaN)来最大化互操作性。GDALu NODATA值适用于给定TIFF IFD的所有样本。

  • CDN上托管的文件将使用 GDAL_METADATA 标记对基线或扩展TIFF不支持的额外元数据进行编码。

    • 根XML节点应为 GDALMetadata

    • 零个、一个或多个子XML节点 Item 可能存在。

    • 项目应具有 name 属性和一个子文本节点及其值。 rolesample 对于具有特殊语义(由GDAL识别)的属性,可以存在属性。价值 sample 应该是介于0和u样本数u-1之间的整数值。

    • 将整型原始值转换为浮点值的小数位数和偏移量可用XML表示 Item 名称属性分别为 SCALEOFFSET ,以及他们的 role 属性分别为 scaleoffset 。解码值为:{Offset}+{Scale}*RAW_VALUE_FROM_Geotiff_FILE

      对于偏移值1和缩放2,应存储以下有效负载:

      <GDALMetadata>
          <Item name="OFFSET" sample="0" role="offset">1</Item>
          <Item name="SCALE" sample="0" role="scale">2</Item>
      </GDALMetadata>
      
    • 网格的类型必须用 Item 谁的 name 设置为 TYPE .

      项目目前认可的价值是:

      • HORIZONTAL_OFFSET :表示至少存在两个样本。第一个样本必须包含纬度偏移,第二个样本必须包含经度偏移。对应于项目 水平网格移动 方法。

      • VERTICAL_OFFSET_GEOGRAPHIC_TO_VERTICAL :表示至少存在一个样本。第一个样品必须包含垂直调整。当源/插值CRS为地理CRS且目标CRS为垂直CRS时,必须使用。对应于项目 垂直网格移动 方法。

      • VERTICAL_OFFSET_VERTICAL_TO_VERTICAL :表示至少存在一个样本。第一个样品必须包含垂直调整。当源和目标CR是垂直CR时必须使用。对应于项目 垂直网格移动 方法。

      • GEOCENTRIC_TRANSLATION :表示至少存在3个样品。前3个样本必须分别沿X、Y和Z轴进行地心调整。当源CRS和目标CRS是地心CRS时必须使用。插值CRS必须是地理CRS。对应于项目 地心网格偏移 方法。

      • VELOCITY :表示至少存在3个样品。前3个样本必须分别是局部地心坐标系中沿E(ast)、N(orth)、U(p)轴的速度。对应于项目 利用变形模型进行动态基准移动 方法。

      • DEFORMATION_MODEL :表示存在 DISPLACEMENT_TYPEUNCERTAINTY_TYPE 元数据项。对应于项目 基于时间的多分量变形模型 方法。

      例如:

      <Item name="TYPE">HORIZONTAL_OFFSET</Item>
      
    • 每个样品的描述必须用一个 name 属性设置为 DESCRIPTIONrole 属性到 description .

      项目当前对此项目识别的值为:

      • latitude_offset :对TYPE=HORIZONTALu OFFSET有效。样本值应该是一个值,用于添加在地理键中编码的CRS中表示的纬度,以获得在目标CRS中表示的纬度值。

      • longitude_offset :对TYPE=HORIZONTALu OFFSET有效。示例值应该是一个值,用于添加在地理键中编码的CRS中表示的经度,以获得在目标CRS中表示的经度值。

      • geoid_undulation :对TYPE=VERTICALu OFFSETu GEOGRAPHICu TOu VERTICAL有效。对于作为地理CRS的源CRS和作为垂直CRS的目标CRS,采样值应是添加到大地水准面相关高度(以目标CRS表示)的值,以获得椭球体高度(以源CRS表示),也称为大地水准面起伏。注意与什么是源CRS和目标CRS以及存储的值的语义相关的可能混淆(要从源转换到目标,必须减去网格中包含的值)。这是政府使用的惯例 EPSG:9665 操作方法。

      • vertical_offset :对TYPE=VERTICALu OFFSETu VERTICALu TO u VERTICAL有效。对于源和目标CRS是垂直CRS,采样值应该是添加到源CRS中表示的高程的值,以获得目标CRS中表示的经度值。

      • x_translation / y_translation / z_translation :对类型=地心坐标转换有效。样本值应该是添加到源CRS中表示的输入地心坐标到目标CRS中表示的地心坐标的值。

      • east_velocity / north_velocity / up_velocity :对TYPE=VELOCITY有效。采样值应为本地地心坐标系中以线性/时间单位表示的速度。

      • east_offset / north_offset / vertical_offset :对类型=变形模型有效。对于东偏移和北偏移,单位可能是度或米。对于垂直偏移,单位必须为米。

      例如:

      <Item name="DESCRIPTION" sample="0" role="description">latitude_offset</Item>
      <Item name="DESCRIPTION" sample="1" role="description">longitude_offset</Item>
      

      可以使用其他值(项目不使用):

      • latitude_offset_accuracy :对TYPE=HORIZONTALu OFFSET有效。样本值应为相应纬度偏移样本的精度。一般以米为单位(如果从NTv2换算)

      • longitude_offset_accuracy :对TYPE=HORIZONTALu OFFSET有效。样本值应为相应经度偏移样本的精度。一般以米为单位(如果从NTv2换算)

    • 符号值的符号约定 longitude_offset 频道应该用一个名为 positive_value 其价值可以是 westeast . NTv2产品最初使用 west 但当从它们转换为GeoTIFF时,这些样本的符号将被反转,因此它们使用更自然的符号 east 惯例。如果没有此项,则默认值为 east .

    • 必须通过名称项为每个样本指定存储在网格中的值的单位 UNITTYPE 和角色 unittype 有效值应该是EPSG中条目的名称 unitofmeasure 桌子。为了最大限度地提高互操作性,强烈建议编写者将自己限制为以下值:

      对于线性单位:

      • metre (如果垂直移动网格文件不存在,则假定为默认值,并且该值用于存储在PROJ CDN上的文件)

      • US survey foot

      对于角度单位:

      • degree

      • arc-second (如果水平移动网格文件的经纬度偏移示例不存在,则假定为默认值,并且该值用于存储在PROJ CDN上的文件)

      对于速度单位:

      • millimetres per year

      经纬度偏移采样应使用相同的单位。地心翻译样本应使用相同的单位。速度样本应使用相同的单位。

      例子:

      <Item name="UNITTYPE" sample="0" role="unittype">arc-second</Item>
      <Item name="UNITTYPE" sample="1" role="unittype">arc-second</Item>
      
    • 对于类型=变形模型,位移类型必须用 Item 谁的 name 设置为 DISPLACEMENT_TYPE .

      可接受的值为: HORIZONTALVERTICAL3DNONE

    • 对于类型=变形模型,不确定性的类型必须用 Item 谁的 name 设置为 UNCERTAINTY_TYPE .

      可接受的值为: HORIZONTALVERTICAL3DNONE

    • 这个 target_crs_epsg_code 元数据项应存在。对于水平移动网格,这是目标地理CRS的EPSG代码。对于垂直移动网格,这是目标垂直CRS的EPSG代码。如果目标CRS没有相关的EPSG代码, target_crs_wkt 必须使用。当前已被项目忽略。

    • 这个 target_crs_wkt 如果 target_crs_epsg_code 无法使用。它的值应该是一个有效的WKT字符串,根据 WKT:2015WKT:2019 当前已被项目忽略。

    • 这个 source_crs_epsg_code 如果源CRS和插值CRS不相同(典型的用例是垂直CRS到垂直CRS的转换),则元数据项必须存在,因为地理键编码插值CRS而不是源CRS。如果源CRS没有相关的EPSG代码, source_crs_wkt 必须使用。当前已被项目忽略。

    • 这个 source_crs_wkt 如果 source_crs_epsg_code 无法使用。它的值应该是一个有效的WKT字符串,根据WKT:2015或WKT:2019年。当前已被项目忽略。

    • 这个 interpolation_crs_wkt 如果地理键不能可靠地表示插值CRS,则可能存在元数据项。它的值应该是一个有效的WKT字符串,根据WKT:2015或WKT:2019年。当前已被项目忽略。

    • 这个 recommended_interpolation_method 可以存在元数据项来描述用于在与网格文件中存储的节点不一致的位置处插值值的方法。潜在价值: bilinearbicubic . 当前已被项目忽略。

    • 这个 area_of_use 元数据项可用于指示有关网格使用区域的纯文本信息(如“USA-Wisconsin”)。如果有多个子网格,则应仅在第一个子网格上设置,但应适用于整个网格集,而不仅仅是第一个子网格。

    • 这个 grid_name 如果此网格中存在子网格的扩展数据块(如果此网格中存在子网格的扩展数据块)。它是一个相对较短的标识符,将被PROJ忽略(该信息可通过网格范围推断)

    • 这个 parent_grid_name 如果这是一个子格网,并且其值应等于父格网的值,则应显示元数据项 grid_name 将被Proj忽略(此信息可由栅格范围推断)

    • 这个 number_of_nested_grids 如果此网格有子网格(即其范围包含在此网格范围中的网格),则应存在元数据项。将被PROJ忽略(此信息可通过网格范围推断)

例子

https://github.com/OSGeo/PROJ-data/blob/master/fr_ign/fr_ign_ntf_r93.tif has been converted from https://github.com/OSGeo/proj-datumgrid/blob/master/ntf_r93.gsb with https://github.com/OSGeo/PROJ-data/blob/master/grid_tools/ntv2_to_gtiff.py

$ tiffinfo ntf_r93.tif

TIFF Directory at offset 0x4e (78)
Image Width: 156 Image Length: 111
Bits/Sample: 32
Sample Format: IEEE floating point
Compression Scheme: AdobeDeflate
Photometric Interpretation: min-is-black
Extra Samples: 3<unspecified, unspecified, unspecified>
Samples/Pixel: 4
Rows/Strip: 111
Planar Configuration: separate image planes
ImageDescription: NTF (EPSG:4275) to RGF93 (EPSG:4171). Converted from ntf_r93.gsb (version IGN07_01, last updated on 2007-10-31)
DateTime: 2019:12:09 00:00:00
Copyright: Derived from work by IGN France. Open License https://www.etalab.gouv.fr/wp-content/uploads/2014/05/Open_Licence.pdf
Tag 33550: 0.100000,0.100000,0.000000
Tag 33922: 0.000000,0.000000,0.000000,-5.500000,52.000000,0.000000
Tag 34735: 1,1,1,3,1024,0,1,2,1025,0,1,2,2048,0,1,4275
Tag 42112: <GDALMetadata>
<Item name="grid_name">FRANCE</Item>
<Item name="target_crs_epsg_code">4171</Item>
<Item name="TYPE">HORIZONTAL_OFFSET</Item>
<Item name="UNITTYPE" sample="0" role="unittype">arc-second</Item>
<Item name="DESCRIPTION" sample="0" role="description">latitude_offset</Item>
<Item name="positive_value" sample="1">east</Item>
<Item name="UNITTYPE" sample="1" role="unittype">arc-second</Item>
<Item name="DESCRIPTION" sample="1" role="description">longitude_offset</Item>
<Item name="UNITTYPE" sample="2" role="unittype">arc-second</Item>
<Item name="DESCRIPTION" sample="2" role="description">latitude_offset_accuracy</Item>
<Item name="UNITTYPE" sample="3" role="unittype">arc-second</Item>
<Item name="DESCRIPTION" sample="3" role="description">longitude_offset_accuracy</Item>
</GDALMetadata>

Predictor: floating point predictor 3 (0x3)
$ listgeo ntf_r93.tif

Geotiff_Information:
    Version: 1
    Key_Revision: 1.1
    Tagged_Information:
        ModelTiepointTag (2,3):
            0                 0                 0
            -5.5              52                0
        ModelPixelScaleTag (1,3):
            0.1               0.1               0
        End_Of_Tags.
    Keyed_Information:
        GTModelTypeGeoKey (Short,1): ModelTypeGeographic
        GTRasterTypeGeoKey (Short,1): RasterPixelIsPoint
        GeodeticCRSGeoKey (Short,1): Code-4275 (NTF)
        End_Of_Keys.
    End_Of_Geotiff.

GCS: 4275/NTF
Datum: 6275/Nouvelle Triangulation Francaise
Ellipsoid: 7011/Clarke 1880 (IGN) (6378249.20,6356515.00)
Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
Projection Linear Units: User-Defined (1.000000m)

Corner Coordinates:
Upper Left    (  5d30' 0.00"W, 52d 0' 0.00"N)
Lower Left    (  5d30' 0.00"W, 40d54' 0.00"N)
Upper Right   ( 10d 6' 0.00"E, 52d 0' 0.00"N)
Lower Right   ( 10d 6' 0.00"E, 40d54' 0.00"N)
Center        (  2d18' 0.00"E, 46d27' 0.00"N)
$ gdalinfo ntf_r93.tif

Driver: GTiff/GeoTIFF
Files: ntf_r93.tif
Size is 156, 111
Coordinate System is:
GEOGCRS["NTF",
    DATUM["Nouvelle Triangulation Francaise",
        ELLIPSOID["Clarke 1880 (IGN)",6378249.2,293.466021293627,
            LENGTHUNIT["metre",1]]],
    PRIMEM["Greenwich",0,
        ANGLEUNIT["degree",0.0174532925199433]],
    CS[ellipsoidal,2],
        AXIS["geodetic latitude (Lat)",north,
            ORDER[1],
            ANGLEUNIT["degree",0.0174532925199433]],
        AXIS["geodetic longitude (Lon)",east,
            ORDER[2],
            ANGLEUNIT["degree",0.0174532925199433]],
    ID["EPSG",4275]]
Data axis to CRS axis mapping: 2,1
Origin = (-5.550000000000000,52.049999999999997)
Pixel Size = (0.100000000000000,-0.100000000000000)
Metadata:
  AREA_OR_POINT=Point
  grid_name=FRANCE
  target_crs_epsg_code=4171
  TIFFTAG_DATETIME=2019:12:09 00:00:00
  TIFFTAG_IMAGEDESCRIPTION=NTF (EPSG:4275) to RGF93 (EPSG:4171). Converted from ntf_r93.gsb (version IGN07_01, last updated on 2007-10-31)
  TYPE=HORIZONTAL_OFFSET
Image Structure Metadata:
  COMPRESSION=DEFLATE
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  -5.5500000,  52.0500000) (  5d33' 0.00"W, 52d 3' 0.00"N)
Lower Left  (  -5.5500000,  40.9500000) (  5d33' 0.00"W, 40d57' 0.00"N)
Upper Right (  10.0500000,  52.0500000) ( 10d 3' 0.00"E, 52d 3' 0.00"N)
Lower Right (  10.0500000,  40.9500000) ( 10d 3' 0.00"E, 40d57' 0.00"N)
Center      (   2.2500000,  46.5000000) (  2d15' 0.00"E, 46d30' 0.00"N)
Band 1 Block=156x111 Type=Float32, ColorInterp=Gray
  Description = latitude_offset
  Unit Type: arc-second
Band 2 Block=156x111 Type=Float32, ColorInterp=Undefined
  Description = longitude_offset
  Unit Type: arc-second
  Metadata:
    positive_value=east
Band 3 Block=156x111 Type=Float32, ColorInterp=Undefined
  Description = latitude_offset_accuracy
  Unit Type: arc-second
Band 4 Block=156x111 Type=Float32, ColorInterp=Undefined
  Description = longitude_offset_accuracy
  Unit Type: arc-second

多网格存储

像NTv2这样的格式可以包含多个子网格。通过使用多个IFD与IFD的最后4个字节(BigTIFF为8个字节)链接在一起,指向下一个IFD的偏移量,可以将其转换为TIFF。

第一个IFD应该有一个完整的描述,根据 General description . 随后的IFD可能具有更紧凑的描述,例如,如果CRS信息与主IFD相同(对于当前设想的用例应该是这样),则省略CRS信息,或者版权/ImageDescription元数据项。

每个IFD都有自己的 NewSubfileType 标记设置为0。

如果低分辨率网格可用,则应将其放在IFD链接链中分辨率较高的子网格之前。在读取时,proj将使用包含兴趣点的最高分辨率网格中的值。

为了从网络中高效读取,CDN上托管的文件将使用类似于中所述的布局 low level paragraph of the Cloud Optimized GeoTIFF GDAL driver page

例如,从NTv2转换的文件的布局为:

  • TIFF/BigTIFF头/签名和指向第一个IFD(图像文件目录)的指针

  • “重影区域”表示生成的进程

  • 第一个网格的IFD,后跟TIFF标记值,不包括tileoffset和TileByteCounts数组

  • 最后一个网格的IFD,后跟TIFF标记值,不包括GDALu元数据标记、TileOffsets和TileByteCounts数组

  • 第一个ifffyted数组的eb计数

  • 上次IFD的tileOffset和TileByteCounts数组

  • 第一个IFD之后IFD的GDALu元数据标记的值

  • 第一个IFD:与块0的纬度偏移量相对应的数据

  • 第一个IFD:与块0的经度偏移相对应的数据

  • 第一个IFD:与块u 0 u 1的纬度偏移相对应的数据

  • 第一个IFD:与块u 0 u 1的经度偏移相对应的数据

  • 第一IFD:与块的纬度偏移量相对应的数据

  • 第一IFD:与块的经度偏移相对应的数据

  • 最后一个IFD:与块0的纬度偏移量相对应的数据

  • 最后一个IFD:与块0的经度偏移相对应的数据

  • 最后一个IFD:与块u 0 u 1的纬度偏移相对应的数据

  • 最后一个IFD:与块u 0 u 1的经度偏移相对应的数据

  • 最后一个IFD:与块的纬度偏移量相对应的数据

  • 最后IFD:与块的经度偏移量相对应的数据

如果存在经度偏移精度和纬度偏移精度,则随后将出现:

  • 第一个IFD:与块0的纬度偏移精度相对应的数据

  • 第一个IFD:与块0的经度偏移精度相对应的数据

  • 第一个IFD:与块的纬度偏移精度相对应的数据

  • 第一IFD:与块的经度偏移精度相对应的数据

  • 最后一个IFD:与块0的纬度偏移精度相对应的数据

  • 最后一个IFD:与块0的经度偏移精度相对应的数据

  • 最后一个IFD:与块的纬度偏移精度相对应的数据

  • 最后IFD:与块的经度偏移精度相对应的数据

备注

TIFF还有另一种链接ifd的机制,SubIFD标记。这有可能定义ifd的层次结构(类似于HDF5组)。大多数使用TIFF的软件(尤其是GDAL)都不支持这一点,也不需要嵌套层次结构,因此采用了带有标准IFD链接机制的“扁平”组织。

多网格数据集实例

https://github.com/OSGeo/PROJ-data/blob/master/au_icsm/au_icsm_GDA94_GDA2020_conformal.tif has been converted from https://github.com/OSGeo/proj-datumgrid/blob/master/oceania/GDA94_GDA2020_conformal.gsb with https://github.com/OSGeo/PROJ-data/blob/master/grid_tools/ntv2_to_gtiff.py

它包含5个子网格。列出子网格及其地理参考的所有基本元数据都包含在文件的前3KB中。

使用放气压缩和浮点预测,文件大小为4.8MB。它是从原始.gsb文件的83 MB无损转换而来的。

https://github.com/OSGeo/PROJ-data/blob/master/ca_nrc/ca_nrc_ntv2_0.tif has been converted from https://github.com/OSGeo/proj-datumgrid/blob/master/north-america/ntv2_0.gsb

它包含114个子网格。列出子网格及其地理参考的所有基本元数据都包含在文件的前40KB内。