Managing Geospatial Data Models With a PIM API
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 demonstrate 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 between the PIM and the applications that use it.
As you might recall, the basic object inside the PIM is the pimVersion. There can be many pimVersions in any PIM and they may, or may not, be directly related to each other (we’ll talk about version to version migrations later on).
A simple model will begin with a single version with a single version number (pimVersion.ID). For now, 1.0 is a pretty good number.
The pimVersion table in the PIM would look something like…
| versionID (real, not null) | versionReference (text) | versionComment (text) |
| 1.0 | 1-0-0 | The initial version of my model |
Then we build a pimFeatureType, say Cemetery, which looks like…
| versionID (real) | featureID (GUID, not null) | userID (bigint) |
| 1.0 | 468ea9bb-917e-448a-9d0a-140c133b067f (New) | 0 (Gold User) |
| featureName (text) | featureCode (text) | Definition (text) |
| Cemetery | CEM | A place where folks are buried. |
| defaultGeometry (text) | permissibleGeometry (text) | featureAlias (text) |
| A | A/P | BurialGround |
The content of featureName, featureCode, definition, featureAlias, defaultGeometry, and permissibleGeometry are all defined by you.
Then we build a master ‘Gold’ configuration for version 1.0 that becomes the parent for all other profiles and extensions of other version 1.0 configurations. By definition, this Gold configuration has a configurationID of the empty GUID; 00000000-0000-0000-0000-000000000000.
That pimConfiguration looks like…
| versionID (real) | configurationID (GUID,not null) | configurationName (text) |
| 1.0 | 00000000-0000-0000-0000-000000000000 | MyMasterModel |
| configDescription (text) | configType (text) | refConfigID (GUID) |
| The complete model for Version 1 | Standard/Model | NULL |
| UserID (bigint) | configAlias (text) | configStatus (int) |
| 0 (Gold User) | Gold | Under construction |
The configurationName, configDescription, configAlias are user defined. The configType and configStatus, are set by convention and determine how the individual tools read and treat each of the configurations. The refConfigID is the configurationID of any parent. Since this Gold configuration is the Parent of all others in Version 1.0, its refConfigID is Null.
And now we associate that pimFeatureType record with the pimConfiguration record. This is done in the pimConfigFeature table and would look something like…
| versionID (real) | configurationID (GUID) | featureID (GUID) |
| 1.0 | 00000000-0000-0000-0000-000000000000
(Pim Config) | 468ea9bb-917e-448a-9d0a-140c133b067f
(PimFeature) |
| userID (bigint) | refConfigID (GUID) | configContainer (text) |
| 0 (Gold User) | NULL | An Esri FeatureDataset |
| featureNumber (int) | altFeatureName (text) | altDefaultGeometry (text) |
| An Esri Subtype Number | Null if Gold otherwise an alternative Name | Null if Gold otherwise an alternative Geometry |
While this looks very complicated, it would result in the following content in the PIM API…
Object pimDbInt = pimDb (after Connection)
Object pimVersion = pimDb.Versions(Root)
Properties pimVersion.ID = 1.0
pimVersion.Name = 1-0-0
pimVersion.Comment = The initial version of my model
pimVersion.Owner = 0
Collections pimVersion.Configs = <PimObjectSet><Of PimConfig> = 1 PimConfig that is...
Properties pimConfig.ID = 00000000-0000-0000-0000-000000000000
pimConfig.VersionID = 1.0
pimConfig.Name = MyMasterModel
pimConfig.Owner = 0
pimConfig.Definition = The complete model for Version 1
pimConfig.ConfigType = Standard/Model
pimConfig.Status = Under Construction
pimConfig.IsApproved = False (Status Code < 3)
Collections pimConfig.Children = <PimObjectSet><Of PimConfig> = 0
pimConfig.Features = <PimObjectSet><Of PimConfig> = 1 PimFeature that is...
Properties pimFeature.ID = 468ea9bb-917e-448a-9d0a-140c133b067f
pimFeature.VersionID = 1.0
pimFeature.Name = Cemetery
pimFeature.Owner = 0
pimFeature.Code = CEM
pimFeature.Definition = A place where folks are buried.
pimFeature.DefaultGeometry = A
pimFeature.PermissibleGeometry = A/P
pimFeature.Container = Null
pimFeature.SubClassOf = Null
Collections pimFeature.SubTypes = <PimObjectSet><Of PimConfig> = 0
pimFeature.RelatedFeatures = <PimObjectSet><Of PimRelatedFeature> = 0
pimFeature.Attributes = <PimObjectSet><Of PimAttributes> = as defined
In the next several posts, we will begin to talk about the tools which are already available to manage the PIM, generate a variety of geospatial storage databases, and perform validation of created datasets.
This post was written by:
Barry Schimpf
Vice President
See all the posts in this series
For more information on this post, the PIM, Zekiah’s geospatial standards support, or our data configuration management capabilities, please e-mail us at contact@zekiah.com