Tag: GPS corrections

By Mike Botts, Botts Innovative Research, Inc.

In the mass market, individuals around the world are creating vast quantities of location data and GPS traces using not only GPS, but also Russia’s GLONASS, Europe’s Galileo, China’s Compass, and India’s Regional Navigational Satellite System. The value of this data and the value chains that produce it will increase significantly with an increase in interoperability of these satnav systems. Currently, non-interoperability represents a serious obstacle to the growth of the GPS market.

The overall system-of-system’s diversity of data formats, data models, processing models and associated custom- built one-to-one communication interfaces significantly inhibits introduction of new subsystems and also new GPS-dependent systems that would support development of future classes of stakeholders. “Many-to-many” networks based on open standards can create interoperability as well as opportunities for the introduction of new technologies, value-added data products, and new users.

To address this problem, sponsors of the 2012 Open Geospatial Consortium (OGC) OWS-9 Interoperability Testbed, including the U.S. National Geospatial-Intelligence Agency (NGA), documented a set of use cases and associated interoperability requirements, selected strategically to address problems whose solutions would be applicable in a wide variety of GPS value chains.

Technology providers participating in the testbed then implemented standards-based solutions that addressed the requirements. These were documented in a draft Engineering Report, “Use of SWE Common and SensorML for GPS Messaging.” The document focuses on the use of the OGC Sensor Web Enablement (SWE) Common Data 2.0 encodings to support an interoperable messaging description and encoding for the next-generation GPS message streams into and out of processing services that provide improved GPS navigation accuracy.

Standards. The OGC Sensor Web Enablement (SWE) suite of standards specifies models and XML encodings that provide a framework within which the geometric, dynamic, and observational characteristics of all types of sensors and sensor systems can be defined.

Furthermore, through standard web-service interfaces, one can task sensor and actuator systems and have immediate access to observations and alerts. SWE standards, now widely implemented around the world, enable developers to make all types of networked sensors, transducers, and sensor data repositories discoverable, accessible, and usable via the Web or other networks. OGC standards are downloadable at no charge, for use by anyone.

OGC Testbed

The OGC OWS-9 testbed’s OWS Innovations thread included a hands-on prototyping activity that addressed a particular set of interoperability requirements related to GPS accuracy.

GPS relies on accurate knowledge regarding the position, measured time, and state of the satellites, provided to GPS devices and processing centers in the form of satellite ephemeris data and status reports. The accuracy of the system relies on communication between the satellites themselves, the data collection systems, the data processing centers, and the GPS devices that ultimately determine their own location. This communication is through various data streams that consist of predefined message structures and encodings.

The accuracy of the positions derived from GPS can be negatively affected by several well-known factors. Improvements to the derived positions within the current operational system can occur (1) through occasional (once a day or once every few hours) updates to the satellites’ clock and ephemeris on-board information, or (2) through post- processing for applications such as geodetic surveying or image processing and georectification. Efforts are underway to provide more timely updates to satellites or positioning devices to improve the accuracy of positioning in real-time.

The GPS Correction Process

One view of the current system for correcting GPS positioning is provided in Figure 1. A GPS positioning unit (shown as a device with red thumb tack) receives signals from four or more GPS satellites derives its position. In addition, the information being sent by all satellites in the GPS system is also received at various receiving stations, stored as raw navigation data, and used to correct the clock and position information for all of the satellites. The correction process can utilize one or more operational processing systems for correcting satellite clock and ephemeris information. Each of these systems tends to utilize particular data sources and often output their results in different message structures and encodings.

One such system for correcting the timing and positioning of GPS satellites is Estimation and Prediction of Orbits and Clocks to High Accuracy (EPOCHA). Currently, navigation and timing improvements are only uploaded to the satellites and GPS devices once a day. To improve the EPOCHA system, the National Geospatial Intelligence Agency (NGA) is researching the logistics and benefits of updating the navigation and timing information at much shorter time frames (for example, every 2–15 minutes).

The corrected satellite clock and state data can then be sent to the satellites, to the processing centers to improve geolocation of real-time or archived positions or remotely sensed observations, and to devices in the field to improve real-time position measurements.

A processing system in widespread use for applying these corrections to positional measurements is the open-source GPS Toolkit (GPSTk). This software was used in OWS-9 to demonstrate the processing of SWE Common encoded GPS data within a Web-enabled environment.

As shown in Figure 1, the data flowing between archiving and processing components exist in a wide variety of formats. Currently, these message streams consist of message structures defined through various documents, some of which have restricted access. Additionally, these streams and the messages they contain are being encoded in various formats, including, for example, a binary exchange format (BINEX), a system-specific XML schema, an HDF5 file format, several text-based formats, and others.

The message components within each of these formats are inconsistent, even though two messages may describe similar information. Often a processing system is required to read data and output results in multiple formats and to understand the inconsistencies between them.

By forcing different software and processing systems to support multiple message structures and data formats, the current system inhibits the effective use of these data by:

• requiring several format-specific readers and writers to be developed in the appropriate software language (C, C++, Java, Python) as required by each application system;
• providing inconsistent message structures between the data used or produced by different processing systems;
• requiring meticulous and thus error-prone human interpretation of the data components based on the limited documentation provided for each;
• creating lack of interoperability with regard to using data designed for or produced by a different particular processing system; and
• discouraging development of new and innovative software and processing solutions.

The Engineering Report addresses the feasibility of using the OGC SWE Common Data v2.0 standard to support all message and data streams within future generations of the GPS operational network. In particular, the effort focuses on message streams that provide input to and output from the processing systems responsible for providing improved position and time accuracy within the GPS network.

Here are the benefits of the SWE Common Data standard:

• The data can be fully described in a machine- and human- readable XML document providing: data type, units, constraints, semantics, quality, labels, and so on; and an unambiguous definition of both the data structure and encoding of messages/records.
• The data values themselves can be encoded in highly  efficient binary or ASCII text blocks or streams.
• A single software application is able to read any data described in SWE Common data.
• Any process can be described in SensorML using SWE Common as inputs, outputs, and parameters.
• Any SensorML-defined process can participate in easily-defined executable workflows.

The Engineering Report describes the formats and how they were encoded, and the Web services created to move data between various GPS processing systems (FIGURE 2).

Conclusions

A common standards framework for all data files and streams within the GPS system would significantly improve interoperability between data centers, processing centers, and user tools.

In addition to a common encoding, common models for equivalent message or data records would also be important for interoperability among data, processing centers, and the tools. Common models and a common data framework enable rapid reconfiguration of workflows using different GPS processing products. Likewise, the availability of a common Web service interface enables one to rapidly and flexibly request specific data products and feed them into an executable workflow.

Here are further benefits:

• SWE Common Data framework is fully self-described and machine readable.
• Common models for all data would support “mix-and-match” capabilities within the processing workflows.
• SWE Web services enable on-demand access to various GPS data products using a common framework.
• SWE Common Data enables use of SensorML for readily defining and executing various workflows on demand.

Future Directions

Further research and development should move closer to a highly interoperable GNSS system that meets the needs of a broader community of users and enables the development of new supporting software by outside communities. Thus the following are recommended:

• Design and reach consensus on consistent data models for all message types in navigation, observation, and state data streams.
• Incorporate SWE Common Data readers/writers in the GPSTk toolkit.
• Create SensorML descriptions for GPSTk apps.
• Demonstrate on-demand design and execution of SensorML-defined workflows for GPS correction.
• Demonstrate on-demand geolocation of UAV, ground-vehicle, and hand- held sensors using SWE services and encodings.

Some of these needs will be addressed in the OWS-10 Testbed that is currently ramping up in the OGC.

---

MIKE BOTTS is president and CTO of Botts Innovative Research, Inc, specializing in the design and application of open standards for sensor systems. He is the creator and chief architect of Sensor Model Language (SensorML), an OGC technical standard for describing the measurement and processing of observations from virtually any sensor system.