This standard enumerates the requirements for defining and representing geographic features in geographic information systems, applications and transmittable data formats.

This "Part 1: Feature models" defines a new General Feature Model with various representations, and how it determines the basic form of geographic information. This is derived from and extends ISO 19109, which, in its current form, only addresses schema-based data storage defined in UML, but leaves possibilities open for other non-schematic design systems as extensions, such as dynamic object systems, as JavaScript and other formats using key-value pairs.

The strict schematic formulations such as might be used in a complied object language or in query languages requiring a predictable format such as SQL in relational databases or any Object-Oriented Databases which depend on a compiled set of object types, tend towards uniformity in the structure of any feature class. This schema approach matches formal abstractions and is useful in controlled applications that depend on the consistency of a strict relational or object-class structures. In this sense, strict schemata are an interoperability barrier between different applications which may share semantic structure but not implementation structures.

The more flexible feature data structures described in this document, will use semantics, taxonomies and ontologies, to interpret a variable structure that match a common taxonomy and constraints but may vary in their structures because two instances in the real world might not be fully describable by a single "attribute template". The approach follows the ideas of a controlled vocabulary that strictly defines terms such as, in this document, the names of the features' types, relations and properties but includes restriction in a class only if demanded by the semantics of reality. Such approaches have proven workable in medical, legal and cultural record keeping, see [15] and [oecd], and its use is not new to geographic information. Feature and attribute catalogs (which are controlled vocabularies) have been in use in digital mapping since the 1980’s, see [7].

Semantically structured data sets aim to represent reality, not the specific needs of a single application. This leads to application independent data stores that can support all applications because they support a data structure that is both flexible and extendable. This shifts the support of interoperability from creating transfer formats, to creating inclusive, flexible, and thereby interoperable data stores usable by a wide range of application.

"Part 2: Metrics for geometry" will describe the distinctions between "Euclidean geometry" in a plane such as might be appropriate for a large-scale map and "geodetic, ellipsoidal and non-Euclidean geometry" in general on a curved surface such that of the Earth. The most common implementation is ellipsoidal geometry using the datum surface, usually a reference oblate ellipsoid of the form:

\$(x^2 + y^2) / a^2 + z^2 / b^2 = 1\$ (where a = "equatorial radius" and b = "polar radius")

Spherical geometry is sufficient for a small area using a local best fit spherical approximation consistent with local curvature. Global use of a single sphere is problematic; for example, geodesics on a sphere close in a single arc (great circles) but on more general ellipsoids, only the meridians and the equator do so. The other issue is that the ellipsoidal coordinates used are based not on the central angle of the radial line to the position, but the tangential angles of the surface, which introduces other subtle and non-uniform errors in "spherical approximations".

"Part 3: Simple geometry" will describe the simplest mathematical geometry definitions, based on linear interpolation in the CRS. The first 3 parts are a replacement for ISO 19125-1:2004, Geographic information – Simple feature access – Part 1: Common architecture. For completeness, this part will also include definitions for geodesic and rhumb "line" interpolations which complete the concept of "line" from Euclidean geometry. Linear equations in the CRS match the Cartesian coordinate equations for lines. The concept of rhumb lines match the constant bearing concept in navigation, which are lines in maps using a Mercator projection. While linear curves depend on the coordinate applied to the geography, geodesic and rhumb lines are controlled by the geometry of the reference surface (usually an ellipsoid of the CRS). Geodesics match the concept of the shortest distance curve. What is a single curve type in flat Euclidian spaces requires 3 different curve types in non-Euclidian, non-flat, ellipsoidal geometries.

Further parts will describe other geometry and topology structures and a set of parallel standards will define WKT (well-known text) and JSON (JavaScript Object Notation) for both features and geometry. It should be noted that WKT and JSON are dependent on key-value encodings, which can use taxonomies to organize the keys, and in some cases, the values as in code lists.

A feature is a representation of a real-world object. For spatial applications, the most important property of a feature is location which will be dealt with in later parts of this standard on geometry, which will be derived from and extend ISO 19107 Geographic information — Spatial schema and will contain implementation guidance and suggestions. The corresponding SQL syntax will be defined in ISO/IEC 13249-3: Information technology — SQL Multimedia and Application Packages - Part 3: Spatial. Where possible, the SQL/MM approaches to geometry will be paralleled in this series of standards, except where an equivalent approach is more consistent with the common mathematical approached used in CAD/CAM applications, modified to fit non-Euclidean reference surfaces. The only example of this divergence currently-known is the use of projective space in the common mathematical derivations for B-spline curves. The current SQL/MM approach uses a slightly different approach to including weights for points, which would have to be translated to projective space for the common B-spline implementations. In SQL, a purely schema form is used, and dynamic data approaches belong to the looser database models such as NoSQL which depends less on transaction and more of data size and simplicity (big data approaches, see [5]).

All normative language (statements that directly affect the implementation of items compliant to the standard, called "standardization targets") is restricted to requirements, recommendations and permissions. The word "shall" implies that conformance requires the statement to apply in the conditions cited in that statement; these are referred to as "requirements" and are numbered with "Req#".

The word "should" implies that the use of best practice recommends the statement to apply in the conditions cited, and these are referred to as "recommendations" and are numbered with "Rec#".

The word "may" implies that conformance and practice allow the statement to apply in the conditions cited, and these are referred to as "permissions" and are numbered with "Per#". Permissions are not necessarily complete, in the sense that everything not specifically blocked by a requirement is permissible. Permissions are often used to prevent the over-interpretation of requirements which might block a valid implementation of the requirement as stated. This is akin to the open-world assumption, e.g. all approaches are permitted unless explicitly and unambiguously forbidden by a requirement.

Any similar words used the text body ("must", "might", "will", etc.) are not official normative statements and are not marked as such; they usually refer to a logical result of compliance to one or more normative statements, and often appear in the discussion of normative implications. No unmarked statement is normative although it may be truly implied by the marked normative statements. The statements (requirements, recommendations and permissions) marked and numbered are normative even if the "normative language" is inappropriately used.

Requirements ("Req#") are collected in requirements classes. Corresponding conformance classes, in Annex A, collate all requirements associated to each conformance class which outline or suggest tests that may be use in to prove conformance with the associated requirements class. Each requirement class and conformance class have a URL label in the namespace of this document. Conformance classes often require conformances to a previously defined class.

Recommendations ("Rec#") and Permissions ("Per#") can be anywhere in the document because they are logically not testable and are not addressed in a Conformance Class "testable items" in any sense. Any test of a requirement that blocks the usage of either any recommendation or permission is invalid. All normative statements, requirements, recommendations, permissions and tests are labelled statements a having a URL in the namespace of the clause, which in turn is in the namespace of this document defining the standard. Any test suite that references this document should use the URL’s to validate its procedures. All such names are listed immediately after each named item.

https://opengeospatial.org/as/FG/P1/FM/1.0/general/

A conformance class tests the sability of a system to conform to the mandatory requirements expressed in this document. Recommendations and Permissions are not tested. The Conformance Clauses are in Annex A where requirements are associated to required tests. There are three conformance classes in Annex A which will gather the Requirements of the corresponding requirement classes, clauses 6.2, 6.3, 6.4 for representing feature models types and suppling suggestion to how the tests may be formulated:

In a Feature Taxonomy or Controlled Vocabulary, two lists of "well-known" terms are created to act as named keys and searchable indexes for both:

The abstract root of the Feature Types is always "Feature" defined in 4.7, Properties are attributes that describe feature instances usually represented by data types or relationship roles that represent associations to other features. The abstract root of all properties is always feature property defined in 4.15. Subclassed under properties is the feature relation defined in 4.16 which is a collection of feature relation roles defined in 4.17.

Depending on the flexibility of the system being uses, a Feature Association can be implemented as a Feature where its roles viewed as "properties" which have a type of Feature Identity. For example, we often give names to these relations, as in "roads cross at an intersection" where intersection becomes a relationship between the roads that meet there. People often do this by naming these place by their properties, such as Five-Points (as in Manhattan and Huntsville, Alabama) or Three-Rivers (as in Pittsburg (Allegheny, Monongahela, and Ohio Rivers) and California, a braided river section on the Kaweah River north of Lake Kaweah, in the Sequoia forests, a Shangri-La for whitewater).

In a Feature Ontology as defined in this document, definitions for features, properties and relationships specify the possibilities for the data representations; i.e. the form of the digital objects each representing one possible view of a feature – see [4], [8], [9], [10], [12], [16] and [20]. An ontology must first contain a taxonomy but can go further to include constraints consistent with those real-world features that can enforce semantic consistency. A feature data set conformant to an ontology is one in which the feature, properties and relationship are semantically consistent with their definitions in the specified taxonomy and other ontological constraints. Since these constraints should reflect "real-world" truths, so in a sense, a valid taxonomy-structured data set which matches the real-world should pass any valid ontology constraints specified by the ontology. In other words, those constraints are tests for the quality of data collection in its representation of reality. If a collected data set is known to be validly consistent with reality, then a "violation" of an ontological constraint may be a flaw in the constraint, not necessarily in the data collection.

"Whereas current Web content has implemented the separation of content from presentation to a large extent, the Semantic Web aims to externalize the inherent semantics from syntax, structure and other considerations. This has led to a layered characterization of metadata that have been used to capture these various aspects of information", see [16], p 24. This separation of concern leads to two meta-requirements (see [16], p 26):

The solution for this separation of semantics and structure is found in the use of both schema and ontologies for the definition of data, see [16], Chapters 5, 6 and 7. Classical structured data formats such as relational or XML data require schemata, but the merging of that data requires the understanding of the underlying semantics. Fluid data structures such as JSON (JavaScript Object Notation) or WKT (well-known text) are based on key-value structures which are dependent on data definition and mostly independent of data structure. The merging of these flexible data formats is dependent on a common set of keys, and a common set of definition for those keys (a common set or mergeable sets of taxonomic metadata).

If the data set is controlled by a taxonomy, each feature instance can incorporate any classes, attributes or associations that are consistent with the semantics of the definitions involved. In this case, each feature instance is essentially its own class, an aggregation of the properties defined by its accumulated edits. “Dynamic” programming languages such as JavaScript (objects represented by JSON) and various forms of LISP, see [18], can support this approach. Even a strict object language can be used to build a dynamic class system using associations in lieu of compile-time linkages, see Figure B.1. Ontology languages begin with a taxonomy but can also add other semantic restrictions like those in an object model. Object models can be mapped to ontologies, but not all ontologies are as restrictive as a non-dynamic UML model. Even in this case, it would be possible to include a feature relation that interlinks object representing the same physical object.

A feature schema implementation contains definitions for each feature type including the properties that might or must be contained and the relationship in which it might or must participate. Since the items in a schema are the same as the items in an ontology, a feature schema should contain a feature ontology and taxonomy (or a reference to a default dictionary). This recommendation for an ontology to be associated to each schema is new but has been a best practice for decades. As mentioned, it is the integration of information management in the semantic web that is driving this movement to a more formal semantic approach to data handling.

In cases where the "dictionary definitions" for the names of the features, properties or relations is sufficient to meet the ontology’s requirements, then these definitions will be sufficient. In cases where multiple languages are used in the application community for the ontology, a well-structured multi-lingual cross walk will be necessary to alleviate issues of interoperability within and between multi-lingual environments.

This standard defines conformance for combinations of associated instances as follows:

A taxonomy lists all feature and property types. A single feature instance can have any number of feature type "tags" and any number of property-value pairs if the semantics of the combination are valid, which will be true if the feature instance reflects the existence and state of the real phenomena that the feature represents, see 4.7.

An ontology consistent with this standard will contain a taxonomy, see Req25, and include constraints, based on the semantics of the interrelationships of the features and properties. In the best circumstances, the features possible in an ontology will be the same as would be collected by the taxonomy alone which, implying that the listed constraints reflect reality.

A schema consistent with this standard will contain a taxonomy, see Req27, but many schemata consistent with previous standards will not. In most of those cases, it defines feature-type and property-type names consistent with geographic tradition and are consistent with common dictionary entries (e.g. Oxford or Webster’s). A schema is more likely to be associated to a specialized application which requires consistent object structures. Schemata tend to segregate feature types, possibly by theme, however the case where a real-world feature/phenomenon is represented by two separate feature types, depending on the system, the digital representation of this feature may be separated into multiple entity/object classes based on applications implying that the real-world feature is instantiated as a digital entity multiple times. If the system recognizes this case, it has several mechanisms to represent the reality:

Some cloud computer implementations use taxonomies, or their near equivalents to structure, index and search for data, see [21]. Big Data application literature similarly discusses the use of taxonomies to control the semantic of tags and the integration of structured, semi-structured and unstructured data, see [1] and [10].

In the literature, the "taxonomy to ontology to schema" spectrum discussed in this standard is usually referred to as "unstructured to semi-structured to structured" data. The elements of the feature taxonomy are feature class names, the elements of the property taxonomy are property or association role names. Ontologies may add constraints on data element instances and schemata may add constraints which will include a full object model. These constraints are often most useful in testing data for consistency. Each instance of feature shall have a feature identity to facilitate association specification (see Req18).

〈programming〉 automatic conversion of a value in one type to another based on the equivalence of values

〈modeling〉 feature with an extent consisting of a set of contained features

〈geometry〉 inability to be divided into two disjoint closed subset geometries

〈programming〉 object which contains or is associated by some form of aggregation to other objects

〈taxonomy〉 established list of standardized terminology (names, words or phrases) with associated definitions for use to identify, describe, index or retrieve information

〈programming〉 object instance which is, as necessary, assumed to support any operation, property or relation

〈geographic information〉 abstraction of real-world phenomena or entity

〈geographic information〉 relationship that links one feature with another feature

〈geographic information〉 catalogue containing definitions and descriptions of the feature types, feature attributes and feature associations occurring in one or more sets of geographic data, together with any feature operations that may be applied

〈geographic information〉 reusable model of a features with common aspects

〈geographic information〉 feature without any contained smaller features with a connected geometric extent defined by a single closed and connected geometry of single dimension

〈geographic information〉 concept that may be specified in detail as one or more feature types

〈geographic information〉 dictionary that contains definitions of and related descriptive information about concepts that may be specified in detail in a feature catalogue

〈programming〉 unique identifier associated to a real-world phenomenon,

〈geographic information〉 potential attribute, quality, or characteristic of a feature [modified from ISO 19101-1]

〈geographic information〉 relationship that links instances of features

〈geographic information〉 name or semantic purpose of an offset in a feature relationship

〈geographic information〉 collection of definitions and declarations for feature classes, properties and associations

〈geographic information〉 feature class or type, whose members are also members of a superclass

〈taxonomy〉 taxonomy such that categories are arranged in a tree structure built to represent the context of a category, using parent-child "is-a" relationships where the parent is broader conceptually than the child

〈programming, web〉 linguistically independent sequence of characters capable of uniquely and permanently identifying that with which it is associated [ISO 19135-1]

〈programming〉 ordered pair of two data items; first, the key (identifier) identifying the semantics of the associated value, and second, the value, either the identified data or a reference (pointer or identity) to that data

compact and human-readable designator that is used to denote and identify a data item

〈programming〉 identifiable component of a software system or design, now more commonly applied to a component that is in some sense self-contained, having an identifiable representation, and sets of operations and relations

〈programming〉 identifier associated to an instance of an digital object to distinguish it from all other objects

〈semantics〉 formal naming and definition of types, properties and relationships of entities that exist in a domain of discourse.

〈programming〉 taxonomic schema with additional ontological constraints

〈modeling〉 named descriptive value associated to or contained in an entity (object or feature type)

〈geography, hydrography〉 feature component represented as a curve between two intersections of features of the same type.

〈mathematics, database〉 set of ordered sets (call "n-tuples") of a fixed number "n" of entities that have a common interrelation status

〈ontology, taxonomy〉 set of entities consistent with a taxonomy definition consisting of a necessary and sufficient set of criteria for an entity being an element of the class.

〈ontology, taxonomy〉 hierarchy of semantic classes based on subseting

〈mathematics〉 ordered set of items in which the order has semantic importance

〈modeling〉 representation of a plan or theory in the form of an outline or model.

〈mathematics〉 unordered collection of related items with no repetition in which the order is of no importance nor significance

〈taxonomy〉 classifying entity in a taxonomy consisting of a name, a definition and relations to other such entities in the taxonomy NOTE: Note 1 to term: The terms are interchangeable, in the sense that a "taxon" in a taxonomy will become a "class" in an object schema, or a type in a "query language", as appropriate. The most common type of relationship is a hierarchical one listing classes as broader (superclass) or narrower (subclass). See hierarchical taxonomy.

〈taxonomy〉 system for classifying entities by logical definitions (criteria) and a hierarchy subtype relationship base on logical subsets of instances in a class

〈geographic information〉 abstract root classification for a feature hierarchy included feature which contribute to a single geographic subject

A feature is a representation of a real-world entity/object. This idea can trace its definition back to the 1960’s in the definition of Simula (a simulation language), the first object-oriented programming language. In Simula, "digital objects" represented "real-world objects"^[4]. Since the 1980’s, spatial or geographic information systems have paralleled this same idea, at about the same time as Simula and OOPL were first being used. Much of the early standardization of GIS followed the same object-oriented paradigm and defined feature classes as object classes (often in UML or it predecessors, such as OMT, object modeling technique).

The problem with digital objects representing real world objects is that, in most schematic modeling, all objects of the same class have essentially the same representation. The "real-world" is not as neat and clean. Any two real-world objects are distinct, often at a fundamental level and, for that reason, each may be a unique instance of their own "class", e.g. must be described in different manners with different properties, not just different values for the same property. While feature schemata are the core of many systems and their associated standards, there is another approach that supports schema but allows more flexibility as needed. This approach steps back from structural formalism and uses semantic taxonomy and ontology, to define feature types and prescribes descriptive properties of features as related parts of a taxonomy. In contrast with a schema, where a class is defined by its properties, a taxonomy-based system allows any feature to be associated with any property where the feature and property definitions are consistent with one another according to a given taxonomy.

A geographic feature taxonomy, ontology or schema will define a namespace that contains definitions of the keys that will be used to identify the semantics of key-value pairs associated to a feature:

A feature instance contains:

A geographic feature schema is an ontology that further defines which properties and relations that can be (optional) or that must be (mandatory) associated to instances of which feature types. All properties not specifically mentioned in this list cannot be part of the structure of a feature of that type. Table 1 below shows how a set of features could be represented and gives some potential examples of a taxonomy for feature type definition that are used in the example.

Classical schema formalism arises from application requirements. For example, a radar-based application would concentrate on the attributes of a feature that affect its radar reflectivity, but a visual-based application would concentrate on the visual attributes of a feature such as color. Radar is not good at detecting color (wrong part of the spectrum), but human eyes are. A radar system would not care what color the Golden Gate Bridge is painted, but a system for visual identification would know "international orange" is a good visual recognition clue; in fact, the "color is used in the aerospace industry to set things apart from their surroundings". See [11]. The use of "international orange" is of interest to a "visual-based" application, but not so much to a "radar reflectivity" application. The "interoperability" advantages of a single database for multiple application are obvious, especially when a single operation uses detection approaching the "DC to Daylight"^[6] spectrum range.

As different applications require integrated formats and information, it is easier to integrate taxonomies than schemata. In fact, integration of schemata often requires that a taxonomy be constructed to map the semantics of attributes and entity names used in the labels of the various schema. These taxonomies can then be compared to determine how the various application schemata can be integrated into a generic "application-independent" format.

Different applications will often have different schemata for the same types of objects, and different data collection rules driven by these differences. If diverse applications are required for a single operation or project, the interoperability advantages inherent in a single datastore, and a single set of "facts" is obvious and usually essential.

Once the decision to create this "common database" the use of a "taxonomy merge" is likely unavoidable. Some features will be only one source dataset, but the majority of the "real-world entities" will have multiple instance features to merge. The first step is the merging of the taxonomies of the disparate datasets, then followed by identifying which of those entities are associated to multiple feature instances, which requires the merging of different object instances from different applications. Easy to do in a taxonomy, difficult to do in schema. Over time, the holes may be filled, and the merged dataset will eventually be an application-independent store that supports all participants in the collections of the data; and the synergistic interoperability of the applications.

The driving purpose of OGC is and has always been making applications interoperable. A taxonomy paradigm for datastores seems to be a rational route to creating synergistic applications that have a single view of the world because they can depend on a merged, complete and flexible taxonomic datastore.

The values of attribute properties will have to be represented in a format consistent with the applications supported. In the textual examples in this standard those types may be in text, such as a JSON, YAML or WKT.

We can represent Wheeler Dam as in Table 1; the "URL #" expressions would be system generated entity ids, which can take the real-world name "Wheeler Dam" into consideration.

In a taxonomy-controlled feature data set, the features and their properties are defined. The association of feature instances to properties only require that the definitions be consistent with data instances. Feature instances would be associated to attributes and association roles defined in the taxonomy as needed. Some programming languages (e.g. JavaScript and LISP) can handle this directly, and non-dynamic object-oriented languages that can be expressed in UML can be programmed to do so also (see Annex B.1). Taxonomy instances for feature types would specify: a feature type name and definition, feature type inheritance, and mandatory properties.

In a schema-controlled feature data set, the properties are defined by the controlling schema. For example, the "logical default" for a dam does not have the properties of a bridge, but in the real world several dams have been designed or modified to include a bridge in its superstructure (such as "Hoover Dam" on the Colorado, and "Wheeler Dam" on the Tennessee). In a parallel case, some but not all dams have hydroelectric properties or flood control mechanism, again optional descriptions are needed to create a complete description dependent on the applications using the data. In a schema-controlled data set, the class for "dam" would have to be able to coexist with "bridge" when it is needed. Considering the complexity of reality and difficulty of an a priori schema that could adapt to all possibilities, the ontological approach is more likely to be usable without continuous redefinition. A schema would require potentially dynamic multiple inheritance or instantiation in a dynamic object-oriented language.

Each of the "dams" serves as part of a water control system (possibly the main purpose of a "dam"), a link in the road system across a waterway (the main purpose of a "bridge") and a source of hydroelectrical power (the main purpose of a "power plant"). This feature-type combination in a single feature is not universal. Some bridges are not associated to neither flood control nor hydroelectric generation. In New York state, the Robert Moses Niagara Hydroelectric Power Station diverts water from above the Niagara Falls and routes it below the falls while generating power. This hydroelectric power plant is not associated to a dam and occupies shoreline only on the New York side of the Niagara River. It also has a Canadian near-twin in the Sir Adam Beck Hydroelectric Power Stations in Ontario, Canada. To minimize erosion at the fall’s face, both Niagara facilities are used to affect the amount of water going over the falls at Niagara. The Wheeler Dam on the Tennessee is also used for mosquito control; Wheeler Lake’s water level is periodically adjusted up or down to disrupt the mosquito life-cycle either drying out or washing out mosquito larvae. This extra-model information is important to only some applications, but to those applications they are often essential. In the case of the TVA dams mentioned here, mosquito control is as important as the hydroelectric processes. The Tennessee Valley in the last half of the 19th century was affected by yellow fever sometimes yearly, spread by mosquitos.

The "use of taxonomy" versus the "use of schema" is a shift of emphasis from syntax (the form or structure of the information) to semantics (the meaning of the information). This transition should not be a surprise since from the beginning the great barrier to the flow of information has been format i.e. schema, and so the biggest boon to interoperability is to step over that barrier and shift our application in the same direction that the web is moving, towards semantic solutions. This makes the data easier to understand and thus easier to move, and finally easier to interoperate between functionality.

https://opengeospatial.org/as/FG/P1/FM/1.0/taxonomy/

https://opengeospatial.org/as/FG/P1/FM/1.0/ontology/

An ontology includes a taxonomy for feature and property. It may add restrictions, for example, limiting which properties are associated to which features. Some describe taxonomy-controlled data as "unstructured" and describe schema-controlled data as "structured". Having labeled the extremes, they declare the choice as binary, missing the very broad middle ground, often called "semi-structured".

https://opengeospatial.org/as/FG/P1/FM/1.0/schema/

A feature schema is a feature ontology that has a more complete set of constraints consistent with a classical object model.

https://opengeospatial.org/as/FG/P1/FM/1.0/taxonomy/

An implementation of the Conformance class Taxonomy shall contain valid definitions for feature and property types, meeting the requirements in Clause 6.2. Each clause below shall associate the numbered requirements to a generic method of verification. Each test is associated to a single requirement defined in the requirements class.

https://opengeospatial.org/as/FG/P1/FM/1.0/ontology/

An implementation the Conformance class Ontology shall contain ontology valid definitions and constraints meeting the requirements in Clause 6.3.

https://opengeospatial.org/as/FG/P1/FM/1.0/schema/

An implementation the Conformance class Schema shall contain schematic valid definitions and constraints meeting the requirements in Clause 6.4

The discussion above implies that the most natural object language to use to implement taxonomic controlled feature data would have to have a dynamic schema/object model. Since most compiled languages (C++, C#) do not work quite that way, this design model assumes a non-dynamic schema by using inheritance and associations.

The classical object implementation of schema-controlled data uses a separate class for each feature type, with embedded attributes for simple properties and associations and roles. The alternative model in Figure 2 breaks the feature classes into separate components allowing a statically structured language to be dynamic.

In a strong feature schema, where all feature classes with their properties and associations are fully defined, as in the original "Simple Features for SQL" model, can used a single table for each feature class. Extending SQL for geographic information only requires the definition of a SQL-datatype for geometries, see ISO/IEC 13249-3.

If we loosen schema constraints, properties will have to be split off into separate tables to be shared by different feature types through foreign key links to these property tables.

To define the idea, the table design below assumes the other extreme where each property and association role can be associated to any feature type, i.e. where only the feature and property taxonomies are used, and no additional constraints are given. Just to be consistent, the taxonomy in the example is presented as a set of relation tables.