It is no secret. Coordinate reference systems (CRSs) are a constant issue in the geospatial community. Unfortunately they are a fact of life for many of us[1]. The GeoPackage standard requires that the CRSs in use be defined[2]. The standard encoding for CRS definitions that was available at the time was included in OGC 01-009 but that one is pretty dated and it has been causing problems in the field. In response, OGC recently adopted 12-063r5 to bring things up to date. The problem is getting people to start using it.
It is a classic chicken and egg problem. Consumers do not want to build support for data that isn’t being produced yet. Providers don’t want to produce data that consumers can’t read. Naturally, we’ve been asked to break the cycle. The traditional approach is to issue a new standard version that cites the new document but as mentioned previously, this is something we’re trying to avoid.
Our solution is to create another extension and to let a specific domain try it out. In this case it is the US National System for GeoINT (NSG) which represents the US defense and intelligence community. NSG has been working on a profile for GeoPackage which constrains and extends the standard. Among other things, the profile will contain an extension that updates the reference for CRS definitions from 01-009 to 12-063r5. Systems designed to work in this domain will be mandated to support the extension but others can adopt it at their own pace.
[1] For example, NGA does not support the use of Web Mercator and has developed other CRSs for use in tiles.
[2] There are three defaults, one for EPSG::4326, one for undefined geographic systems, and one for undefined cartesian systems.
It isn't going to be easy to get support into some environments without funded development. I looked at it for GeoTools, and it is hard. The lack of the ToWGS84 parameters is the core issue.
ReplyDeleteIn some ways its sad, because the modeling purists have prevented an easy transition, so the other improvements don't get realised.
For information in case it may be worth consideration: I'm the author of most of the GeoTools referencing module (Martin Desruisseaux), at least as it was a few years ago (I didn't watched if there is new developments). All my work now happen in Apache Spatial Information System (SIS) - http://sis.apache.org - which currently is basically the evolution of the GeoTools metadata and referencing modules with lot of improvements and bug fixes. Apache SIS already supports the new OGC 12-063 / ISO 19162 standard, in addition to the old OGC 01-009 format, the "GDAL flavor" of WKT 1 (which is slightly different than OGC 01-009) and the referencing part of GML. The SIS referencing is tested against parts of the Geospatial Integrity of Geoscience Software (GIGS) test suite (last time I tried, GeoTools failed some of those tests) and is an implementation of GeoAPI 3.0 OGC standard (GeoTools forked a GeoAPI 2.x version which has not been approved as an OGC standard). Maybe the GeoTools community should consider replacing their referencing module by the Apache SIS one?
DeleteAbout TOWGS84: actually it still exists in the new standard, but in a very different form: the BOUNDCRS element.
An other way for GeoTools to get ISO 19162 support relatively easily without replacing their referencing module would be to upgrade their API to GeoAPI 3.0 (I think they already have a wiki page exploring the consequences). Then, since the Apache SIS's WKT parser is designed for working with an arbitrary CRSFactory, they can supplied the GeoTools's one to the parser.
Delete