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.
|ID – The Feature GUID|
|Name – What it is called|
|Definition – A definition of the Feature|
|DefaultGeometry – one of the geometries included in the pimGeometry table|
|Owner – The Parent GUID|
|PermissibleGeometries – a list of the possible geometries that the feature can take|
|User – the userID of the configuration|
|FeatureNumber – a numeric representation that equates to the feature|
|Container – a string value that equates what might be a Feature Dataset in the Esri model|
|SubclassOf – User for PIM capability in the definition of the Logical Model|
|Configuration – the pimConfiguration to which this feature applies|
|Version – the pimVersion of the configurationNote also that any PIM API pimFeature includes its reference to a pimConfiguration and a pimVersion. But the most important thing to remember about the pimFeature is that it is rigorously identified by its definition, and not it’s name.|
A pimFeature is the geospatial object within the PIM. It is independent of the pimConfiguration; e.g. a given pimFeature may be included in many configurations. Note that the pimFeature has a Name, but its name can be modified (but the definition MAY NOT be changed) when it is assigned to a pimConfiguration. Also note that the pimFeature can be completely independent of the geometry; e.g. the definition of the feature can apply regardless of the geometry based on the ‘PermissibleGeometries’ property. The complete capability of this field within the pimFeature is beyond this blog entry, but the PIM permits and supports geometry manipulations.
This does not preclude any organization from having two independent features; e.g. BuildingPoint and BuildingArea. These are easily supported by defining each of these as two separate pimFeature elements; e.g. where the PermissibleGeometries and DefaultGeometry properties are the same.
The table at the right shows the PIM API properties of the pimFeature. It includes all of the properties that are required to generate and validate geospatial datasets against the PIM. It also includes the properties to accommodate any of the current GIS architectures in use.
Now we have a pimConfiguration that needs to be associated with one or more pimFeatures. This happens by structures within the PIM API but it is accomplished in the PIM database through a table named pimConfigFeature. In reality, the pimConfigFeature table is an intermediate table between the pimConfiguration and pimFeatureType tables in the PIM that provides the many-to-many relationships between a pimConfiguration and a pimFeatureType. But the pimConfigFeature table provides additional capability. It permits for Feature Name changes as well as Feature default geometry changes. The pimConfigFeature table has two additional attributes (altFeatureName and altDefaultGeometry) that allow any configuration to have a feature name or default geometry different from the name from Gold (stored in the pimFeatureType table). This is ONLY applicable to those features which were inherited from the parent (which might be Gold). The GUID/UUID and definition in the parent remain the same but the name may change. This same capability applies to the default geometry (provided the alternative is in the set of permissible geometries). This facilitates migrations from configuration 1 using feature A to configuration 2 using feature A with a different name. More on this in future posts.
These alternative properties are automatically included in the PIM API. If the altFeatureName field in the pimConfigFeature is Null, the name in the pimFeatureType table is used in the API. If it is not, the desired alternative name is used. A similar situation exists for the altDefaultGeometry field. Additionally, the PIM API properties FeatureNumber and Container are stored in the pimConfigFeature table, increasing configuration flexibility. Within the PIM, these capabilities are incorporated into separate ‘views’, improving performance and easing the burden on application developers.
The next post will introduce how attributes are mapped or assigned to features. A similar structure of the many to many features to attributes exists, providing PIM economies, maintaining performance, and providing significant flexibility.
This post was written by:
For more information on this post, the PIM, Zekiah’s geospatial standards support, or our data configuration management capabilities, please e-mail us at firstname.lastname@example.org