This is the third post in our series about Registries, following on from:
- Registries – Beyond Databases: Part 1 – A Better Place to Start 
- Registries – Beyond Databases: Part 2 – Built-In Data Governance 
- Registries – Beyond Databases: Part 3 – Full Geographic Support 
Geographic Data Support
In the first post in this series we suggested that, for a wide range of data centric applications, a registry was a better starting point than a database, as it could greatly accelerate development and reduce time to market. We then looked at the built-in support that registries can offer for data governance. In this blog post, we will look in greater detail at the support that registries provide for geography.
Why buy a GIS?
Many classes of problems require geographic support — including things like land use permits, mineral leases, and tenures — but they don’t really require a GIS. Without an alternative, systems developers often turn to integrating a GIS with other components. This incurs significant maintenance problems in the future, as releases of the GIS and other components get out of synch with one another.
Registries can avoid such problems because they provide geographic support as an intrinsic part of their NoSQL data model.
Registry Objects can have Geographic Properties
A Registry Object is the fundamental building block of any registry information model. Extrinsic Objects, External Link objects, classification schemes (taxonomies), associations, and Packages (logical collections) are all different kinds of Registry Objects. All Registry Objects can have one or more properties, including geographic ones. Unlike many GIS, that restrict thinking to “line features” or “area features”, any Registry Object can have multiple geographic properties at the same time. A “project”, for example, might have a location (a point), a project area (a polygon), and an impact area (another polygon) all at the same time. This simplifies the information model by removing the need to manage multiple features or relational tables in order to represent multiple geographic properties of the same real-world entity.
Geographic properties of Registry Objects are defined in the OGC GML Simple Features specification. The benefit of using the specification is that it opens the door to adding more complex GML geometries as needed in the future. Currently, this means that points, linestrings, and polygons, together with variations such multi-points, multi-linestrings, and multi-polygons, are all supported.
Since any Registry Object can have geometric properties, this means that taxonomies can also have geometric properties. For example, in the classification scheme defined by the Congressional Districts of the United States, the classification nodes Congressional Districts can each have a spatial extent defined by a polygon. This allows for all sorts of interesting data analysis and display capabilities.
Extrinsic Objects often have associated attachments (Repository Items) that are usually described by the Extrinsic Object’s properties. The Extrinsic Object, for example, might have a property “spatialExtent” which is a polygon, and an associated Repository Item which could be a CityGML or other CAD 3D building model, or an audio clip recording details of an inspection, or some other relevant piece of information. Using this approach, the spatial extent of the Extrinsic Objects can provide an arbitrary spatial index for all kinds of related information such as documents, audio clips, photographs, building plans, etc.
Powerful Geospatial Query Language
A Registry provides a powerful query language defined by the OGC CSW-ebRIM. This contains components for all of the CSW-ebRIM data model objects, including:
- Geographic (and other properties)
- Free text
Queries are logical combinations of these components, and they can be transmitted as XML expressions across the Internet.
The Geographic component supports searches using specific geometric query computation such as “Within” or “Intersects” based on a user supplied polygon or linestring. Queries can be created to filter against all geographic properties of an object. This also means that new geographic properties can be easily added to objects without changing any of the application queries.
Real world objects move and change their shape over time, and these changes can be recorded and tracked in the registry simply by sending an appropriate transaction message to update the effected object. Geographic changes can be slow and essentially static, like land or mineral claims, or rapid and constantly changing, like tracking the position of a moving vehicle or vessel, and a registry can easily handle either case.
Registries offer a rich set of geographic properties, query, and transactional capabilities. Clearly a better place to start.