Geospatial Integrity of Geoscience Software (GIGS) User Guide

REPORT NOVEMBER
430-2 2021
Geospatial Integrity of Geoscience

Software (GIGS) User Guide
Acknowledgements
This report was authored by the IOGP GIGS Task Force in collaboration with
the IOGP Geodesy Subcommittee, Geophysical Operations Subcommittee, and
P7 Task Force, all under the auspices of the IOGP Geomatics Committee. The
authors wish to thank all involved for their contributions.
Front cover photography used with permission courtesy of

©Filograph/iStockphoto and ©bluebay2014/iStockphoto
About
GIGS is an open-source digital testing framework designed to evaluate the
capability of software in establishing and maintaining the integrity of geospatial
data. It is primarily aimed at geoscience applications, but elements can be
readily applied to any software that handles spatial data. The testing framework
comprises a series of qualitative evaluations that assess software functionality
and configuration, coupled with data-driven tests that quantify the accuracy and
robustness of geodetic engines and libraries, in executing coordinate operations.
The test package is supported by two documents, a general Guidance Note on
the theory of geospatial integrity and GIGS testing (IOGP Report 430-1) and a
comprehensive User Guide providing technical procedures for executing the GIGS
tests (IOGP Report 430-2, this document).
Feedback
IOGP welcomes feedback on our reports: publications@iogp.org
Disclaimer
Whilst every effort has been made to ensure the accuracy of the information contained in this publication, neither IOGP nor any of its Members past present
or future warrants its accuracy or will, regardless of its or their negligence, assume liability for any foreseeable or unforeseeable use made thereof, which
liability is hereby excluded. Consequently, such use is at the recipient’s own risk on the basis that any use by the recipient constitutes agreement to the terms
of this disclaimer. The recipient is obliged to inform any subsequent recipient of such terms.
Please note that this publication is provided for informational purposes and adoption of any of its recommendations is at the discretion of the user. Except
as explicitly stated otherwise, this publication must not be considered as a substitute for government policies or decisions or reference to the relevant
legislation relating to information contained in it.
Where the publication contains a statement that it is to be used as an industry standard, IOGP and its Members past, present, and future expressly disclaim all
liability in respect of all claims, losses or damages arising from the use or application of the information contained in this publication in any industrial application.
Any reference to third party names is for appropriate acknowledgement of their ownership and does not constitute a sponsorship or endorsement.
Copyright notice
The contents of these pages are © International Association of Oil & Gas Producers. Permission is given to reproduce this report in whole or in part provided
(i) that the copyright of IOGP and (ii) the sources are acknowledged. All other rights are reserved. Any other use requires the prior written permission of IOGP.
These Terms and Conditions shall be governed by and construed in accordance with the laws of England and Wales. Disputes arising here from shall be
exclusively subject to the jurisdiction of the courts of England and Wales.
REPORT NOVEMBER
430-2 2021
Geospatial Integrity of Geoscience

Software (GIGS) User Guide
Revision history
VERSION DATE AMENDMENTS
2.0 November 2021 Major revision
1.0 September 2011 First release

Geospatial Integrity of Geoscience Software (GIGS) User Guide
Contents
Introduction 6
Background 6
Purpose 7
Scope 8
1. GIGS Test Series User Guide 9

1.1 Overview 9
1.2 Scoring 11
1.2.1 Elementary Level 12
1.3 GIGS Test Series Process 13
1.3.1 Populating Test Series Checklists 13
1.4 Flowchart and Test Correlations 14
1.5 Test Series General Guidelines 15
1.5.1 Conditionals 15
1.5.2 0000 Coordinate Reference Systems 15
1.5.3 1000 General User Documentation 15
1.5.4 2100 Predefined Geodetic Parameter Library 16
1.5.5 2200 Predefined Geodetic Data Objects 16
1.5.6 3100 User-defined Geodetic Parameter Library 16
1.5.7 3200 User-defined Geodetic Data Objects 16
1.5.8 4000 User Interface 16
1.5.9 5100 Data Operations (Conversions) 16
1.5.10 5200 Data Operations (Coordinate Transformations) 17
1.5.11 5300 Data Operations (2D Seismic Position Data) 17
1.5.12 5400 Data Operations (3D Seismic Position Data) 17
1.5.13 5500 Data Operations (Surface and Wellbore Deviation Data) 18
1.5.14 6000 Audit Trail 19
1.5.15 7000 Deprecation 19
1.5.16 Error Trapping 19
2. GIGS Test Dataset User Guide 20

2.1 Overview 20
2.2 Test Dataset Access 22
2.3 Test Dataset Formats 22
2.4 Test Dataset Construct 23
2.4.1 ASCII File Header Definition 24
2.4.2 CAUTION: Reading Test Dataset in Excel 26
4
2.5 Test Dataset Numeric Precision and Representation 26

2.5.1 Precision of Geodetic Parameters 26
2.5.2 Precision of GIGS Test Dataset Coordinates 27
2.5.3 Precision of Legacy P-format Data 27
2.6 Test Dataset Naming Convention 28
2.6.1 Test Procedure Naming/Numbering 28
2.6.2 Test Dataset Geodetic Data Object Naming/Numbering 28
2.7 User-Defined Geodetic Data Object Definitions 29
2.8 Predefined Geodetic Data Object Applicability 30
2.9 Test Procedure Project Naming 31
2.10 Round Trip Calculations 31
2.11 Test Procedures Specific Guidelines 32
2.11.1 2200 Predefined Geodetic Data Object Test Procedures 32
2.11.2 3200 User-defined Geodetic Data Object Test Procedures 37
2.11.3 5100 Conversion Test Procedures 43
2.11.4 5200 Coordinate Transformation Test Procedures 49
2.11.5 5300 2D Seismic Test Procedures 59
2.11.6 5400 3D Seismic Test Procedures 67
2.11.7 5500 Wells Test Procedures 71
2.11.8 7000 Deprecation Test Procedures 84
Appendix A: GIGS Test Dataset Index and Maps 85
Appendix B: Non-EPSG Nomenclature Guide 103
Appendix C: GIGS to EPSG Code/Name Relationship 104
Appendix D: GIGS Project Definitions 112
Appendix E: GIGS Supported Coordinate Operation Methods 119
Appendix F: Test Dataset Excel Files Guide 120
5
Introduction
Background
The energy industry makes extensive use of geoscience software that handles spatial data, in
support of safely and efficiently exploring for, producing, and storing sources of energy. The number
of applications that handle spatial data has grown exponentially in the past decade as widespread
digitalization has resulted in a significant increase in the volume, variety and veracity of spatial data
being generated and exchanged.
A diverse range of geophysical, wellbore and cultural data are brought into such applications,
where they are visualised, processed and exported to other software, shared with other users, and
interpreted to form the basis of major operational and business decisions. Such datasets, referred
to hereafter as ‘geoscience data’, are referenced to location in the real world by means of geospatial
data. Typically, the geospatial data are in the form of coordinates, together with the coordinate
reference system being used and other essential geospatial metadata.
There are thousands of different software packages available for use in the energy industry, as well
as dozens of different geodetic engines and libraries. It has been estimated that a typical project will
involve over a hundred transactions where data is moved or manipulated. The users of these applications
require them to be interoperable, exchanging data as needed and without introducing errors.
If all the geospatial data is complete, consistent, correct, and verifiable, and remains so during any
manipulations, then geospatial integrity has been maintained. If geospatial integrity and data quality are
compromised, the validity of any decisions made with the geoscience datasets may be compromised.
Failure of the geospatial integrity of geoscience data sometimes can be attributed to a lack of
understanding or knowledge of the user managing the data, but in other cases it can be traced to
deficiencies or failings in the implementation, configuration or operation of the software.
In 2009 a joint industry project (JIP) sponsored by IOGP was formed in response to significant
concern and documented evidence of safety-critical geospatial data integrity failures in geoscience
applications. In 2011 the first version of the Geospatial Integrity of Geoscience Software (GIGS)
framework was released comprising technical recommendations, a series of software evaluation
tests and a supporting set of standard test data. The entire testing package was subsequently
revised, updated, and re-released as open source in 2021, with enhancements intended to make the
GIGS testing process simpler, more flexible and easier to integrate programmatically.
The GIGS evaluation process is grouped into numbered themes1, referred to as Series:
• 0000 – Coordinate Reference Systems
• 1000 – General User Documentation
• 2000 – Predefined Geodetic Entities
– 2100 - Predefined Geodetic Parameter Library
– 2200 - Predefined Geodetic Data Objects
1 Note that previous versions of GIGS had a standalone series, 8000, for Error Trapping. In recent released these tests have been
embedded in the respective series to which they refer.
6
• 3000 – User-defined Geodetic Entities

– 3100 - User-defined Geodetic Parameter Library
– 3200 - User-defined Geodetic Data Objects
• 4000 – User Interface
• 5000 – Data Operations
– 5100 – Conversions
– 5200 – Coordinate Transformations
– 5300 – 2D Seismic Position Data
– 5400 – 3D Seismic Position Data
– 5500 – Surface and Wellbore Deviation Data
• 6000 – Audit Trail
• 7000 – Deprecation
The evaluation process is guided by structured checklists which describe what should be
tested within the software (see Section 2 of this document for more detail). For many tests, Test
Procedures are required to be undertaken using data from the GIGS Test Dataset (see Section 2 of
this document for more detail).
The GIGS Test Dataset consists of a series of files provided in a variety of formats, including industry
data exchange formats and ASCII. Each file is designed for a specific GIGS test. The Test Data is in
one of three categories:
• Geodetic data definitions, used for Series 2000, Series 3000 and 7000 tests.
• Coordinate operation data, used for Series 5100 and 5200 tests.
• Seismic and wellbore data, used for Series 5300, 5400 and 5500 tests.
There are no Test Data files for the Coordinate Reference Systems (Series 0000) or Documentation
(Series 1000). Some User Interface (Series 4000) and Audit Trail (Series 6000) tests utilise Test Data
used in the Series 5000 tests. At this time, boundary and cultural data have not been developed for
inclusion in the GIGS Test Dataset.
Purpose
This document specifically provides technical guidance on executing a GIGS evaluation with detailed
information on undertaking the GIGS Test Series and utilizing the GIGS Test Dataset.
Evaluators undertaking GIGS Test Procedures using the GIGS Test Dataset should refer to Section
2.11, Test Procedures Specific Guidelines, of this document for individual procedural guidance.
The purpose of this User Guide is to provide software developers and users with recommended
industry best practice to evaluate the capabilities of a software package with respect to establishing
and maintaining geospatial data integrity. The User Guide aims to support the identification of
geospatial integrity failures, via execution of the GIGS process, thereby reducing or eliminating
incorrect data and results, inconsistent understanding, and misleading information in the user
community.
7
To fulfil this purpose, GIGS comprises several elements, which can be accessed via the GIGS main
site (https://gigs.iogp.org):
• GIGS Guidance Note (IOGP Report 430-1), describing the GIGS process
• GIGS User Guide (IOGP Report 430-2, this document), providing specific procedural information
on the GIGS Test Series and GIGS Test Dataset2
• GIGS Test Series package3, containing the framework of tests in checklist structure to
undertake the evaluation, delivered by online platform or spreadsheet format
• GIGS Test Dataset package4, comprising a compiled set of data files used for testing
algorithms and data exchange capabilities
• GIGS Media Pack, made up of presentation material and engagement content
Scope
This User Guide is intended for wide use by anyone involved with geospatial data, with a focus on the
energy industry. It specifically addresses the developers, vendors, and users of geoscience software.
In this User Guide the term ‘software’ includes any executable code and underlying database (either
cloud based or ‘on-premise’) used in spatial data manipulation, including applications, processing
packages and their user interfaces. It also includes software components, such as geodetic
computation engines, extensions and libraries.
This User Guide applies especially to the software functions that address spatial data import,
creation, manipulation, merging, processing, coordinate operations (including transformations and
conversions), visualization, mapping, and export. It is, however, also relevant for existing product
maintenance and to new product design, testing and production support.
It does not address raw data processing methods (e.g., wellbore curve calculation methods)
though the general principles are still valid; nor does it address the quality of the geoscience
datasets themselves. The focus of this User Guide is on the preservation of reference integrity and
maintaining the geospatial quality inherent in the original data set.
This document’s scope is split into two main sections, with Section 1 pertaining to guidelines
on the GIGS Test Series and Section 2 providing guidelines on the GIGS Test Dataset. Ideally, the
User Guide content should be taken in totality, but specific sections can also be used for quick
reference. It is recommended that the scope and content of IOGP Report 430-1 – Geospatial Integrity
of Geoscience Software (GIGS) – Guidance Note (companion to this document) is understood before
considering this document.
2 Previously GIGS comprised 3 Guidance Notes (430-1, 430-2 and 430-3), however due to the creation of the online platform,
430-2 and 430-3 have been consolidated and merged.
3 Previously this was released as “430-2a”, but due to the now web-based delivery the numbering has been dropped
4 Previously this was released as “430-3a”, but due to the now web-based delivery the numbering has been dropped
8
1. GIGS Test Series User Guide
1.1 Overview
The GIGS Test Series is grouped into themes that pertain to different aspects of software
functionality and capability, as defined below. IOGP Guidance Note 430-1 covers the
background of the themes in more detail.
GIGS Test
GIGS Test Series Name This series examines
Series #
Coordinate Reference The association of geodetic metadata to coordinates, and general

0000 Systems aspects of geodetic integrity of the application
Overview documentation, release notes and knowledge bases relating

1000 General User Documentation
to the geospatial aspect of the application
Predefined Geodetic The configuration and functionality of the reference library within the
2100 Parameter Library geodetic engine of the application
Predefined Geodetic The range and accuracy of the reference geodetic data objects
2200 Data Objects supported within the geodetic engine of the application
User-defined Geodetic The configuration and functionality of the user-defined library within
3100 Parameter Library the geodetic engine of the application
User-defined Geodetic The range and accuracy of the user-defined geodetic data objects
3200 Data Objects supported within the geodetic engine of the application
The nomenclature, user-oriented nature and accuracy of information of

4000 User Interface
the UI for geospatial aspects of the application
Data Operations The range and accuracy of coordinate operations, specifically map
5100 (Conversions) projections, supported within the application
Data Operations The range and accuracy of coordinate operations, specifically

5200 (Coordinate Transformations) coordinate transformations, supported within the application
Data Operations The range and accuracy of coordinate operations and data manipulations
5300 (2D Seismic Position Data) pertaining to 2D seismic position data supported within the application
Data Operations The range and accuracy of coordinate operations and data manipulations
5400 (3D Seismic Position Data) pertaining to 3D seismic position data supported within the application
Data Operations (Surface and The range and accuracy of coordinate operations and data manipulations
5500 Wellbore Deviation Data) pertaining to wellbore data supported within the application
The audit trail for coordinate and data operations carried out within the
6000 Audit Trail
geodetic engine of the application
The deprecation of algorithms and files within the geodetic engine of

7000 Deprecation
the application
Figure 1: GIGS Test Series, at time of publication
9
Within each Test Series several tests are presented - typically between 10 and 20 individual
tests per series. These tests refer to a specific element of functionality or capability being
evaluated.
Associated with every test are several response criteria that correspond with a GIGS Level
(see Section 1.2). For each relevant test, the Evaluator should select the criterion that
describes the conditions most closely aligned with the application being tested.
In some cases, a test may be associated with a Test Procedure utilising the Test Dataset
(see Section 2.11).
Tests are numbered sequentially and, where relevant, sub-numbered if multiple tests
pertain to one particular piece of functionality (i.e., 1.1, 1.2, 1.3).
Each test has a “banner” indicating the test subject as well as, where relevant, a tooltip
containing notes, applicable to that Test Series. The tooltip help can be opened by the
“i” icon in the online platform or by opening the cell comment pop-up in the offline
spreadsheet.
The GIGS Test Series is provided in both online and offline formats, as an online platform
and spreadsheet respectively. The online platform offers enhanced functionality for storing
and calculating results and managing evaluation details, however the Test Series content
is identical in both the online and offline versions. Hence, the same result is derived using
either system. Nonetheless, it is strongly recommended that the online platform is used
where possible, and this document refers primarily to operation of the online platform.
Figure 2: GIGS ‘offline’ spreadsheet term definitions
10
Figure 3: GIGS ‘online’ web portal term definitions
1.2 Scoring
The outcome of a GIGS evaluation is the identification of functionality and capability within
an application that either enables or compromises geospatial data integrity. To facilitate
systematic evaluation and comparison, the GIGS Test Series results are presented as GIGS
Scores (alongside contextual evidence and findings). The GIGS Score comprises a GIGS
Level and a percentage score within each level.
See 430-1 for a full description of scoring and associated definitions of geospatial integrity,
however the basic principles are outlined below.
The GIGS Levels (and associated colour indicators) are:
Table 1: GIGS Level definitions
No GIGS Score directly compromises geospatial integrity

no capability to perform coordinate operations, but maintains
Elementary
geospatial integrity
limited capability to perform coordinate operations, establishes and
Basic
maintains geospatial integrity
extensive capability to perform coordinate operations and establishes
Intermediate
and maintains geospatial integrity to a fully satisfactory degree
complete capability to perform coordinate operations with additional
Advanced
features to reduce possibility of compromising geospatial integrity
11
Each criterion in the Test Series is associated with a particular GIGS Level, depending on
how it aligns with the definitions of geospatial data integrity. For example, it can be said
that a certain software function is deemed to be of “Intermediate level” (see IOGP Report
430-1 for further detail).
For the GIGS Level, a percentage score is assigned, to give further indication of the
software functionality, indicating how the application performs for that level. The GIGS
Score assigned to each Series is the lowest level that has been identified in all the tests. A
GIGS Score is assigned for each Series rather than calculating a single total score for the
entire application, however a sum of all scores can be derived if required.
In the online platform, GIGS Scores can be found in the Application Details for each Test
Series. In the offline spreadsheet these can be found at the footer of each Test Series
tab, and in the Dashboard Tab (once the Series is marked as “complete”). The scoring
calculation algorithm is embedded in source code of the online and offline Test Series; and
can be made available on request.
1.2.1 Elementary Level

Elementary level tests do not follow the process described above, as they apply to software
without coordinate operation capability, which therefore cannot be assessed against the
geospatial data integrity definitions associated with Basic, Intermediate and Advanced
capability levels.
Nonetheless, geospatial integrity is still relevant for software that has no functionality to
perform coordinate operations. For example, an application may not have a geodetic engine
in order to perform transformations or conversions, but it may still include functionality to
load, visualize, manipulate and export geospatial data in different CRSs referenced to an
internal/external library of geodetic parameters, and therefore would need to be assessed.
Therefore, provision is made in the GIGS framework for such software to be evaluated using
a different set of criteria than those for “standard” applications.
Such software can only attain the Elementary level of geospatial integrity (or ‘No GIGS
Score’). Evaluators assessing this type of software should ensure that the Condition Test A
(see Section 1.5.1) is set to “No”. Thereafter, all Basic, Intermediate and Advanced tests will
be disabled.
In the offline spreadsheet, if Elementary tests are disabled then they are greyed out and should
be ignored (note that the text may still be visible but should not be considered in any tests).
12
1.3 GIGS Test Series Process

It is recommended that Evaluators should use the online platform version of the GIGS Test
Series due to its numerous advantages in tracking and recording evaluation progress, as
well as enhanced functionality for report generation and user management. The following
guidelines focus mainly on the online platform, although the same principles apply to
the offline spreadsheet version. Note that this section does not advise on the strategy
of planning and executing a GIGS review - see IOGP Report 430-1 for further detail. It is
assumed at this stage that all software and hardware elements/licenses/source code are in
place and suitable resources have been provisioned.
The following workflow is recommended for completing the Test Series:

1) Collate application details including organization, version number, testing date.
2) Assign evaluation personnel including product administrator and Evaluators.
3) Complete application Conditional tests to identify relevant tests.
4) Identify application geographic area of use/applicability to further refine relevant test
elements.
5) Complete relevant Test Series in sequential order, beginning at 0000, alongside
undertaking GIGS Test Procedures (see Section 2.11).
6) Collate and record supporting evidence.
7) Generate GIGS scores and identify any tests for immediate re-evaluation.
8) Generate summary report.
9) Write full report and issue conclusions/recommendations.
1.3.1 Populating Test Series Checklists

The general principle in populating the Test Series checklists is that the Evaluator should
select the test criterion that corresponds most closely with the application being tested,
considering the subject of the test.
Criteria for each test are structured to allow for methodical and logical assessment of the
responses. Generally, the criteria are structured as:
{data/object} is/is not supported and/or {application} does/does not do {function}
The assignment of a criterion to a particular GIGS Level corresponds with the associated
definitions of geospatial integrity for that particular subject and classification (see Section
1.2), and further indicates how the functionality has been implemented:
• No GIGS Score – functionality is supported but implemented in a way that causes
failure of geospatial data integrity.
• Elementary – functionality supported and accurate but does not correspond with a
coordinate operation.
• Basic – functionality is part-supported or not supported.
• Intermediate – functionality is supported and is accurate.
• Advanced – functionality is supported and is accurate, with additional functionality.
13
Note that every test may not have the full range of criteria levels (Basic, Intermediate,
Advanced), for example some tests may refer only to Intermediate or Advanced
functionality. However, all tests will have the possibility of No GIGS Score, to account for any
identified failures in geospatial integrity.
In the offline spreadsheet, criteria selection is made by tick box. In the online platform
selection is made by selecting the criterion from a drop-down menu. Criteria are colour-
coded based on the respective level colour, as outlined in Section 1.2.
Only one criterion may be selected for each test. If there is not a criterion that directly matches
the software functionality, then the closest should be selected and a comment made.
An exception to the above is the 2200 (Predefined Geodetic Data Objects) and 3200 (User-
Defined Geodetic Data Objects) Test Series (see Section 1.5.5 and 1.5.7). These tests require
the completion of matrix style criteria, in which multiple Boolean Yes/No selections should
be made per test.
Compliance with lower-level classification levels is required in any of the levels. For
example, if an Intermediate criterion is appropriate for a particular test, then fulfilment of
the requirements for the Basic level is implied. If that is not the case, the Evaluator should
qualify the response in the comments.
It is highly recommended that supporting comments and evidence are attached to

each test, relating to the subject matter being evaluated. This could be clarifying notes,
screenshots or even calculation results. In the online platform there is a “WSIWYG” editor
embedded alongside each test where rich media or text can be entered and stored. In the
offline spreadsheet a comment field is provided alongside each row.
Depending on the response to the Conditional tests (see Section 1.5.1), a number of Test
Series may be disabled as they will not pertain to the particular application being tested. For
example, if the Evaluator responds “No” to the Conditional test “Does the application support
surface and wellbore deviation data?”, then Test Series 5500 will be disabled. For Elementary
applications, all Basic, Intermediate and Advanced tests will be disabled. In the online
platform any disabled tests will not be visible to the user, however in the offline spreadsheet
a grey hash will be applied to disabled tests and an error presented if one is selected.
All applicable tests should be completed in order to mark the evaluation as complete and to
generate the final GIGS score for each test. Error messages will be displayed alongside any
tests that have been missed or answered in error.
1.4 Flowchart and Test Correlations

A small proportion of tests are highly correlated with other tests either in the same series,
or sometimes in other series. In the online portal these correlations are referred to in the
tooltip, and in the offline spreadsheet they are indicated by comment callouts on the test
number cell. The correlation indicators denote which tests are highly correlated, and it is
strongly recommended that the selected criteria for all correlated tests should be assessed
in unison to ensure agreement between respective tests.
Additionally, a comprehensive flowchart of the Test Series architecture is provided as an

offline graphML file or via the Flowchart page on the online portal.
14
1.5 Test Series General Guidelines

The following sections contain general guidelines and key points to note for each Test Series.
1.5.1 Conditionals
The Conditional Tests are the first element of the Test Series addressed. In the online portal
they are presented to the Evaluator once an application to be evaluated has been set up. In
the offline spreadsheet these tests are contained within the Conditionals tab.
The Conditionals determine which tests are to be undertaken for a particular evaluation.
Depending on the response, certain Test Series or individual tests may be disabled and
removed from the evaluation scoring calculations.
The primary, and first Conditional to address is whether the application has “capability to
perform coordinate operations?”. If “No” is selected then the application is deemed to be
Elementary in nature and all Basic/Intermediate/Advanced tests are disabled, along with
certain entire Test Series.
The other Conditionals address specific aspects of functionality, such as whether the
application supports seismic data or whether it has a user interface.
Adjacent to each Conditional test is a message displaying which Test Series are enabled/
disabled according to how the Conditionals are answered.
The Conditionals selection can be changed at any point in an evaluation if application

functionality changes; however any entries made to tests that are subsequently disabled
will be locked. They can be unlocked by reversing the Conditional response.
It is important to answer the Conditional tests as accurately as possible early in the testing
process, to ensure a relevant and complete consideration of applicable tests is made.
1.5.2 0000 Coordinate Reference Systems

This Test Series addresses general aspects of geospatial integrity, specifically behaviour
of the software with respect to the association of a valid CRS to coordinates. The spatial
data concerned primarily includes seismic and wellbore data but could be applied to any
geospatial data type.
In some tests the terms ‘unspecified CRSs’, ‘<null CRS>’ or ‘invalid CRSs’ may be
presented. The first two terms refer to situations where no CRS information is associated
with a spatial data file, and the latter to instances where incomplete or (partially) incorrect
information is provided on the CRS.
1.5.3 1000 General User Documentation

This Test Series refers to the consistency and coverage of the overview documentation and
release notes of the software that are related to geospatial/geodetic functionality. Tests
referring to specific subjects are embedded in the respective Test Series relating to that
subject.
15
1.5.4 2100 Predefined Geodetic Parameter Library

This Test Series evaluates the functionality and configuration of the geodetic parameter
library that comes with the software. Tests concern the source and reference of the library,
how it is accessed, and version controlled.
1.5.5 2200 Predefined Geodetic Data Objects

This Test Series assesses the geodetic data objects within the predefined geodetic
parameter library, in respect of completeness, correctness, and consistency. The structure
of these tests is such that the criteria responses are presented in matrix form, indicating
that for each test a response for every geodetic data object should be selected.
Test Procedures are required as part of this Test Series, referencing the 22XX GIGS Test
Dataset files (see Section 2.11.1)
1.5.6 3100 User-defined Geodetic Parameter Library

This Test Series evaluates the functionality and configuration of the user-defined geodetic
parameter library that allows users to define and utilise entities that are not part of the
predefined library. Tests concern the source and reference of the library and how it is
created, updated, managed and accessed.
1.5.7 3200 User-defined Geodetic Data Objects

This Test Series assesses the geodetic data objects within the user-defined geodetic
parameter library, in respect of completeness, correctness and consistency. The structure
of these tests is such that the criteria responses are presented in matrix form, indicating
that for each test a response for every geodetic data object should be selected.
1.5.8 4000 User Interface

This Test Series contains several general tests regarding the user interface, including the
display and representation of geospatial information and geodetic parameters. Most other
User Interface aspects are embedded in the other Test Series, as they specifically apply to
the subject matter of that Test Series.
1.5.9 5100 Data Operations (Conversions)

This Test Series deals with software capability for coordinate operations, specifically
conversions, including support and implementation of a range of different map projection
algorithms/formulae, as well as how conversions are integrated in data workflows.
Conversions of particular interest to the energy industry are included in the test series,
however if additional conversions are supported in the application, then it is up to the
Evaluator to define and execute additional tests and Test Data (can potentially be sourced
16
from other geodetic testing packages). Evaluator discretion should be used as to how many
additional tests are implemented.
Dataset files (see Section 2.11.3).
1.5.10 5200 Data Operations (Coordinate Transformations)

This Test Series deals with software capability for coordinate operations, specifically,
coordinate transformations, including support and implementation of a range of different
transformation methods, as well as how transformations are integrated in data workflows.
Coordinate transformation methods of particular interest to the energy industry are

included in the Test Series, however if additional transformations are supported in the
application, then it is up to the Evaluator to define and execute additional Test Data and
tests (which potentially can be sourced from other geodetic testing packages). Evaluator
discretion should be used as to how many additional tests are implemented.
1.5.11 5300 Data Operations (2D Seismic Position Data)

This Test Series assesses how software handles 2D seismic position data in terms of
project configurations and coordinate operations on data import, transfer, and export.
Due to the length of the tests in this series, the tests are grouped under subject-related
headings, but this should not change the order of test completion.
The series is intended to be undertaken utilising industry standard data exchange formats
(P1/XX, SEG-Y), however if none of these formats is supported, then the ASCII equivalent
can be used. If multiple formats are supported in the software, then each test should be
repeated for all format types and any discrepancies in behaviour between the different
formats should be noted in the test comments.
Note that there are several Conditional tests (see Section 1.5.1) that determine which
specific 2D seismic position data formats require tests.
1.5.12 5400 Data Operations (3D Seismic Position Data)

This Test Series assesses how software handles 3D seismic position data in terms of
project configurations and coordinate operations on data import, transfer and export.
Due to the length of the tests in this series, the tests are grouped under subject-related
headings, but this should not change the order of test completion.
17
(P1/XX, P6/XX, SEG-Y), however if none of these formats is supported then the ASCII
equivalent can be used. If multiple formats are supported in the software, then each test
should be repeated for all format types and any discrepancies in behaviour between the
different formats should be noted in the test comments.
specific 3D seismic position data formats require tests.
1.5.13 5500 Data Operations (Surface and Wellbore Deviation Data)

This Test Series assesses how software handles wellbore deviation data in terms of project
configurations and coordinate operations on data import, transfer and export. Due to the
length of the tests in this series, the tests are grouped under subject-related headings, but
this should not change the order of test completion.
(P7/XX), however if none of these formats is supported then the ASCII equivalent can be
used. If multiple formats are supported in the software, then each test should be repeated
for all format types and any discrepancies in behaviour between the different formats
should be noted in the test comments.
formats require tests.
In this Test Series a distinction is made between a well path and a wellbore survey. Various
alternative terms are in use in the industry, but no standard exists, and the terms proposed
in these Guidelines do not constitute a proposal for such standardization. The IOGP Report
483-7u – P7/17 Wellbore Positioning Data Exchange User Guide provides further clarification
on surface and wellbore deviation terms.
In the context of GIGS, the term wellbore survey data refers to the raw measurement data
of Measured Depth (MD), azimuth (AZ) and inclination (INC), that have been gathered in a
wellbore survey. The term ‘well path’ refers to the collection of coordinates of identified
points along the wellbore, calculated from the wellbore survey data, using one of the
algorithms in use in the industry, such as the minimum curvature method5 or the LMP
method6. The GIGS Test Dataset is derived using LMP, if an application does not support
this curve calculation method then it is acceptable to modify the Test Data so it can be
sufficiently imported and processed.
5 Sawaryn, S.J. and Tulceanu, M.A. “A Compendium for Directional Calculations Based on the Minimum Curvature Method:
Part 2.” SPE-110014-MS Society of Petroleum Engineers Annual Technical Conference and Exhibition, Anaheim, USA,
11-14 November 2007.
6 Zinn, “N.D. Accounting for Earth Curvature in Directional Drilling.” SPE-96813-MS. Society of Petroleum Engineers Annual
Technical Conference and Exhibition, Dallas, USA, 9-12 November 2005.
18
1.5.14 6000 Audit Trail

This Test Series deals with software capability for audit trail generation, configuration and
access. The term “auxiliary metadata” is used to refer to metadata that is populated in
respect of each data operation executed (i.e., create, import, merge, and data processing
through to transfer and export). Some software may capture auxiliary metadata but not
capture that in an audit trail. Several tests specifically address this scenario.
1.5.15 7000 Deprecation

This Test Series deals with software capability for the deprecation of geodetic data objects,
both for predefined and user-defined entities. Deprecation is not a widely supported
function in most software so this series may be omitted in those cases.
Test Procedures are required as part of this Test Series, referencing the 7XXX GIGS Test
Dataset file (see Section 2.11.8).
1.5.16 Error Trapping

In previous versions of GIGS, a dedicated Test Series 8000 was defined for Error
Trapping functionality. As it is expected that all software will include some error trapping
mechanisms, and they will be specific to a particular data theme, the error trapping tests
are now embedded in the relevant Test Series to which they are related (for example, Error
Trapping tests pertaining to wellbore data are included in Series 5500).
The error trapping tests described in the Test Series aim to capture software behaviour
regarding geospatial integrity. In the tests, distinction is made between the following
software responses:
• Warning flag (or message) - a message to the User indicating that geospatial integrity
may fail unless preventive actions are taken.
• Error flag (or message) - a message to the User indicating that geospatial integrity
will fail; the software allows the User to proceed.
• Strong error flag (or message) - a message to the User indicating an imminent
serious failure of geospatial integrity; the software blocks the intended action.
19
2. GIGS Test Dataset User Guide
2.1 Overview
The GIGS Test Dataset provides source data for geodetic DDT (data-driven testing) in order
to quantitatively evaluate software capability with respect to maintaining geospatial data
integrity. In addition to the qualitative unit and integration tests that the GIGS Test Series
provides, the GIGS Test Dataset provides a robust method of numerically validating the
architecture, implementation and accuracy of an application’s geodetic computation engine
and library, thereby identifying potential causes of any failures in geospatial data integrity.
Code
TEST DATA
Data source System under test
EXPECTED RESULT ACTUAL RESULT
Compare results
Figure 4: Test driven development testing cycles
The GIGS Test Dataset is associated with certain tests within the Test Series and is only
provisioned for some of the Series, including:
• 2200 – Predefined Geodetic Data Objects Test Data
• 3200 – User-defined Geodetic Data Objects Test Data
• 5100 – Conversion Test Data
• 5200 – Coordinate transformation Test Data
• 5300 – 2D seismic Test Data
• 5400 – 3D seismic Test Data
• 5500 – Wells Test Data
• 7000 – Deprecation Test Data
20
The GIGS Test Dataset comprises different data, depending on the nature of the associated
tests:
• Geodetic data definitions (Series 2200, 3200, 7000) – contains lists of entities and
parameters that either should be created or checked.
• Coordinate operation data (Series 5100, 5200) – contains coordinate data to be
converted or transformed, both forward and reverse.
• Seismic and wellbore data (Series 5300, 5400, 5500) – contains coordinate data and
seismic/well attributes to be converted or transformed.
The GIGS Test Dataset Test Procedures (hereafter referred to as “Test Procedures”)
correspond with the groupings in the GIGS Test Series (see Section 1.5) and are numbered
accordingly. Each Test Procedure has a unique number that corresponds with the relevant
Test Series (for example Test Procedure 5101 is in the 5100 Test Series, Test 1.1).
GIGS Test Procedures have a defined set of results and tolerances that should be achieved
and are therefore deemed to deliver a Boolean pass or fail outcome. If a Test Procedure
result is ‘Pass’ then the respective Test (in the Test Series) is passed, and vice versa for
‘Fail’. For example, if the output of Test Procedure 5101 matches the expected results,
then Test 5100_1.1 would be passed, achieving an Intermediate level (see Section 1.2.). The
failure of a Test Procedure results in a No GIGS Score level being assigned to the test in the
Test Series, as it indicates a failure in geodetic data integrity has occurred.
The majority of ASCII Test Data files are separated into input and output files per Test
Procedure (indicated by an “_input” or “_output” suffix). Therefore, in most cases there is a
one-to-one file relationship for each Test Procedure, whereby the Evaluator loads data into
the application from the input file, then compares the results with the data in the output
file. Where multiple similar routines are to be run for a particular Test Procedure, but
different parameters are required (e.g., for a different CRS), the Test Dataset files are split
further into separate parts, indicated by a “_part{n}” suffix. It is also possible in most cases
to only use the “_output” file if desired which contains the minimum amount of information
to undertake a Test Procedure (see Section 2.4). Associated P-format files are not split into
separate inputs and outputs.
In the input files, the values that are to be loaded into the application will be populated, and
the attributes expected to be calculated will typically be marked as NULL (with the exception
of where a geodetic parameter field is unpopulated). In the output files, all attributes will
be populated including the input values (for reference) and expected output values. In this
regard, it is possible that only the output file could be used in most Test Procedures (as it
is a single file containing both the input and output values, with some exceptions). In some
evaluation routines, however, it may be undesirable to “reveal the answers” prior to the
calculations/operations being undertaken. This is down to Evaluator preference.
The GIGS Test Dataset is referenced to a combination of EPSG authority geodetic data
objects (such as CRS) and synthetic entities that have been generated for GIGS testing
purposes. This means that the Test Dataset corresponds with the EPSG Dataset version
valid at the time of publication (indicated in the Test Data headers). A new GIGS Test Dataset
version is not released every time a new EPSG Dataset version is, hence, Evaluators are
recommended always to consult the latest EPSG Dataset (https://www.epsg.org) if any
discrepancies arise in the Test Procedures.
21
2.2 Test Dataset Access

The GIGS Test Dataset is open source and issued under the GIGS and EPSG terms of use
(see https://gigs.iogp.org).
The GIGS Test Dataset is available for download from the IOGP GIGS website as a zipped
package or individual files, containing various nested folders grouped for each Test Series.
The Test Data files are indexed in Appendix A.
2.3 Test Dataset Formats

The Test Dataset files are offered in a number of formats:
• ASCII base class7 (.txt) – All series
• P1/11 subclass8 (.p111) – Series 5100, 5200, 5300, 5400
• P1/90 subtype9 (.p190) –Series 5300, 5400
• P6/98 subtype (.p698) – Series 5400
The Evaluator may choose to generate a different format from the ASCII base class for use
in a particular application, this may include one of the following file types, but these are not
supplied by IOGP and are therefore not controlled:
• WKT2 subclass (.wkt)
• Excel subclass10 (.xlsx)
• XML subclass (.xml)
The ASCII base class contains all Test Data content in its simplest form. The intention is
that these files provide the reference source code for all other Test Dataset files. These are
the files primarily maintained by the GIGS authors. All other subclasses and subtypes are
derived from the ASCII base class.
The tab-delimited ASCII format is offered as a base class as it is simple, universally

consumable and platform agnostic. This data format can be integrated into whichever
language/workflow is required for the application being tested. The file contents can
be converted easily and programmatically to XML, JSON, Python or any other machine
language format as required.
The P-format subtypes are generated in the format according to the respective standard
(see associated IOGP reports on Format and User Guide). Generally, where tests involve the
use of PX/XX industry standard exchange formats, the strong preference is to utilise the P
files where supported (as opposed to defaulting to ASCII), however in terms of GIGS Test
7 Base class refers to file in which all other classes are derived
8 Subclass refers to secondary file type inherited from the base class. Note there are a small number of Test Data files that cannot be
supplied in P1/11 format due to structure/content restrictions. See specific notes in Section 2.11.
9 Subtype refers to a limited subordinate file type, i.e., this format only applies to a small number of Test Data files
10
See Appendix F for advice on generating Excel Test Dataset files
22
Dataset derivation, the ASCII files remain the “master copy”. The P-format files contain
more explicit definitions of geodetic parameters due to the Common Header and are
superior to other classes where Test Data is to be imported, transferred, or exported using
an industry standard data exchange format.
Previous versions of P-formats are offered as it is recognized that some applications may
not support newer formats, and it is important to be able to test legacy data workflows.
However, it is strongly recommended that primary testing should be undertaken using
the latest versions of the P-format files (see https://www.iogp.org/geomatics/). If the
software supports P-formats, there is no requirement to repeat Test Procedures using
the ASCII data, unless so desired. Due to the legacy nature of the older P-format files
and inconsistencies in how the format has been subsequently adapted and adopted, the
construct of the Test Dataset legacy files may not be exactly conformant with what an
application is expecting. Therefore, modifications may need to be made by the Evaluator to
ensure the legacy files can be correctly exchanged.
The P1/11 subclass is offered as an alternative format for ingesting most Test Data, not
just those Test Procedures that explicitly involve seismic position data. The P1-format is
suited well to the GIGS Test Procedures in that it explicitly defines geodetic parameters in
the header and is flexible in storing point data. There is no requirement however for the
Evaluator to use the P1/11 subclass files if not desired. Note that for most Test Procedures
the P1/11 files are provided as single files (i.e., there are no input/output P1/11 files) due
to the structure of the P-Format and the fact that the output file contains all necessary
information to complete each Test Procedure (see Section 2.4 for further detail) – the
exception being the 5400 Test Procedures, due to the nature of these Tests. If using the
P1/11 subclass then note that the information on Test Dataset files in Section 2.11 will be
invalid where “_input” files are referred to – instead use only the single file.
Note that for the P-format files, the file extension suffix is set to the vintage of P-format
version (e.g., .p717). If the software being tested only accepts the shortened P-format file
extension (e.g., .p7) then it is admissible to change all suffixes to ensure the files can be read.
2.4 Test Dataset Construct

The following description details the construction of the ASCII base class. See the
respective IOGP format documentation for detailed information on how the P-format files
are constructed (see https://www.iogp.org/geomatics/).
The ASCII files comprise a 1D vertical array header (outlined in Section 2.4.1) followed by a 2D
array of data (i.e., a single column header above a multi column/row data table). The 2D data
array consists of the data that is required for the particular test subject and typically contains
either a list of geodetic parameters, or a list of coordinates and associated attributes.
The data array usually comprises a mixture of integer, float and string values, however
(within the ASCII files) there is no associated schema that defines field types. At the
base class level it is preferable to treat all values as strings (text), in order to ensure
that numeric representations are preserved as they are stored (see Section 2.5.1). This
is particularly important for those values derived from the EPSG Dataset. If required, the
ASCII values can be cast to float, but ensuring the correct base is used.
23
Additionally, within the data array there may be attributes that are purposefully not
populated (for example, in an input file where part of a row of data is to be calculated). For
numeric fields these would typically appear as NULL, whereas for text fields these would
appear as empty strings (“”). Note that there are many instances in the data array where
“0” is a valid value and does not pertain to either NULL or an empty string.
For coordinate operation Test Data (transformation and conversion), each coordinate
tuple is assigned a test point ID (field: “Point”) in the form: GIGS-{test number}-{n}, in
order to make it easier to identify and load the point data. Additionally, a transect ID (field:
“Transect”) is assigned a letter (A, B, C, etc.) that identifies groups of points into linear
transects that corresponds with the different latitudinal/longitudinal transects on which
the Test Data have been defined. Finally, a coordinate operation direction field is provided
(either field: “Conversion Direction” or “Transformation Direction”) in the form: FORWARD
or REVERSE, to indicate in which direction the calculation operation is expected to be
undertaken for each data point. There are other auxiliary fields that sometimes appear in
Test Data (for example, identifying points that are out of bounds and should therefore fail).
These are typically represented by Boolean (TRUE, FALSE) values. These fields are not
included in the P-Format files, instead Conversion/Transformation Direction is indicated in
the record identifier (e.g., HC,1,8,2 – see respective IOGP P-Format definitions for further
information).
Note that for coordinate operation Test Data, it is entirely feasible to only use the “_output”
files in undertaking testing, particularly where Test Procedures are being implemented
automatically/programmatically. This is because the output files contain the complete set
of results, as well as input data, and operation information such as conversion direction
and test result tolerance. Using only the output files does provide the “answers” up front,
hence Evaluators may wish to still separate out the files, however the output files should
provide all required information for scripting the Test Procedures (primarily for Series
5100 and 5200 – 5300, 5400 and 5500 may still require the usage of input and output files
depending on the software configuration).
The seismic and wellbore test coordinate data are supplemented with additional identifying
attributes to assist in loading and categorizing test points. For 2D seismic Test Data, line
ID (field: “Line”) is provided in the form: GIGS-{test number}-{n} as well as a shotpoint ID
(field: “SP”) in the form {n}, and usually increasing in intervals of 10.
For wellbore data, a vertical point ID (field: “Point”) is added to appropriate data points
to assist in the identification of key references along the wellbore. IDs include RT (Rotary
Table), KB (Kelly Bushing), WRP (Well Reference Point), VRD (Vertical Reference Datum),
Ground Level, MSL (Mean Sea Level), Horizons, TD (Total Depth) and others (see P7 User
Guide).
2.4.1 ASCII File Header Definition

The ASCII data files have a header that was developed natively for the GIGS Test Dataset
in order to present the Evaluator with the minimum amount of required information in the
simplest format possible. See the respective P-format documentation for Common Header
definitions of the P-format files.
24
The ASCII header comprises hashed11 non-executable “metadata” that describes data
content, in the format defined below:
# File: {file name}

# GIGS Test Procedure: {test number}
# GIGS Test Dataset Version: {gigs version number}
# EPSG Dataset Version: {epsg dataset version number}
# GIGS Test Dataset Issue Date: {gigs version issue date}
# Note12: {text}
# Cartesian Tolerance13: {text}
# Geographic Tolerance13: {text}
# Round Trip Cartesian Tolerance14: {text}
# Round Trip Geographic Tolerance14: {text}
#
# Fields:
# [0]: {field 0 name}
# [n]: {field n name}
#
# [0] # [1] # [2] # [n]
{field 0 data} {field 1 data} {field 2 data} {field n data}
The first vertical 1D block of attributes provide identifying details about the file including,
its name and associated test number, followed by the version of GIGS that the file was
released under, and the version of the EPSG Dataset from which the data was derived.
The second vertical 1D block of attributes contains the field descriptors that define the field
name and associated parameters, where appropriate. When a field contains coordinates,
the field descriptor contains information about the CRS of the coordinate data, typically in
format: {field name} ({gigs crs code}; {gigs crs name}; {epsg crs name}; {crs unit}; {epsg crs code})
The third block of attributes is a horizontal 1D field header that “maps” the column
numbers in the data array to the respective field definitions in the second block. These
column numbers have an additional function of casting all data array values as strings
when the ASCII data is ingested in a spreadsheet program (see Section 2.4.2).
Note that although the header is a standard format it does not necessarily rely on a defined
number of byte locations per line, hence any interpretation program should use tags/string
identifiers, rather than byte counters.
11
A.k.a octothorpe, number sign, pound sign
12
Not all Test Dataset files contain a Note in the header, hence caution is advised when reading the header based solely on the line
number, as these could differ. There may also be multiple Note records
13
Not all Test Dataset files contain a Cartesian or Geographic Tolerance, mainly those in the 5000 Test Series’. These values state the
pass/fail tolerance from the input Test Data and results from the application being tested
14
Not all Test Dataset files contain a Round Trip Tolerances, mainly those in the 5100/5200 Test Series. These values state the pass/fail
tolerance from the input Test Data and results from the application being tested
25
2.4.2 CAUTION: Reading Test Dataset in Excel

Extreme caution should be exercised when opening the ASCII Test Dataset files in Microsoft
Excel or other spreadsheet applications, due to the risk of truncating values with 16 (or
more) significant figures. Excel can store numbers to 15 digits of precision, as per the IEE
754 specification15, which means that very small or very large floating point numbers may
be rounded or truncated. A small portion of the GIGS Test Dataset parameters (such as
ellipsoid axes values) exceed this number of digits and hence are not correctly represented
when read in Excel.
Many of the GIGS Test Dataset parameters are referenced directly to the EPSG Dataset
which stores floating points numbers at full precision. In order to ensure full storage
precision is maintained, it is recommended that the ASCII data array is interpreted as a
string value, and automatic number interpretation is not applied.
Excel has a further idiosyncrasy when loading text files in that numbers and strings are
presented as fixed column widths in a workbook, which if the file is then saved, only the
data that is visible will be preserved.
Therefore, if the Evaluator wishes to use the Test Dataset in Excel format, it is recommended
that a controlled method of loading the data is followed (see Appendix F). This circumvents
some of the Excel ingestion issues that are encountered when the ASCII files are either
‘drag-and-dropped’ into a workbook, or opened in Excel using “Open with” function.
Note it may be required to manipulate the header slightly for ease of use in Excel. The
horizontal field header numbers can also be supplemented with the Field names to allow
for easy identification of columns. The hash header may also be filtered out for ease of
sorting, however this can be restabilised by adjusting the filter. See Appendix F for complete
instruction on the Excel process.
2.5 Test Dataset Numeric Precision and Representation

2.5.1 Precision of Geodetic Parameters
The precision of the geodetic parameters for defining all coordinate operations (coordinate
transformations, conversions) in the GIGS Test Dataset is identical to that in the same
defining parameters within the EPSG Dataset (i.e., equivalent number of significant figures).
Key portions of the GIGS Test Procedures require that Evaluators verify that the precision of
the above parameters, as stored and utilised in the software, are at least as high as that for the
corresponding parameters stored within the EPSG Dataset. This is tested in two scenarios:
• For the software’s predefined geodetic library, the parameter precision for those
coordinate operations are examined against the EPSG Dataset for conformance and/
or non-conformance – as covered in the 2200 Test Series.
• For the software’s ability to allow entry of user-defined geodetic objects, the precision
allowed for the user-defined coordinate operations and other allowable geodetic
objects are sufficient to allow for storage of equivalent precision to that provided in
the EPSG Dataset – as covered in the 3200 Test Series.
https://docs.microsoft.com/en-us/office/troubleshoot/excel/floating-point-arithmetic-inaccurate-result
15
26
2.5.2 Precision of GIGS Test Dataset Coordinates

All input coordinate elements in metres or feet (easting, northing, ellipsoidal heights,
gravity related heights, depths, geocentric Cartesian X,Y,Z, etc.) are given to a minimum
precision of at least 1 centimetre or 1 hundredth of a foot, respectively, i.e., to 2 decimal
places. Some coordinates for certain tests may be stored and presented to 3 decimal places
(at least 1 millimetre) to account for common rounding errors encountered in applications,
however test tolerances are always at the centimetric level, so the additional significant
figure is required only for further investigation.
Latitude and longitude in decimal degrees or grads are input to a minimum precision of
0.0000001 degree, i.e., 7 decimal places (that is DDD.ddddddd). For certain tests some
coordinates may be stored and presented to 8 or 9 decimal places (millimetric) to account
for common rounding errors encountered in applications, however test tolerances are
always at the equivalent of centimetric level, so the additional significant figure is required
only for further investigation.
Geographic coordinate data are not provided in other representations (degrees minutes
seconds, radians, packed DMS, decimal minutes). If the application does not support
import or export of decimal degrees then the coordinates will need to be converted prior to
ingestion, using standard conversion algorithms. See IOGP Report 373-07-01 - Surveying
and Positioning Guidance Note Number 7, part 1 - Using the EPSG Geodetic Parameter Dataset
for further information.
2.5.3 Precision of Legacy P-format Data

Seismic 2D position data in the P1/90 data exchange format coordinates are limited in
precision, simply because the P1/90 format itself has limited coordinate resolution.
Geographic coordinates (latitude and longitude) in degrees in P1/90 are in a packed

sexagesimal DDMMSS.ss format with arc second storage defined using Fortran format F5.2,
which means it only allows a resolution of 0.01 arc second. This is a pseudo-unit used in
the EPSG Dataset for storing CRS definition parameter values given in sexagesimal degrees
(degrees, minutes, and seconds) as a floating point number in a single numeric field.
Similarly, P1/90 map grid coordinates (easting and northing) are limited to a resolution
of 0.1 metres. P1/90 allows a resolution of 0.1 metre for height/depth data, which is the
same resolution as easting and northing coordinates when given in metres. In all cases,
the P1/90 coordinate storage is an order of magnitude less precise than that which modern
software should allow.
To gain increased precision, users of the format may have used implied decimals, which
generally are not recognised by geospatial software. Users may have implemented
workarounds to generate their own P1 Reader software to manage these limitations. When
used out of context, these “workarounds” can create their own geospatial data problems.
27
2.6 Test Dataset Naming Convention
2.6.1 Test Procedure Naming/Numbering

The GIGS Test Dataset files follow a standard naming convention as follows:
GIGS_{series name abbrev.}_{Test Procedure number}_{Test Procedure name abbrev.} 16
Depending on the specific Test Procedure, usually there will also be a _input, _output,
_part{n}, or special identifying suffix (see Appendix A).
The Test Procedure numbers are four digits long, with the first two digits corresponding
to the Test Series number to which the test is related. For example, Test Data file “GIGS_
seis2D_5307_input” is associated with test series 5300 (2D seismic position data).
The Test Procedure number increases incrementally (by 1) for each Test Procedure (i.e.,
5306, 5307, 5308), however although the numbers are sequential, they do not always
indicate the order of the tests, as testing for various Series are not always done in isolation
(depending on the specific functionality of the application).
The Test Dataset occasionally may be modified, supplemented or potentially have elements
removed. When this occurs, the GIGS Test Dataset Version and GIGS Test Dataset Issue
Date values are updated in the file headers. Some legacy Test Procedures have been
removed because they are outdated or irrelevant, but in order to preserve the Test Dataset
structure (and ensure backwards compatibility), number assignments for such Test
Procedures are not re-used. In preliminary drafts of the GIGS documentation, there was
an exact correlation between Test number and Test Procedure number. However, this
correlation was lost as the Test Dataset was updated over various iterations. This is why, in
the current release it may appear that certain numbers are skipped, or in the wrong order.
Additionally, the GIGS Test Dataset is designed to be extensible, so additional Test

Procedures (and therefore numbers) may be introduced in the future.
2.6.2 Test Dataset Geodetic Data Object Naming/Numbering

All user-defined geodetic entities within the Test Dataset are named and numbered
(assigned a GIGS code) to assist with referencing and constructing objects while executing
Test Procedures. GIGS codes are integer numbers in the range 60000 to 69999. The entity
name is prefixed with “GIGS” and describes its type and includes a letter or number which
is unique within that type.
• For geodetic CRSs the EPSG subtypes geocentric and geographic 3D are embedded in
the name, but in the names of geographic 2D CRSs, the ‘2D’ is omitted. For example,
“GIGS geog3DCRS A” and “GIGS geogCRS A”
• Datum names include a letter, for example “GIGS geodetic datum A” or “GIGS vertical
datum U”. CRSs using that datum take the same letter, for example “GIGS geogCRS
B” is a geographic 2D CRS which uses geodetic datum B.
In previous GIGS versions test file names also contained the version date, however this was removed to ease file compilation.
16
The version of the Test Dataset to which the file corresponds now found in the file header.
28
• Conversion (map projection) names include a number, for example “GIGS conversion 3”.
• Projected CRS names include the letter for the base geographic CRS and the number
for the conversion, for example “GIGS projCRS B3” is based on CRS and geodetic
datum B and conversion 3.
• Vertical CRS names include the letter for the datum, a number to indicate axis unit,
and the words ‘height’ or ‘depth’ to indicate positive axis direction, for example “GIGS
vertCRS U1 height”
• For coordinate transformations, the name is not given explicitly but if needed it can
be built implicitly by following the EPSG Dataset convention of {Source CRS name} to
{Target CRS name} {variant number}.
The relationship between GIGS CRSs and “real world systems”, as documented in the
EPSG Dataset, is shown in Appendix C, on the basis that the EPSG CRSs are limited to their
specified “usage extent” as defined in the EPSG Dataset. Conversely, the corresponding GIGS
CRSs have unlimited area of use (i.e., they may be used for any geographic area of the Earth).
The EPSG names and codes are equivalent to the GIGS names and codes for “late
binding”17 systems only (i.e., for CRS and datums not requiring coordinate transformations
as part of the datum definition).
For some real-world geodetic datums and geographic CRS entities, multiple GIGS entities
are created. The duplicate entities, indicated by the prime sign (‘), are necessary only for
software that requires a transformation to WGS 84 as part of the datum or CRS definition
(so called “early binding”). Note that ‘Early binding’ is adopted in some software as a
means of implementing coordinate transformations. In the real world, datums and CRSs
are stand-alone entities capable of existing without defining their relationship to WGS 84.
As per Section 2.6.1, the original GIGS Test Dataset had a complete and sequential Geodetic
Data Object naming/numbering system. However, as the Test Dataset was updated
and modified, some Objects may have been removed or renamed (for example, if their
equivalent EPSG Code changed and was inferred in the GIGS Code). To ensure backwards-
compatibility in the Test Dataset, such names and codes are not re-used. Hence there may
be instances where it appears that codes or names are missing in the order.
2.7 User-Defined Geodetic Data Object Definitions

As described above, each of the geodetic objects used in the Test Series 3000 Test
Procedures is given a GIGS code and name. These geodetic objects are also used in tests
in other Series. Most of these objects correspond to a “real world” geodetic object, which is
already in the EPSG Dataset.
The creation of custom GIGS geodetic objects is deliberate, for the following reasons.
Firstly, these GIGS definitions mitigate geodetic objects that may exist in predefined
libraries within software that have a correct name but incorrect parameters (e.g., the
British National Grid has been defined erroneously in some predefined libraries with a
scale factor 0.9996 rather than the correct value of 0.9996012717). Thus, it allows data
operations tests to be conducted using the correct definitions, controlled by the Evaluator.
Transformation does not form explicitly part of coordinate reference system definition
17
29
Secondly, EPSG CRS, transformation, and conversion data are associated with an area
of applicability. Thus, they should be limited in usage to a specific geographic area. In
principle, this “extent” data should be used by the software to limit use of the CRS or
operation (e.g., to prevent the use of the British National Grid outside of the area covered
by Britain). However, for some GIGS Test Procedures, the Test Data deliberately exceeds
the normal area of use for that data. For example, conversions (map projections) are tested
beyond the projection method extents. Similarly, software is tested to establish which of
the overlapping Canadian and US transformation data options is being referenced. For
this reason, the GIGS geodetic Test Data is deliberately not constrained to the limits of the
equivalent real-world data, as documented in the EPSG Dataset.
The GIGS geodetic Test Data are given names specifically for the GIGS project, for example
GIGS projCRS F7. This is equivalent to the GDA94/MGA zone 54 CRS, except that F7 is
not bounded by “extent” data. Similarly, the GIGS geogCRS J is equivalent to the NAD27
Geographic 2D CRS, but without the associated “extent” data. This process allows fictitious
areas of use to be associated with the GIGS systems in software that does recognise the
EPSG area of use “extent” data.
Thirdly, the CRS ‘WGS 84 / British National Grid’18 is used in the Test Dataset as a common
CRS in which to present the Test Data. This was chosen deliberately to allow full testing of
the coordinate operations in Series 5100 and 5200, and to minimize the number of projects
that need to be created for the Series 5300 through Series 5500 tests. This GIGS CRS has
no real-world equivalent.
The precision of the defining parameters for all GIGS geodetic entities is identical to that
in the equivalent data within the EPSG Dataset. To simplify usage and minimise confusion,
clear descriptions and definitions of all custom GIGS datums, geographic CRSs and
projected CRSs have been tabulated and cross-referenced against their corresponding
EPSG entities (that include the EPSG-defined “area of use” Usage Extent). This has
been done within each of the GIGS Test Data files, and these relationships are tabulated
separately in Appendix F of this document. Testing for geographic applicability is not
included in the tests to date, other than for NADCON and NTv2 gridded transformations
across the US-Canadian border, but the Test Data allow for such testing in the future,
should this be required.
2.8 Predefined Geodetic Data Object Applicability

Each of the geodetic objects used in the Test Series 2000 Test Procedures is given its
respective EPSG Usage Extent alongside other defining parameters19. The ‘Extent’ field
can be utilised to exclude certain objects from testing, if an application is specifically
and legitimately designed not to work with data pertaining to that geographic area. This
provides flexibility in the evaluation, in that not all software needs to support the wide range
of geodetic data objects that are included in the predefined library tests.
18
The British National Grid was defined by Great Britain’s national mapping agency, to be referenced to the Ordnance Survey of Great
Britain 1936 datum. Although it can be linked to the WGS 84 datum mathematically, it is never used in that way, nor is it defined in the
EPSG Geodetic Parameter Registry in that way. Hence, WGS 84 / British National Grid does not exist in the real world and should not be
used outside these Test Procedures.
19
Replaces “Particularly important to E&P industry” field as used in legacy GIGS versions
30
When executing Tests and Test Procedures for the 2000 Series, therefore it is justifiable
to record the results that are specific only to the geodetic data objects relevant to the
software’s general area of use.
Note that the geographic applicability of the objects does not necessarily apply to the
Test Dataset in the 3000 Series, as the custom GIGS objects are designed to be used
outside of the typical area of use. Therefore, a Test Procedure may require the creation
and execution of a coordinate operation, or CRS, outside of the design area of use of the
software. However, in these cases it is the geodetic data object itself (e.g., transformation
or conversion method) that should be noted as ‘not supported’ by the software, rather than
the usage extent associated with the object. For example, an application may be designed
explicitly not for use in the USA. In the 2000 Series, therefore, all geodetic data objects with
a ‘Usage Extent’ of CONUS (‘CONtinental US’) could be excluded from testing; whereas in
the 3000 Series the NADCON tests (‘N American Datum CONversion’) should be reported
as ‘not supported’.
In addition to Usage Extent, where appropriate, each geodetic data object is also assigned
its respective aliases, as recorded in the EPSG Dataset. In some applications, the defining
parameters of the object may match those in the GIGS Test Dataset (and EPSG Dataset), but
the name may be different. Provided that the name is included in the list of aliases, then the
individual test can be deemed a Pass, however, use of any other names should be reported.
2.9 Test Procedure Project Naming

For the Test Series 5000 Data Operations tests, Test Data must be loaded into the software.
This normally will require the creation of a project within the software. To comply with
the test scenarios, these projects need to be referenced to specified CRSs. To identify the
project to which data is to be loaded, GIGS project names have been constructed such
that project names comprise the required horizontal and vertical GIGS CRS names. For
example, “GIGS project A9V1depth” references horizontal CRS “A9” and vertical CRS “V1
depth”. The project CRSs are further detailed in Appendix D.
2.10 Round Trip Calculations

Many of the Test Series 5000 Data Operations Test Procedures require the execution
of round trip calculations, where iterations of forward and reverse computations are
performed, using the output of computation n as input into computation n+1, for a specific
test point (usually the first or last in a set). The coordinate value from each iteration is
compared to the tolerance value specified for each Test Procedure, and the number of
iterations it takes to exceed the tolerance is reported. Realistically, no more than 1000
iterations are necessary to adequately test the function.
The round-trip calculation threshold (e.g., 0.0000006° or 0.006m (6mm)) is the acceptable
change from the original calculated coordinates, not the expected Test Data coordinate. For
example, a single calculation could give a coordinate that differs by 0.03m (30mm) from the
expected result (which is within the 0.05m (50mm) single calculation tolerance), but after
1000 iterations, if the coordinate has changed from the initial calculated value by more
than 0.006m (6mm), that is considered out of the expected tolerance. This is a valid and
31
important test because software operability is not expected to deteriorate the calculation
result or propagate error after the round trips.
Such calculations are an important test for functionality in software where coordinate
data may be exchanged many times back and forth in a particular module/algorithm, for
example where a conversion or transformation is taking place. A failure in geospatial data
integrity may occur if an error is introduced during each operation, and that error then
propagates and increases through the entire calculation chain. This can cause coordinates
to “walk” from their correct values as the number of iterations increases, resulting in
reduced results accuracy.
It is recognised that the round-trip calculation procedures can be cumbersome

to implement, and so they should only be executed where the routine can be run
programmatically. If this is not possible in the software, manual input/output for round
trip calculations should be avoided and the iteration results should be generated by other
means, or the number of iterations reduced to an attainable level.
The test point to be used for round trip calculations is indicated by a comment in the “GIGS
Remarks” field of each input file.
2.11 Test Procedures Specific Guidelines

The following sections contain instructions for executing each Test Procedure. Note that
details of the input and output Test Data files are for guidance only and refer to the ASCII
base class, depending on the chosen, or derived, Test Dataset Format, the actual file
names and structure may be different (see Sections 2.3 and 2.4).
2.11.1 2200 Predefined Geodetic Data Object Test Procedures

The Test Procedures for this series are designed to verify the correctness of geodetic
parameters that are delivered with the software. The latest version of the EPSG Dataset
should be used for these tests and is taken as ‘truth’.
Records in the EPSG Dataset which have been deprecated should be ignored in Series 2000
testing (Deprecation is examined in Series 7000).
The Test Data files for Series 2000 describe a subset of EPSG records which is of particular
interest to the energy industry. It constitutes the minimum set of definitions to be checked.
Evaluators are encouraged to go beyond this minimum set and verify the software’s
complete predefined geodetic parameter library against the EPSG Dataset, but this is not a
requirement.
As per Section 2.8, an EPSG Usage Extent is assigned to each data object; if the application
being tested is unequivocally designed not to operate in certain areas, then objects
associated with such geographies can be excluded from testing.
The Series 2000 tests are structured to follow the ISO 19111 and EPSG data models
for spatial referencing by coordinates. This may be envisaged as a hierarchical series
of entities, with higher-level entities being dependent upon lower-level entities. For
32
example, a geodetic datum (higher-level) includes an ellipsoid (lower level) with the datum
dependent upon that ellipsoid definition. The higher-level entity in this pairing may then
be a lower level in a later pairing, for example a geodetic CRS (higher level) includes a
geodetic datum (lower-level). Lower-level entities may be used in one or many higher-level
entities. The tests begin at the bottom of the hierarchy.
See Appendix B for tips on conducting these tests in software in which the storage of
geodetic parameters does not conform to the EPSG model and/or EPSG nomenclature.
Test Procedure: 2201 - Predefined units of measure
Test Purpose: To verify reference units of measure bundled with the application.
Test Process: Compare unit definitions included in the application against the EPSG Dataset.
Test Data: EPSG Dataset and file GIGS_lib_2201_Unit. As a minimum those units relevant to the application’s
area of use should be tested. This file contains three separate blocks of data for linear units,
angular units and scaling units. It gives the EPSG code and name for the unit of measure, together
with the ratio of the unit to the ISO base unit for that unit type.
Expected Results: • Unit of measure definitions bundled with the application should have the same name and ratio
as the appropriate base unit in the EPSG Dataset. The values of the base unit per unit should be
correct to at least 10 significant figures.
• Units should be reported if they are:
– missing from the application
– additional to those in the EPSG Dataset
– objectively different from those in the EPSG Dataset
Note: • Some applications may not recognise the diversity of units of measure encountered in geodetic
definitions and coordinates. Particular attention should be given to whether the application
distinguishes between different types of feet and supports different representations of degrees.
• The ratio to base unit may be embedded in application code and not readily available to Users.
If this is the case, it may be possible to convert a coordinate set in base unit to the desired unit
in order to compute the effective ratio to base unit. Otherwise, report that the conversion ratio
cannot be determined.
Test Procedure: 2202 - Predefined ellipsoids
Test Purpose: To verify reference ellipsoid parameters bundled with the application.
Test Process: Compare ellipsoid definitions included in the application against the EPSG Dataset.
Test Data: EPSG Dataset and file GIGS_lib_2202_Ellipsoid. As a minimum those ellipsoids relevant to the
application’s area of use should be tested This file gives the EPSG code and name for the ellipsoid,
commonly encountered alternative name(s) for the same object, the value and units for the semi-
major axis, the conversion ratio to metres for these units, and then a second parameter which will
be either the value of the inverse flattening (unitless) or the value of the semi-minor axis (in the
same units as the semi-major axis). It may additionally contain a flag to indicate that the figure is a
sphere: without this flag the figure is an oblate ellipsoid.
Expected Results: • Ellipsoid definitions bundled with application, if any, should have same name and defining
parameters as in the EPSG Dataset. Equivalent alternative parameters are acceptable but should
be reported. The values of the parameters should be correct to at least 10 significant figures.
• For ellipsoids defined by Clarke and Everest, as well as those adopted by IUGG as International,
several variants exist. These must be clearly distinguished.
• Ellipsoids should be reported if they are:
33
Note: • The term ‘spheroid’ may be used in application documentation. ‘Ellipsoid’ is the preferred term
• Some applications require or use different defining parameters to ‘a’ and ‘1/f’, for example ‘e’, ‘e2’ or
‘n’. If necessary, the values of these alternative parameters should be calculated from those given in
the EPSG Dataset using standard formulae available in EPSG Guidance Note 7 part 2 or in geodetic
texts. Where the second parameter is the semi-minor axis ‘b’ and the figure is an ellipsoid, the
derived value of inverse flattening is given in the EPSG Dataset ellipsoid forms and reports.
• If the figure is a sphere, ‘1/f’ is indeterminate and is not used.
• Some applications require that all ellipsoid axes are defined using (international) metres. The
metric equivalent of those given in the EPSG Dataset in other units may be derived using the
appropriate conversion factor taken from the EPSG units definitions. The equivalent metric semi-
major axes are given in file GIGS_lib_2202_Ellipsoid.
Test Procedure: 2203 - Predefined prime meridians
Test Purpose: To verify reference prime meridians bundled with the application.
Test Process: Compare prime meridian definitions included in the application against the EPSG Dataset.
Test Data: EPSG Dataset and file GIGS_lib_2203_PrimeMeridian. As a minimum those prime meridians relevant
to the application’s area of use should be tested.
Expected Results: • Prime meridian definitions bundled with the application should have the same name and
Greenwich Longitude as in the EPSG Dataset. Equivalent alternative units are acceptable but
should be reported.
• The values of the Greenwich Longitude should be correct to at least 7 decimal places (of degrees
or grads).
• Prime meridians should be reported if they are:
Note: • Some applications may not identify prime meridians. In this case it should be assumed that they
are Greenwich.
• Offsets are positive when the subject prime meridian is east of the Greenwich meridian and
negative when west of the Greenwich meridian.
• Some applications may require that all offsets from Greenwich are defined using (decimal)
degrees. The decimal degree equivalents of the sexagesimal format are also included within the
test file.
Test Procedure: 2204 - Predefined geodetic datums
Test Purpose: To verify reference geodetic datums bundled with the application.
Test Process: Compare geodetic definitions included in the application against the EPSG Dataset.
Test Data: EPSG Dataset and file GIGS_lib_2204_GeodeticDatum. As a minimum those geodetic datums
relevant to the application’s area of use should be tested. Tests for component logical consistency
should be included: for example, if a higher-level library-defined component such as ED50 datum is
selected, it should not be possible to change any of its lower-level components such as the ellipsoid
from the predefined value (in this example International 1924).
Expected Results: • Definitions bundled with the application should have the same name and associated ellipsoid and
prime meridian as in the EPSG Dataset.
• Geodetic datums should be reported if they are:
Note: • Critical data are correct: geodetic datum name, ellipsoid name and parameter values, and prime
meridian name and Greenwich Longitude value.
• Some applications may associate a transformation (to WGS 84) with a datum definition. This is
not part of an EPSG datum or CRS definition and if present should be reported. See also Test
Procedure 2207.
34
Test Procedure: 2205 - Predefined geodetic CRSs
Test Purpose: To verify reference geodetic CRSs bundled with the application.
Test Process: Compare geocentric, geographic 3D and geographic 2D CRS definitions included in the application
against the EPSG Dataset.
Test Data: EPSG Dataset and file GIGS_lib_2205_GeodeticCRS. As a minimum those geodetic CRS relevant to
the application’s area of use should be tested. Tests for logical consistency of components should
be included.
Expected Results: • Definitions bundled with the application should have the same name and associated geodetic
datum as in the EPSG Dataset.
• CRS should be reported if they are:
Note: • Critical data are correct: CRS and geodetic datum name etc.
• EPSG Dataset geodetic CRS entries should have Cartesian axes in order X, Y, Z and ellipsoidal
axes in order latitude, longitude, [ellipsoidal height]. The CRS axis order should agree with that in
the EPSG dataset.
• CRSs with the same datum but differing coordinate system attributes (in particular axes order)
are considered to be different CRSs. Occurrences should be reported.
• Some applications may associate a transformation (to WGS 84) with a CRS definition. This is not
part of an EPSG CRS definition and if present should be reported. See also Test Procedure 2208.
Test Procedure: 2206 - Predefined conversions
Test Purpose: To verify reference conversions (map projections) bundled with the application.
Test Process: Compare conversion definitions included in the application against the EPSG Dataset.
Test Data: EPSG Dataset and file GIGS_lib_2206_Conversion. As a minimum those conversions relevant to the
application’s area of use should be tested.
Expected Results: • Conversion definitions bundled with the application should have the same name, method name,
defining parameters and parameter values as in the EPSG Dataset. The values of the parameters
should be correct to at least 10 significant figures.
• Conversions should be reported if they are:
Note: • Critical data are correct name, method name, parameters and their values.
• Some applications require that all map projection parameters are defined using specific units.
The equivalent of those given in the EPSG Dataset in other units may be derived using the
appropriate conversion factor taken from the EPSG units definitions.
35
Test Procedure: 2207 - Predefined projected CRSs
Test Purpose: To verify reference projected CRSs bundled with the application.
Test Process: Compare projected CRS definitions included in the application against the EPSG Dataset.
Test Data: EPSG Dataset and file GIGS_lib_2207_ProjectedCRS. As a minimum those projected CRS relevant to
the application’s area of use should be tested
Expected Results: • Projected CRS definitions bundled with the application should have the same name, coordinate
system (including units, axes abbreviations and axes order) and conversion as in the EPSG
Dataset.
• CRSs should be reported if they are:
Note: • Critical data are correct name and associated datum, coordinate system and map projection.
• The EPSG Dataset projected CRS entries are specific regarding axes order, axes name/
abbreviation and axes units. CRSs with the same datum and map projection but differing
coordinate system attributes (particularly axes order and units) are considered to be different
CRSs. Variances from EPSG should be reported.
• Some applications may associate a transformation (to WGS 84) with a datum definition. This is
not part of an EPSG datum or CRS definition and if present should be reported.
Test Procedure: 2208 - Predefined coordinate transformations
Test Purpose: To verify reference coordinate transformations bundled with the application.
Test Process: Compare transformation definitions included in the application against the EPSG Dataset.
Test Data: EPSG Dataset and file GIGS_lib_2208_CoordTfm. As a minimum those coordinate transformations
relevant to the application’s area of use should be tested.
Expected Results: • Transformation definitions bundled with the application should have the same name, method
name, defining parameters and parameter values as in EPSG Dataset. The values of the
parameters should be correct to at least 10 significant figures.
• Transformations should be reported if they are:
• Some applications require that all transformation parameters are defined using specific units.
Test Procedure: 2209 - Predefined vertical datums
Test Purpose: To verify reference vertical datums bundled with the application.
Test Process: Compare vertical datum definitions included in the application against the EPSG Dataset.
Test Data: EPSG Dataset and file GIGS_lib_2209_VerticalDatum. As a minimum those datums relevant to the
Expected Results: • Definitions bundled with the application should have the same name and defining parameters as
in EPSG Dataset.
• Datums should be reported if they are:
Note: • Critical data is correct datum name.
36
Test Procedure: 2210 - Predefined vertical CRSs
Test Purpose: To verify reference vertical CRSs bundled with the application.
Test Process: Compare vertical CRS definitions included in the application against the EPSG Dataset.
Test Data: EPSG Dataset and file GIGS_lib_2210_VerticalCRS. As a minimum those CRS relevant to the
Expected Results: • Definitions bundled with the application should have the same name and coordinate system
(including axes direction and units) as in EPSG Dataset.
• CRS should be reported if they are:
Note: • Critical data are correct CRS and datum name, axes directions, units and abbreviation.
• The EPSG Dataset vertical CRS entries are specific regarding axes name/abbreviation and axes
units. CRSs with the same datum but differing coordinate system attributes are considered to be
different CRSs.
Test Procedure: 2211 - Predefined vertical transformations
Test Purpose: To verify reference vertical transformations bundled with the application.
Test Process: Compare transformation definitions included in the application against the EPSG Dataset.
Test Data: EPSG Dataset and file GIGS_lib_2211_VertTfm. As a minimum those transformations relevant to the
Expected Results: • Transformation definitions bundled with the application should have same name, method name,
defining parameters and parameter values as in EPSG Dataset. The values of the parameters
should be correct to at least 10 significant figures.
• Transformations should be reported if they are:
• Some applications require that all transformation parameters are defined using specific units.
• Other vertical transformation method, at this time these tests are not covered in the GIGS Test
Dataset or associated Test Procedures, although they may be added at a later date.
End of 2200 Test Procedures
2.11.2 3200 User-defined Geodetic Data Object Test Procedures

The Test Procedures in this series are designed to evaluate the software’s capabilities for
adding user-defined CRS and transformation definitions to its geodetic parameter library.
The Test Procedures assume that the software follows the ISO 19111 and EPSG geodetic
data model. See Appendix B for tips for conducting these tests in software in which the
storage of geodetic parameters does not conform with the EPSG model and/or EPSG
nomenclature.
The Test Procedures in this section should be conducted sequentially as some data loaded
in early tests is required in later tests. The data may be envisaged as a hierarchical series
of entities, with higher-level entities being dependent upon lower-level entities. For
example, a geodetic datum (higher level) includes an ellipsoid (lower level), and the datum
37
is dependent upon that ellipsoid definition. Lower level entities may be used in one or many
higher level entities. The tests begin at the bottom of the entity hierarchy. The fully built-up
CRSs and transformations are used for later tests, particularly those in Series 5000, Data
Operations.
See Section 2.6 for comments on the names of geodetic entities created during these Test
Procedures and Appendix C for their relationship to real world entities documented in the
EPSG Dataset.
If the software requires an area of use to be assigned to user-created geodetic entities, use
the range +90 to -90 degrees latitude and +180 to -180 degrees longitude.
To cater for software using so-called “early binding” and requiring a transformation as part
of the geodetic datum definition, the Test Data for each geodetic datum includes a default
transformation to WGS 84. These default transformations deliberately use the geocentric
translation method to ensure broadest applicability. Similarly, vertical datums are, in
general, associated with mean sea level.
An equivalent EPSG name and code is assigned to each object (see Appendix C), if there is
no respective EPSG entity (i.e., if the object is a custom entity defined specifically for GIGS)
then the value “No direct EPSG equivalent” is populated.
Test Procedure: 3201 - User-defined units of measure
Test Purpose: To verify that the application allows correct definition of a user-defined unit of measure.
Test Process: • Create user-defined unit of measure for each of several different units, using parameters in
fields 0-2
• The values of the base unit per unit should be correct to at least 9 decimal places.
Test Data: GIGS_user_3201_Unit
Expected Results: The application should accept the Test Data. The order in which the name and the unit factor are
entered is not critical, although that given in the Test Dataset is recommended. Test result will be
pass or fail. If fail, details of failure should be reported.
Note: Units are defined relative to an ISO base unit: metre for length, radian for angle, unity for scale.
These are included in the dataset for reference only. The expected input is the number of base units
per unit. It may be described as a fraction formed from two values which EPSG refers to as factor B
and factor C (numerator and denominator respectively). If necessary, use the Test Data ratio as the
numerator and unity as the denominator.
Test Procedure: 3202 - User-defined ellipsoids
Test Purpose: To verify that the application allows correct definition of a user-defined ellipsoid.
Test Process: • Create user-defined ellipsoid for each of several different ellipsoids, using parameters in fields
0-3 and additional factors in fields 4-6.
• Parameters in fields 7-9 provided for information only.
Test Data: GIGS_user_3202_Ellipsoid
Expected Results: The application should accept the Test Data. The order in which the name and the ellipsoid
parameters are entered is not critical, although that given in the Test Dataset is recommended. Test
result will be pass or fail. If fail, details of failure should be reported.
38
Note: • The term ‘spheroid’ may be used in application documentation. ‘Ellipsoid’ is the preferred term.
• Some applications require or uses different defining parameters from ‘1/f’ or ‘b’, for example
‘e’, ‘e2’ or ‘n’. If necessary, the values of these alternative parameters should be calculated from
those given in the EPSG Dataset using standard formulae available in EPSG Guidance Note 7,
part 2 or geodetic texts.
• Some applications require that all ellipsoid axes are defined using (international) metres. The
metric equivalent of Test Data non-metric values can be obtained using the unit conversion
factor included in the Test Data.
• Applications that use only ‘a’ and ‘1/f’ will be unable to define a sphere.
• Applications that use only ‘a’ and ‘b’ will be able to define a sphere by inputting the Test Data
value of ‘a’ for both ‘a’ and ‘b’.
Test Procedure: 3203 - User-defined prime meridians
Test Purpose: To verify that the application allows correct definition of a user-defined prime meridian.
Test Process: • Create user-defined prime meridian for each of several different meridians, using parameters in
fields 0-3
• Parameters in field 4-5 provided for information only.
Test Data: GIGS_user_3203_PrimeMeridian
Expected Results: The application should accept the Test Data. The order in which the name and the meridian
Note: • Offsets are positive when the subject prime meridian is east of the Greenwich meridian and
negative when west of the Greenwich meridian.
• Some applications may require that parameters are entered in sexagesimal degrees (which
should be reported), if this is the case then undertake a suitable conversion on the decimal
degree values before entering.
Test Procedure: 3204 - User-defined geodetic datums
Test Purpose: To verify that the application allows correct definition of a user-defined geodetic datum, using both
user-defined data and predefined components.
Test Process: • Create user-defined geodetic datum for each of several different datums, using parameters in
fields 0-5
• Source of parameters is both user-defined and predefined (library), see field 1
• If the application uses early-binding then refer to early binding tfm code in field 6 and see test
3208 for details.
Test Data: GIGS_user_3204_GeodeticDatum
Expected Results: The application should accept the Test Data. The order in which the name and the meridian
Note: • A geodetic datum comprises its name, and the ellipsoid and prime meridian it uses. The detailed
geodetic definition of origin and orientation is not required.
• As most datums use the Greenwich prime meridian it is acceptable for this to be the default.
• Some applications may require that the datum definition includes a transformation to a standard
CRS, normally WGS 84. See Test Procedure 3208.
• Although the GIGS Test Dataset is static in nature (i.e., does not consider dynamic CRSs), due
to the alignment with the EPSG Dataset, GIGS datum A WGS 84 (6326) is defined as the World
Geodetic System 1984 ensemble which groups together successive realizations of the datum
as one. Depending on the specific configuration of an application it is recommended that the
latest realization is defined (G1762 at time of writing), but it is acceptable to construct either the
full ensemble or another specific realisation. The same applies to GIGS datum G, the European
Terrestrial Reference System 1989 ensemble.
39
Test Procedure: 3205 - User-defined geodetic CRSs
Test Purpose: To verify that the application allows correct definition of a user-defined geodetic CRS.
Test Process: • Create user-defined geodetic CRS for each of several different CRSs, using parameters in fields
0-5
• If the application uses early-binding then refer to early binding tfm code in field 8 and see test
3208 for details. Early-bound entities will be used in 5000 series tests.
Test Data: GIGS_user_3205_GeodeticCRS
Expected Results: The application should accept the Test Data. Test result will be pass or fail. If fail, details of failure
should be reported.
Note: • A geodetic CRS comprises its name, a geodetic datum and a coordinate system giving axes
names, order and units. EPSG characterizes subtypes of geodetic CRS – geographic and
geocentric (based on the coordinate system).
• Some applications may require that the datum definition includes a transformation to a standard
CRS, normally WGS 84. See Test Procedure 3007.
Test Procedure: 3206 - User-defined conversions
Test Purpose: To verify that the application allows correct definition of a user-defined conversion (map projection).
Test Process: • Create user-defined map projection for each of several different conversions, using parameters
in fields 0-27
• If the application can satisfactorily define projection code 65002, there is no requirement to
define 65021 or 65022. However if the application cannot create 65002 because it has a latitude
of origin not on the equator, report the fact and create both 65021 and 65022 instead. These are
needed for later tests.
• Note: The codes 65003 and 65020 and names GIGS conversion ‘3’, ‘20’, ‘21’ and ‘22’ are
deliberately missing from the sequence.
Test Data: GIGS_user_3206_Conversion
Expected Results: The application should accept the Test Data. The order in which the name and the conversion
Note: • Each conversion method requires specific parameters (see EPSG Dataset for details). All
parameters should be variables. Some applications hardwire the values of (some of) these
variables, e.g., scale factor must be 1.0, scale factor must be 0.9996, latitude of origin must be
0 degrees, etc. The data for this test have no “standard” values. Latitudes are positive north,
negative south; longitudes positive east, negative west. Several different map projections are to
be tested.
Test Procedure: 3207 - User-defined projected CRSs
Test Purpose: To verify that the application allows correct definition of a user-defined projected CRS.
Test Process: • Create user-defined projected CRS for each of several different CRS, using parameters in fields
0-15.
Test Data: GIGS_user_3207_ProjectedCRS.
Expected Results: The application should accept the Test Data. The order in which the name and the projection
40
Note: • A projected CRS comprises its name, a geodetic datum, a conversion (map projection) and a
coordinate system giving axes names, order and units.
• The coordinate system is defined within the projected CRS Test Data file; in the ISO/EPSG model
it is a separate entity.
• The projected CRS units may not be the same as those of its components.
• Some applications may require that the datum definition includes a transformation to a
standard CRS, normally WGS 84. This requirement may be inherited by projected CRSs. See Test
Procedures 3204 and 3208.
Test Procedure: 3208 - User-defined coordinate transformations
Test Purpose: To verify that the application allows correct definition of a user-defined coordinate transformation.
Test Process: • Create user-defined coordinate transformation for each of several different coordinate
transformation method, using parameters in fields 0-38
Test Data: GIGS_user_3208_CoordTfm.

• Additional files for grid-based transformations: GIGS_user_3208_CoordTfm_61004_N_SLOPE.LAS,
GIGS_user_3208_CoordTfm_61004_N_SLOPE.LOS, GIGS_user_3208_CoordTfm_61844_QUE27-98.gsb
Expected Results: The application should accept the Test Data. The order in which the name and the coordinate
transformation parameters are entered is not critical, although that given in the Test Dataset is
recommended. Test result will be pass or fail. If fail, details of failure should be reported.
Note: • Each coordinate transformation method requires specific parameters (see EPSG Dataset for
details). All parameters should be variables. Their units may vary. Several different coordinate
transformations are to be tested.
• Some applications may require that a datum definition includes a transformation to a standard
CRS, normally WGS 84. If this is the case treat this test as part of Test Procedure 3204 and report
the fact.
• Although every effort has been made to assign user-defined coordinate transformations with
a respective GIGS code (with a ‘6’ prefix), unfortunately due to restrictions of the 5 digits in the
6XXXX code range, where a coordinate transformation has an equivalent EPSG code of 5 digits,
it is not possible to assign an additional GIGS code. Therefore, some transformations (including
15929, 15788, 15934) have their respective EPSG code also as the GIGS code. In these cases, if
the software already has the EPSG version of the transformation loaded, then this can be used in
place of manually adding the transformation; otherwise, manually add the transformation with
the EPSG code specified. Report this event if it occurs.
• The 3200 series is designed to test the addition of user-defined geodetic data to an application.
To emulate user-defined data for the tests for NADCON and NTv2 methods which both use
parameter files the small test files (n_slope.las for NADCON, QUE27-98.gsb for NTv2), the
expectation is that they may not already be bundled with an application and therefore could be
used as Test Data. The data within the grid files are not used in any functionality calculations and
tests. This test is designed to evaluate whether user data may be inserted into the application.
• The data in the n_slope.las/n_slope.los files to be used for this test is a small subset of the data
in the alaska.las/alaska.los files to be used for Test Procedure 5206, and are mutually exclusive.
There is no relationship between the data in the QUE27-98.gsb file (covers Quebec) to be used for
this test and the data in the NTv2.gsb file for Canada to be used for Test Procedure 5207.
41
Test Procedure: 3209 - User-defined vertical datums
Test Purpose: To verify that the application allows correct definition of a user-defined vertical datum.
Test Process: • Create user-defined geodetic datum for each of several different datums, using parameters in
fields 0-2
• For datum origin refer to the EPSG Dataset (using Equivalent EPSG code)
Test Data: GIGS_user_3209_VerticalDatum
Expected Results: The application should accept the Test Data. The order in which the name and the components are
Note: • Some applications may require that the vertical datum definition includes a transformation to
a standard CRS, normally non-specified mean sea level. This requirement may be inherited by
vertical CRSs. See Test Procedure 3211.
Test Procedure: 3210 - User-defined vertical CRSs
Test Purpose: To verify that the application allows correct definition of a user-defined vertical CRS.
Test Process: • Create user-defined geodetic CRS for each of several different CRSs, using parameters in fields 0-7
• If application uses early-binding then refer to early binding tfm code in field 10 and see test 3208
for details.
Test Data: GIGS_user_3210_VerticalCRS.
Expected Results: The application should accept the Test Data. The order in which the name and the components are
Note: • A vertical CRS comprises its name, a vertical datum, a conversion (map projection) and a
coordinate system giving axes names, order and units.
• The vertical CRS units may not be the same as those of its components.
Test Procedure: 3211 - User-defined vertical coordinate transformations
Test Purpose: To verify that the application allows correct definition of a user-defined vertical coordinate
transformation.
Test Process: • Create user-defined coordinate transformation for each of several different transformation
methods, using parameters in fields 0-21
Test Data: GIGS_user_3211_VertTfm
Expected Results: The application should accept the Test Data. The order in which the name and the coordinate
transformation parameters are entered is not critical, although that given in the Test Dataset is
recommended. Test result will be pass or fail. If fail, details of failure should be reported.
Note: • Each coordinate transformation method requires specific parameters (see EPSG Dataset for
details). All parameters should be variables. Their units may vary. Several different coordinate
transformations are to be tested.
• Some applications may require that a datum definition includes a transformation to a standard
vertical datum, normally (non-specific) mean sea level. If this is the case treat this test as part of
Test Procedure 3209 and report the fact.
42
Test Procedure: 3212 - User-defined concatenated coordinate transformation
Test Purpose: To verify that the application allows correct definition of a user-defined concatenated coordinate
transformation.
Test Process: • Create user-defined concatenated coordinate transformation for each of several different
transformations, using parameters in fields 0-9
Test Data: GIGS_user_3212_ConcatTfm
Expected Results: The application should accept the Test Data. The order in which the steps of the concatenated
coordinate transformation are entered is not critical as long as the step number is correct,
although that given in the Test Dataset is recommended. Test result will be pass or fail. If fail,
details of failure should be reported.
Note: • The concatenated coordinate transformations in the Test Procedure use steps constructed
during Test Procedure 3208.
• The reversing of source and target CRSs in individual steps is not tested
2.11.3 5100 Conversion Test Procedures

The Test Procedures in this series are designed to evaluate the software’s accuracy in
performing conversions (map projections). A number of conversion methods commonly
used in the energy industry are tested using realistic coordinate values (see Appendix E).
The conversion method names follow those in the EPSG Dataset. If the software does not
follow this recommended method naming, see the individual Test Procedure descriptions
that follow for tips for some common alternative names for the same method. Test
Procedures for which the method is not supported by the software should be reported as
such in the Test, and the Test Data excluded from the testing process.
Software is not required to use the formulae published by EPSG, but its algorithms are
expected to give results which are not significantly different (see individual test tolerances)
to those using the EPSG formulae.
The Test Data for this series comprises input and output files with each test point on a
separate row in the data array. Points to be input for the forward and reverse calculations
are generally interleaved in adjacent rows. The general process is to load the input file;
convert the latitude/longitude referenced to a geogCRS to a projCRS; convert easting/
northing referenced to a projCRS to a geogCRS; compare the results with the values in the
output file data array. All points in the input file should be tested in the direction dictated
by the input fields. Round trip calculations from the converted coordinates back to the
original should also be tested for the point or points indicated in the input file, with the final
coordinates compared with the starting values.
The CRS to which input and output coordinates are referenced is given in the file headers
(see series 3000 data for associated parameters). The use of special GIGS geodetic entities
created in the Series 3000 tests is deliberate. Should software fail the Series 3000 tests and
have passed the Series 2000 tests it should still be possible to run this series of tests.
In some cases there may be multiple CRSs to be tested for one Test Procedure (or subtly
different algorithms), in these cases the files are split into multiple parts.
43
Coordinates of test points are given in the order and units that are described in the CRS
definition. Latitude and longitude are given in decimal degree (or grads) representation,
Decimal degree values for latitude are positive for the northern hemisphere, negative for
the southern hemisphere, and values for longitude are positive for the eastern hemisphere,
negative for the western hemisphere.
Each set of Test Data comprises a small number of points, mostly laid out in two
perpendicular transects. These transects avoid the system origin. When considered
appropriate, additional points or transects have been added. The test points are divided into
multiple subsets and data for testing both forward and reverse cases have been generated.
The tests investigate computational behaviour of the method within and slightly beyond the
reasonable area of use. In general, possible failure points at “difficult” locations, such as
a geographic pole, have not been included. Test points have not been extended well away
from a practical and reasonable “area of use”.
The Test Datasets are not exhaustive. Developers are expected to augment the data to test
frequently encountered failure conditions (boundary conditions, etc). Precision of Test Data
is further described in Section 2.5.
The Test Procedures in the 5100 series are designed for the conversion of individual points.
If the software does not have the functionality to allow this it may be necessary to first
create a project for each Test Procedure and to load the test points as if they were the
locations of geoscience data. In this case, the project CRS should be that of the projected
CRS defined in the Test Procedure.
Test Procedure: 5101 - Transverse Mercator conversions
Test Purpose: To verify that conversions for the Transverse Mercator map projection method are consistent with
EPSG.
Test Process: • Invoke coordinate conversions in both directions and inspect results, for all parts
• For the first test point in part 1, perform iterations of forward and reverse computations using the
output of computation n as input into computation n+1, until the output coordinate values exceed
more than 0.006m (6mm) or 0.00000006° from the original calculated values (but no more than
1000 iterations).
Test Data: GIGS_conv_5101_TM_input_part[x]. This data includes forward and reverse calculations. The Test
Data is in four parts, one for each hemisphere quadrant, as well as separate files for JHS/USGS
calculation formulae. Because of the importance of the Transverse Mercator projection method,
this test is more extensive than for other methods.
Expected Results: • Results for the forward and reverse calculations should agree to within 0.03m (30mm) or
0.0000003° of the Test Data. See file GIGS_conv_5101_TM_output_part[x].
• For the round trip calculation the initial calculated coordinates of the point should change by less
than 0.006m (6mm) or 0.00000006° (before 1000 iterations).
• Test result will be pass or fail. If fail, details of failure should be reported.
Note: EPSG considers this method includes Gauss-Boaga and Gauss-Kruger (with all five TM parameters
as variables and suitable parameter values). If the application allows these methods they should be
included in this Test Procedure.
EPSG publishes two sets of formulae for the TM method. USGS formulae are known to break
down for points more than 4° from the central meridian (longitude of origin). The JHS formulae
are robust to at least 30° and although use of the projection is not recommended this far from the
central meridian, the JHS formulae are preferred. Results from both formulae are included in the
Test Data.
44
Test Procedure: 5102 - Lambert Conic Conformal (1SP20) conversions
Test Purpose: To verify that conversions for the Lambert Conic Conformal (1SP) map projection method are
consistent with EPSG.
more than 0.006m (6mm) or 0.00000006 grad from the original calculated values (but no more
than 1000 iterations).
Test Data: GIGS_conv_5102_LCC1_input_part[x]. This data includes forward and reverse calculations. The Test
Data is in two parts.
Expected Results: • Results for the forward and reverse calculations should agree to within 0.03m (30mm) or
0.0000003 grad of the Test Data. See file GIGS_conv_5102_LCC1_output_part[x].
than 0.006m (6mm) or 0.00000006 grad (before 1000 iterations).
Note:
Test Procedure: 5103 - Lambert Conic Conformal (2SP21) conversions
Test Purpose: To verify that conversions for the Lambert Conic Conformal (2SP) map projection method are
more than 0.02 ftUS/ft (0.24in) or 0.00000006° from the original calculated values (but no more
than 1000 iterations).
Test Data: GIGS_conv_5103_LCC2_input_part[x]. This data includes forward and reverse calculations. The Test
Data is in three parts, in which the grid coordinates are in different units.
Expected Results: • Results should agree to within 0.1 ftUS/ft (1.2in) or 0.0000003° of the Test Data.
See file GIGS_conv_5103_LCC2_output_part[x], worksheet 5103 LCC2.
than 0.02 ftUS/ft (or 0.24in) 0.00000006° (before 1000 iterations).
Note:
Test Procedure: 5104 - Oblique Stereographic conversions
Test Purpose: To verify that conversions for the Oblique Stereographic map projection method are consistent with
EPSG.
Test Process: • Invoke coordinate conversions in both directions and inspect results.
• For the last test point, perform iterations of forward and reverse computations using the output
of computation n as input into computation n+1, until the output coordinate values exceed more
than 0.006m (6mm) or 0.00000006° from the original calculated values (but no more than 1000
iterations).
Test Data: GIGS_conv_5104_OblStereo_input. This data includes forward and reverse calculations.
1SP means one standard parallel is used in the conversion definition.

20
2SP means two standard parallels are used in the conversion definition.
21
45
Expected Results: • Results should agree to within 0.05m (50mm) or 0.0000006° of the Test Data.
See file GIGS_conv_5104_OblStereo_output.
Note: There are two significantly different approaches to the handling of the ellipsoidal development
of this map projection method. These are often not clearly distinguished through the method
name. These give significantly different results at locations away from the projection origin and
should be considered to be different methods. In some applications the method is called ‘Double
Stereographic’ equates to the EPSG Oblique Stereographic method.
Test Procedure: 5105 - Hotine Oblique Mercator (variant B) conversions
Test Purpose: To verify that conversions for the Hotine Oblique Mercator (variant B) map projection method are
1000 iterations).
Test Data: GIGS_conv_5105_HOM-B_input_part[x]. This data includes forward and reverse calculations. This test
is in two parts, testing oblique and 90° scenarios for the azimuth of the projection initial line. (The
latter is a known problem area in some applications).
See file GIGS_conv_5105_HOM-B_output_part[x].
Note: Applications may define the map projection in different ways. One variation is in the location at
which false grid coordinates are applied. EPSG caters for two alternatives and considers these to
be different methods – see Test Procedure 5106 below. Another variation involves how the initial
line is defined. EPSG requires an azimuth value. An alternative approach is to define this azimuth
through the coordinates of two points; this approach is not catered for by EPSG.
Test Procedure: 5106 - Hotine Oblique Mercator (variant A) conversions
Test Purpose: To verify that conversions for the Hotine Oblique Mercator (variant A) map projection method are
Test Process: • Invoke coordinate conversions in both directions and inspect results
iterations).
Test Data: GIGS_conv_5106_HOM-A_input. This data includes forward and reverse calculations.
See file GIGS_conv_5106_HOM-A_output.
Note: Applications may define the map projection in different ways. One variation is in the location at
which false grid coordinates are applied. EPSG caters for two alternatives and considers these to be
different methods – see Test Procedure 5105 above. Another variation involves the means by which
the initial line is defined. EPSG requires an azimuth value. An alternative approach is to define this
azimuth through the coordinates of two points; this approach is not catered for by EPSG.
46
Test Procedure: 5107 - American Polyconic conversions
Test Purpose: To verify that conversions for the American Polyconic map projection method are consistent with
EPSG.
iterations).
Test Data: GIGS_conv_5107_AmPolyC_input. This data includes forward and reverse calculations.
See file GIGS_conv_5107_AmPolyC_output.
Note: There are numerous polyconic methods available in the literature giving significantly different
results. The method name “polyconic” therefore is ambiguous.
Test Procedure: 5108 - Cassini-Soldner conversions
Test Purpose: To verify that conversions for the Cassini-Soldner map projection method are consistent with EPSG.
iterations).
Test Data: GIGS_conv_5108_Cass_input. This data includes forward and reverse calculations.
See file GIGS_conv_5108_Cass_output.
Note: Method may be called “Cassini”.
Test Procedure: 5109 - Albers Equal Area conversions
Test Purpose: To verify that conversions for the Albers Equal Area map projection method are consistent with EPSG.
iterations).
Test Data: GIGS_conv_5109_Albers_input. This data includes forward and reverse calculations.
See file GIGS_conv_5109_Albers_output.
Note: Method may be called “Albers”.
47
Test Procedure: 5110 - Lambert Azimuthal Equal Area conversions
Test Purpose: To verify that conversions for the Lambert Azimuthal Equal Area map projection method are
iterations).
Test Data: GIGS_conv_5110_LAEA_input. This data includes forward and reverse calculations.
See file GIGS_conv_5110_LAEA_output.
Note: Method may be called “LAEA”.
Test Procedure: 5111 - Mercator (variant A) conversions
Test Purpose: To verify that conversions for the Mercator (variant A) map projection method are consistent with
EPSG.
1000 iterations).
Test Data: GIGS_conv_5111_MercA_input_part[x]. This data includes forward and reverse calculations. The test
is in two parts, one using a geographic CRS based on the Greenwich meridian, the other using a
non-Greenwich CRS.
See file GIGS_conv_5111_MercA_output_part[x].
Note: • Method may be called Mercator (1SP).

• Part 2 uses a non-Greenwich prime meridian. Applications may not handle CRSs using a prime
meridian other than (by default) Greenwich. Should this be the case, this failure should be
documented.
Test Procedure: 5112 - Mercator (variant B) conversions
Test Purpose: To verify that conversions for the Mercator (variant B) map projection method are consistent with
EPSG.
iterations).
Test Data: GIGS_conv_5112_MercB_input. This data includes forward and reverse calculations
48
See file GIGS_conv_5112_MercB_output.
Note: • In EPSG literature prior to 2010 this method was previously called “Mercator (2SP)”. However this
name is ambiguous. See EPSG Guidance Note 7 part 2 October 2010 or later revision for further
information on the variants of the Mercator method.
• Applications may support variant C rather than this variant B. Should that be the case the test
may be run using a value of 0.0 for the “latitude of origin” defining parameter.
Test Procedure: 5113 - Transverse Mercator (South Orientated) conversions
Test Purpose: To verify that conversions for the Transverse Mercator (South Orientated) map projection method
are consistent with EPSG.
iterations).
Test Data: GIGS_conv_5113_TMSO_input. This data includes forward and reverse calculations.
See file GIGS_conv_5113_TMSO_output.
Note:
2.11.4 5200 Coordinate Transformation Test Procedures

The Test Procedures in this series are designed to evaluate the software’s accuracy in
performing coordinate transformations. Several transformation methods commonly used in
the energy industry are tested, using realistic coordinate values (see Appendix E).
The transformation method names follow those in the EPSG Dataset. If the software
does not follow this recommended method naming, see the individual Test Procedure
descriptions that follow for tips for some common alternative names for the same method.
Test Procedures for which the method is not supported by the software should be reported
as such in the Test, and the Test Data excluded from the testing process.
Software is not required to use the formulae published by EPSG, but its algorithms are
expected to give results which are not significantly different (see individual test tolerances)
to those using the EPSG formulae.
The Test Data for this series comprises input and output files with each test point on a
separate row in the data array. Points to be input for the forward and reverse calculations
are generally interleaved in adjacent rows. The general process is to load the input
file; transform coordinates from geogCRS 1 to geogCRS 2; transform the coordinates
referenced to geogCRS 2 to geogCRS 1; compare the results with the values in the output
file data array. All points in the input file should be tested in the direction dictated by the
49
input fields. Round trip calculations from the transformed coordinates back to the original
should also be tested for the point or points indicated in the input file, with final coordinates
compared with the starting values.
The CRSs to which input and output coordinates are referenced are given in the file headers
In some cases there may be multiple CRSs (usually 2D and 3D versions) to be tested for
one Test Procedure (or subtly different algorithms). In this case the files are split into
multiple parts.
Coordinates of test points are given in the order and units that are described in the CRS
definition. Latitude and longitude are given in decimal degree (or grads) representation,
Decimal degree values for latitude are positive for the northern hemisphere, negative for
the southern hemisphere, and values for longitude are positive for the eastern hemisphere,
negative for the western hemisphere. Note: So-called “early binding” software will require
the transformation to be defined as part of a CRS definition. The necessary transformations
are given in Series 3000 Test Procedures 3007 (horizontal) and 3009 (vertical).
Each set of Test Data comprises a small number of points, mostly laid out in two
perpendicular transects. These transects avoid the system origin. When considered
appropriate, additional points or transects have been added. The test points are divided into
multiple subsets and data for testing both forward and reverse cases have been generated.
The tests investigate computational behaviour of the method within and slightly beyond the
reasonable area of use. In general, possible failure points at “difficult” locations such as
a geographic pole, have not been included. The test points have been extended well away
from a practical and reasonable “area of use”.
The Test Datasets are not exhaustive. Developers are expected to augment the data to test
frequently encountered failure conditions (boundary conditions, etc). Precision of Test Data
is further described in Section 2.5.
The Test Procedures in the 5200 series are designed for the transformation of individual
points. If the software does not have the functionality to allow this, it may be necessary to
first create a project for each Test Procedure and to load the test points as if they were the
locations of geoscience data. In this case, the project CRS could be either the source CRS
or the target CRS defined in the Test Procedure.
Furthermore, the Test Datasets are designed to test methods individually. This configuration
does not test software behaviour for the selection of coordinate transformation method
when several methods are available, for example in Australia where low, medium and high
accuracy variants are promoted using 3-parameter geocentric translation, 7-parameter
coordinate frame and NTv2 methods respectively. Software might not allow a User to
override the use of a higher accuracy method with a coordinate transformation using a
lower accuracy method. This should be investigated without a specific Test Data set.
50
Figure 5: GIGS tests for NTv2 and NADCON methods in relation to grid coverage.
Test Procedure: 5201 - Geographic/geocentric conversions
Test Purpose: To verify that conversions for the geographic/geocentric method are consistent with EPSG method
9602 (Geographic/geocentric conversions).
Test Process: • Invoke coordinate conversions in both directions and inspect results.
• For the first and last test point, perform iterations of forward and reverse computations using the
1000 iterations).
Test Data: GIGS_tfm_5201_GeogGeocen_input. This data includes forward and reverse calculations.
See file GIGS_tfm_5201_GeogGeocen_output.
Note: • Although technically a conversion, this method is most likely to be applicable only in applications
which can handle transformations and is therefore treated in this section.
• Applications may not handle geocentric Cartesian coordinates. Should this be the case, then this
test cannot be conducted. The reason for failure should be stated.
• The same test point input coordinates are used as input in Test Procedures 5201, 5203-5205 and
5211-5213. Output coordinates differ due to the different CRSs and transformations used in these
tests.
51
Test Procedure: 5203 - Position Vector (geographic domain) transformations
Test Purpose: To verify that transformations for the Position Vector 7-parameter transformation method (which
operate both ‘from’ and ‘to’ geographic coordinates) are consistent with EPSG methods. Either the
Position Vector transformation (geog2D domain), method 9606 or Position Vector transformation
(geog3D domain) method 1037 is acceptable.
Test Process: • Invoke GIGS transformation “GIGS geogCRS B to GIGS geogCRS A (2)”, GIGS code 61314 in both
directions and inspect results, for all parts.
• For the first test point in part 1 and part 2, perform iterations of forward and reverse
computations using the output of computation n as input into computation n+1, until the output
coordinate values exceed more than 0.006m (6mm) or 0.00000006° from the original calculated
values (but no more than 1000 iterations).
Test Data: GIGS_tfm_5203_PosVec_input_part[x]. This data includes forward and reverse calculations. The Test
See file GIGS_tfm_5203_PosVec_output_part[x].
• Some applications ignore ellipsoidal heights during these transformations (or set the input
ellipsoidal heights to zero). If that is the case, results will match the results as shown for
the geog2D case, EPSG method 9606. Horizontal coordinates obtained for those points with
ellipsoidal heights significantly different from zero will be incorrect, whereas correct results may
be generated for points with zero (or near zero) ellipsoidal heights. For large ellipsoidal heights
(either positive or negative), the correct results are given by the geog3D EPSG method 1037.
Results that are a match should be clearly documented in the report on the test results.
Note: • If the application does not appear to support this method but has one called “Helmert
7-parameter” or “Bursa Wolf”, this may be an equivalent method.
• In practice coordinate transformation parameters are defined using a variety of units. The Test
Data includes coordinate transformations of interest to the industry using different units of
measure.
5211-5213. Output coordinates differ due to the different CRSs and coordinate transformations in
these tests.
Test Procedure: 5204 - Coordinate Frame Rotation (geographic 2D domain) transformations
Test Purpose: To verify that transformations for the Coordinate Frame Rotation method (which operate both ‘from’
and ‘to’ geographic 2D coordinates) are consistent with EPSG methods. Either the Coordinate
Frame Rotation (geog2D domain), method 9607 or Coordinate Frame Rotation (geog3D domain)
method 1038 is acceptable.
Test Process: • Invoke GIGS transformation “GIGS geogCRS E to GIGS geogCRS A (2)”, GIGS code 15929 in both
coordinate values exceed more than 0.006m (6mm) or 0.00000006° from the original calculated
values (but no more than 1000 iterations).
Test Data: GIGS_tfm_5204_CoordFrame_input_part[x]. This data includes forward and reverse calculations. The
Test Data is in two parts.
52
See file GIGS_tfm_5204_CoordFrame_output_part[x].
Note: • There are two opposing sign conventions for the rotations in 7-parameter geocentric
transformations. EPSG distinguishes these as two discrete methods; see also Test Procedure
5203 above. Applications may use only one of these conventions within its coordinate
transformation engine, but it is expected that it will accept coordinate transformation definitions
for both methods and make the necessary adjustments internally. Should the application fail to
make these adjustments the output will be incorrect.
• If the application does not appear to support this method but has one called “Helmert
7-parameter” or “Bursa Wolf”, this may an equivalent method.
these tests.
Test Procedure: 5205 - Molodensky-Badekas (geographic 2D domain) transformations
Test Purpose: To verify whether transformations for the Molodensky-Badekas method (which operate f both ‘from’
and ‘to’ geographic 2D coordinates) are consistent with EPSG methods. Either the Molodensky-
Badekas (geog2D domain), method 9636 or Molodensky-Badekas (geog3D domain) method 1039 is
acceptable.
Test Process: • Invoke GIGS transformation “GIGS geogCRS C to GIGS geogCRS A (3)”, GIGS code 61003 in both
coordinate values exceed more than 0.00000006° from the original calculated values (but no
more than 1000 iterations).
Test Data: GIGS_tfm_5205_MolBad_input_part[x]. This data includes forward and reverse calculations. The Test
See file GIGS_tfm_5205_MolBad_output_part[x].
Note: • See Test Procedure 5212 for a similar test operating between geocentric coordinates.
these tests.
53
Test Procedure: 5206 - NADCON transformations
Test Purpose: To verify that coordinate transformations for the NADCON method are consistent with EPSG
method 9613.
Test Process: • Invoke respective grid-based transformations in both directions and inspect results, for either
part 1 or part 2 and part 3.
• This test uses two pairs of binary gridded data files [Alaska.las Alaska.los; Conus.las Conus.
los]. It is assumed that these files are included in the application being tested. If necessary, the
gridded data files may be downloaded from NGS. The equivalent EPSG transformation names
are: NAD27 to NAD83 (2) (code 1243) and NAD27 to NAD83 (1) (code 1241).
• For the first test point perform iterations of forward and reverse computations using the output
than 0.00000006° from the original calculated values (but no more than 1000 iterations).
Test Data: GIGS_tfm_5206_Nadcon_input_part[x]. This data includes forward and reverse calculations. The Test
Data is in either one or two parts, if application requires early-binding use parts 2 and 3 only, part 1
is for all other applications.
See file GIGS_tfm_5206_Nadcon_output.
Note: • This method uses a ‘longitude positive to the west’ convention. This should be handled internally
within the application, as the EPSG and ISO convention of longitudes positive east should be
presented to Users.
• In North America there is an overlap in NADCON and NTv2 grid coverage. For applications
incorporating both methods, the results in the area of overlap should be checked. Some of the
test points are in the overlap areas and are common with those in Test Procedure 5207. See
Figure 5 above. The expectation is that NADCON grids are used within the USA and NTv2 grids
are used within Canada.
• The 5200 series is designed to test the transformation functionality of an application. Any
similarities in the grid-based transformations required by those defined in Test Procedure 3208
is coincidental, and not related. As it happens, the source and target CRSs for the NADCON tests
are the same, but Test Procedures 5206 (and 5207) are not dependent upon the results of other
tests, they stand on their own. Test Procedure 5206 requires two pairs of NADCON files, conus.
las/conus.los and alaska.las/alaska.los. The file to be used is determined by the latitude and
longitude of each test point. If the application being tested does not have these grids bundled
within it, they will need to be obtained from the National Geodetic Survey.
Test Procedure: 5207 - NTv2 transformations
Test Purpose: To verify that coordinate transformations for the NTv2 method are consistent with EPSG method 9615.
Test Process: • Invoke respective grid-based transformations in both directions and inspect results, for both parts
• This test uses gridded data files [A66 National (13.09.01).gsb for Australia and NTv2.gsb for
Canada]. It is assumed that these files are included in the application being tested. If necessary,
the gridded data file for Australia may be downloaded from ICSM and for Canada from NRCAN.
Equivalent EPSG transformation names and codes: AGD66 to GDA94 (11) (code 1803); NAD27 to
NAD83 (4) (code 1313).
• For the first test point in part 1 and part 2 perform iterations of forward and reverse
coordinate values exceed more than 0.00000006° from the original calculated values (but no
more than 1000 iterations).
Test Data: GIGS_tfm_5207_NTv2_input_part[x]. This data includes forward and reverse calculations. The Test
54
See file GIGS_tfm_5207_NTv2_output_part[x].
Note: • This method uses a ‘longitude positive to the west’ convention. This should be handled internally
within the application, as the EPSG and ISO convention of longitudes positive east should be
presented to users.
• In North America there is an overlap in NADCON and NTv2 grid coverage. For applications
incorporating both methods the results in the area of overlap should be checked. Some of the
test points are in the overlap areas and common with those in Test Procedure 5206. See figure 1
above. Results should be compared. The expectation is that NADCON grids are used within the
USA and NTv2 grids are used within Canada.
• Some applications support this method only for Canada. However, the NTv2 transformation method
is actively used in many countries outside of Canada (where it originated). For example, official
NTv2 coordinate transformations exist for Australia, New Zealand, France, Spain and Germany.
• An issue has been reported with the implementation of NTv2 grids in Australia in some
applications. The problem points appear to fall on certain parallels and meridians, such as
8.55°S and 138.05°E, which match edge points or corner points of the Australian NTv2 sub grids.
Points to test the 138.05°E meridian have been included. The parallel of 8.55°S, however, fell
outside the Australian online converter used for generating the Test Dataset. The included task
should suffice since failure at the selected meridian 138.05°E test points will also imply failure at
the other problematic sub grid junction points.
Test Procedure: 5208 - Longitude rotation
Test Purpose: To verify that transformations for the Longitude Rotation method are consistent with EPSG method
9601.
Test Process: • Invoke GIGS transformation “GIGS geogCRS H to GIGS geogCRS T (1)”, GIGS code 61763 in both
directions and inspect results
Test Data: GIGS_tfm_5208_LonRot_input. This data includes forward and reverse calculations.
Expected Results: • Results should agree to within 0.03m (30mm) or 0.0000003 grad (dependent on latitude) of the
Test Data. See file GIGS_tfm_5208_LonRot_output.
than 0.006m (6mm) or 0.00000006 grad (before 1000 iterations).
Note: Applications may not handle CRSs using a prime meridian other than Greenwich (by default). This
should be considered a failure for this method.
55
Test Procedure: 5209 - Bin grid transformation
Test Purpose: To verify that transformations for the P6 seismic bin grid affine method are consistent with EPSG
method 9666
Test Process: • Define bin grid in application using parameters in ASCII file, or P6 file used in Test Procedure 5403
• Invoke coordinate operation in both directions and inspect results
than 0.006m (6mm) from the original calculated values (before 1000 iterations).
• This test uses the following Bin Grid definition:
– Projected CRS name: GIGS projCRS A1 (WGS 84 / UTM zone 31N)
– CRS code: GIGS:62001 (EPSG:32631)
– Orientation (deg) = 20
– Bin width I (map grid units) = 25.00
– Bin width J (map grid units) = 12.50
– Increment I = 2.00
– Increment J = 2.00
– Scale factor = 1
– Origin - E = 414188.460
– Origin - N = 5761775.889
– Origin - I = 1
– Origin - J = 10000
Test Data: GIGS_tfm_5209_BinGrid_input. This data includes forward and reverse calculations.
See file GIGS_tfm_5209_BinGrid_output.
Note: • If the application does not handle P6 bin grid data, this Test Procedure should be documented as
non-applicable.
• This Test Procedure is referenced in 5400 (3D Seismic Data) although it has a 52XX code.
This is because the original Test Data was being developed specifically for manual bin grid
transformations, but was then supplemented in later GIGS revisions to incorporate the P6 file.
Test Procedure: 5210 - Vertical offset
Test Purpose: To verify that transformations for the vertical offset method are consistent with EPSG method 9616.
Test Process: • Invoke GIGS vertical transformations “GIGS vertCRS W1 height/depth to GIGS vertCRS V1 height/
depth”, GIGS codes 65400, 65438, 65440 and 65441, in both directions
• The order of transformations is discretionary, but the following is recommended:
– transform height referenced to “GIGS vertCRS W1” into depth referenced to “GIGS vertCRS W1”.
– transform height referenced to “GIGS vertCRS W1” into height referenced to “GIGS vertCRS V1”.
– transform height referenced to “GIGS vertCRS W1” into depth referenced to “GIGS vertCRS V1”.
– transform depth referenced to “GIGS vertCRS W1” into height referenced to “GIGS vertCRS W1”.
– transform depth referenced to “GIGS vertCRS W1” into height referenced to “GIGS vertCRS V1”.
– transform depth referenced to “GIGS vertCRS W1” into depth referenced to “GIGS vertCRS V1”.
– transform height referenced to “GIGS vertCRS V1” into height referenced to “GIGS vertCRS W1”.
– transform height referenced to “GIGS vertCRS V1” into depth referenced to “GIGS vertCRS W1”.
– transform height referenced to “GIGS vertCRS V1” into depth referenced to “GIGS vertCRS V1”.
– transform depth referenced to “GIGS vertCRS V1” into height referenced to “GIGS vertCRS W1”.
– transform depth referenced to “GIGS vertCRS V1” into depth referenced to “GIGS vertCRS W1”.
– transform depth referenced to “GIGS vertCRS V1” into height referenced to “GIGS vertCRS V1”.
56
Test Data: GIGS_tfm_5210_VertOff_input. This data includes forward and reverse calculations using GIGS
vertical datums V and W, that is, vertCRSs V1 height, V1 depth, W1 height and W1 depth.
See file GIGS_tfm_5210_VertOff_output.
Note: • Applications may not handle both heights and depths simultaneously with correct signage (which
should be reported).
• Due to file format structure, this Test Data cannot be consumed in P1/11 subclass format, only
use the ASCII files for this Test Procedure
Test Procedure: 5211 - Geocentric translations (geocentric domain) transformations
Test Purpose: To verify whether coordinate transformations for the geocentric translation method, which operate
‘from’ and ‘to’ geocentric Cartesian coordinates, are consistent with EPSG transformation method
1031.
directions and inspect results.
Test Data: GIGS_tfm_5211_3trnslt_Geocen_input. This data includes forward and reverse calculations.
See file GIGS_tfm_5211_3trnslt_Geocen_output.
Note: • Applications may not handle geocentric Cartesian coordinates. Should this be the case, then this
test cannot be conducted. The reason for failure should be stated.
• See Test Procedures 5212 and 5213 for similar tests operating between geographic 2D CRSs and
geographic 3D CRSs respectively.
5211-5213.
Test Procedure: 5212 - Geocentric translations (geographic 3D domain) transformations.
Test Purpose: To verify whether coordinate transformations for the Geocentric Translation method which operate
‘from’ and ‘to’ geographic 3D coordinate reference systems are consistent with EPSG method 1035.
than 0.006m (6mm) or 0.00000006° in horizontal and vertical from the original calculated values
(before 1000 iterations).
Test Data: GIGS_tfm_5212_3trnslt_Geog3D_input. This data includes forward and reverse calculations.
57
Expected Results: • Results should agree to within 0.03m (30mm) or 0.0000003° horizontal and 0.01m (10mm)
0.00000009° vertical of the Test Data. See files GIGS_tfm_5212_3trnslt_Geog3D_output_AbrMol
or GIGS_tfm_5212_3trnslt_Geog3D_output_EPSGconcat. These two sets use alternative methods,
both of which are valid for the transformation of geographic 3D CRSs. Report which of the
coordinate transformation methods the application is using.
than 0.006m (6mm) or 0.00000006° in horizontal and vertical (before 1000 iterations).
• Some applications ignore the ellipsoidal heights during these transformations (or set the input
ellipsoidal heights to zero). If that is the case, horizontal coordinates obtained for those points
with ellipsoidal heights significantly different from zero will be incorrect, whereas correct results
may be generated for points with zero (or near zero) ellipsoidal heights. For large ellipsoidal
heights (either positive or negative), the correct results are given by the geog3D EPSG method
1035. Results that match should be clearly documented in the report on the test results. To assist
this evaluation, the results file includes data generated using the Abridged Molodensky method.
Note: • See Test Procedures 5211 and 5213 for similar tests operating between geocentric CRSs and
5211-5213. In general output coordinates differ due to the different CRSs and transformations in
these tests. The intermediate geocentric coordinates obtained performing this method, however,
are used as both input and output coordinates for Test Procedure 5211 above.
Test Procedure: 5213 - Geocentric translations (geographic 2D domain) transformations.
Test Purpose: To verify whether coordinate transformations for the geocentric translation method which operate
‘from’ and ‘to’ geographic 2D coordinate reference systems are consistent with EPSG methods.
Either EPSG method 9603 geocentric translation (geog2D domain), or method 9605 Abridged
Molodensky, is acceptable.
Test Data: GIGS_tfm_5213_3trnslt_Geog2D_input. This data includes forward and reverse calculations.
Expected Results: • One of two possible sets of results should agree to within 0.03m (30mm) or 0.0000003° of the
Test Data. See file GIGS_tfm_5213_3trnslt_Geog2D_output_AbrMol or GIGS_tfm_5213_3trnslt_
Geog2D_output_EPSGconcat. These two sets use alternative methods, both of which are valid
for the transformation of geographic 2D CRSs. Report which of the coordinate transformation
methods the application is using.
Note: • See Test Procedures 5211 and 5213 for similar tests operating between geocentric CRSs and
• This test uses a subset of the points used as input into Test Procedures 5201, 5203-5205 and 5212.
58
2.11.5 5300 2D Seismic Test Procedures

The Test Procedures for seismic position data in Series 5300 (2D seismic) require loading
and unloading of Test Data to a software ‘project’. Projects are required to be referenced
to specific coordinate reference systems as defined in the Test Procedures below. See
Appendix D for an explanation of the project naming and see the user-defined library Series
3000 for the definitions of the CRSs. The projects are also used for the Series 5400 3D
Seismic and Series 5500 wells tests.
The majority of tests use a project area in the southwestern part of the North Sea. This
area was chosen because it is within the extended reach of surrounding countries in which
CRSs using several important conversion and transformation methods are found. However,
to use the Test Data agnostically in software that may have predefined implementations of
“real world” CRS which happen to be applicable to the project area, a fictitious CRS (WGS
84 / British National Grid) was chosen as the target CRS for data, ensuring that all software
are using the same objective CRS. To test geodetic data from elsewhere in the world, other
fictitious systems such as one using US Survey Feet are applied to this setting.
The tests in this section use hypothetical seismic line position data. The input Test Dataset
files for these tests are synthetic P1/11 or P1/90 format text files, for which an equivalent
ASCII file is also provided for software that cannot handle the P1-format. The output files
are either in ASCII format or both P1 and ASCII, depending on the nature of the test. The
entire Test Series should be repeated for each data exchange format supported, and the
results reported for any differences between the different formats.
The Test Data for this series comprises input and output files with each test point
(representing a shotpoint) on a separate row in the data array. The general process is to
load the input file and transform/convert coordinates referenced from geogCRS 1/projCRS
1 to geogCRS 2/projCRS 2, then compare the results with the values in the output file data
array. The seismic 2D position data have been designed so that if converted or transformed
correctly the seismic lines will intersect.
The CRS to which input and output coordinates are referenced are given file headers (see
series 3000 data for associated parameters). The use of special GIGS geodetic entities
created in the Series 3000 Test Procedures is deliberate. Should software fail the Series
3000 tests, but have passed the Series 2000 tests it should still be possible to run this
series of Test Procedures.
In some cases, multiple CRSs are tested for one Test Procedure (or subtly different
algorithms). In this case the files are split into multiple parts.
The GIGS Test Dataset currently provides both P1/11 and P1/90 format options, but
Evaluators may wish to repeat the following Test Procedures using other 2D seismic
position data exchange formats that they consider important. SEG-Y files are not provided,
and if required should be generated by Evaluators, based on ASCII files. If the application
supports more than one exchange format (including different P1 vintages), then each
Test Procedure should be repeated for all supported formats and the results individually
reported for each test.
59
Test Procedure: 5306 - Import 2D seismic position data with conversion (map projection) change (1)
Test Purpose: To verify that the application correctly loads horizontal locations from a P1-format file (or ASCII
equivalent) with traditional “full definition” CRS records when a change of map projection is
required.
Test Process: • Load data from test input file to project GIGS_project_A2V1depth.
• Verify coordinates in project GIGS_project_A2V1depth against expected results.
Test Data: GIGS_seis2D_5306_input_part[x]. The Test Data is in two parts, one for onshore, the other for
offshore. The onshore data includes height rather than depth.
Expected Results: • The application recognises P1 (or ASCII) file CRS definition, converts P1 (or ASCII) file horizontal
coordinates and stores correct horizontal locations. Results should agree to within 0.03m
(30mm) or 0.0000003° of the Test Data. See file GIGS_seis2D_5306_output.
• The application stores an audit trail of CRS actions.
Note: • This test involves a change of horizontal CRS from the input CRS defined in the input file to the
project CRS. The test output file assumes that the application applies a coordinate change and
then stores coordinates in the output CRS to which the project is referenced.
• The application should retain an audit trail of coordinate change actions. See Series 6000 tests.
• The P1-format file requires both geographic and grid coordinates. To verify that the application
is handling grid coordinates, the geographic coordinates in the test file have been set to zero and
therefore if used by the Evaluator, should cause the seismic position data to appear outside of
the project area.
• The input file part 1 includes vertical coordinates referenced to a different vertical CRS to that of
the project. This is evaluated in Test Procedure 5314.
• The same input data is used for Series 6000 audit trail tests.
• If the application cannot import P-format data but has a generic ASCII loader, this should be
reported and the equivalent ASCII file used.
Test Procedure: 5307 - Import 2D seismic position data with conversion (map projection) change (2)
equivalent) with EPSG CRS identification, when a change of map projection is required.
Test Data: GIGS_seis2D_5307_input
Expected Results: The application recognises P1 (or ASCII) file CRS definition, converts P1 (or ASCII) file horizontal
coordinates and stores correct horizontal locations. Results should agree to within 0.03m (30mm)
or 0.0000003° of the Test Data. See file GIGS_seis2D_5307_output.
Note: • See Test Procedure 5306.

• The same input data is used for Series 6000 audit trail tests.
60
Test Procedure: 5308 - Import 2D seismic position data with geodetic datum change (1)
equivalent) with traditional CRS definition records when a change of geodetic datum is involved.
offshore.
Expected Results: • The application recognizes P1 (or ASCII) file CRS definition, converts P1 (or ASCII) file horizontal
• The application stores an audit trail of CRS actions.
Note: • This test involves a change of horizontal CRS from input CRS to project CRS. The test output file
assumes that the application applies a coordinate transformation and then stores coordinates in
the CRS to which the project is referenced.
is handling geographic coordinates, the grid coordinates in the test file have been set to zero and
therefore if used by the Evaluator, should cause the seismic position data to appear outside the
project area.
Test Procedure: 5309 - Import 2D seismic position data with geodetic datum change (2)
equivalent) with EPSG CRS identification when a change of geodetic datum is required.
coordinates and stores correct horizontal locations. Results should agree to within 0.03m (30mm)
or 0.0000003° of the Test Data. See file GIGS_seis2D_5309_output
Note: See test 5308.
Test Procedure: 5310 - Import 2D seismic position data with change of horizontal units
equivalent) when a change in projected CRS coordinate units (m/ft) is applied.
• The vertical CRS units should not be converted.
Note: • The P1-format file requires both geographic and grid coordinates. To verify that the application
is handling grid coordinates, the geographic coordinates in the test file have been set to zero and
therefore if used by the Evaluator, should cause the seismic position data to appear outside the
project area.
61
Test Procedure: 5311 - Import 2D seismic position data with coordinates in grads
Test Purpose: To verify that the application correctly loads coordinates given in grads.
coordinates in grads and stores correct horizontal locations. Results should agree to within 0.03m
(30mm) or 0.0000003 grad of the Test Data. See file GIGS_seis2D_5311_output
Note: Gradians is not supported in the P1/11 file format S1 position record, so cannot be supplied.
Test Procedure: 5312 - Import 2D seismic position data with vertical datum change
Test Purpose: To verify that the application correctly loads vertical locations from a P1-format file (or ASCII
equivalent) when a change of vertical datum is required.
offshore. The onshore data includes height rather than depth.
Expected Results: The application recognises P1 (or ASCII) file CRS definition, transforms P1 (or ASCII) file vertical
coordinates and stores correct vertical locations. Results should agree to within 0.03m (30mm) or
0.0000003° of the Test Data. See file GIGS_seis2D_5312_output
Note: • This test involves a change of CRS from input CRS to project CRS. The test output file assumes
that the application applies a coordinate transformation and then stores coordinates in the CRS
to which the project is referenced.
Test Procedure: 5313 - Import 2D location seismic data with ellipsoidal height
Test Purpose: To verify that the application correctly loads vertical locations when ellipsoidal height is used.
Expected Results: The application recognises P1 (or ASCII) file CRS definition, transforms P1 (or ASCII) file ellipsoidal
3D coordinates and stores correct vertical locations. Results should agree to within 0.03m (30mm)
or 0.0000003° of the Test Data. See file GIGS_seis2D_5313_output
Note: • This test involves a change from ellipsoidal height given in the input file to the gravity-related
height which the project uses. The test assumes that the application applies a geoid model
coordinate transformation and then stores coordinates in the CRS to which the project is
referenced. Use of the EGM08 geoid model is assumed.
is handling geographic 3D coordinates, the grid coordinates in the test file have been set to zero
and therefore if used by the Evaluator, should cause the seismic position data to appear outside
the project area.
62
Test Procedure: 5314 - Import 2D location seismic data with change of vertical units
Test Purpose: To verify that the application correctly loads vertical locations from a P1-format file (or ASCII
equivalent) when a change in vertical coordinate units (ft/m) is applied.
Expected Results: The application recognises P1 file CRS definition, converts P1 file vertical coordinates and stores
correct vertical values. Results should agree to within 0.03m (30mm) or 0.0000003° of the Test
Data. See file GIGS_seis2D_5314_output
Note: If the application cannot import P-format data but has a generic ASCII loader, this should be
Test Procedure: 5315 - Import and decimate or reduce 2D seismic position data
Test Purpose: To verify that the application correctly loads and “decimates” locations from a P1-format file (or ASCII
equivalent). The test is designed to reduce the number of locations stored to the minimum required to
honour line geometry, that is, to store only line end points and, if present, intermediate points at which
the line orientation changes (bends). The test is only in the horizontal domain.
Sometimes called “decimation” because some application stores every tenth location. No coordinate
conversions or transformations are required for this test.
Expected Results: The application stores correct horizontal locations. Results should agree to within 0.03m (30mm) or
0.0000003° of the Test Data. See file GIGS_seis2D_5315_output
Note: • Line GIGS-5315-16 includes two curves: application may vary in how it treats these. The output
file includes every shotpoint around these curves.
• Line GIGS-5315-17 has a location (shotpoint 302) with anomalous input coordinates. It should be
filtered out.
Test Procedure: 5316 - Export 2D seismic position data with conversion (map projection) change
Test Purpose: To verify that the application correctly exports to a P1-format file (or ASCII equivalent) when a
change of map projection is required, but the same base geographic CRS is maintained.
Test Process: • Export the Test Data from project GIGS_project_A2V1depth. Exported data should be in P1-format
(or ASCII) referenced horizontally to CRS GIGS projCRS A1 (WGS 84/UTM zone 31N, EPSG CRS
code 32631).
• Verify coordinates in the exported data file against expected results.
Test Data: Seismic line GIGS-5315-17 from GIGS_project_A2V1depth.
Expected Results: • The application exports locations correctly. See file GIGS_seis2D_5316_output
• The application exports CRS definition correctly.
• Results should agree to within 0.03m (30mm) or 0.0000003° of the Test Data.
Note: • This test assumes that seismic line GIGS-5315-17 has been correctly loaded to the project (see
Test Procedure 5315).
• The same Test Data is used for Test Procedures 5316, 5319, 5320 and 5323. Output for 5316 and
5320 should have same coordinate values, only the medium differs.
63
Test Procedure: 5317 - Export 2D seismic position data with geodetic datum change
change of geodetic datum is required.
Test Process: • Export the Test Data from project GIGS_project_A2V1depth, the exported data to be in P1-format
(or ASCII) referenced horizontally to CRS GIGS projCRS B2 (Ordnance Survey Great Britain 1936/
British National Grid, EPSG CRS code 27700.
• Verify coordinates in exported data file against expected results.
Test Data: Seismic lines GIGS-5306-05 and GIGS-5306-11 from project GIGS_project_A2V1depth.
Note: • This test assumes that seismic lines GIGS-5306-05 and GIGS-5306-11 have been correctly loaded
to the project (see Test Procedure 5306).
• The same input Test Data is used for Test Procedures 5317 and 5321. Output should have same
coordinate values, only the medium differs.
Test Procedure: 5318 - Export 2D seismic position data with change of horizontal units
change of horizontal CRS unit (m/ft) is required.
Test Process: • Export the Test Data from project GIGS_project_A2V1depth, the exported data to be in P1-format
(or ASCII) referenced horizontally to CRS GIGS projCRS A23 (WGS 84/BLM 31N (ftUS)).
• Results should agree to within 0.1 ftUS/ft (1.2in) or 0.0000003° of the Test Data.
Note: • This test assumes that seismic lines GIGS-5306-05 and GIGS-5306-11 have been correctly loaded
to the project (see Test Procedure 5306).
Test Procedure: 5319 - Export 2D seismic position data with vertical datum change
change of vertical datum is required.
Test Process: • Export the Test Data from project GIGS_project_A2V1depth, the exported data to be in P1-format (or
ASCII) referenced vertically to CRS GIGS vertCRS W1 depth (Caspian depth, EPSG CRS code 5706).
Test Data: Seismic line GIGS-5315-17 from project GIGS_project_A2V1depth.
Expected Results: • The application exports locations correctly. See file GIGS_seis2D_5319_output.
Note: • This test assumes that seismic line GIGS-5315-17 has been correctly loaded to the project (see
Test Procedure 5315).
• The same input Test Data is used for Test Procedures 5316, 5319, 5320 and 5323. Output for 5319
and 5323 should have same coordinate values, only the medium differs.
64
Test Procedure: 5320 - Transfer 2D seismic position data with conversion (map projection) change
Test Purpose: To verify that the application correctly transfers 2D seismic position data to a different project when
a change of map projection is required.
Test Process: • In project GIGS_project_A2V1depth, select Test Data described below.

• Transfer to project GIGS_project_A1W_A1W1depth.
• Verify data in project GIGS_project_A1W_A1W1depth against expected results.
Expected Results: • The application transfers horizontal and vertical locations correctly.
See file GIGS_seis2D_5320_output.
Note: • This test involves a change of CRS from source project CRS to target project CRS. The test
assumes that the application applies a coordinate change and then stores coordinates in the CRS
to which the target project is referenced.
• The test assumes that seismic line GIGS-5315-17 has been correctly loaded to the source project
(see Test Procedure 5315).
Test Procedure: 5321 - Transfer 2D seismic position data with geodetic datum change
a change of geodetic datum is required.

• Transfer to project GIGS_project_B2V1depth.
• Verify data in project GIGS_project_B2V1depth against expected results.
Expected Results: • The application transfers horizontal locations correctly. See file GIGS_seis2D_5321_output.
• The test assumes that seismic lines GIGS-5306-05 and GIGS-5306-11 have been correctly loaded
to the source project (see Test Procedure 5306).
Test Procedure: 5322 - Transfer 2D seismic position data with horizontal unit change
a change of horizontal CRS unit (m/ft) is required.
Test Process: • In project GIGS_project_A2V1depth, select Test Data as described below.

• Transfer to project GIGS_project_A23V1depth.
• Verify data in project GIGS_project_A23V1depth against Test Data.
65
Expected Results: • The application transfers locations correctly. See file GIGS_seis2D_5322_output.
• Results should agree to within 0.1 ftUS/ft (1.2in) or 0.0000003° of the Test Data.
• The test assumes that seismic lines GIGS-5308-04 and GIGS-5308-12 have been correctly loaded
to the source project (see Test Procedure 5308).
Test Procedure: 5323 - Transfer 2D seismic position data with vertical datum change
a change of vertical datum is involved.

• Transfer to project GIGS_project_A1W1depth.
• Verify data in project GIGS_project_A1W1depth against Test Data.
Expected Results: • The application transfers locations correctly. See file GIGS_seis2D_5323_output.
• The test assumes that seismic line GIGS-5315-17 has been correctly loaded to the source project
(see Test Procedure 5315).
Test Procedure: 5324 - Import 2D seismic position data with NADCON transformation
equivalent) when a transformation using the NADCON method must be applied.
Test Process: • Load data from test input file to project GIGS_project_Z28V1depth.
• Verify coordinates in project GIGS_project_Z28V1depth against expected results.
coordinates using the NADCON method, and stores correct horizontal locations.
• The input data includes some points also used for Test Procedure 5325, with common input
points having identical coordinates. After transformation the coordinates of output points will not
be the same as those output in Test Procedure 5325.
Note: • It may be necessary to force the application to utilise the NADCON method.
• In North America the NADCON grids for Conus and Alaska overlap with the NTv2 grid for
Canada. Application should use NADCON for locations in the US and NTv2 for locations in
Canada. The Test Data includes lines which cross the national boundary. See also Test Procedure
5325. Note: the GIGS Test Data is not an authority on international boundaries. In the test results
the indication of which points fall inside and outside of US is indicative only.
66
Test Procedure: 5325 - Import 2D seismic position data with NTv2 transformation
equivalent) when a transformation using the NTv2 method is applied.
Test Process: • Load data from test input file to project GIGS_project_Z28V1depth.
• Verify coordinates in project GIGS_project_Z28V1depth against expected results.
coordinates using the NTv2 method, and stores correct horizontal locations.
• The input data includes some points also used for Test Procedure 5324, with common input
points having identical coordinates. After transformation the coordinates of output points will not
be the same as those output in Test Procedure 5324.
Note: • It may be necessary to force the application to utilise the NTv2 method.
• In North America the NADCON grids for Conus and Alaska overlap with the NTv2 grid for
Canada. Applications should use NADCON for locations in the US and NTv2 for locations in
Canada. The Test Data includes lines which cross the national boundary. See also Test Procedure
5324. Note: the GIGS Test Data is not an authority on international boundaries. In the test results
the indication of which points fall inside and outside of Canada is indicative only.
2.11.6 5400 3D Seismic Test Procedures

The Test Procedures for seismic position data in Series 5400 (3D seismic) require loading
and unloading of Test Data to a software ‘project’. Projects are required to be referenced to
specific CRS as defined in the Test Procedures below. See Appendix D for an explanation of
the project naming and see the user-defined library Series 3000 for the definitions of these
CRSs. The projects are also used for the Series 5300 2D Seismic and Series 5500 wells tests.
The majority of tests use a project area in the southwestern part of the North Sea. This area
was chosen because it is within the extended reach of surrounding countries in which CRSs
using several important conversion and transformation methods are found. As before, a
fictitious CRS (WGS 84 / British National Grid) was chosen as the target CRS for data, ensuring
that all software are using the same objective CRS. To test geodetic data from elsewhere in the
world, other fictitious systems such as one using US Survey Feet were applied to this setting.
The tests in this section use hypothetical seismic line position data. The input Test Dataset
files for these tests are synthetic P6/11 or P6/98 format text files, as well as P1 file for
a specific test - an equivalent ASCII file is also provided for software that cannot handle
P-format files. The output files are all in ASCII format. The entire Test Series should
be repeated for each data exchange format supported, and the results reported for any
differences between the different formats.
The Test Data for this series comprises input and output files with each test point
(representing a bin grid inline/crossline) on a separate row in the data array. The general
process is to load the input file and transform/convert coordinates referenced from
geogCRS 1/projCRS 1 to geogCRS 2/projCRS 2 - then compare the results with the values
in the output file data array. The seismic 3D position data have been designed so that if
converted or transformed correctly the seismic bin grids will intersect.
67
Five overlapping synthetic surveys are used. Surveys A, B and C fall over part of the
extensive Survey D. Survey E is a small site survey around platform Y. These are shown
schematically in Figure 6, along with the horizontal locations of the synthetic wells that will
be examined in Series 5500 tests. The map grid is at 10km intervals.
The CRS to which input and output coordinates are referenced are given in file headers
The GIGS Test Dataset currently provides both P6/11 and P6/98 format options, but
Evaluators may wish to repeat the following Test Procedures using other 3D seismic
position data exchange formats that they consider important. SPS files are not provided
and, if required, should be generated by Evaluators based on the ASCII files. If the
application supports more than one exchange format (including different P1 vintages) then
each test should be repeated for all supported formats and the results individually reported
for each test.
Figure 6: GIGS 3D seismic and well locations schematic, southern North Sea
(WGS 84 / UTM zone 31N) (see Appendix A for plan map).
68
Figure 7: GIGS 3D seismic Survey E extent and coverage schematic, southern North Sea
(WGS 84 / British National Grid) (see Appendix A for plan map).
Test Procedure: 5403 - Import 3D seismic position data with CRS change
Test Purpose: To evaluate the position of 3D seismic position data when a change of CRS is required on import.
Test Process: • Load Test Data to project GIGS_project_A2V1depth (P1 and P6, or ASCII)
• Measure coordinates of locations described in output data file.
• Compare measured coordinates with output file coordinates. In particular, report differences
in the area of overlap between survey A and survey B and survey D (inline 3501 through 4001,
crossline 13600 through 14800) and in the area of overlap between survey B and survey C and
survey D (inline 6401 through 7001, crossline 18800 through 20000)
Test Data: • GIGS_seis3D_5403_surveyA_input

• GIGS_seis3D_5403_surveyB_input
• GIGS_seis3D_5403_surveyC_input
• GIGS_seis3D_5403_surveyD_input
Expected Results: • Results should agree to within 0.03m (30mm) or 0.0000003° of the Test Data. See files:
– GIGS_seis3D_5403_surveyA_output
– GIGS_seis3D_5403_surveyB_output
– GIGS_seis3D_5403_surveyC_output
– GIGS_seis3D_5403_surveyD_output
• Additional checks should be made on the axes of the bin grid derived from the input data, by
measuring the distance and bearing of each
– GIGS_seis3D_5403_surveyA_output_axes
– GIGS_seis3D_5403_surveyB_output_axes
– GIGS_seis3D_5403_surveyC_output_axes
– GIGS_seis3D_5403_surveyD_output_axes
• The application stores an audit trail of CRS actions
69
Note: • The orthogonal properties of a seismic bin grid cannot be maintained if a change of coordinate
reference system is introduced. The way that a seismic bin grid is defined within a project
influences the effect of this phenomenon.
• When reading coordinate values, care needs to be taken to ensure that it is the bin position
rather than cursor position that is being measured. If application shows cursor position without
notifying user, report this.
• The input data is used for Test Procedures 5404 and 5405.
reported and the equivalent ASCII file used
Test Procedure: 5404 - Export 3D seismic position data with CRS change
Test Purpose: To identify how the application exports 3D seismic position data when a change of CRS is required.
Test Process: • In GIGS_project_A2V1depth, select all Survey B Test Data (including generated inlines and crosslines.
• Export.
• Describe results.
Test Data: See Test Procedure 5403
Expected Results: Results should agree to within 0.03m (30mm) or 0.0000003° of the Test Data.
See file GIGS_seis3D_5404_output. Test result will be pass or fail. If fail, details of failure should be
reported.
Note: • The test assumes that the Test Data has been correctly loaded to the project. See Test Procedure
5403.
• The same Test Data is used for Test Procedure 5405.
Test Procedure: 5405 - Transfer 3D seismic position data with CRS change
Test Purpose: To identify how the application transfers 3D seismic position data when a change of CRS is
required.
Test Process: • In GIGS_project_A2V1depth, select all Survey B Test Data (including generated inlines and
crosslines).
• Describe results.
Test Data: See Test Procedure 5403
Expected Results: Results should agree to within 0.03m (30mm) or 0.0000003° of the Test Data. See file
GIGS_seis3D_5405_output. Test result will be pass or fail. If fail, details of failure should be reported.
Note: • The test assumes that the Test Data has been correctly loaded to the project. See Test Procedure
5403.
Test Procedure: 5406 - Import P6 extent and coverage data (without CRS change)
Test Purpose: To identify that the application imports 3D coverage polygons based on bin grid extent, map grid
extent, geographic extent, total coverage, full fold coverage, null full fold coverage island and null
coverage island from P6/98 extent and coverage records.
Test Process: • Load Test Data to project GIGS_project_A2V1depth.

• Examine whether polygons for bin grid extent, map grid extent, geographic extent, total coverage,
full fold coverage, null full fold coverage island and null coverage island are present. Coordinates
should correspond to the input file.
Test Data: GIGS_seis3D_5406_surveyE_input.
70
Expected Results: • Extent rectangles and coverage polygons are present – see Figure 7.
• Coordinates should correspond to those in the input file (also given in file GIGS_seis3D_5406_
surveyE_output, see below).
Note: • If the application cannot read a P6 format file this test cannot be run.
• The P6/98 format allows for extent records to be in bin grid and/or map grid and/or geographic
coordinates. The test file provides all three.
• The P6/98 format allows for coverage records to be in either bin grid and/or map grid
coordinates. The test file provides both options.
Test Procedure: 5407 - Import P6 extent data with CRS change
Test Purpose: To identify how the application imports different polygons based on bin grid extent, map grid extent,
geographic extent, total coverage, full fold coverage, null full fold coverage island and null coverage
island from P6/98 extent records when a change of CRS is required.
Test Process: • Load Test Data to project GIGS_project_A1W1depth.

• Determine whether the coordinates of the polygon representing the survey extent match those of
the test output file.
Test Data: GIGS_seis3D_5407_surveyE_input
Expected Results: Results should agree to within 0.03m (30mm) or 0.0000003° of the Test Data. See file
GIGS_seis3D_5407_surveyE_output. Test result will be pass or fail. If fail, details of failure should be
reported.
Note: • If the application cannot read a P6 format file, this test cannot be run.
• Extent map grid and geographic records are in the CRS to which the survey is referenced. If the
data are loaded to a different CRS then the map grid and geographic bounding boxes need to be
recalculated from the bin grid extent – a simple conversion of the map grid or geographic corner
coordinates in the source CRS is not correct.
• The three input files describe the survey extent by one each of bin grid, map grid and geographic
coordinates. In this Test Data set there is no datum change involved and the description of the
geographic grid is not rigorously tested.
2.11.7 5500 Wells Test Procedures

The Test Procedures for wellbore data in Series 5500 require loading and unloading of Test
Data to a software project. For these tests, projects require to be referenced to specific CRS
as defined in the Test Procedures below. See Appendix D for an explanation of the project
naming and see the User-defined library Series 3000 for the definitions of the CRSs used.
The projects are also used for the Series 5300 (2D seismic) and 5400 (3D seismic) Test
Procedures.
The majority of tests use a project area in the south-western part of the North Sea. This
area was chosen because it is within extended reach of surrounding countries in which
CRSs using several important conversion and transformation methods are found. As
before, a fictitious CRS (WGS 84 / British National Grid) was chosen as the target CRS for
data, ensuring that all software are using the same objective CRS.
71
To test geodetic data from elsewhere in the world, other fictitious systems such as one
using US Survey Feet were applied to this setting. To test the proper treatment of grid
convergence thoroughly, the four deviated wells have been recomputed for an Australian
scenario.
The tests in this section use hypothetical wellbore position data. The well surface positions
given in the input files are referenced to a variety of horizontal and vertical CRSs, with each
test point (representing an observable/station) on a separate row in the data array. The
input Test Dataset files for these tests are synthetic P7/17 or P7/00 format text files, an
equivalent ASCII file is also provided for software that cannot handle P-format files. The
output files are all in ASCII format. The entire Test Series should be repeated for each data
exchange format supported, and the results reported for differences between the different
formats.
The CRS to which input and output coordinates are referenced are given in file headers
The Test Procedures require the wellbores to be loaded to a project. The general process
is to load the input file and transform/convert coordinates referenced from geogCRS 1/
projCRS 1 to geogCRS 2/projCRS 2, then compare the results with the values in the output
file data array.
Eight wells A through H are used. Four (A, B, D and G) are vertical. The other four wells
(C, E, F and H) are deviated wellbores from two hypothetical platforms XN and YN. The
horizontal positions of the wells are shown schematically in Figure 6. The platform and
wells general layouts and schematic cross sections are shown in the Figures 8-14.
Each of the eight input well files are used in two tests (one testing horizontal geospatial
integrity, the other testing vertical geospatial integrity):
Table 2: GIGS well and platform ID for northern hemisphere tests.
Well Platform Input to Test Procedures
A 5506, 5526
B 5507, 5517
YNC YN 5511, 5515
D 5508, 5515
XNE XN 5510, 5514
YNF YN 5511, 5515
G 5509, 5516
XNH XN 5510, 5514
Because the definition of the sign of grid convergence in the southern hemisphere has been
the source of some confusion, the horizontal tests are repeated in an Australian setting using
the four deviated wellbores recalculated as wells J, K, L and M from platforms XS and YS:
72
Table 3: GIGS well and platform ID for southern hemisphere tests.
Well Platform Input to Test Procedures
XSJ XS 5512
XSK XS 5512
YSL YS 5513
YSM YS 5513
If tests 5506 through to 5517 and 5526 have been successful and if the application has
the functionality to display well cross sections, then in project GIGS_project_A2V1depth,
a cross-section through the bottom hole locations of wells A, B, YNC, D, XNE, YNF, G and
YNH should fall in a straight line in the horizontal plane and another straight line in the
vertical plane. The intersection of wellbores A, B, YNC, D and XNE with horizon 1 should lie
on a straight line in the vertical plane. The intersection of the wellbores YNF, G and XNH
with horizon 1 should lie on another straight line in the vertical plane, between XNE and
YNF there should be a 20m vertical fault. See the cross-section in Figure 8.
The GIGS Test Dataset provides both P7/2000 and P7/17 format, but Evaluators may wish
to repeat the following Test Procedures using other wellbore position data exchange
formats they consider important. If the application supports more than one exchange
format (including different P7 vintages) then each test should be repeated for all supported
formats and the results individually reported for each test.
Figure 8: GIGS Northern Hemisphere Well cross section (see Appendix A for plan map).
73
Figure 9: Platform wells for northern hemisphere well tests.
Figure 10: Platform wells for southern hemisphere well tests.
74
Figure 11: Schematic profile of GIGS well XNE
Figure 12: Schematic profile of GIGS well XNH.
75
Figure 13: Schematic profile of GIGS well YC.
Figure 14: Schematic profile of GIGS well YF.
76
Test Procedure: 5506 - Import wellbore location from geographic CRS coordinates
Test Purpose: To verify that the application can correctly load wellbore data when the horizontal position is given
in geographic 2D (latitude/longitude) coordinates. This test complements that in Test Procedure
5526.
Test Process: • Load data from test file to project GIGS_project_A2V1depth.

• Import wellbore position data from φλ
• Check horizontal locations in project GIGS_project_A2V1depth against Test Data.
Test Data: GIGS_wells_5506_wellA_input
Expected Results: • The conversion of geographical coordinates to grid coordinates is required. Results should agree
to within 0.03m (30mm) of the Test Data. See file GIGS_wells_5506_wellA_output.
Note: • In the input file, the geodesy is defined through reference to EPSG rather than explicitly (as
allowed in the P7/2000 format). The identified system is geographic 3D (see Test Procedure 5526
for of the vertical component).
• The same input data is also used in Test Procedure 5526.
• If the application cannot import a P7 format file, report this and instead use the ASCII file.
Test Procedure: 5507 - Import wellbore location from projected CRS coordinates
Test Purpose: To verify that the application can correctly load vertical wellbore data when the horizontal position
is given in map coordinates. No change of CRS is required.

• Import wellbore position data from EN
Test Data: GIGS_wells_5507_wellB_input.
Expected Results: • Results should agree to within 0.03m (30mm) of the Test Data.
See file GIGS_wells_5507_wellB_output.
Note: • The same input data is also used in Test Procedure 5517.
Test Procedure: 5508 - Import wellbore location with conversion (map projection) change
Test Purpose: To verify that the application correctly imports vertical wellbore data when the horizontal position
given in projected (map) coordinates requires converting to a different projected CRS (map
projection change only).

• Import wellbore position data from different EN
Test Data: GIGS_wells_5508_wellD_input
See file GIGS_wells_5508_wellD_output.
77
Test Procedure: 5509 - Import wellbore location with geodetic datum change
Test Purpose: To verify that the application correctly imports vertical wellbore data when the horizontal position is
given in geographic coordinates and requires converting to a CRS using a different geodetic datum

• Import wellbore position data from different geodetic datum
Test Data: GIGS_wells_5509_wellG_input
See file GIGS_wells_5509_wellG_output.
Test Procedure: 5510 - Import wellbore horizontal location from measured data relative to true north
(northern hemisphere)
Test Purpose: To verify that the application can correctly load horizontal position from deviated wellbore survey
data given as measured depth, inclination and azimuth with azimuth referenced to true north. Well
located in northern hemisphere. This test complements that in Test Procedure 5514.

• Import wellbore position data from MD/Inc/Az - TN, Northern hemisphere
Test Data: • GIGS_wells_5510_wellXNE_input

• GIGS_wells_5510_wellXNH_input
See file GIGS_wells_5510_wellXNE_output and GIGS_wells_5510_wellXNH_output.
Note: • The well reference point coordinates are referenced to a geographic CRS and should be
converted to the project CRS in the application loading process.
• Both input wells XNE and XNH should be tested: their wellbores are orthogonal to one another.
Test Procedure: 5511 - Import wellbore horizontal location from measured data relative to grid north
Test Purpose: To verify that the application can correctly load horizontal position from deviated wellbore data
given as measured depth, inclination and azimuth, with azimuth referenced to grid north and
wellhead location requiring a change of map projection. Well located in northern hemisphere. This
test complements that in Test Procedure 5515.

• Import wellbore position data from MD/Inc/Az - GN
Test Data: • GIGS_wells_5511_wellYNC_input

• GIGS_wells_5511_wellYNF_input
See files GIGS_wells_5511_wellYNC_output and GIGS_wells_5511_wellYNF_output.
78
Note: • Wellhead coordinates are defined through offsets from a facility reference point. See figure 9 above.
• The well reference point coordinates are given in a different projected CRS to that of the project
and correct conversion in the application loading process should be checked.
• Both input wells YNC and YNF should be tested: their wellbores are orthogonal to one another.
Test Procedure: 5512 - Import wellbore horizontal location from measured data relative to true north
(southern hemisphere)
Test Purpose: To verify that the application can correctly load horizontal position from deviated wellbore survey
data given as measured depth, inclination and azimuth, with azimuth referenced to true north. Well
located in the southern hemisphere.
Test Process: • Load data from test file to project GIGS_project_F7V1depth.

• Import wellbore position data from MD/Inc/Az - TN, Southern hemisphere
• Check horizontal locations in project GIGS_project_F7V1depth against Test Data.
Test Data: • GIGS_wells_5512_wellXSJ_input

• GIGS_wells_5512_wellXSK_input
See file GIGS_wells_5512_wellXSJ_output and GIGS_wells_5512_wellXSK_output.
Note: • Grid convergence may be used in the calculation of position from measured data (it does not
necessarily have to be). Whilst the magnitude of grid convergence is defined by map projection
formulae, there are two opposing conventions for the sign of grid convergence. To ensure that
the application performance in this area is fully understood, this Test Procedure repeats Test
Procedure 5510 in a southern hemisphere scenario.
• The well reference point coordinates are referenced to a geographic CRS and should be
converted to the project CRS in the application loading process.
• Both input wells XSJ and XSK should be tested; their wellbores are orthogonal to one another.
Test Procedure: 5513 - Import wellbore horizontal location from measured data relative to grid north
(southern hemisphere)
Test Purpose: To verify that the application can correctly load horizontal position from deviated wellbore data
given as measured depth, inclination and azimuth, with azimuth referenced to grid north and
wellhead location requiring a change of map projection. Well located in the southern hemisphere.
Test Process: • Load data from test file to project GIGS_project_F7V1depth.

• Import wellbore position data from MD/Inc/Az - GN - Southern hemisphere
• Check horizontal locations in project GIGS_project_F7V1depth against Test Data.
Test Data: • GIGS_wells_5513_wellYSL_input

• GIGS_wells_5513_wellYSM_input
See files GIGS_wells_5513_wellYSL_output and GIGS_wells_5513_wellYSM_output.
Note: • See Test Procedure 5512 for grid convergence comment. This Test Procedure repeats that in
5511 for a southern hemisphere location.
• Wellhead coordinates are defined through offsets from a facility reference point. See figure 10 above.
• The well reference point coordinates are given in a different projected CRS to that of the project
and correct conversion in the application loading process should be checked.
• Both input wells YSL and YSM should be tested; their wellbores are orthogonal to one another.
79
Test Procedure: 5514 - Import wellbore vertical location from measured data relative to true north
Test Purpose: To verify that the application can correctly load vertical position from deviated wellbore survey
data given as measured depth, inclination and azimuth with azimuth referenced to true north. Well
located in the northern hemisphere. This test complements that in Test Procedure 5510.
Test Process: • Load data from test files to project GIGS_project_A2V1depth.

• Import wellbore depth data from MD/Inc/Az - TN
• Check vertical locations in project GIGS_project_A2V1depth against Test Data.
Test Data: • GIGS_wells_5514_wellXNE_input

• GIGS_wells_5514_wellXNH_input
See files GIGS_wells_5514_wellXNE_output and GIGS_wells_5514_wellXNH_output.
Test Procedure: 5515 - Import wellbore vertical location from measured data relative to grid north
Test Purpose: To verify that the application can correctly load vertical position from deviated wellbore data given
as measured depth, inclination and azimuth, with azimuth referenced to grid north and well
reference point requiring a change of vertical datum. Well located in the northern hemisphere. This
test complements those in Test Procedures 5508 and 5511.

• Import wellbore depth data from MD/Inc/Az with change of vertical datum
Test Data: • GIGS_wells_5515_wellD_input

• GIGS_wells_5515_wellYNC_input
• GIGS_wells_5515_wellYNF_input
Expected Results: • Results should agree to within 0.1m (100mm) of the Test Data. See files GIGS_wells_5515_wellD_
output, GIGS_wells_5515_wellYNC_output, and GIGS_wells_5515_wellYNF_output.
Note: • The input data is also used in Test Procedures 5508 and 5511
• The well reference point coordinates are referenced to a CRS with a different vertical datum to that
of the project and correct transformation in the application loading process should be checked.
Test Procedure: 5516 - Import wellbore depth data with TVDBML reference
Test Purpose: To verify that the application can correctly load vertical position from wellbore data referenced to
TVDBML.

• Import wellbore depth data with TVDBML reference
Test Data: GIGS_wells_5516_wellG_input
Expected Results: • The application should adjust ‘depths below mud line’ to be ‘depths below <project vertical CRS>’.
Results should agree to within 0.1m (100mm) of the Test Data. See file GIGS_wells_5516_wellG_output
Note: • The input data is also used in Test Procedure 5509.

80
Test Procedure: 5517 - Import wellbore depth data with vertical unit change
Test Purpose: To verify that the application can correctly load vertical position when referenced to a different
vertical CRS to that of the project.

• Import wellbore depth data with change of vertical CS
Test Data: GIGS_wells_5517_wellB_input
Expected Results: • The application should convert depth data given in feet to metres. Results should agree to within
0.1m (100mm) of the Test Data. See file GIGS_wells_5517_wellB_output.
Note: • The same input data are also used in Test Procedure 5507.
Test Procedure: 5518 - Export wellbore data with conversion (map projection) change
Test Purpose: To verify that the application correctly exports wellbore data when a change of map projection is
required.
Test Process: • In project GIGS_project_A2V1depth, export the Test Data.

• Verify coordinates in exported data file against Test Data.
Test Data: Well B from project GIGS_project_A2V1depth, with exported horizontal coordinates to be referenced
to GIGS_projCRS_A1.
Expected Results: • The application exports horizontal locations correctly. Results should agree to within 0.1m
(100mm) of the Test Data. See file GIGS_wells_5518_output. (The same output file applies to all of
Test Procedures 5518, 5521, 5522 and 5525).
Note: • This test assumes that Well B has been correctly loaded to the project (see Test Procedure 5507).
• The Test Data is also used in Test Procedure 5521.
Test Procedure: 5519 - Export wellbore data with geographic CRS change
Test Purpose: To verify that the application correctly exports wellbore data when a change of geographic CRS is
required.
Test Process: • In project GIGS_project_A2V1depth, export data as described in Test Data.

Test Data: Well D from project from project GIGS_project_A2V1depth, with exported horizontal coordinates to be
referenced to GIGS_geogCRS_B.
Expected Results: • The application exports horizontal locations correctly. Results should agree to within 0.1m
(100mm) of the Test Data. See file GIGS_wells_5519_output.
• The application exports CRS definitions correctly.
Note: This test assumes that Well D has been correctly loaded to the project (see Test Procedure 5508).
81
Test Procedure: 5520 - Export wellbore data with change of horizontal CRS units
Test Purpose: To verify that the application correctly exports wellbore data when a change of horizontal CRS unit
is involved.
Test Process: • In project GIGS_project_A2V1depth, export data as described in Test Data.

Test Data: Well G from project GIGS_project_A2V1depth, with exported horizontal coordinates to be referenced
to GIGS_projCRS_A23.
Expected Results: • The application exports horizontal locations correctly. Results should agree to within 0.3 ftUS
(4in) of the Test Data. See file GIGS_wells_5520_output. (The same output data applies to both of
Test Procedures 5520 and 5524).
Note: This test assumes that Well G has been correctly loaded to the project (see Test Procedure 5509).
Test Procedure: 5521 - Export wellbore data with vertical CRS change
Test Purpose: To verify that the application correctly exports wellbore data when a change of vertical CRS is involved.
Test Process: • In project GIGS_project_A2V1depth export data as described in Test Data.

Test Data: Well B from project GIGS_project_A2V1depth, with exported horizontal coordinates to be referenced
to GIGS_projCRS_A1 and exported vertical coordinates to be referenced to GIGS_ vertCRS_W1 depth.
Expected Results: • The application exports vertical locations correctly. Results should agree to within 0.1m (100mm)
of the Test Data. See file GIGS_wells_5521_output. (The same output data applies to all of Test
Procedures 5518, 5521, 5522 and 5525).
Note: • This test assumes that Well B has been correctly loaded to project A7V (see Test Procedure 5507).
• The Test Data is also used for Test Procedure 5518.
Test Procedure: 5522 - Transfer wellbore data with conversion (map projection) change
Test Purpose: To verify that the application correctly transfers wellbore data to another project when a change of
map projection is required.
Test Process: • In project GIGS_project_A2V1depth select Test Data.

Test Data: Well B as loaded to project GIGS_project_A2V1depth.
Expected Results: • The application transfers horizontal locations correctly. Results should agree to within 0.1m
(100mm) of the Test Data. See file GIGS_wells_5522_output. (The same output data applies to all
of Test Procedures 5518, 5521, 5522 and 5525).
• The test assumes that Well B has been correctly loaded to the source project A7V (see Test
Procedure 5507).
• The Test Data is also used for Test Procedure 5525.
82
Test Procedure: 5523 - Transfer wellbore data with geographic CRS change
geodetic datum is required.

• Transfer to project GIGS_project_B2V1depth.
• Verify data in project GIGS_project_B2V1depth against Test Data.
Test Data: Well D as loaded to project GIGS_project_A2V1depth.
Expected Results: • The application transfers horizontal locations correctly. Results should agree to within 0.1m
(100mm) of the Test Data. See file GIGS_wells_5523_output.
Note: • This test involves a change of CRS from the CRS to which the source project is referenced to the
CRS to which the target project is referenced. The test assumes that the application applies a
coordinate change and then stores coordinates in the CRS to which the target project is referenced.
• The test assumes that Well D has been correctly loaded to the source project (see Test Procedure
5508).
Test Procedure: 5524 - Transfer wellbore data with horizontal CRS unit change
horizontal CRS unit is involved.

• Transfer selected data to project GIGS_project_A23V1depth.
• Verify data in project GIGS_project_A23V1depth against Test Data.
Test Data: Well G as loaded to project GIGS_project_A2V1depth.
Expected Results: • The application transfers horizontal locations correctly. Results should agree to within 0.3 ftUS
(4in) of the Test Data. See file GIGS_wells_5524_output. (The same output file applies to both of
Test Procedures 5520 and 5524).
Note: • This test involves a change of CRS from the CRS to which the source project is referenced to the
CRS to which the target project is referenced. The test assumes that the application applies a
coordinate change and then stores coordinates in the CRS to which the target project is referenced.
• The test assumes that Well G has been correctly loaded to the source project (see Test Procedure
5509).
Test Procedure: 5525 - Transfer wellbore data with vertical CRS change
vertical CRS is involved.

• Transfer selected data to project GIGS_project_A1W1depth.
Test Data: Well B as loaded to project GIGS_project_A2V1depth.
Expected Results: • The application transfers vertical locations correctly. Results should agree to within 0.1m
(100mm) of the Test Data. See file GIGS_wells_5525_output. (The same output data applies to Test
Procedures 5518, 5521, 5522 and 5525).
Note: • This test involves a change of vertical datum from source project to target project. The test
• The test assumes that Well B has been correctly loaded to the source project (see Test Procedure
5507).
83
Test Procedure: 5526 - Import wellbore depth data with ellipsoidal vertical data
Test Purpose: To verify that the application can correctly load wellbore vertical position when referenced to a
different vertical datum to that of the project. This test compliments that in Test Procedure 5506.

• Import wellbore depth data with change of vertical CS
Test Data: GIGS_wells_5526_wellA_input
Expected Results: • The application should adjust ‘depths below ellipsoid’ to reference ‘depths below <project vertical
CRS>’ using the EGM2008 geoid model. Results should agree to within 0.1m (100mm) of the Test
Data. See file GIGS_wells_5526_wellA_output.
Note: • The same input data are also used in Test Procedure 5506.
2.11.8 7000 Deprecation Test Procedures

The Test Procedures for this series are designed to verify the geodetic data object
deprecation functionality of the software. The Test Data comprises a number of entities
that have been deprecated in the EPSG Dataset, alongside deprecation details. The Test
Procedure should identify if these entities are present in the application’s predefined
geodetic parameter library, and if so, how they are represented.
Test Procedure: 7001 - Deprecated EPSG data
Test Purpose: To verify whether reference data bundled with the application recognises the EPSG deprecation flag.
Test Process: Review definitions of EPSG deprecated data included in the application.
Test Data: EPSG Dataset and file GIGS_dep_7001. As a minimum those geodetic data objects relevant to the
Expected Results: Data marked as deprecated in the EPSG Dataset should either be clearly distinguished from valid
data or should not be present in the application libraries.
Note: Applications may lag behind updates to the EPSG Dataset. The Test Data deliberately uses
deprecations made several years ago, which by now should be recognised as deprecated by the
application.
84
Appendix A: GIGS Test Dataset Index and Maps

The following index applies only to the ASCII base class Test Data files (i.e., not the P-format files) - depending on the chosen, or derived, Test Dataset format, the
actual file names and structure may be different (see Section 2.3 and 2.4).
Table A1: Index of GIGS Test Procedure objects and components
Test Proc.# Test Object/Subject Test Data Input File Name(s) GIGS CRS(s) used Test Data Output File Name(s)
2000 - Predefined geodetic data objects
2201 unit of measure GIGS_lib_2201_Unit N/A
2202 ellipsoid GIGS_lib_2202_Ellipsoid N/A
2203 prime meridian GIGS_lib_2203_PrimeMeridian N/A
2204 geodetic datum GIGS_lib_2204_GeodeticDatum N/A
2205 geodetic CRS GIGS_lib_2205_GeodeticCRS N/A
2206 conversion GIGS_lib_2206_Conversion N/A
2207 projected CRS GIGS_lib_2207_ProjectedCRS N/A
2208 coordinate transformation GIGS_lib_2208_CoordTfm N/A
2209 vertical datum GIGS_lib_2209_VerticalDatum N/A
2210 vertical CRS GIGS_lib_2210_VerticalCRS N/A
2211 vertical transformation GIGS_lib_2211_VertTfm N/A
3000 - User-defined geodetic data objects
3201 unit of measure GIGS_user_3201_Unit N/A
3202 ellipsoid GIGS_user_3202_Ellipsoid N/A
3203 prime meridian GIGS_user_3203_PrimeMeridian N/A
3204 geodetic datum GIGS_user_3204_GeodeticDatum N/A
3205 geodetic CRS GIGS_user_3205_GeodeticCRS N/A
85
3206 conversion GIGS_user_3206_Conversion N/A
3207 projected CRS GIGS_user_3207_ProjectedCRS N/A
3208 coordinate transformation GIGS_user_3208_CoordTfm N/A

(+GIGS_user_3208_CoordTfm_61004_N_SLOPE.LAS;
GIGS_user_3208_CoordTfm_61004_N_SLOPE.LOS;
GIGS_user_3208_CoordTfm_61844_QUE27-98.gsb – if required)
3209 vertical datum GIGS_user_3209_VerticalDatum N/A
3210 vertical CRS GIGS_user_3210_VerticalCRS N/A
3211 vertical transformation GIGS_user_3211_VertTfm N/A
3212 concatenated transformation GIGS_user_3212_ConcatTfm N/A
5100 - Data Operations - Conversion
Note: if using P1/11 subclass files, only single file is needed
5101 Software performance - Conversions - GIGS_conv_5101_TM_input_part1; A<>A2 *GIGS_conv_5101_TM_output_part1;

Transverse Mercator GIGS_conv_5101_TM_input_part2; A<>A1 GIGS_conv_5101_TM_output_part2;
GIGS_conv_5101_TM_input_part3; F<>F7 GIGS_conv_5101_TM_output_part3;
GIGS_conv_5101_TM_input_part4 G<>G11 GIGS_conv_5101_TM_output_part4
*depending on formula in application, use either
output files _JHS or _USGS
5102 Software performance - Conversions - Lambert GIGS_conv_5102_LCC1_input_part1; M<>M25 GIGS_conv_5102_LCC1_output_part1;

Conic Conformal (1SP) GIGS_conv_5102_LCC1_input_part2 H<>H19 GIGS_conv_5102_LCC1_output_part2;
5103 Software performance - Conversions - Lambert GIGS_conv_5103_LCC2_input_part1; E<>E6 GIGS_conv_5103_LCC2_output_part1;

Conic Conformal (2SP) GIGS_conv_5103_LCC2_input_part2; G<>G17 GIGS_conv_5103_LCC2_output_part2;
GIGS_conv_5103_LCC2_input_part3 G<>G18 GIGS_conv_5103_LCC2_output_part3
5104 Software performance - Conversions - Oblique GIGS_conv_5104_OblStereo_input C<>C4 GIGS_conv_5104_OblStereo_output

Stereographic
5105 Software performance - Conversions - Oblique GIGS_conv_5105_HOM-B_input_part1; G<>G13 GIGS_conv_5105_HOM-B_output_part1;

Mercator GIGS_conv_5105_HOM-B_input_part2 K<>K26 GIGS_conv_5105_HOM-B_output_part2
5106 Software performance - Conversions - Hotine GIGS_conv_5106_HOM-A_input G<>G14 GIGS_conv_5106_HOM-A_output

Oblique Mercator
86
5107 Software performance - Conversions - American GIGS_conv_5107_AmPolyC_input G<>G12 GIGS_conv_5107_AmPolyC_output

Polyconic
5108 Software performance - Conversions - Cassini- GIGS_conv_5108_Cass_input G<>G15 GIGS_conv_5108_Cass_output

Soldner
5109 Software performance - Conversions - Albers GIGS_conv_5109_Albers_input F<>F9 GIGS_conv_5109_Albers_output

Equal Area
5110 Software performance - Conversions - Lambert GIGS_conv_5110_LAEA_input G<>G16 GIGS_conv_5110_LAEA_output

Azimuthal Equal Area
5111 Software performance - Conversions - Mercator GIGS_conv_5111_MercA_input_part1; L<>L27 GIGS_conv_5111_MercA_output_part1;

(1SP) GIGS_conv_5111_MercA_input_part2 D<>D5 GIGS_conv_5111_MercA_output_part2
5112 Software performance - Conversions - Mercator GIGS_conv_5112_MercB_input Y<>Y24 GIGS_conv_5112_MercB_output

(2SP)
5113 Software performance - Conversions - GIGS_conv_5113_TMSO_input G<>G10 GIGS_conv_5113_TMSO_output

Transverse Mercator (South Orientated)
5200 - Data Operations – Coordinate Transformation
Note: if using P1/11 subclass files, only single file is needed
5201 Software performance - Conversions - GIGS_tfm_5201_GeogGeocen_input A GIGS_tfm_5201_GeogGeocen_output

Geographic<>Geocentric
5202 (Test Procedure removed, replaced by tests 5211

through 5213)
5203 Software performance - transformations - GIGS_tfm_5203_PosVec_input_part1; B<>A GIGS_tfm_5203_PosVec_output_part1;

Position Vector (geographic 2D domain) GIGS_tfm_5203_PosVec_input_part2 GIGS_tfm_5203_PosVec_output_part2
5204 Software performance - transformations - GIGS_tfm_5204_CoordFrame_input_part1; E<>A GIGS_tfm_5204_CoordFrame_output_part1;

Coordinate Frame (geographic 2D domain) GIGS_tfm_5204_CoordFrame_input_part2 GIGS_tfm_5204_CoordFrame_output_part2
5205 Software performance - transformations - GIGS_tfm_5205_MolBad_input_part1; C<>A GIGS_tfm_5205_MolBad_output_part1;

Molodensky-Badekas (geographic domain) GIGS_tfm_5205_MolBad_input_part2 GIGS_tfm_5205_MolBad_output_part2
5206 Software performance - transformations - *GIGS_tfm_5206_Nadcon_input_part1; J<>Z GIGS_tfm_5206_Nadcon_output

NADCON GIGS_tfm_5206_Nadcon_input_part2
GIGS_tfm_5206_Nadcon_input_part3
*if early-binding use part 2 and 3, or if late-binding use part 1
87
5207 Software performance - transformations - NTv2 GIGS_tfm_5207_NTv2_input_part1; X<>F GIGS_tfm_5207_NTv2_output_part1;

GIGS_tfm_5207_NTv2_input_part2 J<>Z GIGS_tfm_5207_NTv2_output_part2
5208 Software performance - transformations - GIGS_tfm_5208_LonRot_input T<>H GIGS_tfm_5208_LonRot_output

Longitude rotation
5209 Software performance - conversions - UKOOA P6 GIGS_tfm_5209_BinGrid_input Bin Grid <> A1 GIGS_tfm_5209_BinGrid_output
bin grid
5210 Software performance - transformations - GIGS_tfm_5210_VertOff_input W1<>V1 with both GIGS_tfm_5210_VertOff_output

vertical offset heights and depths
5211 Software performance - transformations - GIGS_tfm_5211_3trnslt_Geocen_input B<>A GIGS_tfm_5211_3trnslt_Geocen_output

geocentric translations (geocentric domain)
5212 Software performance - transformations - GIGS_tfm_5212_3trnslt_Geog3D_input B<>A *GIGS_tfm_5212_3trnslt_Geog3D_output

geocentric translations (geographic 3D domain) *depending on formula in application, use either
output files _AbrMol or _EPSGconcat
5213 Software performance - transformations - GIGS_tfm_5213_3trnslt_Geog2D_input B<>A *GIGS_tfm_5213_3trnslt_Geog2D_output

geocentric translations (geographic 2D domain) *depending on formula in application, use either
output files _AbrMol or _EPSGconcat
5300 - Data Operations - 2D Seismic
Note: if using P1/11 or P1/90 subclass files, only single file is needed
5301 (Test Procedure removed)
5306 Import 2D seismic position data with conversion GIGS_seis2D_5306_input_part1; A1 > A2 GIGS_seis2D_5306_output
(map projection) change (1) - full CRS definition. GIGS_seis2D_5306_input_part2
5307 Import 2D seismic position data with conversion GIGS_seis2D_5307_input; A1 > A2 GIGS_seis2D_5307_output
(map projection) change (2) - EPSG CRS
identification.
5308 Import 2D seismic position data with geodetic GIGS_seis2D_5308_input_part1; B > A2 GIGS_seis2D_5308_output
datum change (1) - full CRS definition. GIGS_seis2D_5308_input_part2
88
5309 Import 2D seismic position data with geodetic GIGS_seis2D_5309_input B > A2 GIGS_seis2D_5309_output
datum change (2) - EPSG CRS identification.
5310 Import 2D seismic position data with change of GIGS_seis2D_5310_input A23 > A2 GIGS_seis2D_5310_output
horizontal units
5311 Import 2D seismic position data given in grads GIGS_seis2D_5311_input Agr > A2 GIGS_seis2D_5311_output
5312 Import 2D seismic position data with vertical GIGS_seis2D_5312_input_part1; W1height > V1depth GIGS_seis2D_5312_output
datum change. W1depth > V1depth
5313 Import 2D seismic position data with ellipsoidal GIGS_seis2D_5313_input A > V1depth GIGS_seis2D_5313_output
height.
5314 Import 2D seismic position data with change of GIGS_seis2D_5314_input V2height > V1depth GIGS_seis2D_5314_output
vertical units.
5315 Import and “decimate” 2D seismic position data GIGS_seis2D_5315_input n/a GIGS_seis2D_5315_output
5316 Export 2D seismic position data with conversion (Test Data loaded to project in earlier tests) A2 > A1 GIGS_seis2D_5316_output
(map projection) change.
5317 Export 2D seismic position data with geodetic (Test Data loaded to project in earlier tests) A2 > B2 GIGS_seis2D_5317_output
datum change.
5318 Export 2D seismic position data with change of (Test Data loaded to project in earlier tests) A2 > A23 GIGS_seis2D_5318_output
horizontal units.
5319 Export 2D seismic position data with vertical (Test Data loaded to project in earlier tests) V1depth > W1depth GIGS_seis2D_5319_output
datum change.
5320 Transfer 2D seismic position data with (Test Data loaded to project in earlier tests) A2 > A1 GIGS_seis2D_5320_output
conversion (map projection) change.
5321 Transfer 2D seismic position data with geodetic (Test Data loaded to project in earlier tests) A2 > B2 GIGS_seis2D_5321_output
datum change.
5322 Transfer 2D seismic position data with change of (Test Data loaded to project in earlier tests) A2 > A23 GIGS_seis2D_5322_output
horizontal CRS units.
5323 Transfer 2D seismic position data with vertical (Test Data loaded to project in earlier tests) V1depth > W1depth GIGS_seis2D_5323_output
datum change.
5324 Import 2D seismic position data with geodetic GIGS_seis2D_5324_input J>Z GIGS_seis2D_5324_output
datum change using NADCON
5325 Import 2D seismic position data with geodetic GIGS_seis2D_5325_input J>Z GIGS_seis2D_5325_output
datum change using NTv2
89
5400 - Data Operations - 3D Seismic
5403 Import 3D seismic position data with CRS change GIGS_seis3D_5403_surveyA_input; A1 > A2 GIGS_seis3D_5403_surveyA_output;
GIGS_seis3D_5403_surveyB_input; A > A2 GIGS_seis3D_5403_surveyA_output_axes;
GIGS_seis3D_5403_surveyC_input; GIGS_seis3D_5403_surveyB_output;
GIGS_seis3D_5403_surveyD_input GIGS_seis3D_5403_surveyB_output_axes;
GIGS_seis3D_5403_surveyC_output;
GIGS_seis3D_5403_surveyC_output_axes;
GIGS_seis3D_5403_surveyD_output;
GIGS_seis3D_5403_surveyD_output_axes
5404 Export 3D seismic position data with CRS (Test Data loaded to project in earlier tests) A2 > A1 GIGS_seis3D_5404_output
change.
5405 Transfer 3D seismic position data with CRS (Test Data loaded to project in earlier tests) A2 > A1 GIGS_seis3D_5405_output
change.
5406 Import P6 extent and coverage records GIGS_seis3D_5406_SurveyE_input.P6* A2 GIGS_seis3D_5406_surveyE_output

*Test Data only offered as P6 as specifically test P-formats
5407 Import P6 extent records with conversion (map GIGS_seis3D_5407_surveyE_input.P6* A2 > A1 GIGS_seis3D_5407_surveyE_output
projection) change *Test Data only offered as P6 as specifically test P-formats
5500 - Data Operations - Well Data
5506 Import wellbore position data from latitude, GIGS_wells_5506_wellA_input A > A2 GIGS_wells_5506_wellA_output
longitude
5507 Import wellbore position data from EN GIGS_wells_5507_wellB_input A2 GIGS_wells_5507_wellB_output
5508 Import wellbore position data from different EN GIGS_wells_5508_wellD_input A1 > A2 GIGS_wells_5508_wellD_output
90
5509 Import wellbore position data from different GIGS_wells_5509_wellG_input B > A2 GIGS_wells_5509_wellG_output
geodetic datum
5510 Import wellbore position data from MD/Inc/Az - GIGS_wells_5510_wellXNE_input; A2 GIGS_wells_5510_wellXNE_output;

TN GIGS_wells_5510_wellXNH_input GIGS_wells_5510_wellXNH_output
5511 Import wellbore position data from MD/Inc/Az - GIGS_wells_5511_wellYNC_input; A1 > A2 GIGS_wells_5511_wellYNC_output;
GN GIGS_wells_5511_wellYNF_input GIGS_wells_5511_wellYNF_output
5512 Import wellbore position data from MD/Inc/Az - GIGS_wells_5512_wellXSJ_input; F > F1 GIGS_wells_5512_wellXSJ_output;
TN (Southern Hemisphere) GIGS_wells_5512_wellXSK_input GIGS_wells_5512_wellXSK_output
5513 Import wellbore position data from MD/Inc/Az - GIGS_wells_5513_wellYSL_input; F7 > F1 GIGS_wells_5513_wellYSL_output;
GN (Southern Hemisphere) GIGS_wells_5513_wellYSM_input GIGS_wells_5513_wellYSM_output
5514 Import wellbore depth data from MD/Inc/Az GIGS_wells_5514_wellXNE_input; V1 depth GIGS_wells_5514_wellXNE_output;
GIGS_wells_5514_wellXNH_input GIGS_wells_5514_wellXNH_output
5515 Import wellbore depth data with change of GIGS_wells_5515_wellD_input; W1 depth > V1 depth GIGS_wells_5515_wellD_output;
vertical datum GIGS_wells_5515_wellYNC_input; GIGS_wells_5515_wellYNC_output;
GIGS_wells_5515_wellYNF_input GIGS_wells_5515_wellYNF_output
5516 Import wellbore depth data with TVDBML GIGS_wells_5516_wellG_input V1 depth GIGS_wells_5516_wellG_output
reference
5517 Import wellbore depth data with change of GIGS_wells_5517_wellB_input V1depth ft and m GIGS_wells_5517_wellB_output
vertical CRS unit
5518 Export wellbore data with conversion (map (Test Data loaded to project in earlier tests) A2 > A1 GIGS_wells_5518_output
projection) change.
5519 Export wellbore data with geodetic datum (Test Data loaded to project in earlier tests) A2 > B GIGS_wells_5519_output
change.
5520 Export wellbore data with change of horizontal (Test Data loaded to project in earlier tests) A2 > A23 GIGS_wells_5520_output
CRS units.
5521 Export wellbore data with vertical datum change. (Test Data loaded to project in earlier tests) V1 depth > W1 depth GIGS_wells_5521_output
5522 Transfer wellbore data with conversion (map (Test Data loaded to project in earlier tests) A2 > A1 GIGS_wells_5522_output
projection) change.
5523 Transfer wellbore data with geodetic datum (Test Data loaded to project in earlier tests) A2 > B GIGS_wells_5523_output
change.
91
5524 Transfer wellbore data with change of horizontal (Test Data loaded to project in earlier tests) A2 > A23 GIGS_wells_5524_output
CRS units.
5525 Transfer wellbore data with vertical datum (Test Data loaded to project in earlier tests) V1 depth > W1 depth GIGS_wells_5525_output
change.
5526 Import wellbore depth data referenced to GIGS_wells_5526_wellA_input A > V1 depth GIGS_wells_5526_wellA_output
ellipsoidal height
7000 - Deprecation
7001 Recognise EPSG deprecated data GIGS_dep_7001 N/A N/A
92
GIGS Test Dataset Index Maps

Small-scale Map of all GIGS Test Dataset Points (symbolised by Series)
Figure A1: Small-scale map of all GIGS Test Dataset Points
93
Large-scale Map of GIGS Test Dataset Points focused on Southern North Sea (symbolised by Series)
Figure A2: Large-scale map of GIGS Test Dataset Points focused on Southern North Sea
94
Small-scale Map of all 5100 Series (Conversions) GIGS Test Dataset Points (symbolised by Test Procedure)
Figure A3: Small-scale map of all 5100 Series GIGS Test Dataset Points
95
Small-scale Map of all 5200 Series (Transformations) GIGS Test Dataset Points (symbolised by Test Procedure)
96
Small-scale Map of all 5300 Series (2D Seismic) GIGS Test Dataset Points (symbolised by Test Procedure)
Figure A5: Small-scale map of all 5300 Series (2D Seismic) GIGS Test Dataset Points
97
Large-scale Map of 5300 Series (2D Seismic) GIGS Test Dataset Points focused on Southern North Sea (symbolised by Test Procedure)
Figure A6: Large-scale map of 5300 Series GIGS Test Dataset Points focused on Southern North Sea
98
Large-scale Map of 5400 Series (3D Seismic) GIGS Test Dataset Points (symbolised by Test Procedure)
Figure A7: Large-scale map of 5400 Series (3D Seismic) GIGS Test Dataset Points
99
Small-scale Map of all 5500 Series (Wells) GIGS Test Dataset Points (symbolised by Test Procedure)
100
Large-scale Map of 5500 Series (Wells) GIGS Test Dataset Points focused on Southern North Sea (symbolised by Test Procedure)
Figure A9: Large-scale map of 5500 Series GIGS Test Dataset Points focused on Southern North Sea
101
Large-scale Map of 5500 Series (Wells) GIGS Test Dataset Points focused on the South Pacific (symbolised by Test Procedure)
Figure A10: Large-scale map of 5500 Series GIGS Test Dataset Points focused on the South Pacific
102
Appendix B: Non-EPSG Nomenclature

Guide
The following guidance applies when conducting Test Procedures where the geoscience software
does not conform to the EPSG model or nomenclature.
The ISO/EPSG model represents the consensus of best practice that has evolved over 30 years of
digital geospatial data management. While it is assumed that future geoscience software will follow
the model, the current generation of geoscience software does not always do so. The GIGS Test
Dataset may be used with such geoscience software if the software’s model can be mapped to the
ISO/EPSG model. In this document it is impossible to cover all non-conformant cases. Commonly
encountered issues are:
• Nomenclature.
• Axes names and abbreviations and coordinate order may be hard-wired into the software
rather than being dependent upon CRS definition
• Units.
• Although not part of any formal CRS definition, some geoscience software requires that a
datum definition includes a transformation to WGS 84.
The most common is the use of ‘coordinate system’ to mean the ISO/EPSG entity coordinate
reference system. In the ISO/EPSG model, coordinate system is just one part of a CRS. Other
commonly encountered incorrectly used terms are ‘datum shift’ for coordinate transformation, and
‘spheroid’ for ellipsoid.
The names of coordinate conversion and coordinate transformation methods may sometimes be
problematic. Where particular terms are known to be encountered, these are noted in the relevant
Test Procedures in Series 1000. Another problem is that a single method name may be used to
apply to formulae that give significantly different results. This becomes apparent when results do
not correspond with the “expected results” in the Test Dataset.
The names of coordinate conversion and transformation method parameters may sometimes be
problematic. One term may incorrectly be used for all of ‘latitude of origin’, ‘latitude of natural
origin’ and ‘latitude of false origin’; similarly for longitude with the added complication that it may
be called ‘central meridian’. ‘False easting’, ‘easting at false origin’ and ‘easting at projection
centre’ may all be called ‘false easting’; similarly for ‘false northing’.
Care must be taken by the Evaluator to recognise such disparity in terms in particular software and
discretion used in undertaking associated Test Procedures; it is recommended that terminology
differences are reported.
103
Appendix C: GIGS to EPSG Code/Name

Relationship
The correlation between GIGS entities and “real world systems” as documented in the EPSG Dataset
is shown below, with the understanding that the official EPSG CRSs are limited to their specified
“area of use” as defined in the EPSG Dataset, whereas the corresponding GIGS CRSs have unlimited
area of use (i.e., they may be used for any geographic area of the Earth). This table only shows
horizontal geodetic data objects as the EPSG equivalence for vertical objects is much simpler and
can be found in the headers of respective Test Dataset files.
Table C1: Index of GIGS Test Dataset objects and associated EPSG Code/Names
GIGS Object Name GIGS Code Object Type EPSG Name EPSG Code Comment
GIGS geodetic datum A 66001 Geodetic datum World Geodetic System 1984 6326 Use as ensemble, or
ensemble specific realisation
GIGS geodetic datum B 66002 Geodetic datum Ordnance Survey of Great 6277
Britain 1936
GIGS geodetic datum B’ 66017 Geodetic datum N/A N/A Specific for early
binding with EPSG
transformation 1314
GIGS geodetic datum C 66003 Geodetic datum Amersfoort 6289
GIGS geodetic datum C’ 66018 Geodetic datum N/A N/A Specific for early binding
with GIGS coordinate
transformation 61003
GIGS geodetic datum D 66004 Geodetic datum Batavia (Jakarta) 6813
GIGS geodetic datum E 66005 Geodetic datum Reseau National Belge 1972 6313
GIGS geodetic datum E’ 66023 Geodetic datum N/A N/A Specific for early binding
with EPSG coordinate
GIGS geodetic datum F 66006 Geodetic datum Geocentric Datum of 6283

Australia 1994
GIGS geodetic datum G 66007 Geodetic datum European Terrestrial 6258; For late binding systems
Reference System 1989 6742; only. This GIGS Datum is
ensemble; Geodetic Datum 6152; functionally equivalent to
of Malaysia 2000; NAD83 6190; any static datum defined
(High Accuracy Reference 6674 as part of a geodetic
Network); Posiciones CRS that uses the GRS
Geodesicas Argentinas 1980 ellipsoid
1998; Sistema de Referencia
Geocentrico para las
AmericaS 2000
GIGS geodetic datum H 66008 Geodetic datum Nouvelle Triangulation 6807

Francaise (Paris)
GIGS geodetic datum J 66009 Geodetic datum North American Datum 1927 6267
GIGS geodetic datum J’ 66021 Geodetic datum N/A N/A Specific for early binding
transformation 1243
GIGS geodetic datum J’’ 66019 Geodetic datum N/A N/A
104
GIGS geodetic datum J’’’ 66020 Geodetic datum N/A N/A Specific for early binding
transformation 1693
GIGS geodetic datum T 66010 Geodetic datum Nouvelle Triangulation 6275

Francaise
GIGS geodetic datum L 66011 Geodetic datum Batavia 6211
GIGS geodetic datum K 66012 Geodetic datum Hungarian Datum 1972 6237
GIGS geodetic datum X 66013 Geodetic datum Australian Geodetic Datum 6202
1966
GIGS geodetic datum X’ 66022 Geodetic datum N/A N/A Specific for early binding
GIGS geodetic datum Y 66014 Geodetic datum Pulkovo 1942 6284
GIGS geodetic datum Z 66015 Geodetic datum North American Datum 1983 6269
GIGS geodetic datum M 66016 Geodetic datum European Datum 1950 6230
GIGS geodetic datum ZZ 66269 Geodetic datum North American Datum 1983 6269
GIGS geodetic datum AA 66326 Geodetic datum World Geodetic System 1984 6326
ensemble
GIGS geodetic datum BB 66277 Geodetic datum Ordnance Survey of Great 6277
Britain 1936
GIGS geodetic datum CC 66289 Geodetic datum Amersfoort 6289
GIGS geodetic datum DD 66813 Geodetic datum Batavia (Jakarta) 6813
GIGS geodetic datum EE 66313 Geodetic datum Reseau National Belge 1972 6313
GIGS geodetic datum FF 66283 Geodetic datum Geocentric Datum of 6283

Australia 1994
GIGS geodetic datum HH 66807 Geodetic datum Nouvelle Triangulation 6807

Francaise (Paris)
GIGS geocenCRS A 64001 Geodetic CRS WGS 84 4978
GIGS geog3DCRS A 64002 Geodetic CRS WGS 84 4979
GIGS geogCRS A 64003 Geodetic CRS WGS 84 4326
GIGS geogCRS Alonlat 64004 Geodetic CRS N/A N/A No direct EPSG
equivalent; WGS 84 with
CS axes changed
GIGS geogCRS Agr 64033 Geodetic CRS N/A N/A Latitude and longitude
for GIGS geogCRS A
in degrees, for GIGS
geogCRS Agr in grads
GIGS geog3DCRS B 64019 Geodetic CRS N/A N/A No direct EPSG

equivalent
GIGS geogCRS B 64005 Geodetic CRS OSGB36 4277
GIGS geog3DCRS C 64021 Geodetic CRS N/A N/A No direct EPSG

equivalent
GIGS geogCRS C 64006 Geodetic CRS Amersfoort 4289
GIGS geogCRS D 64007 Geodetic CRS Batavia (Jakarta) 4813
GIGS geog3DCRS E 64022 Geodetic CRS N/A N/A No direct EPSG

equivalent
105
GIGS geogCRS E 64008 Geodetic CRS Belge 1972 4313
GIGS geogCRS F 64009 Geodetic CRS GDA94 4283
GIGS geogCRS G 64010 Geodetic CRS ETRS89; GDM2000; 4258; For late binding systems
NAD83(HARN); 4742; only. This GIGS CRS is
POSGAR98; SIRGAS 2000; 4152; functionally equivalent
Hartebeesthoek94 4190; to any geodetic CRS with
4674; a static datum using the
4148 GRS 1980 ellipsoid
GIGS geogCRS H 64011 Geodetic CRS NTF (Paris) 4807
GIGS geogCRS J 64012 Geodetic CRS NAD27 4267
GIGS geogCRS T 64013 Geodetic CRS NTF 4275
GIGS geogCRS L 64014 Geodetic CRS Batavia 4211
GIGS geogCRS K 64015 Geodetic CRS HD72 4237
GIGS geogCRS X 64016 Geodetic CRS AGD66 4202
GIGS geogCRS Y 64017 Geodetic CRS Pulkovo 1942 4284
GIGS geogCRS Z 64018 Geodetic CRS NAD83 4269
GIGS geogCRS M 64020 Geodetic CRS ED50 4230
GIGS geogCRS ZZ 64269 Geodetic CRS NAD83 4269
GIGS geogCRS BB 64277 Geodetic CRS OSGB36 4277
GIGS geogCRS FF 64283 Geodetic CRS GDA94 4283
GIGS geogCRS CC 64289 Geodetic CRS Amersfoort 4289
GIGS geogCRS EE 64313 Geodetic CRS Belge 1972 4313
GIGS geogCRS AA 64326 Geodetic CRS WGS 84 4326
GIGS geogCRS HH 64807 Geodetic CRS NTF(Paris) 4807
GIGS geogCRS DD 64813 Geodetic CRS Batavia (Jakarta) 4813
GIGS geogCRS B’ 64023 Geodetic CRS N/A N/A Specific for early
binding with EPSG
transformation 1314
GIGS geog3DCRS B’ 64024 Geodetic CRS N/A N/A Specific for early
binding with EPSG
transformation 1314
GIGS geogCRS C’ 64025 Geodetic CRS N/A N/A Specific for early binding
GIGS geog3DCRS C’ 64026 Geodetic CRS N/A N/A Specific for early binding
GIGS geogCRS E’ 64027 Geodetic CRS N/A N/A Specific for early binding
GIGS geog3DCRS E’ 64028 Geodetic CRS N/A N/A Specific for early binding
GIGS geogCRS J’ 64029 Geodetic CRS N/A N/A Specific for early binding
transformation 1243
106
GIGS geogCRS J’’ 64030 Geodetic CRS N/A N/A Specific for early binding
transformation 1241
GIGS geogCRS J’’’ 64031 Geodetic CRS N/A N/A Specific for early binding
transformation 1693
GIGS geogCRS X’ 64032 Geodetic CRS N/A Specific for early binding
GIGS projCRS A1 62001 Projected CRS WGS 84 / UTM zone 31N 32631
GIGS projCRS A1-2 62002 Projected CRS N/A N/A No direct EPSG
equivalent; similar to
WGS 84 / UTM zone
31N but with different
Coordinate System
WGS 84 / UTM zone
Coordinate System
WGS 84 / UTM zone
Coordinate System
WGS 84 / UTM zone
Coordinate System
WGS 84 / UTM zone
Coordinate System
GIGS projCRS A2 62007 Projected CRS N/A N/A No direct EPSG

equivalent; would be
equivalent to WGS 84 /
British National Grid.
For GIGS purposes only
- no equivalent system
exists in the real world.
GIGS projCRS A21 62008 Projected CRS N/A N/A To be used as an

alternative to GIGS
projCRS A2 if the
software is unable to
define a Transverse
Mercator projection with
latitude of natural origin
not on the equator.
GIGS projCRS B2 62009 Projected CRS OSGB36 / British National Grid 27700
107
GIGS projCRS B22 62010 Projected CRS N/A N/A To be used as an

alternative to GIGS
projCRS B2 if the
software is unable to
define a Transverse
Mercator projection with
latitude of natural origin
not on the equator.
GIGS projCRS C4 62011 Projected CRS Amersfoort / RD New 28992
GIGS projCRS D5 62012 Projected CRS N/A N/A Equivalent to Batavia

/ NEIEZ (code 3001)
except that its definition
is with respect to the
Jakarta meridian; See
GIGS projCRS L27
(62037)
GIGS projCRS E6 62013 Projected CRS Belge 1972 / Belgian Lambert 31370
72
GIGS projCRS F7 62014 Projected CRS GDA94 / MGA zone 54 28354
GIGS projCRS F8 62015 Projected CRS GDA94 / MGA zone 55 28355
GIGS projCRS F9 62016 Projected CRS GDA94 / Australian Albers 3577
GIGS projCRS G10 62017 Projected CRS Hartebeesthoek94 / Lo21 2049
GIGS projCRS G11 62018 Projected CRS POSGAR 98 / Argentina 5 22175
GIGS projCRS G12 62019 Projected CRS SIRGAS2000 / Brazil 5880

Polyconic
GIGS projCRS G13 62020 Projected CRS N/A N/A No direct EPSG
equivalent; Functionally
equivalent to GDM2000
/ East Malaysia BRSO;
utilising different
projection
GIGS projCRS G14 62021 Projected CRS GDM2000 / East Malaysia 3376
BRSO
GIGS projCRS G15 62022 Projected CRS GDM2000 / Johor Grid 3377
GIGS projCRS G16 62023 Projected CRS ETRS89-extended / LAEA 3035

Europe
GIGS projCRS G17 62024 Projected CRS NAD83(HARN) / Utah North 2921
(ft)
GIGS projCRS G18 62025 Projected CRS NAD83(HARN) / Utah North 3568
(ftUS)
GIGS projCRS H19 62026 Projected CRS NTF (Paris) / Lambert zone II 27572
GIGS projCRS A23 62027 Projected CRS N/A N/A No direct EPSG
equivalent; would be
equivalent to WGS 84
/ BLM 31N (ftUS). For
GIGS purposes only - no
equivalent system exists
in the real world.
GIGS projCRS Y24 62034 Projected CRS Pulkovo 1942 / Caspian Sea 3388
Mercator
108
GIGS projCRS M25 62035 Projected CRS N/A N/A No direct EPSG
equivalent; Deprecated
EPSG projCRS
2192 ED50 / France
EuroLambert;
remains relevant as
represents LCC 1SP;
not to be confused with
replacement EPSG
projCRS 2154 RGF93 /
Lambert-93 (LCC 2SP)
GIGS projCRS K26 62036 Projected CRS HD72 / EOV 23700
GIGS projCRS L27 62037 Projected CRS Batavia / NEIEZ 3001
GIGS projCRS J28 62038 Projected CRS NAD27 / UTM zone 8N 26708
GIGS projCRS Z28 62039 Projected CRS NAD83 / UTM zone 8N 26908
GIGS projCRS AA1 62028 Projected CRS WGS 84 / UTM zone 31N 32631
GIGS projCRS BB2 62029 Projected CRS OSGB36 / British National Grid 27700
GIGS projCRS CC4 62030 Projected CRS Amersfoort / RD New 28992
GIGS projCRS EE6 62031 Projected CRS Belge 1972 / Belgian Lambert 31370
72
GIGS projCRS FF8 62032 Projected CRS GDA94 / MGA zone 54 28354
GIGS projCRS HH19 62033 Projected CRS NTF (Paris) / Lambert zone II 27572
GIGS ellipsoid A 67030 Ellipsoid WGS 84 7030
GIGS ellipsoid B 67001 Ellipsoid Airy 1830 7001
GIGS ellipsoid C 67004 Ellipsoid Bessel 1841 7004
GIGS ellipsoid E 67022 Ellipsoid International 1924 7022
GIGS ellipsoid F 67019 Ellipsoid GRS 1980 7019
GIGS ellipsoid H 67011 Ellipsoid Clarke 1880 (IGN) 7011
GIGS ellipsoid I 67052 Ellipsoid Clarke 1866 Authalic Sphere 7052
GIGS ellipsoid J 67008 Ellipsoid Clarke 1866 7008
GIGS ellipsoid K 67036 Ellipsoid GRS 1967 7036
GIGS ellipsoid X 67003 Ellipsoid Australian National Spheroid 7003
GIGS ellipsoid Y 67024 Ellipsoid Krassowsky 1940 7024
GIGS PM A 68901 Prime Meridian Greenwich 8901
GIGS PM D 68908 Prime Meridian Jakarta 8908
GIGS PM H 68903 Prime Meridian Paris 8903
GIGS PM I 68904 Prime Meridian Bogota 8904
GIGS conversion 1 65001 Conversion UTM zone 31N 16031
GIGS conversion 2 65002 Conversion British National Grid 19916
GIGS conversion 4 65004 Conversion RD New 19914
GIGS conversion 5 65005 Conversion Netherlands East Indies 5328

Equatorial Zone (Jkt)
GIGS conversion 6 65006 Conversion Belgian Lambert 72 19961
109
GIGS conversion 7 65007 Conversion Australian Map Grid zone 54 17454
GIGS conversion 8 65008 Conversion Australian Map Grid zone 55 17455
GIGS conversion 9 65009 Conversion Australian Albers 17365
GIGS conversion 10 65010 Conversion South African Survey Grid 17521

zone 21
GIGS conversion 11 65011 Conversion Argentina zone 5 18035
GIGS conversion 12 65012 Conversion Brazil Polyconic 19941
GIGS conversion 13 65013 Conversion N/A N/A No direct EPSG

equivalent; EPSG 19894
but referenced using
Hotine Oblique Mercator
(variant B) rather than
Hotine Oblique Mercator
(variant A) method
GIGS conversion 14 65014 Conversion Borneo RSO 19894
GIGS conversion 15 65015 Conversion Johor Grid 19893
GIGS conversion 16 65016 Conversion Europe Equal Area 2001 19986
GIGS conversion 17 65017 Conversion SPCS83 Utah North zone 15362

(International feet)
GIGS conversion 18 65018 Conversion SPCS83 Utah North zone (US 15297
Survey feet)
GIGS conversion 19 65019 Conversion Lambert zone II 18082
GIGS conversion 2 alt A 65021 Conversion N/A N/A No direct EPSG

equivalent; Alternative
when applied to WGS 84
ellipsoid; Only needed if
61002 is not possible
GIGS conversion 2 alt B 65022 Conversion N/A N/A No direct EPSG

equivalent; Alternative
when applied to Airy
1830 ellipsoid; Only
needed if 61002 is not
possible
GIGS conversion 23 65023 Conversion N/A N/A No direct equivalent;

but would be called
BLM 31N (ftUS); EPSG
16031 (UTM zone 31N)
but Units in ftUS rather
than m
GIGS conversion 24 65024 Conversion Caspian Sea Mercator 19884
GIGS conversion 25 65025 Conversion N/A N/A No direct EPSG

equivalent; Deprecated
EPSG 18086 France
EuroLambert;
remains relevant as
represents LCC 1SP;
not to be confused with
replacement EPSG
18085 Lambert-93 (LCC
2SP)
GIGS conversion 26 65026 Conversion Egyseges Orszagos Vetuleti 19931
110
GIGS conversion 27 65027 Conversion Netherlands East Indies 19905

Equatorial Zone
GIGS conversion 28 65028 Conversion UTM zone 8N 16008
GIGS geogCRS A to WGS 61001 Coordinate N/A N/A No direct EPSG

84 (1) Transformation equivalent
GIGS geogCRS B to GIGS 61196 Coordinate OSGB36 to WGS 84 (2) 1196

geogCRS A (1) Transformation
GIGS geogCRS B to GIGS 61314 Coordinate OSGB36 to WGS 84 (6) 1314

GIGS geogCRS C to GIGS 61002 Coordinate N/A N/A No direct EPSG

geogCRS A (1) Transformation equivalent
GIGS geogCRS C to GIGS 15934 Coordinate Amersfoort to WGS 84 (3) 15934

GIGS geogCRS C to GIGS 61003 Coordinate N/A N/A No direct EPSG

geogCRS A (3) Transformation equivalent; parameter
values taken from 15740
Amersfoort to ETRS89 (4)
GIGS geogCRS D to GIGS 61759 Coordinate Batavia (Jakarta) to Batavia 1759

geogCRS L (1) Transformation (1)
GIGS geogCRS E to GIGS 61610 Coordinate BD72 to WGS 84 (2) 1610

GIGS geogCRS E to GIGS 15929 Coordinate BD72 to WGS 84 (3) 15929

GIGS geogCRS F to GIGS 61150 Coordinate GDA94 to WGS 84 (1) 1150

GIGS geogCRS H to GIGS 61763 Coordinate NTF (Paris) to NTF (1) 1763
geogCRS T (1) Transformation
GIGS geogCRS J to GIGS 61173 Coordinate NAD27 to WGS 84 (4) 1173

GIGS geogCRS J to GIGS 61004 Coordinate N/A N/A No direct EPSG

geogCRS A (2) Transformation equivalent; files included
with GIGS Test Dataset
GIGS geogCRS J to GIGS 61692 Coordinate NAD27 to WGS 84 (34) 1692

GIGS geogCRS K to GIGS 61242 Coordinate HD72 to WGS 84 (4) 1242

GIGS geogCRS L to GIGS 61123 Coordinate Batavia to WGS 84 (1) 8452

GIGS geogCRS M to 61275 Coordinate ED50 to WGS 84 (17) 1275

GIGS geogCRS A (1) Transformation
GIGS geogCRS T to GIGS 61193 Coordinate NTF to WGS 84 (1) 1193

GIGS geogCRS X to GIGS 15788 Coordinate AGD66 to WGS 84 (16) 15788

GIGS geogCRS Y to GIGS 61254 Coordinate Pulkovo 1942 to WGS 84 (1) 1254
GIGS geogCRS Z to GIGS 61188 Coordinate NAD83 to WGS 84 (1) 1188

111
Appendix D: GIGS Project Definitions
For the Data Operations tests (5000 Series), Test Data must be loaded into the geoscience software.
This will normally require the creation of a ‘project’ within the software. To comply with the test
scenarios these projects need to be defined to reference specific coordinate reference systems.
GIGS project names have been constructed from the required horizontal and vertical CRS names.
For example, “GIGS project A9V1depth” is to be referenced to horizontal CRS “A9” and vertical CRS
“V1 depth”. The project CRSs are detailed below:
GIGS_project_A2V1depth
This project is used for many of the GIGS well and seismic location import tests. This project should
be referenced to the following horizontal and vertical CRSs:
Horizontal CRS: GIGS projCRS A2
Vertical CRS: GIGS vertCRS V1 depth

1) The project area covers the following geographic bounding rectangle:
north: 52°40’N, south: 51°40’N, west: 1°40’E, east: 3°40’E
2) Horizontal CRS: GIGS projCRS A2
This is equivalent to the geodetically fictitious CRS WGS 84 / British National Grid except that “A2” is
not limited by the associated EPSG Area of Use limitations for the British National Grid conversion.
Defining parameters are built up through Test Procedures 3001 through 3006 and possibly 3007.
Alternatively, if the required predefined library components are available, the CRS could be defined
through association of the British National Grid conversion with WGS 84 geodetic datum and an
appropriate Cartesian coordinate system, assuming that associated EPSG area of use limitations
are overridden. Note: this can only be done in software in which the ellipsoid parameters are part of
the datum definition and are not part of the conversion definition.
Horizontal CRS components:
Ellipsoid: GIGS ellipsoid A, a = 6,378,137.0m, 1/f = 298.2572236 (= WGS 84, EPSG ellipsoid code 7030)
Prime meridian: GIGS PM A (= Greenwich, EPSG prime meridian code 8901)
Geodetic datum: name = GIGS geodetic datum A. (= WGS 84, EPSG datum code 6326)
(Coordinate transformation relationship to WGS 84: geocentric translations dX=dY=dZ=0)
Conversion: GIGS conversion 2 (= British National Grid, EPSG conversion code 19916):
method = Transverse Mercator (= EPSG coordinate operation method code 9807)

latitude of natural origin = 49°N
longitude of natural origin = 2°W
scale factor at natural origin = 0.9996012717
112
false easting = 400,000.0 metres

false northing = -100,000.0 metres (note: minus)
Coordinate system: (= EPSG coordinate system code 4400):

first axis = easting, direction = east, abbreviation = E, units = metre
second axis = northing, direction = north, abbreviation = N, units = metre
3) Vertical CRS: GIGS vertCRS V1 depth
This is equivalent to the CRS Baltic 1977 depth (EPSG CRS code 5612) which has no geodetic validity
in the project area but, for GIGS purposes, has been assumed to have global applicability.
For GIGS purposes in case the software “assumes” a vertical datum of mean sea level (msl), this
CRS has been defined to be equal to unspecified MSLdepth (EPSG CRS code 5715).
Defining parameters are built up through Test Procedures 3008 and possibly 3009.
Vertical CRS components:
Vertical datum (= EPSG datum code 5105):

name = GIGS vertical datum V
Coordinate system (= EPSG coordinate system code 6498):
axis = Depth, direction = down, abbreviation = D, unit = metre
GIGS_project_F1V_F7V1depth
This project is used for some GIGS well tests.
This project should be referenced to the following horizontal and vertical CRSs:
Horizontal: GIGS projCRS F7
Vertical: GIGS vertCRS V1 depth

north: 51°40’S, south: 52°40’S, west: 139°40’E, east: 141°40’E
2) Horizontal CRS: GIGS projCRS F7
This GIGS projCRS F7 is equivalent to the EPSG CRS GDA 94 / MGA zone 54 (EPSG CRS code 28354)
except “F7” is not limited by the associated EPSG Area of Use for that CRS.
Horizontal CRS definitions as follows:
Ellipsoid: GIGS ellipsoid A, a = 6,378,137.0m, 1/f = 298.2572221 (= GRS 80, EPSG ellipsoid code 7019)
Prime meridian: GIGS PM A (= Greenwich, EPSG prime meridian code 8901)
Geodetic datum: name = GIGS geodetic datum F. (= GDA 94, EPSG datum code 6283)
113
Conversion: GIGS conversion 7 (= MGA zone 54, EPSG conversion code 17354):

longitude of natural origin = 141°E
false northing = 10,000,000.0 metres

3) Vertical CRS GIGS vertCRS V1 depth

See GIGS_project_A2V1depth.
GIGS_project_A1W_A1W1depth
This project is used for some GIGS seismic location and wellbore transfer tests. This project should
be referenced to the following horizontal and vertical CRSs:
Horizontal: GIGS projCRS A1
Vertical: GIGS vertCRS W1 depth

This is equivalent to EPSG CRS WGS 84 / UTM zone 31N (EPSG CRS code 32631) except that “A1” is
not limited by the associated EPSG Area of Use for that CRS.
Prime Meridian: GIGS PM A (= Greenwich, EPSG prime meridian code 8901)
Geodetic Datum: name = GIGS geodetic datum A (= WGS 84, EPSG datum code 6326)
Conversion: GIGS conversion 1 (= UTM zone 31N, EPSG conversion code 16031):

false northing = 0.0 metres
114

3) Vertical CRS “GIGS vertCRS W1 depth
This is equivalent to the EPSG CRS Caspian depth (EPSG CRS code 5706) which has no geodetic
validity in the project area but, for GIGS purposes, has been assumed to have global applicability.
For GIGS purposes in case the software “assumes” a vertical datum of msl, this vertical datum has
been defined (through GIGS coordinate transformation codes 65440, 65441, 65400 and 65438) to
be equal to 28m below GIGS vertical datum V which, as elsewhere, has been defined to be equal to
unspecified msl.
Defining parameters are built up through Test Procedure 3008 and possibly 3009.
Vertical CRS components:
Vertical datum: name = GIGS vertical datum W (= EPSG datum code 5105)
axis = Depth, direction = down, abbreviation = D, unit = metre
GIGS_project_A9V_A23V1depth
be referenced to the following horizontal and vertical CRSs, which are defined below:
Horizontal: GIGS projCRS A23

This is equivalent to WGS 84 / UTM zone 31N in US survey feet. There is no equivalent to this
fictitious CRS in the EPSG Dataset.
Geodetic Datum: name = GIGS geodetic datum A (= WGS 84, EPSG datum code 6326)
115
Conversion: GIGS conversion 23.

false Easting = 1,640,416.667 US survey feet
false Northing = 0.0 US survey feet
1 US survey foot = 12/39.37 metres
first axis = easting, direction = east, abbreviation = X, units = US survey foot
second axis = northing, direction = north, abbreviation = Y, units = US survey foot

GIGS_project_B1V_B2V1depth
be referenced to the following horizontal and vertical CRSs,
Horizontal: GIGS projCRS B2

2) Horizontal CRS: GIGS projCRS B2
This is equivalent to EPSG CRS OSGB36 / British National Grid (EPSG CRS code 27700) except that
for GIGS purposes the area of applicability is fictitiously extended. That is, GIGS ProjCRS B1 is not
limited by the associated EPSG Area of Use for EPSG Code 27700.
Ellipsoid: GIGS ellipsoid B, a = 6,377,563.396m, 1/f = 299.3249646 (= Airy 1830, EPSG ellipsoid code
7001)
Geodetic Datum: name = GIGS geodetic datum B (= Ordnance Survey of Great Britain 1936, EPSG
datum code 6277)
(For GIGS purposes only, GIGS geogCRS B is defined with the relationship to GIGS geogCRS A (WGS
84): geocentric translations dX=371m, dY=-112 m (note: minus) and dZ=434m)
116
Conversion: GIGS conversion 2 (= British National Grid, EPSG conversion code 19916)

false northing = -100,000.0 metres (note: minus)


GIGS_project_Z28V1depth
This project is used for some GIGS seismic location tests. This project should be referenced to the
following horizontal and vertical CRSs:
Horizontal: GIGS projCRS Z28

north: 75°N, south: 15°N, west: 165°E, east: 85°W. Note that this crosses the 180° meridian.
2) Horizontal CRS: GIGS projCRS Z28
This is equivalent to EPSG CRS NAD83 / UTM zone 8N (EPSG CRS code 26908) except that for GIGS
purposes the area of applicability is fictitiously extended. That is, GIGS ProjCRS Z28 is not limited by
the associated EPSG Area of Use for EPSG Code 26908.
Ellipsoid: GIGS ellipsoid J, a = 6,378206.4m, 1/f = 294.9786982 (= Clarke 1866, EPSG ellipsoid code
7008)
Geodetic Datum: name = GIGS geodetic datum J (=North American Datum 1927, EPSG datum code
6267)
(For GIGS purposes only, GIGS geogCRS J is defined with the relationship to GIGS geogCRS A (WGS
84): geocentric translations dX=-8m (note: minus), dY=160m and dZ=176m)
117
Conversion: GIGS conversion 28 (= UTM zone 8N, EPSG conversion code 16008)

false northing = 0.0 metres


118
Appendix E: GIGS Supported Coordinate

Operation Methods
Test Datasets were produced for many of the conversion and transformation methods as identified
in the EPSG Dataset. Methods identified as high or medium priority for the energy industry have
been addressed and associated Test Data are provided. The table below, lists the included methods
and also notes the mechanism used for calculating the test point data. In most cases, spreadsheets
developed by EPSG for verifying formulae published in IOGP Report 373-07-02 – Geomatics Guidance
Note Number 7, part 2 - Coordinate Conversions and Transformations including Formulas are available
upon request. All of the conversion and transformation Test Data have been rigorously verified using
independently sourced geodetic software.
Table E1: Index of GIGS Test Dataset coordinate operation methods
EPSG Method Name EPSG Method Code Calculation Method for Test Data
Transverse Mercator 9807 EPSG calculations

Lambert Conic Conformal (1SP) 9801 EPSG calculations
Lambert Conic Conformal (2SP) 9802 EPSG calculations
Oblique Stereographic 9809 EPSG calculations
Hotine Oblique Mercator (variant A) 9812 EPSG calculations
Hotine Oblique Mercator (variant B) 9815 EPSG calculations
American Polyconic 9818 EPSG calculations
Cassini-Soldner 9806 EPSG calculations
Albers Equal Area 9822 Geomatrix
Lambert Azimuthal Equal Area 9820 EPSG calculations
Mercator (variant A) 9804 EPSG calculations
Mercator (variant B) 9805 EPSG calculations
Transverse Mercator (South Orientated) 9808 EPSG calculations
Geographic/geocentric conversions 9602 EPSG calculations
Geocentric translations (geocentric domain) 1031 EPSG calculations
Geocentric translations (geog2D domain) 9603 EPSG calculations
Geocentric translations (geog3D domain) 1035 EPSG calculations
Abridged Molodensky 9605 EPSG calculations
Position Vector transformation (geog2D domain) 9606 EPSG calculations
Position Vector transformation (geog3D domain) 1037 EPSG calculations
Coordinate Frame Rotation (geog2D domain) 9607 EPSG calculations
Coordinate Frame Rotation (geog3D domain) 1038 EPSG calculations
Molodensky-Badekas (geog2D domain) 9636 EPSG calculations
Molodensky-Badekas (geog3D domain) 1039 EPSG calculations
NADCON 9613 US National Geodetic Survey (NGS) online calculator
NTv2 9615 Natural Resources Canada and Land Victoria
(Australia) online calculators
Longitude rotation 9601 Manual
UKOOA P6 seismic bin grid transformation 9666 EPSG calculations
Vertical Offset 9616 EPSG calculations
119
Appendix F: Test Dataset Excel Files Guide
Where the Evaluator requires the Test Dataset files to be read in Excel there are a number of
workflows that can be used to correctly load the data in a controlled way, avoiding truncation and
rounding issues. A data import wizard should always be used, as loading the files directly (either
by ‘Open’, drag and drop or through Windows Explorer) may cause formatting problems. It is highly
recommended that Method 3 is used. Note these recommendations are only valid at the time of
publication and pertain to the specific software versions available at such time. IOGP takes no
responsibility for the accuracy of the content within.
Method 1: Using “From Text” Text Import Wizard (legacy)

The Excel legacy Text Import Wizard is present in pre-2016 versions of Office, or can be enabled for
use in newer versions22
To load a Test Dataset file, open the From Text Wizard from the Get Data function in the Get and
Transform Data section (Data ribbon).
https://support.microsoft.com/en-us/office/text-import-wizard-c5b02af6-fda1-4440-899f-f78bafe41857
22
120
Select the file to import
Select Delimited
121
Tick on Tab
Select all columns (using shift + right click) in Data Preview and tick on Text
122
Select Existing Worksheet and cell A1
To help column identification, select the Field names in the hash header and copy
123
Right click on the final hash row (in the first column) and select Paste Special
Select Transpose
124
If required, hide the hash header and set column names to Wrap Text, adjust column widths until
suitable
Method 2: Using “From Text/CSV” Get Data Wizard (manual)

To load a Test Dataset file, open the From Text/CSV Wizard from the Get Data function in the Get and
125
Select Load and data should appear as a Queried table
126
To help column identification, select the Field names in the hash header and copy
Right click on the first row showing as Column1 (first column) select Paste Special
127
Select Transpose
If required, hide the hash header by applying a text filter to the first column
128
Enter does not contain “#”
Data should then appear with the header filtered out, and is fully sortable
The style of the table can be further refined in the Table Design ribbon
129
Method 3: Using “From Text/CSV” Get Data Wizard and PowerQuery (semi-
automated)
To load a Test Dataset file, open the From Text/CSV Wizard from the Get Data function in the Get and
130
Select Transform Data
In Power Query Editor, open the Advanced Editor, from the Query section of Home ribbon
131
Below the “Source =” line (NOTE: this line is typically wrapped, but it depends on the Display
Options) insert the following query lines:
/*Remove header information and fetch the Test Data*/
ColName = Table.ColumnNames(Source){0},
GigsTestData = Table.SelectRows(Source, each not Text.StartsWith( Record.Field(
_ , ColName) , “#”)),
/* Extract origina colums names */

OldCaptionList = Table.ColumnNames(Source),
/* Generate new colum names from header information */

GigsCaptionList =
List.Transform(List.RemoveLastN(Table.ToList(Table.SelectRows(Source,
each Text.StartsWith(Record.Field( _ , ColName), “# [“)), Combiner.
CombineTextByDelimiter(“”)),1), each Text.AfterDelimiter( _ , “]:”)),
/* Generate column rename lists */

RenameCaptionList = List.Zip({OldCaptionList, GigsCaptionList}),
/* Rename Gigs Test Data colums */

FinalGigsTestDataResult = Table.RenameColumns(GigsTestData,
RenameCaptionList),
/* Change all column types to text in order to avoid rounding errors etc */
#”Changed Type” = Table.TransformColumnTypes(FinalGigsTestDataResult,
List.Transform( Table.ColumnNames(FinalGigsTestDataResult), each { _, type
text } ) )
The resulting Editor view should appear as below
132
Delete the last line in the “let” section and ensure that the last line in the let section does not end
with a comma as illustrated below
Ensure there are no Syntax errors detected and select Done, then select Close & Load
133
Data should then appear as Queried table in Excel, without a header. Note that if the location/
content of the source txt file changes then the query will need to be updated
The style of the table can be further refined in the Table Design ribbon
134
This page is intentionally blank
135
Registered Office Brussels Office Houston Office www.iogp.org
City Tower, Level 14 Avenue de Tervuren 188A 15377 Memorial Drive Follow us on Twitter:
40 Basinghall Street B-1150 Brussels Suite 250 @iogp_news
London EC2V 5DE Belgium Houston, TX 77079 Connect with us on LinkedIn:
United Kingdom USA www.iogp.org/linkedin
T +44 (0)20 3763 9700 T +32 (0)2 790 7762 T +1 (713) 261 0411 Follow us on Facebook:
reception@iogp.org reception-europe@iogp.org reception-americas@iogp.org www.facebook.com/IOGPNews
GIGS is an open-source digital testing

framework designed to evaluate the
capability of software in establishing
and maintaining the integrity of
geospatial data. It is primarily aimed
at geoscience applications, but
elements can be readily applied to
any software that handles spatial
data. The testing framework
comprises a series of qualitative
evaluations that assess software
functionality and configuration,
coupled with data-driven tests that
quantify the accuracy and robustness
of geodetic engines and libraries,
in executing coordinate operations.
The test package is supported by two
documents, a general Guidance Note
on the theory of geospatial integrity
and GIGS testing (IOGP Report 430-
1) and a comprehensive User Guide
providing technical procedures
for executing the GIGS tests
(IOGP Report 430-2, this document).

Geospatial Integrity of Geoscience Software (GIGS) User Guide

Uploaded by

Document Informationclick to expand document informationIADC

Document Informationclick to expand document information

Copyright:

Available Formats

Geospatial Integrity of Geoscience Software (GIGS) User Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Geospatial Integrity of Geoscience Software (GIGS) User Guide

Uploaded by

Copyright:

Available Formats

REPORT NOVEMBER

Geospatial Integrity of Geoscience

Front cover photography used with permission courtesy of

IOGP welcomes feedback on our reports: publications@iogp.org

Geospatial Integrity of Geoscience

VERSION DATE AMENDMENTS

2.0 November 2021 Major revision

1.0 September 2011 First release

1. GIGS Test Series User Guide 9

2. GIGS Test Dataset User Guide 20

2.5 Test Dataset Numeric Precision and Representation 26

Appendix A: GIGS Test Dataset Index and Maps 85

Appendix B: Non-EPSG Nomenclature Guide 103

Appendix C: GIGS to EPSG Code/Name Relationship 104

Appendix D: GIGS Project Definitions 112

Appendix E: GIGS Supported Coordinate Operation Methods 119

Appendix F: Test Dataset Excel Files Guide 120

• 3000 – User-defined Geodetic Entities

1. GIGS Test Series User Guide

Coordinate Reference The association of geodetic metadata to coordinates, and general

Overview documentation, release notes and knowledge bases relating

The nomenclature, user-oriented nature and accuracy of information of

Data Operations The range and accuracy of coordinate operations, specifically

The deprecation of algorithms and files within the geodetic engine of

Figure 1: GIGS Test Series, at time of publication

Figure 2: GIGS ‘offline’ spreadsheet term definitions

Figure 3: GIGS ‘online’ web portal term definitions

The GIGS Levels (and associated colour indicators) are:

Table 1: GIGS Level definitions

No GIGS Score directly compromises geospatial integrity

1.2.1 Elementary Level

1.3 GIGS Test Series Process

The following workflow is recommended for completing the Test Series:

1.3.1 Populating Test Series Checklists

{data/object} is/is not supported and/or {application} does/does not do {function}

It is highly recommended that supporting comments and evidence are attached to

1.4 Flowchart and Test Correlations

Additionally, a comprehensive flowchart of the Test Series architecture is provided as an

1.5 Test Series General Guidelines

The Conditionals selection can be changed at any point in an evaluation if application

1.5.2 0000 Coordinate Reference Systems

1.5.3 1000 General User Documentation

1.5.4 2100 Predefined Geodetic Parameter Library

1.5.5 2200 Predefined Geodetic Data Objects

1.5.6 3100 User-defined Geodetic Parameter Library

1.5.7 3200 User-defined Geodetic Data Objects

1.5.8 4000 User Interface

1.5.9 5100 Data Operations (Conversions)

1.5.10 5200 Data Operations (Coordinate Transformations)

Coordinate transformation methods of particular interest to the energy industry are

1.5.11 5300 Data Operations (2D Seismic Position Data)

1.5.12 5400 Data Operations (3D Seismic Position Data)

1.5.13 5500 Data Operations (Surface and Wellbore Deviation Data)

1.5.14 6000 Audit Trail

1.5.15 7000 Deprecation

1.5.16 Error Trapping

2. GIGS Test Dataset User Guide