Syndicate content
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.