Architecture

6.1 Architecture — SQL implementation using predefined data types

6.1.1 Overview

This standard defines a schema for the management of feature table, Geometry, and Spatial
Reference System information in an SQL-implementation based on predefined data types. This
part of ISO 19125 does not define SQL functions for access, maintenance, or indexing of
Geometry in an SQL-implementation based on predefined data types.
Figure 1 illustrates the schema to support feature tables, Geometry, and Spatial Reference
Information in an SQLimplementation based on predefined data types.

a) The GEOMETRY_COLUMNS table describes the available feature tables and their
Geometry properties.

b) The SPATIAL_REF_SYS table describes the coordinate system and transformations for
Geometry.

c) The FEATURE TABLE stores a collection of features. A feature table‘s columns

represent feature attributes, while rows represent individual features. The Geometry of a
feature is one of its feature attributes; while logically a geometric data type, a Geometry
Column is implemented as a foreign key to a geometry table.

d) The GEOMETRY TABLE stores geometric objects, and may be implemented using either
standard SQL numeric types or SQL binary types.

Figure 1: Schema for feature tables using predefined data types

Depending upon the storage type specified by the GEOMETRY_COLUMNS table, a geometric
object is stored either as an array of coordinate values or as a single binary value. In the former
case, predefined SQL numeric types are used for the coordinates and these numeric values are
obtained from the geometry table until the geometric object has been fully reconstructed. In the
latter case, the complete geometric object is obtained in the Well-known Binary Representation as a
single value.

6.1.2 Identification of feature tables and geometry columns

Feature tables and Geometry columns are identified through the GEOMETRY_COLUMNS table.
Each Geometry Column in the database has an entry in the GEOMETRY_COLUMNS table. The data
stored for each geometry column consists of the following:
a) the identity of the feature table of which this Geometry Column is a member;

b) the name of the Geometry Column;

c) the spatial reference system ID (SRID) for the Geometry Column;

d) the type of Geometry for the Geometry column;

e) the coordinate dimension for the Geometry Column;

f) the identity of the geometry table that stores geometric objects for this Geometry Column;

g) the information necessary to navigate the geometry table in the case of normalized geometry storage.

6.1.3 Identification of Spatial Reference Systems

Every Geometry Column and every geometric entity is associated with exactly one Spatial
Reference System. The Spatial Reference System identifies the coordinate system for all
geometric objects stored in the column, and gives meaning to the numeric coordinate values for
any geometric object stored in the column. Examples of commonly used Spatial Reference
Systems include ―Latitude Longitude‖ and ―UTM Zone 10‖.
The SPATIAL_REF_SYS table stores information on each Spatial Reference System in the
database. The columns of this table are the Spatial Reference System Identifier (SRID), the
Spatial Reference System Authority Name (AUTH_NAME), the Authority Specific Spatial
Reference System Identifier (AUTH_SRID) and the Wellknown Text description of the Spatial
Reference System (SRTEXT). The Spatial Reference System Identifier (SRID) constitutes a
unique integer key for a Spatial Reference System within a database.
Interoperability between clients is achieved via the SRTEXT column which stores the Well-known
Text representation for a Spatial Reference System.

6.1.4 Feature tables

A feature is an abstraction of a real-world object. Feature attributes are columns in a feature table.
Features are rows in a feature table. The Geometry of a feature is one of its feature attributes;
while logically a geometric data type, a geometry column is implemented as a foreign key to a
geometry table.
Relationships between features may be defined as foreign key references between feature tables.
6.1.5 Geometry tables

6.1.5.1 Normalized geometry schema

The normalized geometry schema stores the coordinates of geometric objects as predefined SQL
numeric types. One or more coordinates (X, Y and optionally Z and M ordinate values) will be
represented by pairs of numeric types in the geometry table, as shown in Figure 2. Each
geometric object is identified by a key (GID) and consists of one or more primitive elements
ordered by an element sequence (ESEQ). Each primitive element in the geometric object is
distributed over one or more rows in the geometry table, identified by a primitive type (ETYPE),
and ordered by a sequence number (SEQ).
The rules for geometric object representation in the normalized schema are defined as follows.

a) ETYPE designates the Geometry Type.

b) Geometric objects may have multiple elements. The ESEQ value identifies the individual
elements.

c) An element may be built up from multiple parts (rows). The rows and their proper sequence are
identified by the SEQ value.

d) Polygons may contain holes, as described in the Geometry object model.

e) PolygonRings shall close when assembled from an ordered list of parts. The SEQ value
designates the part order.

f) Coordinate pairs that are not used shall be set to Nil in complete sets (both X and Y). This is
the only way to identify the end of the list of coordinates.

g) For geometric objects that continue onto an additional row (as defined by a constant element
sequence number or ESEQ), the last Point of one row is equal to the first Point of the next.

h) There is no limit on the number of elements in the geometric object, or the number of rows in
an element.
 Figure 2: Example of geometry table for Polygon Geometry using SQL

6.1.5.2 Binary geometry schema

The binary Geometry schema is illustrated in Table 1, uses GID as a key and stores the geometric
object using the Well-known Binary Representation for Geometry (WKBGeometry). The geometry
table includes the minimum bounding rectangle for the geometric object as well as the
WKBGeometry for the geometric object. This permits construction of spatial indexes without
accessing the actual geometric object structure, if desired.

Table 1: Example of geometry table for Polygon

Geometry Using the Well-known Binary
Representation for Geometry

GID XMIN YMIN XMAX YMAX Geometry

1 0 0 30 30 < WKBGeometry >

2 30 0 60 30 < WKBGeometry >

3 0 30 30 60 < WKBGeometry >

 4 30 30 60 60 < WKBGeometry >

6.1.5.3 SQL/MM geometry schema

The geometric attributes of a feature may also be specified using an extension of

SQL/MM 6.1.6 Text

6.1.6.1 ANNOTATIONS Metadata Table

Each feature table/geometry column pair that has associated annotation text entities will be
represented as a row in the ANNOTATIONS metadata table, or view. The data stored for each for
annotation is:
The identity of the feature table containing the text column
The column in the feature table that contains the text entity key for associating multiple
text elements to a single text entity
A base scale for which the text placement is designed
Optionally, a geometry column in the feature table for associated geometry representing
an envelop for the text
The identity of the text element table containing the geometry column
The column name in the text element table that contains the text to be placed
The column name in the text element table that contains the location geometry of the text
The column name in the text element table that contains the optional leader line that may
be associated with the text.
The column name in the text element table that contains text rendering data
Default values for the text element, either by value of by using ―sql-value expressions‖
that can be evaluated on the feature entry associated to the text.
Default values for the text rendering data, as a collection of XML elements as a single text
string.
The base scale for all size values that will be given in points1 (1 point = 0.35146 mm). Each text object has
a font size from the style. To enable annotation text, a mechanism is needed whereby text may be defined in
points but (usually) based on a specific map scale. Thus, a text object would be placed using a font size of
24 point at 1:1000000 and client-rendering engines would use this information to scale the text size
appropriate to changes in the map scale. This base scale would be stored once in the metadata. Any point
size values in the metadata attributes column (see below) or in individual rows would be relative to this
value, as would letter-spacing and word-spacing, stroke-width (for text and leader line) and both vertical
and horizontal margins. Application may round to the nearest point during scaling.

1
There is some minor disagreement on the standard for a text point. The US-UK standard is 1/72.27 inch,
Adobe Postscript use 1/72 inch. Traditional typesetters use 1/64 inch and European (based on a French
standard) use approximately 1/67 inch. At the sizes of normal text at normal display scale, none of these
differences are significant. These manor differences man make fine scale comparison of output difficult to
make.
6.1.6.2 Table or View Constructs for structural metadata

The following CREATE TABLE statement creates an appropriately structured table to be included in
the schema, describing how text is stored in a feature table. This should be either an actual
metadata table or an updateable view so that insertion of reference system information can be done
directly with SQL.
Note that there is no requirement that the annotated feature have any other attributes.
Unattributed annotations are in essence context-free, and may be used to place any text on the
data, such as collection metadata or notes to user about unusual situations of which he may wish
to be aware.
 CREATE TABLE ANNOTATION_TEXT_METADATA AS
{
F_TABLE_CATALOG AS CHARACTER VARYING NOT NULL,
F_TABLE_SCHEMA AS CHARACTER VARYING NOT NULL,
F_TABLE_NAME AS CHARACTER VARYING NOT NULL,
F_TEXT_KEY_COLUMN AS CHARACTER VARYING NOT NULL,
F_TEXT_ENVELOPE_COLUMN AS CHARACTER VARYING NOT NULL,

A_ELEMENT_TABLE_CATALOG AS CHARACTER VARYING NOT NULL,

A_ELEMENT_TABLE_SCHEMA AS CHARACTER VARYING NOT NULL,
A_ELEMENT_TABLE_NAME AS CHARACTER VARYING NOT NULL,

A_ELEMENT_TEXT_KEY_COLUMN AS CHARACTER VARYING NOT NULL

A_ELEMENT_TEXT_SEQ_COLUMN AS CHARACTER VARYING NOT NULL
A_ELEMENT_TEXT_VALUE_COLUMN AS CHARACTER VARYING NOT NULL,
A_ELEMENT_TEXT_LEADERLINE_COLUMN AS CHARACTER VARYING NOT NULL,
A_ELEMENT_TEXT_LOCATION_COLUMN AS CHARACTER VARYING NOT NULL,
A_ELEMENT_TEXT_ATTRIBUTES_COLUMN AS CHARACTER VARYING NOT NULL,

A_MAP_BASE_SCALE AS NUMBER NOT NULL,

A_TEXT_DEFAULT_EXPRESSION AS CHARACTER VARYING,
A_TEXT_DEFAULT_ATTRIBUTES AS CHARACTER VARYING
}
Note that there are no constraints on row in this table, allowing a single feature table/geometry
column pair to be annotated using text from different feature table columns.

6.1.6.3 Field Description

The fields in the Annotations metadata information view are given in

Table 2: Column definitions for Annotation Text metadata

Columns Description

F_TABLE_ the fully qualified name of the feature table containing the geometry column to be
CATALOG, annotated
SCHEMA,
NAME

F_TEXT_ The names of the column in the feature table that contain:
KEY_COLUMN.
A KEY for the text to which the text elements can use as a point of aggregation.
ENVELOPE_CO
LUMN, An ENVELOPE_COLUMN that contains a geometry object that acts as an
envelope for the set of text elements in this text entity. This column should also be
a valid geometry column.

Columns Description
 A_ELEMENT_TABLE the fully qualified name of the text element table containing the text elements
CATALOG, used for the F_Text columns column defined above
SCHEMA,
NAME

A_TEXT_ELEMENT The names of the columns in the ELEMENT_TABLE that contain the:
KEY_COLUMN
SEQ_COLUMN a) The foreign KEY for the text entity as specified in the
VALUE_COLUM F_TEXT_KEY_COLUMN.
N
LEADERLINE_ b) A sequence (SEQ) column which will be used to order the text
COLUMN elements in this text entity. Any sortable type is valid for this column
in the table, although integers would be the obvious choice.
LOCATUIN_CO
LUMN c) A text string VALUE for this text element.
ATTRIBUTES_
COLUMN d) The LEADERLINE for this text element if it has one (should
also be a geometry column).

e) The LOCATION for this text element (should also be a geometry

column).

f) The local text ATTRIBUTES providing the opportunity to override

the text attributes currently in force. This is an XML type, and will be
a collection of XML elements each describing a text attribute of the
current text element. Unspecified attributes take the value most
recently defined.
A_MAP_BASE_SCALE The base scale for all size values that will be given in points2 (1 point = 0.35146
mm).
Each text object has a font size from the style. To enable annotation text, a
mechanism is needed whereby text may be defined in points but (usually) based on a
specific map scale. Thus, a text object would be placed using a font size of 24 point
at 1:1000000 and clientrendering engines would use this information to scale the text
size appropriate to changes in the map scale. This base scale would be stored once in
the metadata. Any point size values in the metadata attributes column (see below) or
in individual rows would be relative to this value, as would letter-spacing and word-
spacing, stroke-width (for text and leader line) and both vertical and horizontal
margins. Application may round to the nearest point during scaling.
Columns Description

A_TEXT_DEFAULT_ The default values for the corresponding ―A_TEXT_‖ columns above, for
EXPRESSION cases where these columns are NULL in the feature table. They may be
ATTRIBUTES values or ―query‖ expressions in terms of other columns in the database.
These defaults shall be overridden on a row by row basis when the
corresponding columns in the feature table row are not NULL. Formats,
which are large text strings, and interpretation for these columns are
discussed in Part 1.

2
There is some minor disagreement on the standard for a text point. The US-UK standard is 1/72.27 inch, Adobe
Postscript use 1/72 inch. Traditional typesetters use 1/64 inch and European (based on a French standard) use
approximately 1/67 inch. At the sizes of normal text at normal display scale, none of these differences are significant.
These manor differences man make fine scale comparison of output difficult to make.
 6.1.7 Use of numeric data types

SQL-implementations usually provide several numeric data types. In this standard, the use of a
numeric data type in examples is not meant to be binding. The data type of any particular column
can be determined, and casting operators between similar data types are available. Any particular
implementation may use alternative data types as long as casting operations shall not lead to
difficulties.

6.1.8 Notes on SQL/CLI access to Geometry values stored in binary form

SQL/CLI provides standard mechanisms to bind character, numeric and binary data values.

This subclause describes the process of retrieving geometric object values for the case where the
binary storage alternative is chosen.

The WKB_GEOMETRY column in the geometry table is accessed in SQL/CLI as one of the binary
SQL data types (SQL_BINARY, SQL_VARBINARY, or SQL_LONGVARBINARY).

EXAMPLE The application would use the SQL_C_BINARY value for the fCType parameter of SQLBindCol
(or
SQLGetData) in order to describe the application data buffer that shall receive the fetched Geometry data
value. Similarly, a dynamic parameter whose value is a Geometry would be described using the
SQL_C_BINARY value for the fCType parameter of SQLBindParameter.

This allows binary values to be both retrieved from and inserted into the geometry tables.

6.2 Architecture — SQL implementation using Geometry Types

6.2.1 Overview

This standard defines a schema for the management of feature table, Geometry, and Spatial
Reference System information in an SQL-implementation with a Geometry Type extension.

Figure 3 illustrates the schema to support feature tables, Geometry, and Spatial Reference
Information in an SQLimplementation with a Geometry Type extension.

a) The GEOMETRY_COLUMNS table describes the available feature tables and their Geometry
properties.

b) The SPATIAL_REF_SYS table describes the coordinate system and transformations for
Geometry.

c) The feature table stores a collection of features. A feature table‘s columns represent feature
attributes, while rows represent individual features. The Geometry of a feature is one of the
feature attributes, and is an SQL Geometry Type.
 Figure 3: Schema for feature tables using SQL with Geometry Types

6.2.2 Identification of feature tables and geometry columns

Feature tables and Geometry columns are identified through the GEOMETRY_COLUMNS table.
Each Geometry Column in the database has an entry in the GEOMETRY_COLUMNS table. The
data stored for each geometry column consists of the following:

a) the identity of the feature table of which this Geometry Column is a member;

b) the name of the Geometry Column;

c) the spatial reference system ID for the Geometry Column;

d) the coordinate dimension for the Geometry column;

The columns in the GEOMETRY_COLUMNS table for the SQL with Geometry Types environment
are a subset of the columns in the GEOMETRY_COLUMNS table defined for the SQL-
implementation based on predefined data types.

An alternative method for identification of feature tables and Geometry Columns may be available for SQL-
implementations with Geometry Types. In the SQL-implementation with Geometry Types, the Geometry
Column may be represented as a row in the COLUMNS metadata view of the SQL
INFORMATION_SCHEMA.
Spatial Reference System Identity and coordinate dimension is, however, not a standard part of the SQL
INFORMATION_SCHEMA. To access this information, the GEOMETRY_COLUMNS table would still need
to be referenced.

6.2.3 Identification of Spatial Reference Systems

Every Geometry Column is associated with a Spatial Reference System. The Spatial Reference
System identifies the coordinate system for all geometric objects stored in the column, and gives
meaning to the numeric coordinate values for any geometric object stored in the column. Examples
of commonly used Spatial Reference Systems include ―Latitude Longitude‖ and ―UTM Zone 10‖.
 The SPATIAL_REF_SYS table stores information on each Spatial Reference System in the
database. The columns of this table are the Spatial Reference System Identifier (SRID), the Spatial
Reference System Authority Name (AUTH_NAME), the Authority Specific Spatial Reference
System Identifier (AUTH_SRID) and the Wellknown Text description of the Spatial Reference
System (SRTEXT). The Spatial Reference System Identifier (SRID) constitutes a unique integer
key for a Spatial Reference System within a database.

Interoperability between clients is achieved via the SRTEXT column which stores the Well-known
Text representation for a Spatial Reference System.

6.2.4 Feature tables

A feature is an abstraction of a real-world object. Feature attributes are columns in a feature table.
Features are rows in a feature table. The Geometry of a feature is stored in a Geometry Column
whose type is drawn from a set of SQL Geometry Types.

Relationships between features may be defined as foreign key references between feature tables.

6.2.5 Background information on SQL User Defined Types

The term User Defined Type (UDT) refers to a data type that extends the SQL type system.

UDT types can be used to define the column types for tables, this allows values stored in the
columns of a table to be instances of UDT.

SQL functions may be declared to take UDT values as arguments, and return UDT values as
results.

An UDT may be defined as a subtype of another UDT, referred to as its supertype. This allows an
instance of the subtype to be stored in any column where an instance of the supertype is expected
and allows an instance of the subtype to be used as an argument or return value in any SQL
function that is declared to use the supertype as an argument or return value.

The above definition of UDT is value based.

SQL implementations that support User Defined Types may also support the concept of References
to User Defined Types instances that are stored as rows in a table whose type corresponds to the
type of the User Defined Type. The terms RowType and Reference to RowType are also used to
describe such types.

This standard allows Geometry Types to be implemented as either pure value based Types or as
Types that support persistent References.

The Types for Geometry are defined in black-box terms, i.e. all access to information about a
Geometry Type instance is through SQL functions. No attempt is made to distinguish functions that
may access Type instance attributes (such as the dimension of a geometric object) from functions
that may compute values given a Type instance (such as the centroid of a Polygon). In particular,
an implementation of this standard would be free to nominate any set of functions as observer
methods on attributes of a User Defined Type, as long as the signatures of the SQL functions
described in this standard are preserved.
6.2.6 SQL Geometry Type hierarchy

The SQL Geometry Types are organized into a type hierarchy shown in Figure 4.

Figure 4: Figure: SQL Geometry Type hierarchy

The root type, named Geometry, has subtypes for Point, Curve, Surface and Geometry Collection.
A Geometry Collection is a Geometry that is a collection of possibly heterogeneous geometric
objects. MultiPoint, MultiCurve and MultiSurface are specific subtypes of Geometry Collection used
to manage homogenous collections of Points, Curves and Surfaces. The 0 dimensional Geometry
Types are Point and MultiPoint.
The one-dimensional Geometry Types are Curve and MultiCurve together with their subclasses. The
two-dimensional Geometry Types are Surface and MultiSurface together with their subclasses.

SQL functions are defined to construct instances of the above Types given Well-known Text or
Binary representations of the types. SQL functions defined on the types implement the methods
described in the Geometry Object Model.

6.2.7 Geometry values and spatial reference systems

In order to model Spatial Reference System information, each geometric object in the SQL with
Geometry Types implementation is associated with a Spatial Reference System as specified by
SQL/MM. In addition to the SQL/MM
 6.2.8 Access to Geometry values in the SQL with Geometry Type case

Spatial data are accessed using the SQL query language extended with SQL routines to create
Geometry Types as well as routines to observe or mutate their attributes, as specified by SQL/MM..

6.2.9 Text

6.2.9.1 Text Object Implementation

6.2.9.1.1 Text Objects

The text object, and their component elements which can be used either as a feature attribute or
as a free-floating object, is defined in 7.2.20.

6.2.9.2 Metadata Table (View)

The metadata at a table level allows common information to be stored at a common level and not
for each record. This keep the data for each record as compact as possible. There is no specific
specification for this metadata table. But the data requirements in Table 3 must be available from
the metadata store. This data if created as a table would look like this:

CREATE TABLE ANNOTATION_TEXT_METADATA AS

{
F_TABLE_CATALOG AS CHARACTER VARYING NOT NULL,
F_TABLE_SCHEMA AS CHARACTER VARYING NOT NULL,
F_TABLE_NAME AS CHARACTER VARYING NOT NULL,
F_TEXT_COLUMN AS CHARACTER VARYING NOT NULL,

A_TEXT_DEFAULT_MAP_BASE_SCALE AS CHARACTER VARUONG,

A_TEXT_DEFAULT_EXPRESSION AS CHARACTER VARYING,
A_TEXT_DEFAULT_ATTRIBUTES AS CHARACTER
VARYING }
The fields in the table above are described in shall be a view of database administration tables and
must contain the following fields for each text column (column of a ANNOTATION_TEXT type):

Table 3: Text metadata attributes

FIELD DEFINITION COMMENT

F_TABLE_CATALOG Name of the table in Databases have format for this based on
which the text type SQL:1999.
F_TABLE_SCHEMA
values are stored.
F_TABLE_NAME

F_TEXT_COLUMN_NAME Name of the column in Databases have format for this based on SQL:1999.
which the text type This column in the feature table
value are stored. described above must be of type
ANNOTATION_TEXT.
A_TEXT_DEFAULT_MAP_BASE_SCALE The base map scale for
which the text will be
displayed

A_TEXT_DEFAULT_EXPRESSION This column allows the Any valid database column expression resulting
actual text of a text in a string is acceptable. The expression is
object to come from evaluated for the each row. If this field is null, the
data outside the text individual text objects may have their own
object VALUE field. embedded text or nothing shall be displayed. Any
embedded text shall override this expression
value.
During query to support display, client
applications should add this expression to their
select list so that any returned records will have
the information needed to evaluate this expression
without round tripping back to the database. .
Note that this is the one case where the data
critical to the display of text is stored outside the
text object or metadata. It should be obvious to
anyone changing the VALUE field that they are
changing the text object. It may not be obvious to
someone updating a column covered by the text
expression that they are affecting the text object
display.

A_TEXT_DEFAULT_ATTRIBUTES As many text attributes The Text Style, Layout and Leader Line Style
may be common in one described below may be stored in the metadata as
table, the database may well as the individual rows. Any values in the
store the common ones individual rows shall override the metadata
once here and allow for values. The resulting attributes are an overlay of
individual row (record) the metadata attributes and individual row
overrides. attribute values.