Center of Excellence for Geospatial Information Science (CEGIS)

Semantics and Data Graphs Based on The National Map

Web Ontology Language (OWL) files of data summaries, shapes, and patterns




Topographic data vocabulary are serialized as Resource Description Framework (RDF)

Topographic data vocabulary serialized as Resource Description Framework (RDF)

(Public domain.)


USGS Created Ontologies

The National Map knowledge graphs include modules for different forms of physical features and spatial semantics. 

Web Ontology Language (OWL) files for Linked Geospatial Data from The National Map exist for the themes listed below. The Universal Resource Identifiers (URI) for these files use the prefix topo:<> .

Various stages of ontology design are described below. First, glossary definitions for standard feature types were captured to support formal models of concepts. The files are compressed and can be download here TOPO or from the tab below.  Instance data of individual features were converted from GIS data formats. Concept maps help visualize the relations between classes or sets of entities and their literal annotation. Finally, OWL characteristics are assigned to graph properties to support inference.  The project is developing ontology files for the data themes listed below.

  • topo:Boundary
  • topo:Landform
  • topo:NamedPoint
  • topo:Structure
  • topo:SurfaceWater
  • topo:Transportation


Geospatial Feature Sematics

Matching Esri to GeoSPARQL feature classes

GIS platforms such as Esri describe geospatial feature classes as geographic coordinate geometries (Esri). Geometries are associated with a description of the type of object the geometry represents. Geospatial ontology uses the concept of feature classes as real-world objects. This approach aligns the technology more closely to the cognitive perceptions of GIS users.  The two concepts, features as geometric representations and features as geographic objects, share the same core concept – a set of geographic measurements based on Cartesian coordinate system. In the ontological context, those measurements take one form, such as Ground Positioning System (GPS) and in the GIS context, those measurements take the form of a map. An ontology is available for integrating GIS and geospatial ontology feature representations and geometry objects as coordinates.


Lookup Tables

A feature and feature class are defined differently in GIS and in geospatial ontology. In GIS, a feature is an object that stores its geographic representation, which is typically a point, line, or polygon, as one of its properties (or fields) in the row. In ArcGIS, feature classes are homogeneous collections of features with a common spatial representation and set of attributes stored in a database table, for example, a line feature class for representing road centerlines. 

Feature classes in GIS are geometry types that are further simplified. Each row of a GIS table has one x point and one y point to define a single line segment. Multiple segments may make up a linear feature if collections of such segments are further combined and defined as objects.

So, how does a user interpret what type of ‘Thing’ a geometric representation stands for? Features have attribute fields that may or may not include a classification of feature typology. The National Map of the U.S. Geological Survey has built lookup tables for feature classification of their very large databases. Lookup tables simplify computation by creating an index for stored attribute values. In the case of The National Map, lookup tables also decrease database errors because important information is maintained in a single array with codes, called FCodes and FTypes, as references to values in that array. 

 A general class for the feature concept is categorized as the FType in the form of the first three digits and the FCode, the feature class of an instance, as two digits attached to the end of the FType. For example, the Structures theme has feature classes Struct_Line and Struct_Point that have 3-digit FTypes associated with them, also called SubTypes. The feature domains, the FCodes, build on the Stuct_Line subtype and Struct_Point subtype, Energy and Education respectively. (Structures, Data Dictionary.  Though lookup tables are computationally efficient, how could a user or automated program get to the complex semantics of the associated definitions? 


Competency questions

Because geographic information involves maps and knowledge, the objective is to create an ontology that integrates, but differentiates, between geometry and objects. We will organize an OWL graph that expands access to the semantics of models such as lookup tables by creating object classes. The Point and Line geometries must be associated with objects separate from codes. The objectives for the models are to enable and support the following queries:

  • All entities have a Feature classification and be associated with geometric coordinates
  • All entities or their Feature classifications have an FCode
  • All entities and/or their geometries are members of a GIS Feature Class

Queries for which an OWL ontology must be able to produce results are called competency queries. Competency queries must be supported by results produced by assertions or reasoning.


Concept map

A good way to approach the problem is to draw a concept map that includes graphic symbols representing the existing data, lines between entities to represent properties, and different lines that should result from inference. The Figure 1 below would show how this works.

Concept map of data FType/FCode interaction with GeoSPARQL Feature

The concept map is a visual image of linking FTypes and FCodes from The National Map to the Feature subclass of the GeoSPARQL ontology. The geometry values integrate as well.

(Credit: Dalia Varanka. Public domain.)

The blue ovals and lines represent the directly connected entities in our GIS tables; two types of FeatureClasses, the relation between FeatureClasses and their SubType codes, the relation of SubTypes and FCodes, and descriptions and definitions of SubTypes and FCodes. The inferred relations of our model are that features require geometric representation, features need semantic specification that exist in natural language definitions, and FeatureClasses and Geometries have the same information but formatted differently.

A similar approach as described here can be appled to other codes applied to geospatial features, such as Federal Information Processing Standards (FIPS) codes. FIPS codes are now integrated with the Geographic Names Information System (GNIS) database. 





Surface water concept

This figure depicts the concept map of surface water classes for ontology

(Public domain.)

Past Projects

Research on ontology matching involved a design based on the National Hydrographic Dataset (NHD).   

Click here to access the zip file.