Understanding Geospatial Data Rules in the Platform Independent Model (PIM)
This post continues a series describing our approach to using a platform-independent approach to managing data models and standards. In any situation where a geospatial data model is agreed upon and adopted by multiple participants, management of the model itself becomes a significant issue. Over time, modifications to the model are required. Such modification can have significant impacts on the implementations of each participant. As a result, configuration management is needed to ensure smooth transition and traceability between data model versions.
Through our work with the Spatial Data Standard for Facilities, Infrastructure, and Environment (SDSFIE), Zekiah has developed an understanding of these issues. The issues are not unique to Federal data standards, but are also applicable to state, local and regional geospatial data standardization efforts. We have not only developed an approach for addressing these issues, but also model-independent tools to support versioning, compliance-checking, transition, profiling and other issues. This series details our approach and this post continues the discussion begun in the following posts:
Expanding Usefulness of Geospatial Data Standards
Applying Flexible, Yet Standard, Geospatial Conventions
In consideration of the development of the PIM schema (and consequently the PIM API Object Model), a series of GIS capability and logical rules were developed to define how the contents of the PIM tables are converted into the PIM API Object Model which is completely ‘Platform Independent’. The complete set of rules is clearly too complex for this document, but a complete set of rules is available. In general, the rules are divided into categories based on the ‘object’ to which they apply.
There is a common rule for all objects. This rules states “Any geospatial element is defined by its definition and not its name.” What this means is that to accept an element is to accept the application of the definition to the element. Therefore, each geospatial element definition is identified in the PIM by a GUID/UUID (a globally unique identifier). As an example, what this means is that a Feature (PIM pimFeature) is NOT identified as a “Road Centerline” but rather a precise, agreed to definition of what this means. This rule is fundamentally intended to remove the naming issue from the development and implementation of the standard.
While this sounds trivial, it is not. This is because each Feature Type (pimFeature) has a ‘default’ geometry and a set of ‘permissible’ geometries. The PIM offers the flexibility to accommodate a variety of geometry definitions. The current set is Point, Line, and Polygon, and “NONE”. The first three reflect the 2D set of geometries and the last indicates a ‘non-spatial’ table, which is included in the PIM. However, other geometry options including all 3D can be handled properly by the PIM and the PIM.API. Therefore, features should generally be defined as being geometry independent but a complete set of geometries is amongst the first action by any organization wishing to use the capability of the PIM. So a Building might be either a point or a polygon, line, or surface, etc.
Road Centerline is one of a number of special cases, where the Feature Type itself constrains the geometry. Other examples might be ‘Control Point’, ‘Landmark’ etc. But many Feature Types are independent of the geometry.
It should be noted that if an organization does not wish to make Feature Types geometry independent, the PIM will still function just as well.
Each individual element has special rules.
The Feature Object (pimFeature) has a number of rules:
A – Each pimFeature MUST have one Default Geometry (defaultGeometry). The Default Geometry must be one of the defined geometries in pimGeometry and be included in the Permissible Geometries (permissibleGeometry).
B – Each pimFeature MUST have at least one additional defined Attribute Object (pimAttribute).
C – Each pimFeature MUST have a single Version Name, but it MAY have a different single Configuration Name (in pimConfigFeature).
D – Each pimFeature MAY appear in more than a single Configuration (pimConfiguration), but MAY ONLY appear once in any single Configuration.
This represents only a small sample of all of the rules. It is the complete set of rules that define how the attributes within the PIM (not the attributes within a Feature Type) are structured and how the PIM.API is organized.
The complexity of the rules prevents their inclusion in this post. As a single example, there is a rule which states:
Any given attribute is represented as a single Data Type. However, string character lengths, default values, and individual constraints (Domains) may vary from Feature Type to Feature Type for the same Attribute.
Rather than focus on what this means, suffice it to say that it affords maximum flexibility across a number of Federal, State, Local, and Business standards. And it does not compromise the ability to generate the GIS storage structures listed in prior posts.
The next post will outline the PIM schema and its interactions. Stay tuned…
This post was written by:
For more information on this post, SDSFIE, Zekiah’s geospatial standards support, or our data configuration management capabilities, please e-mail us at firstname.lastname@example.org