ISEA: inverse projection method is not implemented

[ppKrauss]

As expressed here, even with QGIS is impossible to "see ISEA".
A projection is useless if we cannot visualize it... Without visualization you lose confidence and a multitude of applications.

At PROJ Readmes and/or documentation, ideal is to citate a "how to visualize" tutorial, or explain "Danger: you can calculate distances and areas, but can't visualize because there are implementation limitations".

[rouault]

even with QGIS is impossible to "see ISEA".

the reason is much likely that only the forward method (geographic coordinates -> projected coordinates) is implemented, whereas QGIS also requires the inverse method to be implemented. Which doesn't look (to me at least) as a trivial exercise

[rouault]

I see this was discussed in #1778 already

[ppKrauss]

Hi @rouault, can you or other PROJ contributors reuse this CPP implementation of the inverse transform?

• https://github.com/riskaware-ltd/open-eaggr/blob/master/EAGGR/Src/Model/IProjection/Snyder.cpp#L190

• https://github.com/riskaware-ltd/open-eaggr/blob/master/EAGGR/Src/CoordinateConversion/CoordinateConverter.cpp

[rouault]

reuse this CPP implementation of the inverse transform?

no, it is licensed under LGPL v3 which is more restrictive than the MIT license used by PROJ. Someone could potentially extract the maths/algorithms to have a clean-room implementation, but we cannot directly derive code from that implementation

[ppKrauss]

Someone could potentially extract the maths/algorithms to have a clean-room implementation, (...)

Perfect!

[busstoptaktik]

@USGSExplorer1, the PROJ Github repository is for discussing the PROJ source code, so do not post questions about PROJ usage here. You can seek advice for PROJ usage on the PROJ mailing list, cf. https://proj.org/community/channels.html

[busstoptaktik]

@USGSExplorer1 If you provide a pull request with an implementation, I'm sure it will be seriously considered. PROJ is a contribution driven open source project - if you need a certain functionality, you're most welcome to provide it, or to hire someone capable to do it on your behalf.

So this is not the place to ask whether something will be implemented or not: It will, if someone makes it happen. That someone could be you, or anyone else having the need, willingness, and capability.

[jerstlouis]

As I mentioned in the OGC FMSDI Phase 3 ER, there is an MIT license implementation in Java of the inverse projection in the geogrid project:

https://github.com/mocnik-science/geogrid/blob/master/src/main/java/org/giscience/utils/geogrid/projections/ISEAProjection.java

I ported this code to eC, which is a superset of C very similar to C++ (the ported code uses very little in terms of eC-specific functionality that is not basic C or C++).

I would be happy to contribute this port to PROJ, if someone commits to integrate it (happy to help with this as needed, but not lead the effort), or alternatively someone could start directly from the Java version.

This could be a topic for the 24th OGC Code Sprint in London next week, where a sub-group will focus on OGC API - DGGS implementations for the ISEA3H DGGRS.

cc. @MichaelJendryke @doublebyte1 @ldesousa @mpadillaruiz @perrypeterson @rouault

These GeoJSON files in the ISEA planar projection could be used for tests (to map it back to latitude, longitude on the globe):

• gebco-A6-0-E-level11-ISEA.geojson
• gebco-A6-0-E-level12-ISEA.geojson

Separately, we're also hoping to register a CRS in the OGC registry, but this somewhat pending on the definition of a proper CRS definition, which itself is somewhat pending on the whole PROJ JSON / CRS JSON work item. Being able to identify that CRS in GeoTIFF would also be very helpful (I believe GeoTIFF is currently limited to CRS with EPSG codes?).

Support for the inverse ISEA projection in PROJ is a really critical piece of functionality that would immensely help the DGGS community.

[jerstlouis]

Please see cleaned up and contributed code attached:

isea-projection.ec.zip

It includes both forward and inverse projections for ISEA:

https://maps.gnosis.earth/ogcapi/collections/blueMarble/map?crs=[OGC:1534]

as well as for the rotated/sheared/scaled ISEA 5x6 space described in the FMSDI-3 ER and video:

https://maps.gnosis.earth/ogcapi/collections/blueMarble/map?crs=[OGC:153456]

The only bit of trickyness in porting this to C or C++ would be related to the Degrees/Radians/Angle unit classes in eC.
Degrees are internally stored in radians and can be passed directly to the libc mathematical functions, but converting to/from double implies the Pi/180 conversion factor.

@MichaelJendryke @rouault

The 5x6 space is particularly useful not only for the ISEA9R DGGS (and 2DTMS), but also for doing calculations for ISEA3H (and possibly other ISEA-based DGGS) with very intuitive and easy to manipulate coordinates.

[ldesousa]

@jerstlouis Thank you for this contribution, very welcome. I haven't checked the code yet, but I have a question, the first time I checked the PROJ implementation it only supported a single icosahedron orientation (one vertice one each pole). Does this implementation allow for other, more popular, icosahedron orientations?

[jerstlouis]

@ldesousa The current PROJ library supports both the standard (+orient=isea) and polar (+orient=pole) orientations.

It also has a +azi= parameter which might also control orientation?

This new code has an orientation property in the ISEAPlanarProjection class which allows to set a latitude and longitude orientation, and a commented out #define POLAR_ORIENTATION to change the default values.

The default values are the standard ISEA orientation (lat: 31.7174744114613, lon: -11.25).

[ppKrauss]

🎉🎉!!! Thanks @jerstlouis ! Soon another dream will come true, by PROJ and active collaborators like you!

[jerstlouis]

Thanks @ppKrauss! Please try it out if you can. The Travis CI build for the PR needs the attention of a project member I think to approve the workflows. I think the previous build issues related to C++ compiler / versions / Warnings as errors are now ironed out ...

[rouault]

I think the previous build issues related to C++ compiler / versions / Warnings as errors are now ironed out

I've approved the workflows. Quite a bunch of warnings to solve