GGDM and schema-driven geospatial models
Learn why a geospatial data model is more than a list of field names and why mappings need model, profile, version, and code-list context.
Why this matters
Large geospatial communities often need common definitions for feature types, attributes, relationships, and coded values. A shared model makes exchange more consistent, but only if implementations preserve which model and profile they actually used.
Learn it
GGDM is a DGIWG geospatial data model used to describe geospatial features and their attributes in a structured, schema-driven way. When working with GGDM-like models, separate the conceptual feature from its implementation schema, profile, version, source identity, and code lists. Mapping into another system may require semantic decisions, not just renaming fields.
Work through an example
If a source uses a coded attribute, copying the numeric code without the code-list context can destroy its meaning. A good mapping preserves the source code and records the destination interpretation.
Source model โ profile/schema โ feature โ attributes โ code lists
โ
mapping + provenance
โ
destination modelPractice
- 1Choose one feature and list its geometry, attributes, coded values, and relationships.
- 2Identify which information comes from the model and which comes from a particular implementation profile.
- 3Draft a mapping note that preserves source model, version, and code-list provenance.
What to watch for
A field-to-field spreadsheet is not automatically a semantic mapping. Confirm feature meaning, attribute definition, cardinality, units, and code-list interpretation.
Where this takes you
This reasoning applies to GGDM, S-100 product catalogues, OGC schemas, and any standards-based geospatial migration.