Every three months, geospatial experts all over the world from academia, government and industry gather together at the Open Geospatial Consortium (OGC) Technical Committee (TC) meetings to develop international geospatial standards. OGC TC meetings are where innovation of location interoperability happen. I started attending OGC TC meetings since 2003, and always enjoy the collaborative and innovative nature of the meetings.

I just got back from the 113th OGC TC Meeting in Toulouse, France. There are always new developments in the OGC community that excite me, and the Toulouse TC was not an exception. One such development was a presentation from Geonovum revealed that the Dutch government was in the process of endorsing the SensorThings API as a national standard for sharing IoT data. It is great to see the SensorThings API getting adoption around the world — innovative IoT applications can be built by mix-and-match data from different IoT systems. The OGC API was definitely the focal point of the Toulouse TC. It was a major milestone, making it much easier for developers to consume geospatial data on the Web from multiple sources. Developers considered traditional OGC standards to be difficult to use. Fortunately, the new generation of OGC standards, such as SensorThings and OGC APIs, are quickly changing that perception. If the OGC API sounds new to you, have a read through this blog post about OGC APIs and the evolution of OGC standards.

I was also impressed by the emerging OGC Open Routing API. Today when we use a routing service, such as Google Maps Routes and Services, Bing Maps Directions or even Waze, we typically get stuck with a tightly integrated solution. That means integrating, overlaying, or comparing routes from different routing service providers is not an easy task. Let’s say Routing Service A offers great public transport routing, while Routing Service B offers great walking directions. It only makes sense if we can combine the two routing results (i.e., routes) together. The emerging Open Routing API is able to make that happen. However, what excited me most at the Toulouse TC was the OGC Moving Feature JSON.

OGC Moving Features — sharing world-wide movement data

As the price of location trackers and IoT data plans are decreasing dramatically, more and more organizations will install location trackers on everyday objects and try to extract insight out of the moving feature data. The OGC Moving Feature standard is a critical component in order to unleash the power of movement data.

I am a working group member and a big fan of the OGC Moving Feature standard. It is a great example of an OGC implementation standard based on a solid scientific foundation. A moving feature means a feature’s location continuously changes over time. Such moving feature might also have some non-spatial attributes, and those values also change over time. For example, a bus can be a Moving Feature, and its location, speed, direction, and number of passengers change over time. The following figure illustrates the Moving Feature concept, including leaf, trajectory, prism, and foliation.

Feature Movement: trajectory, leaf, foliation, and prism [ISO 19141:2008]

In this figure, the orange 2D rectangle moves and rotates. Each representation of the rectangle at a time instance is called a leaf. A trajectory is the path traced by a corner point of the rectangle over time. The set of points contained in all of the leaves, and in all of the trajectories, forms a prism. Finally the set of leaves forms a foliation, meaning that there is a complete and separate representation of the geometry of the Moving Feature for each specific time.

OGC Moving Feature currently has two different standard encodings: XML (OGC 18–075) and CSV (OGC 14–084r2). MF-JSON is currently a candidate standard, waiting for approval voting. Offering JSON encoding is a great step for wider adoption. The reason is obvious: developers love JSON and run as fast as they can away from XML. The current version of the Moving Feature JSON standard defines two JSON encoding formats: MF-JSON Trajectory and MF-JSON Prism. The cherry on top was that the latest version of the MF-JSON Trajectory is also based on GeoJSON!

What does that mean and what are the benefits? Being compatible with GeoJSON means the numerous existing GeoJSON tools are also immediately available to the MF-JSON. For example, I copied and pasted an example MF-JSON to a GeoJSON editor (geojson.io), and voilà! I can get a quick overview of the trajectory without any coding (figure below).

In summary, the theme of the OGC Toulouse TC is about being more developer friendly and agile without losing the solid scientific foundation of OGC. OGC API and OGC Moving Feature represent a positive trend for OGC. I feel that the OGC community has found its North Star, and I am excited to see more of the bright future of geospatial technologies at the next OGC TC meeting.

Finally here is a picture of the banquet of the OGC Toulouse TC at the beautiful Toulouse City Hall.