Main

Mapping from Earth, Sky, and Space

News

David Hart, CP, SP, RPP - President, Continental Mapping Consultants

The development of specifications – specs – has always been a difficult challenge in surveying and mapping. In just the last few years, as new remote sensing technologies (like lidar), and methods (like crowd sourcing and data fusion) are integrated, we’ve been involved in a wide range of “spec update” projects. Three of our key client sectors: State Departments of Transportation (DOTs), the US Army Corps of Engineers (USACE), and the National Geospatial Intelligence Agency (NGA) are all currently undergoing massive shifts in their understanding of how to develop and administer specifications and guidance for the creation of mapping products. The difficulties we have witnessed – and participated in – have been profound. We are learning some important lessons from these experiences, and have changed the way we engage with our clients in order to help facilitate a better understanding of the need, the requirement, and the deliverables of a project. 

We’ve developed unique perspective on what we have come to recognize as the problem of abstraction in specification development. The scales at which we deliver data vary widely from boundary surveying of sites smaller than an acre, 1cm accuracy mobile lidar for automated machine guidance, to global scale mapping deliverables with mapping areas covering tens-of-thousands of square kilometers. In all of these, we have found several key concepts that hold true no matter what the project is and regardless of size, scale, or deliverable.

First, it must be relearned that a map is an abstraction. That is, a generalization and simplification of reality. Abstraction is not easy. It is a high level mental function that requires thought, judgment and interpretation. In almost every “spec development” effort I’ve been involved with, the process has been: take an existing spec, introduce new technologies, work processes and needs, and add them on top of an existing specification.  It ends up being like putting a third layer of shingles on your house - it collapses of its own weight.

Examples of these difficulties are everywhere:  DOTs are busy trying to integrate lidar – particularly mobile lidar – into their survey and mapping specs – with mixed results.  USACE is diligently (and I think successfully) working on a Civil Information Management (CIM) spec that integrates seamlessly with BIM, and NGA has recently launched its massive Map of the World (MoW) concept, broken into 3 topical areas: data, technology, and processes.

From our experience, the process that eventually emerges that leads to successful spec development includes several key elements, outlined below:

Defining the Need

In all cases, there are three key questions we’ve termed the three C’s.  This entails defining the currency (date of acquisition), clarity (resolution and/or accuracy) and content (features on the map) that are needed to solve a problem. Do I need a map, a measurement, or a model?  Answering these questions helps establish the framework for geospatial data collection.

3 cS v2

Determining What is Critical and What is Referential

This is a key concept in validating the first step of the process, and often resets the discussion back to step one. Due to the fact that a map is a generalization and a simplification, everything can’t be deemed critical.

Constraining to Budget

This seems obvious, but constraining to the budget is often ignored until later stages. It is at this point that we must validate the resources necessary to meet the “wish list” developed in the first two steps. Once this is introduced, definitions of what is truly “critical” and expectations for referential features are often adjusted and relaxed.

Database Design

This is a formal and involved process. In almost every instance, people are inclined to build on what is there (bottom up) and things quickly come unraveled. A “top down” database development methodology – something well documented in database design literature - should be used. The formal process works like this:

  • Conceptual Design– A high level description.  What do I need on my map to solve my problem?
  • Logical Design – Specific descriptions of what defines an entity. A transportation example: is the entity the guardrail or the components of the guardrail? Do you want to define specific assemblies of those entities, or is that too much information? Establish relationships and constraints (linkages) between entities.
  • Physical Design – Detailed description of entities.  At this point you must define level of detail (LOD) concepts, such as limiting the number of vertices and faces to represent an entity at a certain scale. This work is very involved and is also the point at which software capability and representation come into play.

Developing Measures of Acceptance

This is the last and undoubtedly most important part of the process. This is where standards and acceptance parameters need to be tightly coupled with specifications and guidance. It is taking “fit for use” concepts and developing reliable, repeatable, and unbiased evaluation processes to determine acceptability of a map. The stickiest issues here - the one that causes 99% of all project delivery problems across the board - deal with just four of the sixteen map data quality elements (as defined by ISO 19114 Geospatial Data Quality Elements):

  1. Completeness regarding errors of omission,
  2. Completeness regarding errors of commission,
  3. Thematic classification correctness, and
  4. Non-quantitative attribute correctness.

Each of these elements are problems of abstraction, and therefore interpretive and subjective. Due to this fluidity, their evaluation cannot be automated, which most often leads to a biased review. We have done original research that proves this (for another article!).

Most organizations that try to update their specs have stumbled out of the gate. Fortunately though, each eventually comes to realize the need to develop a formal process that helps establish scalable and constrained specs that ultimately help them deliver their program. Our experience in this process is expanding rapidly.

Please give us a call if you’d like more detailed accounts of our experience in the spec development trenches!

Click here for downloadable White paper.

Sitemap