With the increasing focus on information security across all sectors of government, IT policies are placing increased restrictions on information architectures, including GIS. While these restrictions may not prevent the development of a robust enterprise geospatial architecture, the approval and accreditation processes can introduce significant delays, during which work must continue. This is where workarounds come into play.
Light detection and ranging, or LIDAR, is a type of remote sensing technology that is similar to radar. It is used in a variety of geographic and environmental applications to model and analyze the physical world.
Often mounted to an airplane or motor vehicle, the sensing unit uses radio waves and the measured time delay between pulse transmission and reflected pulse receipt to determine the distance from an object. There are two styles in which this data can be received by the unit. Some units use what is called “discrete-return,” which only records data at predetermined precise locations (space or time). Some refer to this style as “point” because it returns information specific to locations. The other type of data receipt is called “waveform,” which records data nearly continuously from the unit.
I have been a part of three different data collection efforts that collected line geometry and infrastructure of recreational trails. One effort was the development of the Fish and Wildlife Services (FWS) Trails Inventory Program. This effort involved collecting trails data in FWS national wildlife refuges across the United States. The second was an effort to collect trails data on all of the recreational trails at Haleakala National Park in Hawaii. This effort was based upon the FWS trails data collection with a few minor changes to how the data was collected. In the third effort I was responsible for taking the data to its final state and for training field staff employed by the Student Conservation Association.
Based on these experiences, I have come to understand that the keys to a successful data collection effort lie in:
- Flexibility, and
- Very clear goals of what is to be accomplished.
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:
- Performing an initial load of the PIM from the user defined Standard and providing a mechanism for modification/update
- Generating Schemas or compatible physical implementations in a variety of GIS formats
- Validating (checking) user data in these same GIS formats against the Standard
- Assisting with both User to User translations and Version to Version migrations
- Enforcing a discipline that allows for performance of #2 though #4 above.
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.Read More »
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.
A quick review of the pimConfiguration to the pimFeature shows…
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.
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.
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.