Applying Flexible, Yet Standard, Geospatial Conventions

Previous posts have touched the problems that traditionally face those wanting some geospatial consistency in data collection, data presentation, and data understanding. These issues drive much of the continual interest and push for increased Metadata and many of the “Use Liability” clauses that are attached to current datasets. After all, if you don’t really know what the feature is, or what many of the attributes really mean, geospatial data is of considerably reduced value.

Another problem with geospatial standards is they are never stable. In case you haven’t gotten the message, “requirements continue to change”. I think this came from Nostradamus. Regardless, if you want to have a reliable standard and standard management system, you need a way to accommodate this continued change. We need to avoid the age-old complaint of “I just spent a bundle on being compliant and the standard moved out from under me!!”

Hence, the Platform Independent Model (PIM)…

Over the last several years, we have developed a solution that we believe handles many of these conditions and helps to simplify diverse geospatial datasets into a single overarching ‘data model’. We have applied our approach in the real world to provide configuration management over widely used data models such as the Spatial Data Standard for Facilities, Infrastructure, and Environment (SDSFIE) as well as other data models used in the Federal government. The next couple of posts will hopefully explain how the PIM works, and what it does. However, rather than explain the details of ‘how’ of the PIM, we will concentrate on the ‘what’ of the PIM capabilities.

The PIM and its API work support applications based on logical models or physical implementations

The PIM (and its associated PIM API) are related to objects and how the objects correlate to the relational database into which the PIM is persisted. It is important to understand that the PIM manages the platform-independent structure of a data model, storing the rules by which physical data structures can be generated. So, using the Esri approach for discussion, the PIM is not a geodatabase in itself, but is rather the rule set from which a geodatabase can be generated in compliance with our data model. It is “platform-independent” because we are not constrained to generating representations only as Esri geodatabases, but also PostGIS, SpatiaLite, GML, Bentley, Oracle Spatial and others. The PIM API can actually be extended to support new platforms as they emerge.

The best approach to making this understandable is to explain this in terms of how it relates to a real geospatial model; e.g. the Feature, Attribute, and Value model. In that model, each of these objects (Feature, Attribute, and Value) has properties that help to amplify the capabilities of the model. These properties are sometimes based on the requirements of various GIS formats and applications. Without prejudice, we will attempt to explain how these capabilities are handled within the PIM and PIM API arrangement. Some of these descriptions will relate to users and some will relate to developers. In either case, we will attempt to make a complex situation clear.

Within the PIM, each element is identified by a Version, User, and Element Identifier (say the featureID or the attributeID). Therefore, it is possible to trace any element across versions (supporting automated version to version upgrades) or users (supporting data sharing between users through automated transformations), while retaining different names for included elements. In short, the PIM gives users the ability to tailor or profile a core data model to suit their needs, while also maintaining the traceability and configuration management necessary to support version upgrades and interchange between user-defined profiles.

In the next several posts, we will begin to explore rules which govern geospatial generations and the tables within the PIM and how those tables lead to the objects in the PIM API model. We will define the use of the various tables and how they relate. And we will define all of the terms included in the PIM process and how those terms allow users to create, and maintain, a flexible standard that supports effective generation, validation, and migration of data in user datasets.

Stay tuned…

This post was written by:

Barry Schimpf

Vice President

For more information on this post, SDSFIE, Zekiah’s geospatial standards support, or our data configuration management capabilities, please e-mail us at contact@zekiah.com