What do you see at the first glance in this picture? A drink in peculiar shaped glass, a drop of orange watercolour, or a hexagonal prism (geek!)? If you do see an efficient way to encode a simple 3D geometry based on an extrusion of a 2D polygon, you must be as excited as I’m to know that JSON encoding of geometries like this are becoming internationally standardised as OGC Features and Geometries JSON, or JSON-FG for short. And it does not stop there: JSON-FG also provides standard mechanisms to enhance the well-know and widely supported GeoJSON format with coordinate reference systems other than WGS84, temporal properties and feature typing.
I was positively surprised a couple of years ago to find that GitHub has natively supported rendering GeoJSON content already since 2013 using Leaflet! If that does not tell you that GeoJSON is a strong format for encoding spatial information for the Web I don’t know what does. GeoJSON has been standardised by the IETF as RFC 7946 in 2016 and the JSON-FG Standard has been in drafting by the OGC since mid-2021 as a backwards-compatible extension of it. As an OGC Member we have been following the process at Spatineo with strong interest, as we see many interesting use cases for it in various domains, including built environment, engineering & infrastructure, utilities, environmental services, forestry and aviation.
Regardless of how much you like or dislike XML and GML application schemas as a standardised exchange format for location information, you probably agree with me that the JSON based encodings and APIs are the number one options for modern information systems and applications. I’ve personally grown keen to XML Schema and Schematron as I’ve played with them since the mid 1990’s, but let’s face it: coders love JSON (and hate XML). Even if XML would work perfectly well for system-to-system data integrations and GML encodings are really well established in the GIS community, I’m afraid XML is doomed to lose the technology battle against JSON. There will be less and less talented coders out there using XML tech stacks, which means that XML software libraries will gradually get outdated and eventually die. A bit like the in video tape war between VHS and Betamax this will have little to do with technical superiority of the available options.
The JSON-FG spec officially titled “OGC Features and Geometries JSON – Part 1: Core” (OGC 21-045) introduces a small set of fixed and well-defined building blocks for describing its extensions to GeoJSON:
- Temporal information: A standard “time” member for describing time instants or periods that nail the GeoJSON Feature in time like the “geometry” property does for location. Think time sliders for maps.
- Geometry: A standard “place” member for providing the GeoJSON location using non-WGS84 coordinates, or using non-GeoJSON geometry types, such as Polyhedron, MultiPolyhedron, Prism, and MultiPrism. The usual GeoJSON “geometry” property will still be available to use for GeoJSON geometry types in WGS84, so everything will still work in plain GeoJSON software.
- Reference systems: A standard “coordRefSys” member for explicitly providing the coordinate reference system ID used in the “place” geometry. The name may sound a bit silly, but there are good reasons not to have is clash with the “crs” property used in some of the GeoJSON flavours. The value of this property explicitly does not apply to the “geometry” property to keep things simple and backwards compatible.
- Feature type(s): A standard “featureType” member for declaring that the the GeoJSON object complies with a defined semantics and content of an externally defined object (feature) type. The GeoJSON Feature is mandated to have a “type” member with a fixed value “feature”, so this is a way to provide a bit more guidance to the users on what kind of feature the object represents. For homogeneous feature collections of the same feature type this only needs to be provided once at the collection level.
- Schema(s): Allows for linking to JSON Schemas describing the names and content types of the “properties” members of JSON-FG Features either at the feature collection or at individual feature level. In plain GeoJSON there is no way to describe the contents under the “properties” member for validation purposes.
I was talking to Clemens Portele, one of the co-chairs of OGC JSON-FG standards working group, in Frascati last month, and found out that the current draft version 0.1 standard is eagerly waiting for feedback and comments from the user community. It will only be published an official OGC Standard when enough people say it works for them and any discovered wrinkles have been ironed out! This makes complete sense to me, as nobody wants to have yet another standard which doesn’t quite cut it.
However, the JSON-FG spec is complete and ready to use, so there is no reason to wait for the final version before giving it a spin. Several API and client implementations are already available for you to choose, and any the GeoJSON compatible software will also be able to show you the basic information.
At Spatineo we are currently looking for pilot projects to implement and test the JSON-FG support, so let me know if you find this interesting! And don’t forget to report any issues you find in the JSON-FG GitHub repo.
Photo by Jill Burrow / Pexels.
This article was originally posted in LinkedIn.
