[ Table of contents ]

11   Application program interface

11.1    Introduction

This International Standard specifies an API for the SRF operations in Clause 5 and Clause 10. The API specifies non-object data types (see 11.2), and object classes (see 11.3) used to perform the spatial operations. Two functions are provided to create certain object instances (see 11.4 and 11.5). Two query functions are also provided to indicate the extent of support of an API implementation for a profile of the SRM (see 11.6 and Clause 12). The API also specifies data storage structures for the representation of SRM concepts that are not used to perform spatial operations (see 11.9).

Class is the term used to categorize the general form of object instances. Each class definition specifies the methods (if any) that operate on the object. Methods are specified by giving their syntax (input and output parameters), semantics (how the inputs interact with the state of an instance of the class and produce any outputs), and error conditions. In particular, the state of an instance of the class is implicitly an input for each of its methods with the exception of the Create method. The Create method of an object depends only on its explicit inputs. The state of a class instance may change only as the result of applying a method of the class.

The active objects created as instances of a given class are reliably denoted by object references. Once created, objects exist and respond to method invocations until they are destroyed. The property of being created and existing until destruction is termed the object life cycle. Classes inherit methods from other classes through the subclass/superclass relationship. Method inheritance is transitive: a subclass also inherits the methods that have been inherited by its superclass.

Non-object data types do not have an object life cycle nor do they have operations other than those defined by a programming language that this API might be bound to.

EXAMPLE   Integer is a non-object data type. Programming languages to which this API may be bound have definition mechanisms and operations for creating and then performing arithmetic operations on integers as variables and/or constants in the programming language.

The API specifies seven abstract classes (see 11.3.3 and 11.3.5):

a)       LifeCycleObject,

b)       BaseSRF,

c)       BaseSRF2D,

d)       BaseSRF3D,

e)       BaseSRFwithTangentPlaneSurface,

f)         BaseSRFwithEllipsoidalHeight, and

g)       BaseSRFMapProjection.

These abstract classes are used as base classes from which subclasses including concrete classes inherit common sets of methods. LifeCycleObject includes the creation and destruction methods that all other classes inherit. The LifeCycleObject creation method specification may be overridden in a concrete subclass to provide subclass specific inputs and error conditions. The use of abstract classes in this International Specification is solely for the purpose of specifying common methods in only one place instead of repeating the same specification in each concrete class for which it applies. API implementations are not required to implement abstract classes.

The API specifies six classes whose methods are not exposed as part of the API:

a)       three coordinate classes: Coordinate2D, Coordinate3D, and SurfaceCoordinate;

b)       one direction class Direction and

c)       two position classes: Position2D, and Position3D.

These classes are private classes that hide all aspects of the implementation of instances of these objects from the application.

The API specifies a set of concrete classes that correspond to specific SRFTs specified in Clause 8 (see 11.3.6 through 11.3.10). An instance of one of these concrete classes corresponds to a specific SRF.

Instances of concrete SRF classes that correspond to the coded collection of SRFT instances specified in Table 8.30 are created by a function. This function CreateStandardSRF is a function of the corresponding SRF_Code (see 11.4).

Instances of concrete SRF classes that correspond to the members of SRF Sets specified in Table 8.31 are also created by a function. This function CreateSRFSetMember is a function of that takes as an input the SRFS_Code_Info (see 11.5).

The class hierarchy is illustrated in Figure 11.1. Procedural rules for using LifeCycleObjects in applications and examples of use of the API are provided in 11.8.

11.2    Non-object data types

11.2.1    Overview

Basic non-object data types represent single pieces of information such as numbers, codes, and other individual data items. Structured data types represent data records of basic non-object data types.

11.2.2    Abbreviations

Table 11.1 lists the SRFTs and their abbreviations used in the formation of enumerant names and record element names of non-object types.

Table 11.1 — SRFT abbreviations

 

11.2.3    Numbers

Two categories of numbers are specified: integer numbers and floating-point numbers. The general-purpose integer data types are Integer_Positive and Integer. All implementations that conform to this standard shall support at least the minimum ranges for values of these data types as specified in Table 11.2.

Table 11.2 — Integer data types

 

Long_Float is a non-object data type defined for floating-point numbers. This data type corresponds to the double precision floating-point data type specified by IEC 60559. However, implementations on architectures that support other floating-point representations are allowed.

11.2.4    Logicals

The general-purpose logical data type is Boolean. All implementations that conform to this standard shall support this type as specified in Table 11.3.

Table 11.3 — Logical data type

 

11.2.5    Object_Reference

An Object_Reference is an opaque non-object data type that allows an application to reliably access an instance of an object. Object_References may be compared for equality and tested to see if they are equal to the special value NULL_Object. If two Object_References are equal, they refer to the same object instance. If an Object_Reference is equal to the special value NULL_Object it does not reference any object instance. In all the method specifications in this clause, whenever an argument passed to or returned from a method is an object, it is an object reference that is passed.

11.2.6    Enumerated data types

11.2.6.1        Introduction

Enumerated data types are data types whose values are specified from an ordered list of names. The names are assigned numbers whose values indicate the position within the ordered list. It is these numbers that are actually manipulated by the implementation. Enumerated data types are a closed list the members of which do not change based on registration or deprecation. This clause specifies the enumerated data types within this International Standard.

11.2.6.2        Axis_Direction

This data type represents the values of the axis direction parameter(s) of the SRFTs LOCAL_SPACE_RECTANGULAR_3D and LOCAL_SPACE_RECTANGULAR_2D.

Axis_Direction ::= (  POSITIVE_PRIMARY_AXIS,
                      POSITIVE_SECONDARY_AXIS,
                      POSITIVE_TERTIARY_AXIS,
                      NEGATIVE_PRIMARY_AXIS,
                      NEGATIVE_SECONDARY_AXIS,
                      NEGATIVE_TERTIARY_AXIS )

11.2.6.3        Coordinate_Valid_Region

This data type represents coordinate location with respect to valid-regions (see 8.3.2.4).

Coordinate_Valid_Region ::= ( VALID,
                              EXTENDED_VALID,                               
                              DEFINED )

VALID denotes a coordinate that is contained in the valid-region and in the CS domain.
EXTENDED_VALID denotes a coordinate that is contained in the extended valid-region and in the CS domain but not in the valid-region.
DEFINED denotes a coordinate that is contained in the CS domain but not in the valid or the extended valid-regions.

11.2.6.4        Interval_Type

This data type is used to specify coordinate component intervals in the SetValidRegion, SetExtendedValidRegion, GetValidRegion, and GetExtendedValidRegion methods of class BaseSRF3D and in the SetValidGeodeticRegion, SetExtendedValidGeodeticRegion, GetValidGeodeticRegion, and GetExtendedValidGeodeticRegion methods of class BaseSRFMapProjection.

Interval_Type::= (  OPEN_INTERVAL,        // The bounded open interval (a, b).
     GE_LT_INTERVAL,      // The bounded interval [a, b).
     GT_LE_INTERVAL,      // The bounded interval (a, b].
     CLOSED_INTERVAL,    // The bounded interval [a, b].
     GT_SEMI_INTERVAL,  // The unbounded interval (a, +infinity).
     GE_SEMI_INTERVAL,  // The unbounded interval [a, +infinity).
     LT_SEMI_INTERVAL,  // The unbounded interval (-infinity, b).
     LE_SEMI_INTERVAL,  // The unbounded interval (-infinity, b].
     UNBOUNDED                 // All values (-infinity, +infinity)
)

11.2.6.5        Polar_Aspect

This data type represents the values of the polar aspect parameter of SRFT POLAR_STEREOGRAPHIC.

Polar_Aspect ::= ( NORTH,
                   SOUTH )

11.2.7    Selection data types

11.2.7.1        Introduction

Selection data types are similar to enumerated data types but form a set of entries that may be extended. Selection data types are all defined to be as distinct sub-data types of the numeric of data type Integer, but with specific meanings attached to each value. The set of selections may be augmented by assigning meanings to additional values. Selection data types are otherwise processed in the same manner as enumerated data types. The integer codes are unique within each concept set, but not between sets. Although the RT_Code is used in combination with an ORM_Code, its code space follows the general rule and is independent of the ORM_Code.

In each code space the valid Integer values are 0 and greater. Negative code values are implementation dependent and non-conforming. In each code space, the Integer value 0 (UNSPECIFIED) is reserved. Some API methods and functions allow 0 (UNSPECIFIED) as an input Integer code value and/or an output Integer code value. The valid use of 0 (UNSPECIFIED) is defined in the specification of the appropriate method or function.

11.2.7.2        CS_Code

The Integer code data type CS_Code specifies a CS by its code as defined in Clause 5 or by registration. Table 5.7 is a directory of CS specifications, each of which includes a code value and a corresponding label.

11.2.7.3        DSS_Code

The Integer code data type DSS_Code specifies an DSS by its code as defined Table 9.2 and Table J.20 or by registration. Each DSS specification includes a code value and a corresponding label.

 

11.2.7.4        ORM_Code

The Integer code data type ORM_Code specifies an ORM by its code as defined in Annex E and Annex J or by registration. Each ORM specification includes a code value and a corresponding label (see Clause 7).

11.2.7.5        ORMT_Code

The Integer code data type ORMT_Code specifies an ORM Template code defined in Clause 7 or by registration. Table 7.12 is a directory of ORMT specifications, each of which includes a code value and a corresponding label.

 

11.2.7.6        RT_Code

The Integer code data type RT_Code specifies a reference transformation H_SR. Each RT_Code is defined in Annex E in the entry for the ORM or by registration, specified by the ORM_Code value, with which it is associated. Each reference transformation specification associated with an ORM includes a code value and a corresponding label.

API methods or functions that require the RT_Code data type shall also require its associated ORM_Code.

11.2.7.7        SRF_Code

The Integer code data type SRF_Code specifies an SRF by its code as defined in Table 8.30 or by registration. Each SRF specification includes a code value and a corresponding label (see Clause 8).

 

11.2.7.8        SRFS_Code

The Integer code data type SRFS_Code specifies an SRF set by its code as defined in Table 8.48 or by registration. Each SRF set specification includes a code value and a corresponding label (see Clause 8).

 

SRFS_Code ::= (          < 0  :      // implementation_dependent,

                                      0  :      SRFS_UNSPECIFIED,

                                      1 :       SRFS_ALABAMA_SPCS,

                               2  :      SRFS_GTRS_GLOBAL_COORDINATE_SYSTEM,

                               3  :      SRFS_JAPAN_RECTANGULAR_PLANE_CS,

                               4  :      SRFS_LAMBERT_NTF,

                               5  :      SRFS_UNIVERSAL_POLAR_STEREOGRAPHIC,

                               6  :      SRFS_UNIVERSAL_TRANSVERSE_MERCATOR,

                               7  :      SRFS_WISCONSIN_SPCS,

                             >7  :      // reserved for registration )

 

11.2.7.9        SRFS member types

11.2.7.9.1       Introduction

The Integer code types that specify the SRFS members associated with the SRFS defined in Table 8.48.

11.2.7.9.2       SRFSM_Alabama_SPCS_Code

The Integer code data type SRFSM_Alabama_SPCS_Code specifies a member of the Alabama SPCS SRFS in Table 8.50 or by registration.

11.2.7.9.3       SRFSM_GTRS_Global_Coordinate_System _Code

The Integer code data type SRFSM_GTRS_Global_Coordinate_System_Code specifies a member of the GTRS Global Coordinate System SRFS in Table 8.52 and Table 8.53 or by registration.

11.2.7.9.4       SRFSM_Japan_Rectangular_Plane_CS_Code

The Integer code data type SRFSM_Japan_Rectangular_Plane_CS_Code specifies a member of the Japan Rectangular Plane CS SRFS in Table 8.55 or by registration.

11.2.7.9.5       SRFSM_Lambert_NTF_Code

The Integer code data type SRFSM_Lambert_NTF_Code specifies a member of the Lambert NTF SRFS in Table 8.57 or by registration.

11.2.7.9.6       SRFSM_Universal_Polar_Stereographic_Code

The Integer code data type SRFSM_Universal_Polar_Stereographic_Code specifies a member of the Universal Polar Stereographic SRFS in Table 8.59 or by registration.

11.2.7.9.7       SRFSM_Universal_Transverse_Mercator_Code

The Integer code data type SRFSM_Universal_Transverse_Mercator_Code specifies a member of the Universal Transverse Mercator SRFS in Table 8.61 or by registration.

11.2.7.9.8       SRFSM_Wisconsin_SPCS _Code

The Integer code data type SRFSM_Wisconsin_SPCS_Code specifies a member of the Wisconsin SPCS SRFS Table 8.63 or by registration.

11.2.7.10     SRFT_Code

The Integer code data type SRFT_Code specifies an SRFT by its code as defined in Clause 8 or by registration. Table 8.3 is a directory of SRFT specifications. Each SRFT specification includes a code value and a corresponding label.

 

11.2.7.11     Status_Code

The Status_Code non-object selection data type specifies the status codes associated with methods on instances of classes specified in this International Standard. The meaning of values other than SUCCESS varies according to the class and method or function and is further defined in the “Error conditions” field of each method or function specification in Table 11.6 through Table 11.48 (see common error conditions in 11.3.2). This selection data type may be extended in a language binding specification.

Status_Code ::= (      < 0  :      // implementation_dependent,

                                      0 :       // reserved

                                      1 :      SUCCESS,     // the operation was performed successfully

                               2  :      INVALID_SRF,

                               3  :      INVALID_SOURCE_SRF,

                               4  :      INVALID_SOURCE_COORDINATE,

                               5  :      INVALID_TARGET_COORDINATE,

                               6  :      INVALID_POINT1_COORDINATE,

                               7  :      INVALID_POINT2_COORDINATE,

                               8  :      OPERATION_UNSUPPORTED,

                               9  :      INVALID_SOURCE_DIRECTION,

                             10  :      INVALID_TARGET_DIRECTION,

                             11  :      INVALID_CODE,

                             12  :      INVALID_INPUT,

                             13  :      CREATION_FAILURE,

                             14  :      DESTRUCTION_FAILURE,

                             15  :      FLOATING_OVERFLOW,

                             16  :      FLOATING_UNDERFLOW,

                             17  :      FLOATING_POINT_ERROR,           

                             18  :      MEMORY_ALLOCATION_ERROR,  

                           >18  :      // reserved for language binding specification )

 

11.2.8    Array data types

11.2.8.1        Introduction

Array data types specify an ordered set whose elements may be of any single data type. The index of the first element in the array is either “0” or “1” depending on the language binding. Table 11.4 specifies the notation for Array data types.

Table 11.4 — Array data type notation

 

The symbol “length” is a positive integer that specifies the length of the array. When the length is specified by another field of a record data type or by a function parameter, the field name or function parameter name will be used to indicate that the size of the array is obtained from the value of that construct.

11.2.8.2        Coordinate2D_Array

This data type specifies an array of Coordinate2D objects.

Coordinate2D_Array ::= {

   length                         Integer_Positive;

   coordinate2D_array             Object_Reference [ length ];

}

11.2.8.3        Coordinate3D_Array

This data type specifies an array of Coordinate3D objects.

Coordinate3D_Array ::= {

   length                         Integer_Positive;

   coordinate3D_array             Object_Reference [ length ];

}

11.2.8.4        Coordinate_Valid_Region_Array

This data type specifies an array of Coordinate_Valid_Region variables.

Coordinate_Valid_Region_Array ::= {

   length                         Integer_Positive;

   valid_region_array             Coordinate_Valid_Region[ length ];

}

11.2.8.5        Direction_Array

This data type specifies an array of Direction objects.

Direction_Array ::= {  

   length                       Integer_Positive;

   direction_array              Object_Reference [ length ];

}

11.2.8.6        Vector_3D

This data type specifies an array of three Long_Float variables representing a vector in 3D Euclidean space.

Vector_3D ::= Long_Float[ 3 ]

11.2.9    Structured data types

11.2.9.1        Introduction

Non-object data types created as records whose elements are basic non-object data types are called structured non-object data types. This International Standard specifies a set of structured non-object data types to collect the (non-ORM) parameters needed to specify an SRF by means of an SRF template, and to collect parameters needed to specify an ORM transformation.

The following notation is used for defining the variant record data structures for non-object types:

<Variant_Record_Data_Type> ::= ( <Selector_Name>    <Selection_Data_Type> )

{

   <Variable_Name>    <Variable_Data_Type>

   <Variable_Name>    <Variable_Data_Type>

   …

   [

       <Selection_Name> :    <Variable_Name>    <Variable_Data_Type>;

       <Selection_Name> :    <Variable_Name>    <Variable_Data_Type>;

       …

   ]

}

 

Where:

 

<Variant_Record_Data_Type>:     The variant record data type that is being defined.

<Selector_Name>:                      The name of the selector

<Selector_Data_Type>:               The selection data type used to select the content of the variant record.

<Variable_Name>:                       The name of a record element.

<Variable_Data_Type>:                The data type of a record element. Data type “<empty>” signifies the element is not present in the record.

<Selection_Name>:                     A selection data type enumerant for which a record element applies.

{}:                                               The body of the variant record.

[]:                                               The variant part of the variant record.

11.2.9.2        SRFT parameters

11.2.9.2.1       EC_Parameters

This non-object data type specifies the parameters that correspond to SRFT EQUIDISTANT_CYLINDRICAL.

EC_Parameters ::= { 
   origin_longitude               Long_Float;
   central_scale                  Long_Float;
   false_easting                  Long_Float;
   false_northing                 Long_Float;

}

11.2.9.2.2       LCC_Parameters

This non-object data type specifies the parameters that correspond to SRFT LAMBERT_CONFORMAL_CONIC.

LCC_Parameters ::= {             
   origin_longitude               Long_Float;

   origin_latitude                Long_Float;
   latitude1                      Long_Float;
   latitude2                      Long_Float;
   false_easting                  Long_Float;
   false_northing                 Long_Float;

}

11.2.9.2.3       LSR_2D_Parameters

This non-object data type specifies the parameters that correspond to SRFT LOCAL_SPACE_RECTANGULAR_2D.

LSR_2D_Parameters ::= {

   forward_direction              Axis_Direction;

}

11.2.9.2.4       LSR_3D_Parameters

This non-object data type specifies the parameters that correspond to SRFT LOCAL_SPACE_RECTANGULAR_3D.

LSR_3D_Parameters ::= {

   forward_direction              Axis_Direction;

   up_direction                   Axis_Direction;

}

11.2.9.2.5       Local_Tangent_Parameters

This non-object data type specifies the parameters that correspond to SRFT LOCAL_TANGENT_SPACE_AZIMUTHAL_SPHERICAL, and SRFT LOCAL_TANGENT_SPACE_CYLINDRICAL.

Local_Tangent_Parameters ::={    
   geodetic_longitude             Long_Float;
   geodetic_latitude              Long_Float;
   azimuth                        Long_Float;
   height_offset                  Long_Float;

}

11.2.9.2.6       LTSE_Parameters

This non-object data type specifies the parameters that correspond to SRFT LOCAL_TANGENT_SPACE_EUCLIDEAN.

LTSE_Parameters ::={

   geodetic_longitude             Long_Float;

   geodetic_latitude              Long_Float;

   azimuth                        Long_Float;

   x_false_origin                 Long_Float;

   y_false_origin                 Long_Float;

   height_offset                  Long_Float;

}

 

11.2.9.2.7       LCE_3D_Parameters

This non-object data type specifies the parameters that correspond to SRFT LOCOCENTRIC_EUCLIDEAN_3D.

LCE_3D_Parameters ::= {

   lococentre                     Vector_3D;

   primary_axis                   Vector_3D;

   secondary_axis                 Vector_3D;

}

11.2.9.2.8       M_Parameters

This non-object data type specifies the parameters that correspond to SRFT MERCATOR.

M_Parameters ::= {     
   origin_longitude               Long_Float;

   central_scale                  Long_Float;
   false_easting                  Long_Float;
   false_northing                 Long_Float;

}

11.2.9.2.9       Oblique_Mercator_Parameters

This non-object data type specifies the parameters that correspond to SRFT OBLIQUE_MERCATOR_SPHERICAL.

Oblique_Mercator_Parameters ::= {
   longitude1                     Long_Float;
   latitude1                      Long_Float;
   longitude2                     Long_Float;
   latitude2                      Long_Float;
   central_scale                  Long_Float;
   false_easting                  Long_Float;
   false_northing                 Long_Float;

}

11.2.9.2.10    PS_Parameters

This non-object data type specifies the parameters that correspond to SRFT POLAR_STEREOGRAPHIC.

PS_Parameters ::= {              
   polar_aspect                   Polar_Aspect;
   origin_longitude               Long_Float;
   central_scale                  Long_Float;
   false_easting                  Long_Float;
   false_northing                 Long_Float;

}

11.2.9.2.11    SRFS_Code_Info

This Variant_Record_Data_Type specifies an arbitrary SRFS_Code with its associated SRFS member code. The record element SRFSM_unspecified shall be set to zero (unspecified) when the selector value is SRFS_UNDEFINED.

SRFS_Code_Info ::= ( srfs_code    SRFS_Code )
{

 [

SRFS_UNSPECIFIED:            

  SRFSM_unspecified           Integer;

SRFS_ALABAMA_SPCS:           

  SRFSM_alabama_spcs          SRFSM_Alabama_SPCS_Code;

SRFS_GTRS_GLOBAL_COORDINATE_SYSTEM:                     

  SRFSM_gtrs_global_coordinate_system

                              SRFSM_GTRS_Global_Coordinate_System_Code;

SRFS_JAPAN_RECTANGULAR_PLANE_CS:

  SRFSM_japan_rectangular_plane_cs

                              SRFSM_Japan_Rectangular_Plane_CS_Code;

SRFS_LAMBERT_NTF:            

  SRFSM_lambert_ntf           SRFSM_Lambert_NTF_Code;

SRFS_UNIVERSAL_POLAR_STEREOGRAPHIC:

  SRFSM_universal_polar_stereographic    SRFSM_Universal_Polar_Stereographic_Code;

SRFS_UNIVERSAL_TRANSVERSE_MERCATOR:

  SRFSM_universal_transverse_mercator    SRFSM_Universal_Transverse_Mercator_Code;

SRFS_WISCONSIN_SPCS:         

  SRFSM_wisconsin_spcs        SRFSM_Wisconsin_SPCS_Code;

   ]

}

11.2.9.2.12    TM_Parameters

This non-object data type specifies the parameters that correspond to SRFT TRANSVERSE_MERCATOR.

TM_Parameters ::= {    
   origin_longitude               Long_Float;
   origin_latitude                Long_Float;

   central_scale                  Long_Float;
   false_easting                  Long_Float;
   false_northing                 Long_Float;

}

11.2.9.3        ORM transformation parameters

11.2.9.3.1       ORM_Transformation_2D_Parameters

This non-object data type represents a 2D ORM four-parameter transformation as specified in 7.3.3.

ORM_Transformation_2D_Parameters ::= {  

   delta_x                        Long_Float;
   delta_y                        Long_Float;
   omega                          Long_Float;
   delta_s                        Long_Float;

}

The valid range in radians for values of omega is (-2π, 2π). The valid range for delta_s is greater than -1.

11.2.9.3.2       ORM_Transformation_3D_Parameters

This non-object data type represents a 3D ORM seven-parameter transformation as specified in 7.3.2.

ORM_Transformation_3D_Parameters ::= {  

   delta_x                        Long_Float;

   delta_y                        Long_Float;

   delta_z                        Long_Float;

   omega_1                        Long_Float;

   omega_2                        Long_Float;

   omega_3                        Long_Float;

   delta_s                        Long_Float;

}

The valid range in radians for values omega_1, omega_2, and omega_3 is (-2π, 2π). The valid range for delta_s is greater than -1.

11.3    Object classes

11.3.1    Introduction

SRF objects specify methods that implement the spatial operations specified in Clause 10. To aid in specification, most of the functionality of the API is defined using a class hierarchy with each abstract class providing the specification of those methods that are common to each of its subclasses. The remaining functionality is provided in concrete class and function specifications. The implementation of abstract classes is not required.

The functionality of the methods are specified in the class specification tables (see 11.3.2) that provide the method name, the semantics, inputs and outputs of the method, and the error conditions of the method. These methods manipulate internal data (object state) and any input parameters passed in. The success condition is a nominal behaviour of all methods and is not listed within the error conditions field. The success condition is associated with Status_Code SUCCESS.

EXAMPLE 1         In Table 11.13, the phrase “this SRF” refers to the internal state of an instance of a concrete class subclassed (directly or indirectly) from the abstract class specified in the table. In particular, the abstract method GetORMCode “Outputs the ORM_Code and the RT_Code of this SRF”, and shows “Inputs: none”.

Language bindings may add additional error conditions and related binding-specific mechanisms including the passing of inputs and outputs, and the presentation of method status. Language bindings shall specify these mechanisms, since this International Standard does not restrict such mechanisms. Under an error condition, output values are undefined. When several error conditions apply to a method invocation, the first error condition detected by an implementation shall be presented as the method status. The error conditions applicable to a method invocation are the common error conditions specified in 11.3.2 and the additional error conditions specified in the class specification table for the method and any language-binding specific error conditions applicable to the method.

A language binding mechanism for presentation of method status shall support the association of a unique error Status_Code (11.2.7.11)

EXAMPLE 2         If a language binding supports exception handling and if a language binding uses that mechanism to present method failure, then an exception object method that returns the corresponding Status_Code would satisfy this requirement.

11.3.2    Class specification format

Class data types are specified in tables in Table 11.5 through Table 11.44 with the following elements:

Table 11.5 — Class specification elements

 

The method field of a concrete class is labelled “Method”. The method field of an abstract class is labelled “Abstract method” or “Private method”. A private method is used to document the functionality of other methods. A subclass inherits all the abstract methods of its superclass including methods that the superclass has inherited. In particular, an abstract method inherited by a concrete class shall be implemented for the concrete class. An implementation may implement private methods in concrete classes for internal use, but public access to a concrete implementation of a private method is not a requirement. The order in which the methods are listed in each class follows a life cycle pattern, i.e., creation methods, then data manipulation methods, and then spatial operations.

The Error conditions field of a method specification does not separately list the following common error conditions.

a)       INVALID_SRF if the SRF object invoking the method was not successfully initialized by the API or is invalid. The condition does not apply to create methods.

b)       FLOATING_OVERFLOW if a floating-point overflow error occurred in the performance of the method.

c)       FLOATING_UNDERFLOW if a floating-point underflow error occurred in the performance of the method.

d)       FLOATING_POINT_ERROR if a floating-point error (other than an overflow or underflow error) occurred in the performance of the method.

e)       MEMORY_ALLOCATION_ERROR if a memory allocation error occurred in the performance of the method.

f)         INVALID_INPUT if a Long_Float input is positive or negative infinity, or a not-a-number (NAN) value. If additional conditions apply, they are listed with this Status_Code in the (abstract/private) method Error conditions field.

11.3.3    LifeCycleObject

The LifeCycleObject class is the most basic abstract class from which all other classes inherit. LifeCycleObject is an abstract class. All other abstract classes are defined in 11.3.5.

Table 11.6 — LifeCycleObject

 

11.3.4     Private objects

11.3.4.1        Introduction

Private object classes are concrete classes that represent objects whose methods and attributes are not exposed to the API user. Instances of these objects may be created and destroyed by methods on other objects specified in the API. Object references for instances of private objects may be passed to and returned from methods. This allows an implementation of the API to store data that can be maintained for these private object classes in whatever form is convenient for the implementation.

11.3.4.2        Coordinate3D

The Coordinate3D class represents a coordinate of CS data type 3D. It specifies no additional public methods.

Table 11.7 —Coordinate3D

 

11.3.4.3        Coordinate2D

The Coordinate2D class represents a coordinate of CS data type 2D. It specifies no additional public methods.

Table 11.8 — Coordinate2D

 

11.3.4.4        SurfaceCoordinate

The SurfaceCoordinate class represents a coordinate of CS data type surface. It specifies no additional public methods.

Table 11.9 — SurfaceCoordinate

 

11.3.4.5        Direction

The Direction class represents the reference coordinate corresponding to the reference position and the normal vector of a direction in a 3D object-space. It specifies no additional public methods.

Table 11.10 — Direction

 

11.3.4.6        Position3D

The Position3D class represents a point in a 3D position-space. It specifies no additional public methods. It is the input or output of some private methods of the BaseSRF3D class.

Table 11.11 — Position3D

 

11.3.4.7        Position2D

The Position2D class represents a point in a 2D position-space. It specifies no additional public methods. It is the input or output of some private methods of the BaseSRF2D class.

Table 11.12 — Position2D

 

11.3.5    Abstract classes

11.3.5.1        BaseSRF

This is the base class for all SRF classes. BaseSRF provides common methods to return coded values that may be associated with an SRF class instance.

Table 11.13 — BaseSRF

 

11.3.5.2        BaseSRF2D

This is the base class for all 2D SRF classes. BaseSRF2D is a subclass of BaseSRF. This abstract class adds the following methods:

CreateCoordinate2D,
GetCoordinate2DValues,
ChangeCoordinate2DSRF,
ChangeCoordinate2DSRFObject,
ChangeCoordinate2DArraySRF,
ChangeCoordinate2DArraySRFObject, and
EuclideanDistance.

These methods, respectively, create a Coordinate2D, query component values of an exiting Coordinate2D, change Coordinate2D representation from some other 2D SRF instance, change an array of Coordinate2D representation from some other 2D SRF instance, or compute the Euclidean distance between coordinates.

The ChangeCoordinate2DSRF method is for the case of source and target SRF instances based on object-fixed ORMs for the same spatial object using the methodology of 10.4.2 and the ORM reference transformations specified by the RT_Code input to the concrete SRF Create method. The method ChangeCoordinate2DSRFObject is for the general case of any pair of instances of concrete SRFs subclassed from BaseSRF2D where the ORM transformation H_ST is explicitly specified with an input ORM_Transformation_2D_Parameters data structure. The ChangeCoordinate2DArraySRF and the ChangeCoordinate2DArraySRFObject methods are similar to the above operating on arrays of spatial objects.

BaseSRF2D also adds the private methods Generating2D and InverseGenerating2D that are used to specify the functionality of the ChangeCoordinate2DSRF, and ChangeCoordinate2DSRFObject methods.

Table 11.14 — BaseSRF2D

 

NOTE: The method ChangeCoordinate2DSRF semantics describes the required functionality in terms of the private methods Generating2D, and InverseGenerating2D. This computational scheme is presented only for the purpose of specifying the required functionality, and does not take into account error checking and various computational short cuts and efficiencies that an actual implementation design would consider. (Some of these efficiencies are presented in Clause 10). This remark is also applicable to the ChangeCoordinate2DSRFObject method.

11.3.5.3        BaseSRF3D

This is the base class for 3D SRF classes. BaseSRF3D is a subclass of BaseSRF. This abstract class adds the methods SetValidRegion and SetExtendedValidRegion to define coordinate valid and extended valid-regions to an SRF as in 8.3.2.4, and GetValidRegion and GetExtendedValidRegion to retrive this information.

BaseSRF3D adds the following methods:

CreateCoordinate3D,
GetCoordinate3DValues,
ChangeCoordinate3DSRF,
ChangeCoordinate3DSRFObject,
ChangeCoordinate3DArraySRF,
ChangeCoordinate3DArraySRFObject, and
EuclideanDistance.

These methods, respectively, create a Coordinate3D, query component values of an exiting Coordinate3D, change Coordinate3D representation from some other 3D SRF instance, change an array of Coordinate3D representation from some other 3D SRF instance, or compute the Euclidean distance between coordinates.

BaseSRF3D also adds the following methods:

CreateDirection,
GetDirectionValues,
ChangeDirectionSRF,
ChangeDirectionSRFObject,
ChangeDirectionArraySRF, and
ChangeDirectionArraySRFObject.

These methods, respectively, create a Direction, query component values of an exiting Direction, change Direction representation from some other 3D SRF instance, or change an array of Direction representation from some other 3D SRF instance.

The ChangeCoordinate3DSRF and ChangeDirectionSRF methods are for source and target SRF instances based on object-fixed ORMs for the same spatial object using the methodology of 10.3.1 and the ORM reference transformations specified by the RT_Code input to the concrete SRF Create method. The methods ChangeCoordinate3DSRFObject and ChangeDirectionSRFObject are for the general case of any pair of instances of concrete SRF classes subclassed from BaseSRF3D where the ORM transformation H is explicitly specified with an input ORM_Transformation_3D_Parameters data structure.

BaseSRF3D also adds the private methods Generating3D and InverseGenerating3D that are used to specify the functionality of the ChangeCoordinate3DSRF, ChangeCoordinate3DSRFObject, ChangeDirectionSRFObject, and ChangeDirectionSRF methods.

Table 11.15 — BaseSRF3D

 

NOTE: The method ChangeCoordinate3DSRF semantics describes the required functionality in terms of the private methods Generating3D, and InverseGenerating3D. This computational scheme is presented only for the purpose of specifying the required functionality, and does not take into account error checking and various computational short cuts and efficiencies that an actual implementation design would consider. (Some of these efficiencies are presented in Clause 10). This remark is also applicable to the ChangeCoordinate3DSRFObject, ChangeDirectionSRF and ChangeDirectionSRFObject methods.

11.3.5.4        BaseSRFwithTangentPlaneSurface

This is the base class for the following SRF classes:

LocalTangentSpaceEuclidian,
LocalTangentSpaceAzimuthalSpherical, and
LocalTangentSpaceCylindrical.

BaseSRFwithTangentPlaneSurface is derived from the BaseSRF3D class. It adds methods for the surface coordinate system that is induced on the vertical coordinate component zero surface. That surface is a tangent plane to the oblate ellipsoid RD of the ORM of the SRF. The added methods for SurfaceCoordinate operations are CreateSurfaceCoordinate, GetSurfaceCoordinateValues, to create and query values of a SurfaceCoordinate, and AssociateSurfaceCoordinate and PromoteSurfaceCoordinate to relate a SurfaceCoordinate coordinate to Coordinate3D coordinate. The EuclideanDistance method of BaseSRF3D operates on a pair of Coordinate3D coordinates. This class adds a version of EuclideanDistance to operate on a pair of SurfaceCoordinate coordinates.

Table 11.16 — BaseSRFwithTangentPlaneSurface

 

11.3.5.5        BaseSRFwithEllipsoidalHeight

This is the base class for the Celestiodetic SRF class and the BaseSRFMapProjection class. BaseSRFwithEllipsoidalHeight is derived from the BaseSRF3D class. It adds methods for the surface coordinate system that is induced on the zero ellipsoidal height surface. The added methods for SurfaceCoordinate operations are CreateSurfaceCoordinate, GetSurfaceCoordinateValues, to create and query values of a SurfaceCoordinate, and AssociateSurfaceCoordinate and PromoteSurfaceCoordinate to relate a SurfaceCoordinate coordinate to Coordinate3D coordinate. The EuclideanDistance method of BaseSRF3D operates on Coordinate3D coordinates. This class adds a version of EuclideanDistance to operate on SurfaceCoordinate coordinates. It also adds the GeodesicDistance method that returns the geodesic distance between a pair of SurfaceCoordinate coordinates.

The class also adds the method CreateLocalTangentSpaceEuclideanSRF to create a LocalTangentSpaceEuclidean SRF on a point on the zero ellipsoidal height surface. And it adds the VerticalOffset method for vertical offset models (see 9.3).

Table 11.17 — BaseSRFwithEllipsoidalHeight

 

11.3.5.6        BaseSRFMapProjection

This is the base class for concrete map projection SRF classes. BaseSRFMapProjection is derived from the BaseSRFwithEllipsoidalHeight class. This abstract class adds the following methods:

SetValidGeodeticRegion,
SetExtendedValidGeodeticRegion,
GetValidGeodeticRegion and
GetExtendedValidGeodeticRegion

These methods define and retrieve coordinate valid and extended valid-regions with surface geodetic coordinate component intervals in addition to map projection coordinate component intervals that can be specified using the SetValidRegion and SetExtendedValidRegion methods of BaseSRF3D.

The BaseSRFMapProjection class also adds the following map projection specific methods:

ConvergenceOfTheMeridian,
PointDistortion, and
MapAzimuth.

Table 11.18 — BaseSRFMapProjection

 

11.3.6    SRF concrete subclasses of BaseSRF2D

11.3.6.1        Introduction

Concrete classes based on BaseSRF2D inherit all the methods of the following classes:

LifeCycleObject,
BaseSRF, and
BaseSRF2D

classes. They add class specific Create methods. In those cases for which the Create method has a class specific input data structure, a GetSRFParameters method for the class is also specified.

11.3.6.2        LocalSpaceRectangular2D

Table 11.19 — LocalSpaceRectangular2D

 

11.3.6.3        LocalSpaceAzimuthal

Table 11.20 — LocalSpaceAzimuthal

 

11.3.6.4        LocalSpacePolar

Table 11.21 — LocalSpacePolar

 

11.3.7    SRF concrete subclasses of BaseSRF3D

11.3.7.1        Introduction

Concrete classes based on BaseSRF3D inherit all the methods of the following classes:

LifeCycleObject,
BaseSRF, and
BaseSRF3D.

They add class specific Create methods. In those cases for which the Create method has a class specific input data structure, a GetSRFParameters method for the class is also specified.

11.3.7.2        Celestiocentric

Table 11.22 — Celestiocentric

 

11.3.7.3        LocalSpaceRectangular3D

Table 11.23 — LocalSpaceRectangular3D

 

11.3.7.4        LococentricEuclidean3D

Table 11.24 — LococentricEuclidean3D

 

11.3.7.5        Celestiomagnetic

Table 11.25 — Celestiomagnetic

 

11.3.7.6        EquatorialInertial

Table 11.26 — EquatorialInertial

 

11.3.7.7        SolarEcliptic

Table 11.27 — SolarEcliptic

 

11.3.7.8        SolarEquatorial

Table 11.28 — SolarEquatorial

 

11.3.7.9        SolarMagneticEcliptic

Table 11.29 — SolarMagneticEcliptic

 

11.3.7.10     SolarMagneticDipole

Table 11.30 — SolarMagneticDipole

 

11.3.7.11     HeliosphericAriesEcliptic

Table 11.31 — HeliosphericAriesEcliptic

 

11.3.7.12     HeliosphericEarthEcliptic

Table 11.32 — HeliosphericEarthEcliptic

 

11.3.7.13     HeliosphericEarthEquatorial

Table 11.33 — HeliosphericEarthEquatorial

 

11.3.8    SRF concrete subclasses of BaseSRFwithTangentPlaneSurface

11.3.8.1        Introduction

Concrete classes based on BaseSRFwithTangentPlaneSurface inherit all the methods of the following classes:

LifeCycleObject,
BaseSRF, BaseSRF3D, and
BaseSRFwithTangentPlaneSurface.

They add class specific Create and GetSRFParameters methods.

11.3.8.2        LocalTangentSpaceEuclidean

Table 11.34 — LocalTangentSpaceEuclidean

 

11.3.8.3        LocalTangentSpaceAzimuthalSpherical

Table 11.35 — LocalTangentSpaceAzimuthalSpherical

 

11.3.8.4        LocalTangentSpaceCylindrical

Table 11.36 — LocalTangentSpaceCylindrical

 

11.3.9    SRF concrete subclass of BaseSRFwithEllipsoidalHeight

11.3.9.1        Introduction

Concrete classes based on BaseSRFwithEllipsoidalHeight inherit all the methods of the LifeCycleObject, BaseSRF, BaseSRF3D, and BaseSRFwithEllipsoidalHeight.

11.3.9.2        Celestiodetic

Table 11.37 — Celestiodetic

 

11.3.9.3        Planetodetic

Table 11.38 — Planetodetic

 

11.3.10 SRF concrete subclasses of BaseSRFMapProjection

11.3.10.1     Introduction

Concrete classes based on BaseSRFMapProjection inherit all the methods of the following classes:

LifeCycleObject,
BaseSRF,
BaseSRF3D,
BaseSRFwithEllipsoidalHeight, and
BaseSRFMapProjection.

They add class specific Create and GetSRFParameters methods.

11.3.10.2     Mercator

Table 11.39 — Mercator

 

11.3.10.3     ObliqueMercatorSpherical

Table 11.40 — ObliqueMercatorSpherical

 

11.3.10.4     TransverseMercator

Table 11.41 — TransverseMercator

 

11.3.10.5     LambertConformalConic

Table 11.42 — LambertConformalConic

 

11.3.10.6     PolarStereographic

Table 11.43 — PolarStereographic

 

11.3.10.7     EquidistantCylindrical

Table 11.44 — EquidistantCylindrical

11.4    Standard SRFs

This subclause defines a function that creates an SRF object that corresponds to one of the standard SRFs specified in 8.6. A standard SRF object differs from other instances of its SRFT class in that the GetSRFCodes method of the object outputs the corresponding SRF_Code. The function, CreateStandardSRF, specified in Table 11.45 creates and outputs a standard SRF object from an SRF_Code input. Each output SRF object corresponds to an entry in Table 8.31.

Table 11.45 — CreateStandardSRF

 

EXAMPLE:           CreateStandardSRF with srf_code = 4 and an rt_code, produces as output an SRF object corresponding to SRF GEOCENTRIC_WGS_1984.

11.5    SRF set classes

This subclause defines a function that creates an SRF object that corresponds to a member of one of the standard SRF sets specified in 8.7. An SRF set member object differs from other instances of its SRFT class in that the GetSRFCodes method of the object outputs the corresponding SRFS_Code and the SRFS member code Integer. The function CreateSRFSetMember creates and outputs an SRF object in the SRF set corresponding to the input SRFS_Code, ORM_Code and SRFS member code Integer.

Table 11.46 — CreateSRFSetMember

 

EXAMPLE:  CreateSRFSetMember with parameters set_code_info.srfs_code = SRFS_ALABAMA_SPCS, set_code_info.SRFSM_alabama_spcs = 1, an orm_code and an rt_code, produces as output an SRF object corresponding to SRFS member ALABAMA_SPCS zone 1.

11.6    Implementation support query functions

Two query functions are provided to indicate the support of an API implementation for subsets of the SRM as may be defined by a profile. (see Clause 12 and 14.2). The function QuerySRFSupport indicates which SRF classes are supported. The function QueryORMSupport indicates which ORMs or ORM and RT combinations are supported.

Table 11.47 — QuerySRFTSupport

 

Table 11.48 — QueryORMSupport

 

11.7    Object inheritance hierarchy

The object inheritance hierarchy is summarized in Figure 11.1.

          
        

Figure 11.1 — Object inheritance hierarchy

 

 

            
                  

Figure 11.1 — Object inheritance hierarchy (continued)

 

       
      

Figure 11.1 — Object inheritance hierarchy (continued)

11.8    Method precedence for life cycle objects and examples

There are restrictions on the order in which the methods of objects derived from LifeCycleObject may be invoked. The restrictions are:

a)       The Create method (including subclassed versions) of a life cycle object shall be the first method invoked on any instance of the object.

b)       The Destroy method (including subclassed versions) of a life cycle object shall be the last method invoked on any instance of the object. Depending on the language binding and the language capabilities, invocation of the destroy method may be:

1)       explicit – invoked by the API user,

2)       implicit – managed by the runtime system, or

3)       implicit/optionally explicit – managed by the runtime system if not explicitly invoked by the API user on any single instance.

c)       All other methods shall only be invoked after the Create method and before the Destroy method.

The following examples illustrate the method sequence for life cycle objects.

NOTE: The status for each invocation of a method or function should be checked for error conditions. For brevity and clarity this status checking is not shown in these examples.

EXAMPLE 1: Find the Euclidean distance between two locations.

--Note: Label in italics denotes a symbolic constant for this example -

Celestiodetic method Create(ORM_N_AM_1983, RT_N_AM_1983_CONUS; Output: ex1_srf)

ex1_srf method CreateCoordinate3D( Inputs: -77º(π/180º), +38º( π/180º), 0;
                                   Output: coordinate1)

ex1_srf method CreateCoordinate3D( Inputs +3º( π/180º), +49º( π/180º), 0;
                                   Output: coordinate2)

ex1_srf method EuclideanDistance( Inputs coordinate1, coordinate2;
                                  Output: distance)

-- use distance result --

coordinate1 method destroy

coordinate2 method destroy

ex1_srf method destroy
 

EXAMPLE 2: Change SRF representation of a location from UTM to Celestiocentric

--Note: Labels in italics denote symbolic constants for this example --

Function    CreateSRFSetMember
                  ( Inputs: ( SRFS_UNIVERSAL_TRANSVERSE_MERCATOR,
                              SRFSM_ZONE_23_NORTHERN_HEMISPHERE ),
                              ORM_N_AM_1983,

                              RT_N_AM_1983_CONUS, 
                    Output: source_srf)

source_srf method CreateCoordinate3D( Inputs: 350000, 400, 0,

                                      Output: source_coordinate)

Function CreateStandardSRF( Inputs: SRF_GEOCENTRIC_WGS_1984,

                                    RT_WGS_1984_IDENTITY,

                            Output: target_srf) 

target_srf method ChangeCoordinate3DSRF( Inputs: source_srf, source_coordinate,
                                         Outputs: target_coordinate, region)

-- check region value and use result --

source_coordinate method destroy 

target_coordinate method destroy

source_srf method destroy

target_srf method destroy

11.9    Data storage structures

11.9.1    Introduction

The data storage structures specify the exact ordering sequence and size of the information for persistent storage in any mass storage media. These structures are defined within this International Standard for applications that store SRM data and are not used with API methods or functions defined in this International Standard.

11.9.2    SRFT_Parameters

This non-object data type specifies the parameters for an arbitrary SRF template.

SRFT_Parameters ::= ( template_code     SRFT_Code )
{

orm_code         ORM_Code;

 [

CELESTIOCENTRIC:                 

  cc_srf_parameters               <empty>;

LOCAL_SPACE_RECTANGULAR_3D:      

  lsr_3d_srf_parameters           LSR_3D_Parameters;

CELESTIODETIC:                   

  cd_srf_parameters               <empty>;

PLANETODETIC:                    

  pd_srf_parameters               <empty>;

LOCAL_TANGENT_SPACE_EUCLIDEAN:   

  ltse_srf_parameters             LTSE_Parameters;

LOCAL_TANGENT_SPACE_AZIMUTHAL_SPHERICAL:

  ltsas_srf_parameters            Local_Tangent_Parameters;

LOCAL_TANGENT_SPACE_CYLINDRICAL: 

  ltsc_srf_parameters             Local_Tangent_Parameters;

LOCOCENTRIC_EUCLIDEAN_3D:        

  lce_3d_srf_parameters           LCE_3D_Parameters;

CELESTIOMAGNETIC:                

  cm_srf_parameters               <empty>;

EQUATORIAL_INERTIAL:             

  ei_srf_parameters               <empty>;

SOLAR_ECLIPTIC:                  

  sec_srf_parameters              <empty>;

SOLAR_EQUATORIAL:                

  seq_srf_parameters              <empty>;

SOLAR_MAGNETIC_ECLIPTIC:         

  sme_srf_parameters              <empty>;

SOLAR_MAGNETIC_DIPOLE:           

  smd_srf_parameters              <empty>;

HELIOSPHERIC_ARIES_ECLIPTIC:     

  haec_srf_parameters             <empty>;

HELIOSPHERIC_EARTH_ECLIPTIC:     

  heec_srf_parameters             <empty>;

HELIOSPHERIC_EARTH_EQUATORIAL:   

  heeq_srf_parameters             <empty>;

MERCATOR:                        

  m_srf_parameters                M_Parameters;

OBLIQUE_MERCATOR_SPHERICAL:      

  oms_srf_parameters              Oblique_Mercator_Parameters;

TRANSVERSE_MERCATOR:             

  tm_srf_parameters               TM_Parameters;

LAMBERT_CONFORMAL_CONIC:         

  lcc_srf_parameters              LCC_Parameters;

POLAR_STEREOGRAPHIC:             

  ps_srf_parameters               PS_Parameters;

EQUIDISTANT_CYLINDRICAL:         

  ec_srf_parameters               EC_Parameters;

LOCAL_SPACE_RECTANGULAR_2D:      

  lsr_2d_srf_parameters           LSR_2D_Parameters;

LOCAL_SPACE_AZIMUTHAL:           

  lsa_srf_parameters              <empty>;

LOCAL_SPACE_POLAR:               

  lsp_srf_parameters              <empty>;

]

}

11.9.3    SRFS_Info

This non-object data type specifies the parameters for an arbitrary SRF set.

SRFS_Info ::= {     

   orm_code                         ORM_Code;

   srfs_code_info                   SRFS_Code_Info;

}

11.9.4    SRF_Parameters_Info_Code

This non-object selection data type specifies an SRF code type.

SRF_Parameters_Info_Code ::= (   <  1  : // implementation dependent,

1  :    TEMPLATE,

2  :    SET,

3  :    INSTANCE,

                                                               >  3  : // reserved for registration )

11.9.5     SRF_Parameters_Info

This non-object data type specifies the parameters for an arbitrary SRF, SRF set or SRF template.

SRF_Parameters_Info ::= ( srf_parameters_info_code    SRF_Parameters_Info_Code )

{

rt_code          RT_Code;

 [TEMPLATE:        srf_template           SRFT_Parameters;

  SET:             srf_set                SRFS_Info;

  INSTANCE:        srf_instance           SRF_Code;

 ]

}

11.9.6    SRF_Reference_Surface_Info

This non-object data type specifies the information for an arbitrary SRF with its associated DSS information.

SRF_Reference_Surface_Info ::= { 

   dss_code                                              DSS_Code;

   srf_parameters_info                SRF_Parameters_Info;

}

11.9.7    Coordinate structures

Structures are defined to store the specific values of a coordinate.

11.9.7.1         CD_3D_Coordinate

This non-object data type specifies the 3D coordinate components for SRFT CELESTIODETIC.

CD_3D_Coordinate ::= {             

   longitude                        Long_Float;
   latitude                         Long_Float;
   ellipsoidal_height               Long_Float;

}

11.9.7.2         CD_Surface_Coordinate

This non-object data type specifies the surface coordinate components for SRFT CELESTIOCENTRIC.

CD_Surface_Coordinate ::= {        

   longitude                        Long_Float;
   latitude                         Long_Float;

}

11.9.7.3         EI_3D_Coordinate

This non-object data type specifies the 3D coordinate components for SRFT EQUATORIAL_INERTIAL.

EI_3D_Coordinate ::= {             

   right_ascension                  Long_Float;
   declination                      Long_Float;
   radius                           Long_Float;

}

11.9.7.4        Euclidean_2D_Coordinate

This non-object data type specifies the 2D coordinate components for Euclidean space SRFTs.

Euclidean_2D_Coordinate ::= {      

   u                                Long_Float;
   v                                Long_Float;

}

11.9.7.5         Euclidean_3D_Coordinate

This non-object data type specifies the 3D coordinate components for Euclidean space SRFTs.

Euclidean_3D_Coordinate ::= {      

   u                                Long_Float;
   v                                Long_Float;
   w                                Long_Float;

}

11.9.7.6        LSA_2D_Coordinate

This non-object data type specifies the 2D coordinate components for SRFT LOCAL_SPACE_AZIMUTHAL_2D.

LSA_2D_Coordinate ::= {     

   azimuth                          Long_Float;         

   radius                           Long_Float;

}

11.9.7.7         LSP_2D_Coordinate

This non-object data type specifies the surface coordinate components for SRFT LOCAL_SPACE_POLAR_2D.

LSP_2D_Coordinate ::= {            

   angle                            Long_Float;
   radius                           Long_Float;

}

11.9.7.8        LTSAS_3D_Coordinate

This non-object data type specifies the 3D coordinate components for SRFT LOCAL_TANGENT_SPACE_AZIMUTHAL_SPHERICAL.

LTSAS_3D_Coordinate ::= { 

   azimuth                          Long_Float;

   angle                            Long_Float;

   radius                           Long_Float;

}

11.9.7.9         LTSAS_Surface_Coordinate

This non-object data type specifies the surface coordinate components for SRFT LOCAL_TANGENT_SPACE_AZIMUTHAL_SPHERICAL.

LTSAS_Surface_Coordinate ::= {

   azimuth                          Long_Float;
   angle                            Long_Float;

}

11.9.7.10      LTSC_3D_Coordinate

This non-object data type specifies the 3D coordinate components for SRFT LOCAL_TANGENT_SPACE_CYLINDRICAL.

LTSC_3D_Coordinate ::= {           

   angle                            Long_Float;
   radius                           Long_Float;
   height                           Long_Float;

}

11.9.7.11      LTSC_Surface_Coordinate

This non-object data type specifies the surface coordinate components for SRFT LOCAL_TANGENT_SPACE_CYLINDRICAL.

LTSC_Surface_Coordinate ::= {      

   angle                            Long_Float;
   radius                           Long_Float;

}

11.9.7.12     LTSE_3D_Coordinate

This non-object data type specifies the 3D coordinate components for SRFT LOCAL_TANGENT_SPACE_EUCLIDEAN.

LTSE_3D_Coordinate ::= {           

   x                                Long_Float;
   y                                Long_Float;
   height                           Long_Float;

}

11.9.7.13      LTSE_Surface_Coordinate

This non-object data type specifies the surface coordinate components for SRFT LOCAL_TANGENT_SPACE_EUCLIDEAN.

LTSE_Surface_Coordinate ::= {                          

   x                                Long_Float;
   y                                Long_Float;

}

11.9.7.14     Map_Projection_3D_Coordinate

This non-object data type specifies the 3D coordinate components for map projection SRFTs.

Map_Projection_3D_Coordinate ::= { 

   easting                          Long_Float;
   northing                         Long_Float;
   ellipsoidal_height               Long_Float;

}

11.9.7.15      Map_Projection_Surface_Coordinate

This non-object data type specifies the surface coordinate components for map projection SRFTs.

Map_Projection_Surface_Coordinate ::= { 

   easting                          Long_Float;

   northing                         Long_Float;

}

11.9.7.16     Spherical_3D_Coordinate

This non-object data type specifies the 3D coordinate components for spherical SRFTs.

Spherical_3D_Coordinate ::= {      

   longitude                        Long_Float;
   latitude                         Long_Float;
   radius                           Long_Float;

}

11.9.8    Spatial_Coordinate_Code

This non-object selection data type specifies the spatial coordinate type.

Spatial_Coordinate_Code ::= (      < 1    :      // implementation dependent,

1         :  CC_3D,

2         :  CD_3D,

3         :  CD_SURFACE,

4         :  CM_3D,

5         :  EC_AUGMENTED_3D,

6         :  EC_SURFACE,

7         :  EI_3D,

8         :  HAEC_3D,

9         :  HEEC_3D,

10     :  HEEQ_3D,

11     :  LCC_AUGMENTED_3D,

12     :  LCC_SURFACE,

13     :  LCE_3D,

14     :  LSA_2D,

15     :  LSP_2D,

16     :  LSR_2D,

17     :  LSR_3D,

18     :  LTSAS_3D,

19     :  LTSAS_SURFACE,

20     :  LTSC_3D,

21     :  LTSC_SURFACE,

22     :  LTSE_3D,

23     :  LTSE_SURFACE,

24     :  M_AUGMENTED_3D,

25     :  M_SURFACE,

26     :  OMS_AUGMENTED_3D,

27     :  OMS_SURFACE,

28     :  PD_3D,

29     :  PD_SURFACE,

30     : PS_AUGMENTED_3D,

31     :  PS_SURFACE,

32     :  SEC_3D,

33     :  SEQ_3D,

34     :  SMD_3D,

35     :  SME_3D,

36     :  TM_AUGMENTED_3D,

37     :  TM_SURFACE,

                                                          > 37   : // reserved for registration )

 

11.9.9     Coordinate

This non-object data type stores one of the defined coordinate.

Coordinate ::=  (   spatial_coord_code Spatial_Coordinate_Code )

{

 [ CC_3D:                  cc_3d            Euclidean_3D_Coordinate;

   CD_3D:                  cd_3d            CD_3D_Coordinate;

   CD_SURFACE:             cd_surface       CD_Surface_Coordinate;

   CM_3D:                  cm_3d            Spherical_3D_Coordinate;

   EC_AUGMENTED_3D:        ec_aug_3d        Map_Projection_3D_Coordinate;

   EC_SURFACE:             ec_surface       Map_Projection_Surface_Coordinate;

   EI_3D:                  ei_3d            Equatorial_Inertial_3D_Coordinate;

   HAEC_3D:                haec_3d          Spherical_3D_Coordinate;

   HEEC_3D:                heec_3d          Spherical_3D_Coordinate;

   HEEQ_3D                 heeq_3d          Spherical_3D_Coordinate;

   LCC_AUGMENTED_3D        lcc_aug_3d       Map_Projection_3D_Coordinate;

   LCC_SURFACE:            lcc_surface      Map_Projection_Surface_Coordinate;

   LCE_3D:                 lce_3d           Euclidean_3D_Coordinate;

   LSA_2D:                 lsa_2d           LSA_2D_Coordinate;

   LSP_2D:                 lsp_2d           LSP_2D_Coordinate;

   LSR_2D:                 lsr_2d           Euclidean_2D_Coordinate;

   LSR_3D:                 lsr_3d           Euclidean_3D_Coordinate;

   LTSAS_3D:               ltsas_3d         LTSAS_3D_Coordinate;

   LTSAS_SURFACE:          ltsas_surface    LTSAS_Surface_Coordinate;

   LTSC_3D:                ltsc_3d          LTSC_3D_Coordinate;

   LTSC_SURFACE:           ltsc_surface     LTSC_Surface_Coordinate;

   LTSE_3D:                ltse_3d          LTSE_3D_Coordinate;

   LTSE_SURFACE:           ltse_surface     LTSE_Surface_Coordinate;

   MERCATOR_AUGMENTED_3D:  m_aug_3d         Map_Projection_3D_Coordinate;

   MERCATOR_SURFACE:       m_surface        Map_Projection_Surface_Coordinate;

   OMS_AUGMENTED_3D:       oms_aug_3d       Map_Projection_3D_Coordinate;

   OMS_SURFACE:            oms_surface      Map_Projection_Surface_Coordinate;

   PD_3D:                  pd_3d            CD_3D_Coordinate;

   PD_SURFACE:             pd_surface       CD_Surface_Coordinate;

   PS_AUGMENTED_3D:        ps_aug_3d        Map_Projection_3D_Coordinate;

   PS_SURFACE:             ps_surface       Map_Projection_Surface_Coordinate;

   SEC_3D:                 sec_3d           Spherical_3D_Coordinate;

   SEQ_3D:                 seq_3d           Spherical_3D_Coordinate;

   SMD_3D:                 smd_3d           Spherical_3D_Coordinate;

   SME_3D:                 sme_3d           Spherical_3D_Coordinate;

   TM_AUGMENTED_3D:        tm_aug_3d        Map_Projection_3D_Coordinate;

   TM_SURFACE:             tm_surface       Map_Projection_Surface_Coordinate;

 ]

}

11.9.10 RD_Code

RD_Code is a Selection data type (see 11.2.6). RD_Code specifies the RD code associated with a specified RD as defined in Clause 7. Table 7.3 is a directory of RD specifications, each of which includes a code value and a corresponding label. In the API, a standard or registered RD is represented by its RD code.

11.9.11 OBRS_Code

OBRS_Code is a Selection data type (see 11.2.6). OBRS_Code specifies an OBRS code defined in Clause 7. Table 7.18 is a directory of OBRS specifications, each of which includes a code value and a corresponding label. An OBRS is an SRM concept that is not directly used in the functional API.

[ Table of contents ]