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.01-0-0The initial version of my model

Then we build a pimFeatureType, say Cemetery, which looks like…

versionID (real) featureID (GUID, not null)userID (bigint)
1.0468ea9bb-917e-448a-9d0a-140c133b067f (New)0 (Gold User)
featureName (text)featureCode (text)Definition (text)
CemeteryCEMA place where folks are buried.
defaultGeometry (text)permissibleGeometry (text)featureAlias (text)
AA/PBurialGround

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.000000000-0000-0000-0000-000000000000MyMasterModel
configDescription (text)configType (text)refConfigID (GUID)
The complete model for Version 1Standard/ModelNULL
UserID (bigint)configAlias (text)configStatus (int)
0 (Gold User)GoldUnder 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.000000000-0000-0000-0000-000000000000

 

(Pim Config)

468ea9bb-917e-448a-9d0a-140c133b067f

 

(PimFeature)

userID (bigint)refConfigID (GUID)configContainer (text)
0 (Gold User)NULLAn Esri FeatureDataset
featureNumber (int)altFeatureName (text)altDefaultGeometry (text)
An Esri Subtype NumberNull if Gold otherwise an alternative NameNull 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