GeoTIFF Format Specification
`
`GeoTIFF Revision 1.0
`
`+---------------------------------------------------------------------+
`
`
`
` Specification Version: 1.8.1
` Last Modified: 31 October, 1995
`
`
`Authors:
`
`
`
` Niles Ritter, Jet Propulsion Laboratory
` Cartographic Applications Group
` 4800 Oak Grove Dr.
` Pasadena, CA 91109
` email:ndr@tazboy.jpl.nasa.gov
`
` Mike Ruth, SPOT Image Corp
` Product Development Group
` 1897 Preston White Dr.
` Reston, VA 22091
` email:ruth@spot.com
`
`
`Acknowledgments:
`
`
`
`GeoTIFF Working Group:
` Mike Ruth, Niles Ritter, Ed Grissom, Brett Borup, George Galang,
` John Haller, Gary Stephenson, Steve Covington, Tim Nagy,
` Jamie Moyers, Jim Stickley,Joe Messina, Yves Somer.
`
`Additional advice from discussions with Tom Lane, Sam Leffler regarding
`TIFF implementations.
`
`Roger Lott, Fredrik Lundh, and Jarle Land provided valuable information
`regarding projections, projection code databases and geodetics.
`
`GeoTIFF Mailing list:
` Posting: geotiff@tazboy.jpl.nasa.gov
` Subscription: geotiff-request@tazboy.jpl.nasa.gov
` (send message "subscribe geotiff your-name-here").
`
`
`WhatsApp LLC
`Exhibit 1018
`Page 001
`
`

`

`Disclaimers and Notes for This Version:
`
`
`
`This proposal has not been approved by SPOT, JPL, or any other organization.
`This represents a proposal, which derives from many discussions between an
`international body of TIFF users and developers.
`
`
`
`The authors and their sponsors assume no liability for any special, incidental,
`indirect or consequences of any kind, or any damages whatsoever resulting from
`loss of use, data or profits, whether or not advised of the possibility of
`damage, and on any theory of liability, arising out of or in connection with
`the use of this specification.
`
`
`
`Copyright
`
`
`
`Portions of this specification are copyrighted by Niles Ritter and Mike Ruth.
`Permission to copy without fee all or part of this material is granted provided
`that the copies are not made or distributed for direct or commercial advantage
`and this copyright notice appears.
`
`
`
`Licenses and Trademarks
`
`
`
`Aldus and Adobe are registered trademarks, and TIFF is a registered trademark
`of Aldus Corp., now owned by Adobe. SPOT Image, ESRI, ERDAS, ARC/Info, Intergraph
`and Softdesk are registered trademarks.
`
`Concurrence
`
`
`
` The following members of the GeoTIFF working group have reviewed and approved
`of this revision.
`
`
`
` Name Organization Representing
` -------------------- ----------------------- ------------
` Niles Ritter Jet Propulsion Labs JPL Carto Group
` Mike Ruth SPOT Image Corp. (USA) SPOT Image Corp. (USA)
`
`
`+--------------------------------------------------------------------+
`
`WhatsApp LLC
`Exhibit 1018
`Page 002
`
`

`

`Table of Contents
`
`+--------------------------------------------------------------------+
`
`+--------------------------------------------------------------------+
`
`1 Introduction
`
`+--------------------------------------------------------------------+
`
`+----------------------------------+
`
`1.1 About this Specification
`
`
`
`This is a description of a proposal to specify the content and structure of
`a group of industry-standard tag sets for the management of georeference or
`geocoded raster imagery using Aldus-Adobe's public domain Tagged-Image File
`Format (TIFF).
`
`
`
`This specification closely follows the organization and structure of the TIFF
`specification document.
`
`+----------------------------------+
`
`1.1.1 Background
`
`
`
`TIFF has emerged as one of the world's most popular raster file formats. But
`TIFF remains limited in cartographic applications, since no publicly available,
`stable structure for conveying geographic information presently exists in the
`public domain.
`
`
`
`Several private solutions exist for recording cartographic information in TIFF
`tags. Intergraph has a mature and sophisticated geotie tag implementation,
`but this remains within the private TIFF tagset registered exclusively to
`Intergraph. Other companies (such as ESRI, and Island Graphics) have geographic
`solutions which are also proprietary or limited by specific application to
`their software's architecture.
`
`
`
`Many GIS companies, raster data providers, and their clients have requested
`that the companies concerned with delivery and exploitation of raster geographic
`imagery develop a publicly available, platform interoperable standard for the
`support of geographic TIFF imagery. Such TIFF imagery would originate from
`satellite imaging platforms, aerial platforms, scans of aerial photography
`or paper maps, or as a result of geographic analysis. TIFF images which were
`supported by the public "geotie" tagset would be able to be read and positioned
`correctly in any GIS or digital mapping system which supports the "GeoTIFF"
`standard, as proposed in this document.
`
`WhatsApp LLC
`Exhibit 1018
`Page 003
`
`

`

`
`
`The savings to the users and providers of raster data and exploitation softwares
`are potentially significant. With a platform interoperable GeoTIFF file,
`companies could stop spending excessive development resource in support of
`any and all proprietary formats which are invented. Data providers may be able
`to produce off-the-shelf imagery products which can be delivered in the "generic"
`TIFF format quickly and possibly at lower cost. End-users will have the advantage
`of developed software that exploits the GeoTIFF tags transparently. Most
`importantly, the same raster TIFF image which can be read and modified in one
`GIS environment may be equally exploitable in another GIS environment without
`requiring any file duplication or import/export operation.
`
`+----------------------------------+
`
`1.1.2 History
`
`
`
`The initial efforts to define a TIFF "geotie" specification began under the
`leadership of Ed Grissom at Intergraph, and others in the early 1990's. In
`1994 a formal GeoTIFF mailing-list was created and maintained by Niles Ritter
`at JPL, which quickly grew to over 140 subscribers from government and industry.
`The purpose of the list is to discuss common goals and interests in developing
`an industry-wide GeoTIFF standard, and culminated in a conference in March
`of 1995 hosted by SPOT Image, with representatives from USGS, Intergraph, ESRI,
`ERDAS, SoftDesk, MapInfo, NASA/JPL, and others, in which the current working
`proposal for GeoTIFF was outlined. The outline was condensed into a prerelease
`GeoTIFF specification document by Niles Ritter, and Mike Ruth of SPOT Image.
`
`Following discussions with Dr. Roger Lott of the European Petroleum Survey
`Group (EPSG), the GeoTIFF projection parametrization method was extensively
`modified, and brought into compatibility with both the POSC Epicentre model,
`and the Federal Geographic Data Committee (FGDC) metadata approaches.
`
`+----------------------------------+
`
`1.1.3 Scope
`
`
`
`The GeoTIFF spec defines a set of TIFF tags provided to describe all "Cartographic"
`information associated with TIFF imagery that originates from satellite imaging
`systems, scanned aerial photography, scanned maps, digital elevation models,
`or as a result of geographic analyses. Its aim is to allow means for tying
`a raster image to a known model space or map projection, and for describing
`those projections.
`
`
`
`GeoTIFF does not intend to become a replacement for existing geographic data
`interchange standards, such as the USGS SDTS standard or the FGDC metadata
`standard. Rather, it aims to augment an existing popular raster-data format
`to support georeferencing and geocoding information.
`
`
`
`WhatsApp LLC
`Exhibit 1018
`Page 004
`
`

`

`The tags documented in this spec are to be considered completely orthogonal
`to the raster-data descriptions of the TIFF spec, and impose no restrictions
`on how the standard TIFF tags are to be interpreted, which color spaces or
`compression types are to be used, etc.
`
`
`
`+----------------------------------+
`
`1.1.4 Features
`
`
`
`GeoTIFF fully complies with the TIFF 6.0 specifications, and its extensions
`do not in any way go against the TIFF recommendations, nor do they limit the
`scope of raster data supported by TIFF.
`
`
`
`GeoTIFF uses a small set of reserved TIFF tags to store a broad range of
`georeferencing information, catering to geographic as well as projected
`coordinate systems needs. Projections include UTM, US State Plane and National
`Grids, as well as the underlying projection types such as Transverse Mercator,
`Lambert Conformal Conic, etc. No information is stored in private structures,
`IFD's or other mechanisms which would hide information from naive TIFF reading
`software.
`
`
`
`GeoTIFF uses a "MetaTag" (GeoKey) approach to encode dozens of information
`elements into just 6 tags, taking advantage of TIFF platform-independent data
`format representation to avoid cross-platform interchange difficulties. These
`keys are designed in a manner parallel to standard TIFF tags, and closely follow
`the TIFF discipline in their structure and layout. New keys may be defined
`as needs arise, within the current framework, and without requiring the
`allocation of new tags from Aldus/Adobe.
`
`
`
`GeoTIFF uses numerical codes to describe projection types, coordinate systems,
`datums, ellipsoids, etc. The projection, datums and ellipsoid codes are derived
`from the EPSG list compiled by the Petrotechnical Open Software Corporation
`(POSC), and mechanisms for adding further international projections, datums
`and ellipsoids has been established. The GeoTIFF information content is designed
`to be compatible with the data decomposition approach used by the National
`Spatial Data Infrastructure (NSDI) of the U.S. Federal Geographic Data Committee
`(FGDC).
`
`
`
`While GeoTIFF provides a robust framework for specifying a broad class of existing
`Projected coordinate systems, it is also fully extensible, permitting internal,
`private or proprietary information storage. However, since this standard arose
`from the need to avoid multiple proprietary encoding systems, use of private
`implementations is to be discouraged.
`
`+----------------------------------+
`
`WhatsApp LLC
`Exhibit 1018
`Page 005
`
`

`

`1.2 Revision Notes
`
`
`
`This is the final release of GeoTIFF Revision 1.0, supporting the new EPSG
`2.x codes.
`
`
`
`Changes from 1.8 document: minor spelling and typo corrections.
`
`
`
`+----------------------------------+
`
`1.2.1 Revision Nomenclature
`
`A Revision of GeoTIFF specifications will be denoted by two integers separated
`by a decimal, indicating the Major and Minor revision numbers. GeoTIFF stores
`most of its information using a "Key-Code" pairing system; the Major revision
`number will only be incremented when a substantial addition or modification
`is made to the list of information Keys, while the Minor Revision number permits
`incremental augmentation of the list of valid codes.
`
`+----------------------------------+
`
`1.2.2 New Features
`
`
`
`Revision 1.0 New Transformation Matrix Tag.
`
`Index Table added in Section 6.4 to assist in looking up geodesy codes.
`
`+----------------------------------+
`
`1.2.3 Clarifications
`
`Revision 1.0:
`
` o The former ModelTransformationTag (33920) conflicts with
` an internal Intergraph implementation and is being deprecated,
` in favor of a new tag (34264, registered to JPL).
`
` o The "Origin" keys have been renamed with "Natural" or "Nat"
` prefixes, to distinguish from "False" origins, and to have
` a closer match to EPSG/POSC terminology. All Revision 0.2
` names shall be recognized in a backward-compatible fashion.
`
` o The GeoTIFF/Cartlab web page addresses have been moved out
` of the author's ~ndr/ personal directory, and may now be found at:
`
` http://www-mipl.jpl.nasa.gov/cartlab/geotiff/geotiff.html
`
`Revision 0.2:
`
` o South Oriented Gauss Conformal is Transverse Mercator with South
`
`WhatsApp LLC
`Exhibit 1018
`Page 006
`
`

`

` pointing up, and so has been given a distinct code, rather than
` aliased to Transverse Mercator.
`
`Revision 0.1:
`
` o GeoTIFF-writers shall store the GeoKey entries in key-sorted order
` within the GeoKeyDirectoryTag. This is a change from preliminary
` discussions which permitted arbitrary order, and more closely follows
` the TIFF discipline.
`
` o The third value "ScaleZ" in ModelPixelScaleTag = (ScaleX, ScaleY,
` ScaleZ) shall by default be set to 0, not 1, as suggested in preliminary
` discussions. This is because most standard model spaces are
` 2-dimensional (flat), and therefore its vertical shape is
` independent of the pixel-value.
`
` o The code 32767 shall be used to imply "user-defined", rather than
` 16384. This avoids breaking up the reserved public GeoKey code space
` into two discontiguous ranges, 0-16383 and 16385-32767.
`
` o If a GeoKey is coded "undefined", then it is exactly that; no
` parameters should be provided (e.g. EllipsoidSemiMajorAxis, etc).
` To provide parameters for a non-coded attribute, use "user-defined".
`
`
`
`
`+----------------------------------+
`
`1.2.4 Organizational changes
`
`
`
`None.
`
`+----------------------------------+
`
`1.2.5 Changes in Requirements
`
` Changes to this preliminary revision:
`
` o Support for new transformation matrix tag (34264) required.
`
`
`+----------------------------------+
`
`1.2.6 Agenda for Future Development
`
`
`
`Revision 1.0, which is the first true "Baseline" revision, is proposed to support
`well-documented, public, relatively simple Projected Coordinate Systems (PCS),
`including most commonly used and supported in the international public domains
`today, together with their underlying map-projection systems. Following the
`critiques of the 0.x Revision phase, the 1.0 Revision spec is hereby released
`in Sept '95.
`
`WhatsApp LLC
`Exhibit 1018
`Page 007
`
`

`

`
`
`In the coming year, incremental 1.x augmentations to the "codes" list will
`be established, as well as discussions regarding the future "2.0" requirements.
`
`
`
`The Revision 2.0 phase is proposed to extend the capability of the GeoTIFF
`tagsets beyond PCS projections into more complex map projection geometries,
`including single-project, single-vendor, or proprietary cartographic
`solutions.
`
`
`
`TBD: Sounding Datums and related parameters for Digital Elevation Models (DEM's)
`and bathymetry -- Revision 2?
`
`
`
`+----------------------------------+
`
`1.3 Administration
`
`+----------------------------------+
`
`1.3.1 Information and Support:
`
`The most recent version of the GeoTIFF spec, EPSG/POSC tables, and source code
`is available via anonymous FTP at:
`
`
`
` ftp://mtritter.jpl.nasa.gov/pub/tiff/geotiff/
`
`and is mirrored at the USGS:
`
`
` ftp://ftpmcmc.cr.usgs.gov/release/geotiff/jpl_mirror/
`
` There are several subdirectories called spec/ tables/ and code/.
`
` The USGS also has an archive of prototype GeoTIFF images at:
`
` ftp://ftpmcmc.cr.usgs.gov/release/geotiff/images/
`
`
`Information and a hypertext version of the GeoTIFF spec is available via WWW
`at the following site:
`
`
` http://www-mipl.jpl.nasa.gov/cartlab/geotiff/geotiff.html
`
`
`A mailing-list is currently active to discuss the on-going development of this
`standard. To subscribe to this list, send e-mail to:
`
`
` GeoTIFF-request@tazboy.jpl.nasa.gov
`
`
`with no subject and the body of the message reading:
`
`
`
`WhatsApp LLC
`Exhibit 1018
`Page 008
`
`

`

` subscribe geotiff your-name-here
`
`
`To post inquiries directly to the list, send email to:
`
`
` geotiff@tazboy.jpl.nasa.gov
`
`
`
`
`+----------------------------------+
`
`1.3.2 Private Keys and Codes:
`
`As with TIFF, in GeoTIFF private "GeoKeys" and codes may be used, starting
`with 32768 and above. Unlike the TIFF spec, however, these private key-spaces
`will not be reserved, and are only to be used for private, internal purposes.
`
`+----------------------------------+
`
`1.3.3 Proposed Revisions to GeoTIFF
`
`Should a feature arise which is not currently supported, it should be formally
`proposed for addition to the GeoTIFF spec, through the official mailing-list.
`
`
`
`The current maintainer of the GeoTIFF specification is Niles Ritter, though
`this may change at a later time. Projection codes are maintained through EPSG/POSC,
`and a mechanism for change/additions will be established through the GeoTIFF
`mailing list.
`
`
`
`+--------------------------------------------------------------------+
`
`2 Baseline GeoTIFF
`
`+--------------------------------------------------------------------+
`
`
`
`+----------------------------------+
`
`2.1 Notation
`
`This spec follows the notation remarks of the TIFF 6.0 spec, regarding "is",
`"shall", "should", and "may"; the first two indicate mandatory requirements,
`"should" indicates a strong recommendation, while "may" indicates an option.
`
`+----------------------------------+
`
`2.2 GeoTIFF Design Considerations
`
`Every effort has been made to adhere to the philosophy of TIFF data abstraction.
`The GeoTIFF tags conform to a hierarchical data structure of tags and keys,
`similar to the tags which have been implemented in the "basic" and "extended"
`
`WhatsApp LLC
`Exhibit 1018
`Page 009
`
`

`

`TIFF tags already supported in TIFF Version 6 specification. The following
`are some points considered in the design of GeoTIFF:
`
` o
`
` Private binary structures, while permitted under the TIFF spec, are in general
`difficult to maintain, and are intrinsically platform- dependent. Whenever
`possible, information should be sorted into their intrinsic data-types, and
`placed into appropriately named tags. Also, implementors of TIFF readers would
`be more willing to honor a new tag specification if it does not require parsing
`novel binary structures.
`
` o
`
` Any Tag value which is to be used as a "keyword" switch or modifier should
`be a SHORT type, rather than an ASCII string. This avoids common mistakes of
`mis-spelling a keyword, as well as facilitating an implementation in code using
`the "switch/case" features of most languages. In general, scanning ASCII strings
`for keywords (CaseINSensitiVE?) is a hazardous (not to mention slower and more
`complex) operation.
`
` o
`
` True "Extensibility" strongly suggests that the Tags defined have a
`sufficiently abstract definition so that the same tag and its values may be
`used and interpreted in different ways as more complex information spaces are
`developed. For example, the old SubFileType tag (255) had to be obsoleted and
`replaced with a NewSubFileType tag, because images began appearing which could
`not fit into the narrowly defined classes for that Tag. Conversely, the
`YCbCrSubsampling Tag has taken on new meaning and importance as the JPEG
`compression standard for TIFF becomes finalized.
`
`+----------------------------------+
`
`2.3 GeoTIFF Software Requirements
`
`GeoTIFF requires support for all documented TIFF 6.0 tag data-types, and in
`particular requires the IEEE double-precision floating point "DOUBLE" type
`tag. Most of the parameters for georeferencing will not have sufficient accuracy
`with single-precision IEEE, nor with RATIONAL format storage. The only other
`alternative for storing high-precision values would be to encode as ASCII,
`but this does not conform to TIFF recommendations for data encoding.
`
`
`
`It is worth emphasizing here that the TIFF spec indicates that TIFF-compliant
`readers shall honor the 'byte-order' indicator, meaning that 4-byte integers
`from files created on opposite order machines will be swapped in software,
`and that 8-byte DOUBLE's will be 8-byte swapped.
`
` A
`
` GeoTIFF reader/writer, in addition to supporting the standard TIFF tag types,
`must also have an additional module which can parse the "Geokey" MetaTag
`information. A public-domain software package for performing this function
`is now available; see the "References" in section 5 for the location.
`
`
`
`
`
`WhatsApp LLC
`Exhibit 1018
`Page 010
`
`

`

`+----------------------------------+
`
`2.4 GeoTIFF File and "Key" Structure
`
`
`
`This section describes the abstract file-format and "GeoKey" data storage
`mechanism used in GeoTIFF. Uses of this mechanism for implementing georeferencing
`and geocoding is detailed in section 2.6 and section 2.7 .
`
` A
`
` GeoTIFF file is a TIFF 6.0 file, and inherits the file structure as described
`in the corresponding portion of the TIFF spec. All GeoTIFF specific information
`is encoded in several additional reserved TIFF tags, and contains no private
`Image File Directories (IFD's), binary structures or other private information
`invisible to standard TIFF readers.
`
`
`
`The number and type of parameters that would be required to describe most popular
`projection types would, if implemented as separate TIFF tags, likely require
`dozens or even hundred of tags, exhausting the limited resources of the TIFF
`tag-space. On the other hand, a private IFD, while providing thousands of free
`tags, is limited in that its tag-values are invisible to non-savvy TIFF readers
`(which don't know that the IFD_OFFSET tag value points to a private IFD).
`
`
`
`To avoid these problems, a GeoTIFF file stores projection parameters in a set
`of "Keys" which are virtually identical in function to a "Tag", but has one
`more level of abstraction above TIFF. Effectively, it is a sort of "Meta-Tag".
`A Key works with formatted tag-values of a TIFF file the way that a TIFF file
`deals with the raw bytes of a data file. Like a tag, a Key has an ID number
`ranging from 0 to 65535, but unlike TIFF tags, all key ID's are available for
`use in GeoTIFF parameter definitions.
`
`
`
`The Keys in GeoTIFF (also call "GeoKeys") are all referenced from the
`GeoKeyDirectoryTag, which defined as follows:
`
`
`GeoKeyDirectoryTag:
` Tag = 34735 (87AF.H)
` Type = SHORT (2-byte unsigned short)
` N = variable, >= 4
` Alias: ProjectionInfoTag, CoordSystemInfoTag
` Owner: SPOT Image, Inc.
`
`
`This tag may be used to store the GeoKey Directory, which defines and references
`the "GeoKeys", as described below.
`
`
`
`The tag is an array of unsigned SHORT values, which are primarily grouped into
`blocks of 4. The first 4 values are special, and contain GeoKey directory header
`information. The header values consist of the following information, in order:
`
`WhatsApp LLC
`Exhibit 1018
`Page 011
`
`

`

`
`
` Header={KeyDirectoryVersion, KeyRevision, MinorRevision, NumberOfKeys}
`
` where
`
` "KeyDirectoryVersion" indicates the current version of Key
` implementation, and will only change if this Tag's Key
` structure is changed. (Similar to the TIFFVersion (42)).
` The current DirectoryVersion number is 1. This value will
` most likely never change, and may be used to ensure that
` this is a valid Key-implementation.
`
` "KeyRevision" indicates what revision of Key-Sets are used.
`
` "MinorRevision" indicates what set of Key-codes are used. The
` complete revision number is denoted <KeyRevision>.<MinorRevision>
`
` "NumberOfKeys" indicates how many Keys are defined by the rest
` of this Tag.
`
`
`This header is immediately followed by a collection of <NumberOfKeys> KeyEntry
`sets, each of which is also 4-SHORTS long. Each KeyEntry is modeled on the
`"TIFFEntry" format of the TIFF directory header, and is of the form:
`
`
`
` KeyEntry = { KeyID, TIFFTagLocation, Count, Value_Offset }
`
` where
`
` "KeyID" gives the key-ID value of the Key (identical in function
` to TIFF tag ID, but completely independent of TIFF tag-space),
`
` "TIFFTagLocation" indicates which TIFF tag contains the value(s)
` of the Key: if TIFFTagLocation is 0, then the value is SHORT,
` and is contained in the "Value_Offset" entry. Otherwise, the type
` (format) of the value is implied by the TIFF-Type of the tag
` containing the value.
`
` "Count" indicates the number of values in this key.
`
` "Value_Offset" Value_Offset indicates the index-
` offset *into* the TagArray indicated by TIFFTagLocation, if
` it is nonzero. If TIFFTagLocation=0, then Value_Offset
` contains the actual (SHORT) value of the Key, and
` Count=1 is implied. Note that the offset is not a byte-offset,
` but rather an index based on the natural data type of the
` specified tag array.
`
`
`Following the KeyEntry definitions, the KeyDirectory tag may also contain
`additional values. For example, if a Key requires multiple SHORT values, they
`shall be placed at the end of this tag, and the KeyEntry will set
`
`WhatsApp LLC
`Exhibit 1018
`Page 012
`
`

`

`TIFFTagLocation=GeoKeyDirectoryTag, with the Value_Offset pointing to the
`location of the value(s).
`
`
`
`All key-values which are not of type SHORT are to be stored in one of the following
`two tags, based on their format:
`
`
`
`GeoDoubleParamsTag:
` Tag = 34736 (87BO.H)
` Type = DOUBLE (IEEE Double precision)
` N = variable
` Owner: SPOT Image, Inc.
`
`
`This tag is used to store all of the DOUBLE valued GeoKeys, referenced by the
`GeoKeyDirectoryTag. The meaning of any value of this double array is determined
`from the GeoKeyDirectoryTag reference pointing to it. FLOAT values should first
`be converted to DOUBLE and stored here.
`
`
`
`GeoAsciiParamsTag:
` Tag = 34737 (87B1.H)
` Type = ASCII
` Owner: SPOT Image, Inc.
` N = variable
`
`
`This tag is used to store all of the ASCII valued GeoKeys, referenced by the
`GeoKeyDirectoryTag. Since keys use offsets into tags, any special comments
`may be placed at the beginning of this tag. For the most part, the only keys
`that are ASCII valued are "Citation" keys, giving documentation and references
`for obscure projections, datums, etc.
`
`
`
`Note on ASCII Keys:
`
`
`Special handling is required for ASCII-valued keys. While it is true that TIFF
`6.0 permits multiple NULL-delimited strings within a single ASCII tag, the
`secondary strings might not appear in the output of naive "tiffdump" programs.
`For this reason, the null delimiter of each ASCII Key value shall be converted
`to a "|" (pipe) character before being installed back into the ASCII holding
`tag, so that a dump of the tag will look like this.
`
`
`
` AsciiTag="first_value|second_value|etc...last_value|"
`
` A
`
` baseline GeoTIFF-reader must check for and convert the final "|" pipe character
`of a key back into a NULL before returning it to the client software.
`
`
`
`GeoKey Sort Order:
`
`
`WhatsApp LLC
`Exhibit 1018
`Page 013
`
`

`

`In the TIFF spec it is required that TIFF tags be written out to the file in
`tag-ID sorted order. This is done to avoid forcing software to perform N-squared
`sort operations when reading and writing tags.
`
`
`
`To follow the TIFF philosophy, GeoTIFF-writers shall store the GeoKey entries
`in key-sorted order within the CoordSystemInfoTag.
`
`
`
`Example:
`
` GeoKeyDirectoryTag=( 1, 1, 2, 6,
` 1024, 0, 1, 2,
` 1026, 34737,12, 0,
` 2048, 0, 1, 32767,
` 2049, 34737,14, 12,
` 2050, 0, 1, 6,
` 2051, 34736, 1, 0 )
` GeoDoubleParamsTag(34736)=(1.5)
` GeoAsciiParamsTag(34737)=("Custom File|My Geographic|")
`
`
`The first line indicates that this is a Version 1 GeoTIFF GeoKey directory,
`the keys are Rev. 1.2, and there are 6 Keys defined in this tag.
`
`The next line indicates that the first Key (ID=1024 = GTModelTypeGeoKey) has
`the value 2 (Geographic), explicitly placed in the entry list (since
`TIFFTagLocation=0). The next line indicates that the Key 1026 (the
`GTCitationGeoKey) is listed in the GeoAsciiParamsTag (34737) array, starting
`at offset 0 (the first in array), and running for 12 bytes and so has the value
`"Custom File" (the "|" is converted to a null delimiter at the end). Going
`further down the list, the Key 2051 (GeogLinearUnitSizeGeoKey) is located in
`the GeoDoubleParamsTag (34736), at offset 0 and has the value 1.5; the value
`of key 2049 (GeogCitationGeoKey) is "My Geographic".
`
`
`
`The TIFF layer handles all the problems of data structure, platform independence,
`format types, etc, by specifying byte-offsets, byte-order format and count,
`while the Key describes its key values at the TIFF level by specifying Tag
`number, array-index, and count. Since all TIFF information occurs in TIFF arrays
`of some sort, we have a robust method for storing anything in a Key that would
`occur in a Tag.
`
`
`
`With this Key-value approach, there are 65536 Keys which have all the flexibility
`of TIFF tag, with the added advantage that a TIFF dump will provide all the
`information that exists in the GeoTIFF implementation.
`
`
`
`This GeoKey mechanism will be used extensively in section 2.7, where the numerous
`parameters for defining Coordinate Systems and their underlying projections
`are defined.
`
`+----------------------------------+
`
`WhatsApp LLC
`Exhibit 1018
`Page 014
`
`

`

`2.5 Coordinate Systems in GeoTIFF
`
`Geotiff has been designed so that standard map coordinate system definitions
`can be readily stored in a single registered TIFF tag. It has also been designed
`to allow the description of coordinate system definitions which are non-standard,
`and for the description of transformations between coordinate systems, through
`the use of three or four additional TIFF tags.
`
`However, in order for the information to be correctly exchanged between various
`clients and providers of GeoTIFF, it is important to establish a common system
`for describing map projections.
`
`In the TIFF/GeoTIFF framework, there are essentially three different spaces
`upon which coordinate systems may be defined. The spaces are:
`
`
`
` 1) The raster space (Image space) R, used to reference the pixel values
` in an image,
` 2) The Device space D, and
` 3) The Model space, M, used to reference points on the earth.
`
`
`In the sections that follow we shall discuss the relevance and use of each
`of these spaces, and their corresponding coordinate systems, from the standpoint
`of GeoTIFF.
`
`
`
`+----------------------------------+
`
`2.5.1 Device Space and GeoTIFF
`
`
`
`In standard TIFF 6.0 there are tags which relate raster space R with device
`space D, such as monitor, scanner or printer. The list of such tags consists
`of the following:
`
`
`
` ResolutionUnit (296)
` XResolution (282)
` YResolution (283)
` Orientation (274)
` XPosition (286)
` YPosition (287)
`
`
`
`
`In Geotiff, provision is made to identify earth-referenced coordinate systems
`(model space M) and to relate M space with R space. This provision is independent
`of and can co-exist with the relationship between raster and device spaces.
`To emphasize the distinction, this spec shall not refer to "X" and "Y" raster
`coordinates, but rather to raster space "J" (row) and "I" (column) coordinate
`variables instead, as defined in section 2.5.2.2.
`
`
`
`+----------------------------------+
`
`WhatsApp LLC
`Exhibit 1018
`Page 015
`
`

`

`2.5.2 Raster Coordinate Systems
`
`+----------------------------------+
`
`2.5.2.1 Raster Data
`
`
`
`Raster data consists of spatially coherent, digitally stored numerical data,
`collected from sensors, scanners, or in other ways numerically derived. The
`manner in which this storage is implemented in a TIFF file is described in
`the standard TIFF specification.
`
`
`
`Raster data values, as read in from a file, are organized by software into
`two dimensional arrays, the indices of the arrays being used as coordinates.
`There may also be additional indices for multispectral data, but these indices
`do not refer to spatial coordinates but spectral, and so of not of concern
`here.
`
`
`
`Many different types of raster data may be georeferenced, and there may be
`subtle ways in which the nature of the data itself influences how the coordinate
`system (Raster Space) is defined for raster data. For example, pixel data derived
`from imaging devices and sensors represent aggregate values collected over
`a small, finite, geographic area, and so it is natural to define coordinate
`systems in which the pixel value is thought of as filling an area. On the other
`hand, digital elevations models may consist of discrete "postings", which may
`best be considered as point measurements at the vertices of a grid, and not
`in the interior of a cell.
`
`2.5.2.2 Raster Space
`
`
`
`The choice of origin for raster space is not entirely arbitrary, and depends
`upon the nature of the data collected. Raster space coordinates shall be referred
`to by their pixel types, i.e., as "PixelIsArea"