IEC 13249-3:2016 – SQL Multimedia and Application Packages: Spatial (SQL/MM Spatial)

The standard IEC 13249-3:2016 — titled Information technology — Database languages — SQL multimedia and application packages — Part 3: Spatial — is widely known as SQL/MM Spatial. It defines the user‑defined types (UDTs), methods, and conventions for storing, managing, and querying spatial data directly within SQL databases. This article provides a technical overview of the standard’s scope, core requirements, implementation highlights, and compliance considerations.

Scope and Objectives

IEC 13249-3:2016 specifies a set of spatial data types and operators that extend the SQL language to handle geometric and geographic information. Its primary goals are:

To provide a consistent and portable interface for spatial data across different database management systems (DBMS).
To define an abstract geometry model based on the Well‑Known Text (WKT) and Well‑Known Binary (WKB) representations.
To support common spatial operations such as intersection, union, distance, and buffer calculation.
To enable spatial indexing and coordinate system handling through standardized functions.

The standard is part of the ISO/IEC 13249 series, which covers multimedia and application packages for SQL. It adapts and harmonises concepts from the Open Geospatial Consortium (OGC) Simple Feature Access specification, ensuring interoperability with the broader GIS ecosystem.

Benefit: By following IEC 13249-3, developers write spatial queries and functions that work unchanged across compliant database platforms, reducing vendor lock‑in and easing system integration.

Technical Requirements and Data Model

Geometry Type Hierarchy

The standard defines a hierarchy of geometry types rooted at ST_Geometry. Each type supports specific methods and participates in spatial predicates. The following table lists the primary types and their characteristics.

Type	Description	Constraints & Subtypes
`ST_Point`	A 0‑dimensional geometry representing a single coordinate.	Coordinates may include Z (elevation) and M (measure) values.
`ST_Curve`	1‑dimensional geometry whose coordinates define a parametric curve.	Subtypes: `ST_LineString`, `ST_CircularString`.
`ST_Surface`	2‑dimensional geometry bounded by one or more closed curves.	Subtypes: `ST_Polygon`, `ST_CurvePolygon`.
`ST_GeomCollection`	A homogenous or heterogeneous collection of geometries.	Subtypes: `ST_MultiPoint`, `ST_MultiLineString`, `ST_MultiPolygon`.

Spatial Predicates and Operations

IEC 13249-3 defines a comprehensive set of Boolean predicates and analysis functions. The table below summarises the most common predicates used in spatial filtering and relationship testing.

Predicate	Example	Description
`ST_Equals`	a.ST_Equals(b)	Returns `TRUE` if geometries are spatially equal.
`ST_Disjoint`	a.ST_Disjoint(b)	Returns `TRUE` if geometries share no points in common.
`ST_Intersects`	a.ST_Intersects(b)	Returns `TRUE` if geometries have at least one point in common.
`ST_Touches`	a.ST_Touches(b)	Returns `TRUE` if geometries touch only at boundary points.
`ST_Contains`	a.ST_Contains(b)	Returns `TRUE` if b is wholly inside a.

Additional operations include constructive methods (e.g., ST_Buffer, ST_ConvexHull, ST_Union), metric functions (ST_Area, ST_Length, ST_Distance), and coordinate system transformation (ST_Transform). All methods follow the naming prefix ST_ to avoid collisions with non‑spatial functions.

Best Practice: Use the ST_Within / ST_Contains pair carefully to avoid double‑counting rows. Always consider whether the predicate you need is exactly the inverse of another (e.g., ST_Contains(a,b) is equivalent to ST_Within(b,a)).

Implementation Highlights

Integration with SQL Environments

SQL/MM Spatial is designed to be a natural extension of the SQL object‑relational model. Implementations typically:

Define geometry columns using the ST_Geometry type or one of its subtypes.
Support spatial indexes via R‑trees or grid‑based structures to accelerate predicate evaluation.
Provide import/export of WKT and WKB formats for interoperability with external GIS tools.

Conformance Levels

The standard defines two conformance levels:

Level 0: Basic geometry types (Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon) and fundamental predicates and operations.
Level 1: Full support including circular interpolation (ST_CircularString, ST_CurvePolygon), parametric curves, and advanced operations (e.g., ST_IsValid, ST_MakeValid).

Caution: Not every “SQL/MM Spatial” implementation declares its conformance level openly. Verify documentation for level‑of‑support to avoid deploying code that relies on higher‑level features unavailable in the target database.

Compliance and Conformance

Compliance with IEC 13249-3:2016 is achieved by implementing all required features for the declared conformance level and satisfying the type‑checking and semantic rules defined in the standard. Key compliance aspects include:

Consistent Naming: All spatial functions must use the ST_ prefix and the prescribed argument list (overloading is allowed but must be documented).
Coordinate Reference System (CRS) Support: The database must track the SRID (Spatial Reference Identifier) for each geometry and correctly transform when requested.
Null Handling: Spatial functions must comply with SQL’s three‑valued logic, returning UNKNOWN when any argument is NULL.
Geometry Validation: The standard specifies validity rules for each geometry type (e.g., rings must close, no self‑intersections for simple polygons).

Conformance testing is typically performed by the vendor or a third‑party using the abstract test suite provided by the standard. For users, choosing a database that has undergone formal conformance testing ensures predictable behaviour when migrating or sharing geographic applications.

Important: Non‑compliant implementations may produce incorrect results for geometry construction and spatial predicates, leading to application failures or data corruption. Always validate your DBMS against the IEC 13249‑3 conformance tests.

Frequently Asked Questions

Q: How does IEC 13249-3 relate to the OGC Simple Features standard?
A: IEC 13249-3 largely adopts the geometry model, type hierarchy, and operations defined by the OGC Simple Feature Access – Part 1 (Common Architecture). The SQL/MM version adds SQL‑specific mappings, type constraints, and integration with SQL object‑relational features. Both standards share the same foundation for spatial data representation.

Q: Which database systems implement IEC 13249-3?
A: Major implementations include Oracle Spatial (with the SDO_GEOMETRY system, which is based on SQL/MM), IBM Db2 Spatial Extender, PostgreSQL with PostGIS (largely compliant at Level 0), and Microsoft SQL Server spatial types (geometry and geography, which follow a similar but not identical model). Always check the specific version documentation for conformance details.

Q: What do the suffixes ‘Z’ and ‘M’ in coordinate values mean?
A: ‘Z’ indicates elevation (3D coordinate) and ‘M’ indicates a measure value (e.g., timestamp, distance along a route). Not all methods are required to handle Z‑ and M‑values; the standard clearly specifies which operations are defined for 2D, 3D, and measured geometries.

Q: Are there differences between the 2011 and 2016 editions of IEC 13249-3?
A: Yes. The 2016 edition (IEC 13249-3:2016), which is technically identical to ISO/IEC 13249-3:2016, includes clarifications on circular string handling, additional predicates, and improved documentation of coordinate systems. It also aligns more closely with SQL:2016. The Canadian adoption of the 2016 edition is referenced as CAN/CSA-ISO/IEC 13249-3-16.

— Published 2026. This article is for informational purposes and does not substitute the official standard document. For authoritative specification and conformance testing details, refer directly to IEC 13249-3:2016 or its national adoptions.

📥 Standard Documents Download

🔒

Please wait 10 seconds, the download links will appear after the ad loads