[PROJ] Pitching the proj project to Google's Geo team

[Cameron Shorter]

Thanks Martin, I was unaware of this, and plan to add some extra bullets to
my slides (probably with a link back to this email).

On Wed, Aug 24, 2022 at 12:11 AM Martin Desruisseaux <
martin.desruisseaux at geomatys.com> wrote:

> Le 20/08/2022 à 23:40, Cameron Shorter via PROJ a écrit :
>
> I now have a job at Google (outside of Geospatial), and have been asked to
> present to Google's Geo team about misaligned maps due to tectonic plate
> movements, and what to do about that.
>
> I did not answered directly to the first question yet, but are you aware
> of OGC GGXF effort?
>
>
> https://github.com/opengeospatial/CRS-Gridded-Geodetic-data-eXchange-Format/
>
> This is a proposed OGC standard format for encoding the information needed
> for performing coordinate transformations due to tectonic plate movements,
> among other geodetic operations. It is currently based on netCDF, but we
> try to split the standard in a "carrier neutral" core and an annex which
> applies the core to netCDF-4 carrier. That way, it keeps the door open for
> adding other carriers (e.g. ZARR or GeoTIFF) if needed.
>
> A little bit of history: ESRI and IOGP (the maintainer of EPSG database)
> started to look at this issue maybe 5~10 years ago. ESRI already made a
> first proposal based on netCDF at that time (so contrarily to what have
> been said on this mailing list, this effort did not started because of PROJ
> doing something similar 2 years ago). However that work had little progress
> until 2 years ago for human resource reason: CRS activity in the last years
> at OGC has progressed a lot thanks to a man who accomplished a tremendous
> amount of standardization work: Roger Lott from IOGP. But Roger has been
> busy with the first version of ISO 19162 (WKT 2) before 2015, then with
> revision of ISO 19111 precisely for taking in account plate movements (that
> ISO 19111 revision introduced dynamic CRS and "Point Motion" operation),
> then with revision of ISO 19162 for leveraging above-cited new
> capabilities, and revision of EPSG database schema (version 10.x changed
> significantly compared to 9.x) for same reason. Roger became available for
> new work only 2 years ago.
>
> The GGXF working group includes members from IOGP, ESRI, AIG
> (International Association of Geodesy), various mapping agencies and Chris
> Crook who helped to design the GeoTIFF format used by PROJ for gridded
> datum shifts. So not only we are well aware of the work PROJ initiated, but
> one of the key designers of that work is one of the most active GGXF
> contributors.
>
> The group has produced two documents. One document about deformation model
> (largely Chris's work) has been completed and will be submitted at OGC for
> approval I think in October. The other document is about the GGXF format
> itself, which after 2 years of work is close to completion. The feasibility
> of GGXF is tested by a prototype written in Python by Chris.
>
> So to address the tectonic movements issue, I think that OGC standards are
> putting pieces in place, thanks to Roger's and Chris's work. I presume that
> when GGXF will be an approved standard, it will be used in EPSG database as
> operation parameters whose value is a path to a GGXF file. But there is a
> delay of many years between standard approval and their actual
> implementation in open source software. For example in Apache SIS, we have
> not yet implemented the new features introduced in ISO 19111:2019 (point
> motion operations, etc.) and the corresponding updates in ISO 19162:2019
> and EPSG database version 10.x. In PROJ as well, I'm not sure if "Point
> Motion operation" is already implemented.
>
> So I believe that OGC standards are in good progress for addressing the
> issue raised by Cameron, but implementations lag a few years behind (which
> is normal).
>
>     Martin
>
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220824/53ee011f/attachment.htm>