Syndicate content
Thursday, January 2, 2014

A while back, my colleague Barry Schimpf touched upon some of the tools that we use in conjunction with the Platform Independent Model (PIM). Today, I will delve into one of the tools we use to generate physical schemas from the PIM. Before, I jump in, let’s review what a PIM is and what it does.

The PIM is an approach we have developed to enable proper configuration management of geospatial data models. We have used it successfully for federal customers to track multiple versions of complex data models, validate physical implementations of those models, and support profiling and adaptation of the models across user communities. The focus of a PIM is on the data model as opposed to the actual geospatial data so a PIM itself doesn’t store any geospatial feature data. It is merely a representation of the logical model; defining the feature types, attributes, relationships, and constraints necessary to build a geospatial data set that is in compliance with a particular data standard.

Thursday, May 24, 2012

So nearly everything we have discussed so far is not really useful unless we can figure a way to get it to help with what we need to do with geospatial data.  It's sort of like having the world's greatest bowling ball with no lanes.  How do we make this help us with increasing productivity, promoting sharing, reducing user frustration, and making us 'cost competitive?' The simple, practical answer is flexible, user modifiable applications.

What are these applications?

Making practical use of a data standard involves a number of required functions.  These are:

  1. Performing an initial load of the PIM from the user defined Standard and providing a mechanism for modification/update
  2. Generating Schemas or compatible physical implementations in a variety of GIS formats
  3. Validating (checking) user data in these same GIS formats against the Standard
  4. Assisting with both User to User translations and Version to Version migrations
  5. Enforcing a discipline that allows for performance of #2 though #4 above. 
Monday, May 7, 2012

Much of the conceptual background and structure managing a geospatial data model using a platform-independent model (PIM) has been outlined in previous posts.  And while it is useful to understand how the PIM is structured in the tables and views inside the PIM database, the critical knowledge relates to the way the PIM API retrieves and organizes this information, and details the properties and methods of the various PIM API objects.  So if you are not particularly interested in the conceptual, now would be a good time to pay attention.

This post begins the process of moving from the abstract to the concrete. In the next series of posts, we will begin to build a simple data model in order to not only demostrate the concepts that have been previously discussed but also to showcase many of the existing tools for helping with various management tasks such as version migrations, script generation and data validation. In this post, we'll begin discussing the API provides the business rules for interacting with the PIM, enables configuration management activities, and acts as the interface bewteen the PIM and the applications that use it.

Friday, April 27, 2012

The PIM now contains sets of features (the pimFeature) grouped into sets (the pimConfiguration) with properties and referencing sets of attributes (the pimAttribute).  For may GIS solutions, this is all that is required for collecting, validating, and displaying geospatial data. 

But the PIM also contains the ability to constrain attribute values in a variety of ways, in much the same way that many of the RDBMS data stores contain a similar ability.  Probably the simplest of these ways is the 'Nulls Allowed' property.  In nearly all cases, attributes will be coded as 'Nulls Allowed', but specific user preferences might dictate otherwise, provided the user fully understands the implications of this coding. 

Monday, April 16, 2012

A quick review of the pimConfiguration to the pimFeature shows...

Friday, April 6, 2012

In a previous post, we discussed the meaning of the pimConfiguration as a collection of elements in the Platform Independent Model (PIM).  One of those elements (in fact, the most important geospatial one) is the pimFeature.  The pimFeature is that table/object that defines the geometric object that gets displayed on the map, sometimes called the 'shape'.  It is defined based on the contents of the pimGeometry table within the PIM.  These are currently defined as Point, Line/Polyline, or Polygon but could be easily expanded to 3D geometries and multipart geometries.

Wednesday, March 28, 2012

This post will begin to introduce PIM and PIM API organization.  The PIM API is coupled with the tables and views in the PIM based on the rule set discussed in the previous post.

The fundamental object (and table) in the PIM API and the PIM is the pimVersion.  Each element in the PIM and PIM API is tied to a version.  In the current structure, pimVersions are identified (pimVersion.ID) by a real number.  The use of a real number in this context as opposed to some string value; e.g. '2.1.4', is arbitrary and can be easily accommodated in small PIM revisions. 

Saturday, March 24, 2012

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.

Monday, March 19, 2012

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.

Friday, January 13, 2012

Background:  While many organizations see the clear advantages of establishing and using geospatial data standards, obtaining compliance from constituents continues to be a frustrating, and costly, problem.  Users are frequently reluctant to adopt a new standard given the potential cost of modifying applications that use an existing, custom schema or simply having a 'not invented here' mentality.  This was true within the Department of Defense (DoD) Installation Geospatial Information and Services (IGI&S) community, even though a standard had existed from more than 10 years.  As a part of 2006 Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE) initiative, Zekiah developed a data standardization concept intended to provide flexibility in schema naming conventions and organization without compromising ease of data sharing, conversion, and information understanding.