Geometry types, coordinate systems, and encoding rules
Geometry Types
GeoPackage supports the standard geometry types defined in the Simple Features specification (ISO 19125). These geometries can be stored in both 2D and 3D variants, with optional measurement (M) values.
Basic Geometry Types
Point - Represents a single location in space. Common uses in Danish municipalities include fire hydrants, street lights, or inspection points.
Example: A fire hydrant in Aarhus Kommune located at coordinates (571234.5, 6224567.8) in EPSG:25832.
LineString - An ordered sequence of points forming a continuous line. Used for representing roads, utility lines, or administrative boundaries.
Example: A bicycle path connecting multiple parks in Copenhagen, defined by a series of coordinate pairs that trace the path's centerline.
Polygon - A closed area defined by one exterior ring and zero or more interior rings (holes). Perfect for representing parcels, zones, or municipal boundaries.
Example: A building footprint in Odense with the outer boundary representing the building perimeter and an interior ring representing a courtyard.
MultiPoint - A collection of points. Useful for representing distributed features like tree inventories across a municipality.
Example: All oak trees in a municipal park, where each tree is a point in the collection but they're managed as a single feature representing "oak tree locations."
MultiLineString - Multiple line segments that may or may not be connected. Often used for complex road networks or river systems.
Example: The Gudenå river system with its multiple branches and tributaries, where each branch is a separate line but together they form the complete river network.
MultiPolygon - Multiple polygons stored as a single feature. Used when a single administrative unit consists of non-contiguous areas.
Example: A municipality that includes both mainland areas and several islands, such as Langeland Kommune, where all areas belong to the same administrative unit but are geographically separated.
Geometry Collections
GeometryCollection - A heterogeneous collection of geometries. While supported, it's generally better to use specific geometry types when possible for clearer data models.
Example: A comprehensive infrastructure asset record that includes a point (access hatch), lines (pipes), and polygon (service area) all associated with a single water pumping station.
Z and M Dimensions
GeoPackage supports additional dimensions beyond the standard X and Y coordinates:
Z (elevation) - Adds height information to geometries. Essential for terrain modeling, building heights, or underground infrastructure.
Example: A sewer network in Aalborg where pipes are stored as LineStringZ features, with the Z coordinate representing the depth below ground level for each point along the pipe.
M (measure) - Provides linear referencing along geometries. Useful for road maintenance records where events are recorded at specific distances along a route.
Example: A road in Esbjerg Kommune where potholes are recorded at specific meter marks along the road centerline (e.g., pothole at M=234.5 means 234.5 meters from the start of the road segment).
These can be combined to create variants like PointZ, LineStringZM, or PolygonM.
Coordinate Reference Systems
GeoPackage includes built-in support for coordinate reference systems (CRS) through the gpkg_spatial_ref_sys table. This table defines the coordinate systems used by the spatial data.
Coordinate Systems in Danish Context
For Danish municipal applications, you'll typically work with these coordinate systems:
EPSG:25832 (ETRS89 / UTM zone 32N) - The standard coordinate system for most Danish geospatial data. This is a projected coordinate system using meters as units.
Example: The coordinates (571234.5, 6224567.8) in EPSG:25832 represent a location in eastern Jutland, measured in meters from the UTM zone 32N origin.
EPSG:4326 (WGS 84) - Geographic coordinates in degrees. Often used for web mapping applications and GPS data.
Example: The same location as above would be approximately (10.2044°, 56.1629°) in EPSG:4326, representing longitude and latitude.
EPSG:4937 (ETRS89 3D) - Three-dimensional geographic coordinates for Denmark when height information is required.
Example: A survey point on Møn's Klint including both horizontal position and elevation above the ellipsoid.
The gpkg_spatial_ref_sys Table
This system table contains the definition of each coordinate system used in the GeoPackage. Each record includes:
srs_name- A human-readable name for the coordinate systemsrs_id- A unique identifier within the GeoPackageorganization- The organization defining the CRS (typically "EPSG")organization_coordsys_id- The organization's code (e.g., 25832)definition- The WKT (Well-Known Text) definition of the coordinate systemdescription- Additional descriptive information
Every geometry column in a GeoPackage must reference an entry in this table, ensuring that all spatial data has a clearly defined coordinate system.
Example: A typical entry for Danish data might look like:
srs_name: ETRS89 / UTM zone 32N
srs_id: 25832
organization: EPSG
organization_coordsys_id: 25832
definition: PROJCS["ETRS89 / UTM zone 32N", ...]
description: Used for most Danish municipal dataGeometry Encoding
GeoPackage uses a specific binary encoding format for geometries called GeoPackage Binary Format. This format wraps the standard Well-Known Binary (WKB) encoding with additional GeoPackage-specific header information.
GeoPackage Binary Format Structure
The encoding consists of two main parts:
GeoPackage Binary Header - Contains metadata about the geometry including:
- Magic number and version information
- Flags indicating byte order, envelope type, and coordinate dimensions
- Spatial reference system identifier
- Optional envelope (bounding box) for the geometry
Well-Known Binary (WKB) Geometry - The actual geometry data encoded according to the ISO 19125 standard.
Why This Encoding Matters
The GeoPackage binary format provides several advantages:
Self-contained spatial reference - Each geometry includes its CRS identifier, eliminating ambiguity about coordinate systems.
Optional envelopes - The header can include the bounding box of the geometry, enabling spatial indexing and faster queries without parsing the entire geometry.
Compact storage - Binary encoding is more efficient than text-based formats like WKT or GeoJSON.
Standardized interoperability - By using WKB internally, GeoPackage maintains compatibility with existing geospatial libraries and tools.
Working with Encoded Geometries
As a user of GeoPackage, you typically won't need to manually encode or decode geometries. Most GIS software and geospatial libraries (like GDAL, GeoTools, or PostGIS) handle this automatically. However, understanding the encoding helps when:
- Debugging spatial data issues
- Optimizing database performance
- Developing custom applications that read or write GeoPackage files
- Ensuring data quality during migration from other formats
Example: When importing a CSV file with coordinates into a GeoPackage, your GIS software will automatically convert the text coordinates into the GeoPackage binary format with the appropriate header and CRS reference.
Practical Considerations for Danish Municipalities
When working with GeoPackage in Danish municipal contexts, keep these guidelines in mind:
Consistent coordinate systems - Standardize on EPSG:25832 for most datasets to ensure compatibility across municipal systems and with national datasets like GeoDanmark.
Example: If your municipality receives GPS data in EPSG:4326 from field workers, transform it to EPSG:25832 before storing it in your GeoPackage to maintain consistency with other municipal data.
Appropriate geometry types - Choose the simplest geometry type that represents your data. Don't use MultiPolygon if all your features are single polygons.
Example: If each building in your database is always a single polygon, define the geometry column as Polygon rather than MultiPolygon, even though MultiPolygon could technically hold the data.
Dimension selection - Only include Z or M dimensions when necessary, as they increase storage requirements and processing complexity.
Example: For a simple street tree inventory where only the location matters, use Point geometry. Only use PointZ if you specifically need to record the elevation or tree height.
Documentation - Always populate the description fields in the gpkg_spatial_ref_sys table to help future users understand the coordinate systems in your GeoPackage.
Summary
GeoPackage's support for diverse geometry types, flexible coordinate systems, and efficient binary encoding makes it an excellent choice for Danish municipal geospatial applications. The format's self-contained nature and standardized encoding ensure that spatial data remains accessible and correctly interpreted across different systems and organizations.
Knowledge Check Quiz
Test your understanding of geometry types, coordinate systems, and encoding rules in GeoPackage:
Question 1: Which geometry type would be most appropriate for storing the complete municipal boundary of Ærø Kommune, which consists of the main island plus several smaller islands?
a) Polygon
b) MultiPoint
c) MultiPolygon
d) GeometryCollection
Question 2: What is the standard coordinate reference system used for most Danish municipal geospatial data?
a) EPSG:4326 (WGS 84)
b) EPSG:25832 (ETRS89 / UTM zone 32N)
c) EPSG:3857 (Web Mercator)
d) EPSG:4937 (ETRS89 3D)
Question 3: You need to store a sewer pipe network where you want to record the depth of each pipe segment. Which geometry type should you use?
a) LineString
b) LineStringM
c) LineStringZ
d) MultiLineString
Question 4: What information does the GeoPackage binary header include that standard WKB does not?
a) Spatial reference system identifier
b) Optional envelope (bounding box)
c) Coordinate dimension flags
d) All of the above
Question 5: A road maintenance database needs to record the location of repairs along road segments, with each repair logged at a specific distance from the start of the road. Which dimension should be used?
a) Z dimension
b) M dimension
c) No additional dimension needed
d) Both Z and M dimensions
Question 6: What table in a GeoPackage stores the coordinate reference system definitions?
a) gpkg_geometry_columns
b) gpkg_contents
c) gpkg_spatial_ref_sys
d) gpkg_crs_definitions
Question 7: You receive GPS coordinates in decimal degrees (latitude/longitude) from field workers. These coordinates are in which CRS?
a) EPSG:25832
b) EPSG:4326
c) EPSG:3857
d) EPSG:4937
Question 8: Which geometry type would be best for a dataset of all bus stops in a municipality?
a) Point
b) MultiPoint
c) Either Point or MultiPoint, depending on data model
d) LineString
Question 9: What is the primary advantage of GeoPackage's binary encoding over text-based formats like WKT?
a) Easier to read manually
b) More compact storage
c) Simpler to edit with text editors
d) Better for version control systems
Question 10: A building footprint dataset where some buildings have interior courtyards would require which geometric feature?
a) Multiple polygons
b) A polygon with interior rings
c) A MultiPolygon
d) A GeometryCollection
Answer Key
- c) MultiPolygon - Since the municipality consists of multiple non-contiguous areas (islands), MultiPolygon is the appropriate geometry type.
- b) EPSG:25832 (ETRS89 / UTM zone 32N) - This is the standard projected coordinate system for Danish geospatial data, with distances measured in meters.
- c) LineStringZ - The Z dimension represents elevation/depth, making it perfect for recording pipe depths below ground level.
- d) All of the above - The GeoPackage binary header includes all these elements, wrapping the standard WKB geometry with additional metadata.
- b) M dimension - The M (measure) dimension is specifically designed for linear referencing along line features.
- c) gpkg_spatial_ref_sys - This system table contains all CRS definitions used in the GeoPackage.
- b) EPSG:4326 - Decimal degree coordinates (latitude/longitude) indicate WGS 84 geographic coordinates.
- c) Either Point or MultiPoint, depending on data model - Use Point if each bus stop is a separate feature, or MultiPoint if you want to group related stops together as a single feature.
- b) More compact storage - Binary encoding is significantly more space-efficient than text representations.
- b) A polygon with interior rings - A single polygon can have one exterior ring (building outline) and one or more interior rings (courtyards), which is more appropriate than using multiple polygons.