Added Popular Visualisation Pseudo-Mercator projection to the list of supported projections

[J-Christophe]

@AndrewAnnex wants to add the Popular Visualisation Pseudo-Mercator projection to the list of supported projections. This projection will result in the addition of 237 CRS. The list of 237 CRS can be found here

https://drive.google.com/file/d/1LLSUrl4progCn_1KukicDlyc2FbA5A-n/view?usp=share_link

[ghobona]

The proposed CRS definitions have been uploaded for discussion at https://github.com/opengeospatial/Planetary-DWG/blob/main/draft_crs_definitions/proposal001.adoc

[AndrewAnnex]

Not sure how much discussion there needs to be, but just to say it the justification for adding these codes is to better enable interoperability with existing web GIS frameworks and front-ends that assume pseudo-mercator projections for planetary bodies.

[J-Christophe]

Agreed with Andrew. It is another projection to support.

The identification code is generated automatically through the implementation of an algorithm that takes into account the NAIF ID, the code for the non-projected CRS, and the projection code. In order to address Andrew's concern, it is necessary to include a new projection code to accommodate this specific projection. Consequently, a multitude of CRS will be added for each combination of NAIF ID and code for the non-projected CRS.

So as it is automatic, the WKT2 outputs should be correct. Therefore, I support the addition of this projection and the resulting CRS from this new projection to support

I guess @thareUSGS has the same opinion

[thareUSGS]

Yes. To support the many viewers out there that are locked into using pseudo-Mercator projections, I also recommend this update as a new projection code.

[desruisseaux]

Does it really needs to be the Pseudo-Mercator projection? I do not know the historical reason why this projection has been created in the first place, but it looks a lot like wrong understanding of geodesy. EPSG has been reluctant to add this projection to their registry, and finally did it only because it was so widely used. Do we really want to propagate the Pseudo-Mercator mistake to the whole solar system? The EPSG registry has a better projection from geodetic perspective:

• EPSG:1026 — Mercator (Spherical)

The difference between Pseudo-Mercator and Mercator (Spherical) is that the latter is either properly associated to a sphere or use the authalic radius of an ellipsoid, while the former is associated to an ellipsoid but ignores that fact (it takes only the semi-major axis, ignoring other axis or flatness). Otherwise the formulas are identical (the only difference is a R for "radius" instead of a a for "semi-major axis").

In the proposal posted by Gobe, all CRS with a flattening factor of 0 (e.g. ELLIPSOID["Mercury (2015) - Sphere", 2440530, 0]) work the same. We only need to replace METHOD["Popular Visualisation Pseudo Mercator"] by METHOD["Popular Mercator (Spherical)"] and the rest should be the same. Numerical values will be the same.

For the CRS with a non-zero flattening factors such as ELLIPSOID["Mercury (2015)", 2440530, 1075.123348017621], do we really needs to provide those CRS since Pseudo-Mercator will ignore the flattening factor and provide the exact same results than the CRS defined just before, with ELLIPSOID["Mercury (2015) - Sphere", 2440530, 0]?

[thareUSGS]

I have also never been a fan of Pseudo-Mercator (web Mercator), but it is widely used in tiling schemes.

But are you saying -- if we must support Pseudo-Mercator, we should only list one code per body using the spherical definition? I would support that.

Although it sounds like you, @desruisseaux, would rather just skip it entirely?

I wonder if I add "Popular" to my favorite projection if it would gain more traction too. ;-)

[AndrewAnnex]

@desruisseaux I chose Pesuedo-Mercator to be consistent with EPSG 3857 which itself if a correction for the now deprecated EPSG 3785 so that EPSG 1024 is used to define the mercator projection (see https://en.wikipedia.org/wiki/Web_Mercator_projection and https://alastaira.wordpress.com/2011/01/23/the-google-maps-bing-maps-spherical-mercator-projection/). This choice was also discussed in https://github.com/OSGeo/PROJ/pull/3645.

@thareUSGS While I see the point about the flattening being ignored and replacing things with the spherical ellipsoids that would be inconsistent with EPSG 3857 which uses WGS 84 with flattening (4326).

I think 1024 is actually precisely what we want as it is closely tied to the (flawed) flavor of mercator that all the web gis frameworks and tiling schemes use. I worry that being overly pedantic here would cause subtle issues that would make it too hard to adapt these external projects to allow for planetary applications. Since there are no other legitimate needs for better/different mercator projects for other planetary bodies to my knowledge, then I think the choice should be whatever is needed to support these use cases which means adopting the quirks. As far as I am aware, 1024 is the preferred conversion to use for this use case despite the issues noted above.

[desruisseaux]

The issue with the Pseudo-Mercator projection is in the way that it handles the WGS84 ellipsoid. But in the case of extra-terrestrial bodies, the ellipsoids are not WGS84. Each body has a new ellipsoid. For all CRS definitions using a ellipsoid without flattening factor, EPSG:1026 (the spherical Mercator) is mathematically equivalent to EPSG:1024 (pseudo-Mercator). Existing applications can just consider EPSG:1024 as synonymous to EPSG:1026 in the special case when the ellipsoid is a sphere. It seems to cover a lot of definitions in Gobe's list, and would be a first step toward avoiding to perpetuate the pseudo-Mercator problem.

For the cases where the flattening factor is non-zero (or more precisely non-infinity), we could omit all the CRS definitions that are sequivalent to the spherical case, and see what remind after that.

[ghobona]

Great discussion. The list originated from the Planetary DWG. I simply posted it in support of the DWG Chair.

[AndrewAnnex]

I wasn't confused about these bodies or the ellipsoids @desruisseaux, but I do not like pushing this as a concern for downstream packages to conform to when those applications are not written by geodesists (a majority, I think I can fairly guess) even if it is a subtlety that can be trivially accounted for, should someone know about the issue. It could require changes to dozens of frameworks and libraries given that the norm is to use 1024, or at least that is my concern that maybe could be addressed. Is there a different CRS that I am not aware of that uses 1026 and is commonly used? Does PROJ know to treat it as a no-op conversion? So while I see the "problem" I still don't see how this manifests with any harm or mis-use to make it a material issue to solve with planetary bodies. On the other hand, I could be overly worried about this, I just have a preference to do whatever causes less friction downstream in libraries and software others maintain.

That said I now do think it makes sense to reduce the list of projections just to those that use the spherical ellipsoids (but currently still use 1024). This would remove every code that does not end with "90" in the list. But at that point, we assume no flattening so I am not sure if the change to 1026 is necessary as per the discussion above

[desruisseaux]

Thanks Gobe and Adrew for you replies. Indeed if we remove all definitions based on ellipsoids, it would not only remove redundancies, but also makes EPSG:1024 and EPSG:1026 synonymous. I do not know if PROJ supports that operation method, but I think it is probable. I can check by asking to Even.

Using EPSG:1026 instead of 1024 for spherical bodies makes a conceptual difference: it tells users that a circle on the map is a circle on the ground (assuming that the use of a sphere is considered a good approximation). We can not rely on that when using Pseudo-Mercator. The difference on WGS84 is not very big (but still important for some applications), but some extra-terrestrial bodies are more flattened than Earth, making Pseudo-Mercator worst.

I realise that packages are not written by geodesists, but I think it is one of OGC purposes to guide non-specialists for providing a reasonably realistic description of the physical world. For framework makers, EPSG:1026 support can be simple:

1. If the datum is not a sphere, raises an error.
2. Otherwise treat as synonymous of EPSG:2014.

That's all. We can ask framework makers opinion, but it does not seem too much burden to me. Point 1 is the difference with EPSG:1024 and is what make EPSG:1026 safer as a description of the reality. More advanced frameworks could, instead of raising an error, follow the EPSG Guidance Note advice and use the radius of conformal sphere. But this is optional.

Regarding if there is a lot of CRS using EPSG:1026. It is surely less used than EPSG:1024, but it may be because very few terrestrial CRS use a spherical figure of the Earth. The situation is different in astronomy, where we do have a lot of planets with a spherical figure and no ellipsoid. Propagating the EPSG:1024 confusion is unnecessary for them.

[AndrewAnnex]

@desruisseaux Yes please do check with Even on this. Again the hope is to enable downstream software that are already coupled to 1024 to at least work more easily with these codes accepting these known flaws because they are closer to what is popular (rightly or wrongly) so that the transitions to more correct codes can be motivated better.

I wonder if I lost something in the discussion however that makes me even more hesitant to adopt 1026 and the spherical ellipsoids. From the text on page 44 of the Guidance Note 7 part 2:

This method is utilised by some popular web mapping and visualisation applications. Strictly speaking the inclusion of 'Mercator' in the method name is misleading: it is not a Mercator projection, it is a different map projection and uses its own distinct formula: it is a separate method. Unlike either the spherical or ellipsoidal Mercator projection methods, this method is not conformal: scale factor varies as a function of azimuth, which creates angular distortion. Despite angular distortion there is no convergence in the meridian, so the graticule has a similar appearance to the graticule of a Mercator projection, but the graticules of the two projections do not overlay. See IOGP publication 373-23 (Web Mercator) for further information

The intent of these codes is strictly not to include a perfect mercator projection for planetary bodies as there is no objective need for one. The intent is strictly to support popular web mapping and visualization applications, whatever it happens to be named. So again I ask is the switch to 1026 really the right thing to do here? I just worry changing to 1026 while pedantically correct for mercator projections would actually do harm and create a bunch of codes that cannot be used for practical use cases.

[desruisseaux]

I just did a test with a WKT string. EPSG:1026 is not supported by PROJ 9.0.1 (it is supported by Apache SIS however). But I can volunteer for submitting a patch to PROJ as it would be a trivial addition.

The above citation from EPSG Guidance Note 7 part 2 is what I tried to said when I wrote that a circle on the screen is not a circle in the real world. This is a consequence of the Pseudo-Mercator projection not being conformal. However this is true only when Pseudo-Mercator is applied on an ellipsoid such as WGS84. When Pseudo-Mercator is applied on a sphere, the projection become conformal with mathematics equivalent to the Mercator spherical case. Maybe the EPSG guidance note does not mention that fact because Pseudo-Mercator has been created specifically for use with ellipsoids. It is useless for spheres because the existing Mercator projections were already doing the exact same thing.

In our case with astronomical bodies, we are applying the projection on spheres. Consequently Pseudo-Mercator is conformal in that particular situation and fully equivalent to Mercator spherical. However while mathematically equivalent, the use of EPSG:1026 carries a semantic difference. It makes explicit the fact that shapes are preserved (circles on the map are real circles). If even an expert cited EPSG guidance Note 7 part 2 as a note of caution despite the fact that it does not apply to spheres, non-expert users are likely to be even more confused.

So in summary: Pseudo-Mercator applies to ellipsoids and is unnecessary for spheres. The use of Mercator spherical is not only about being pedantically correct, it does carry a semantic difference as it tells users that the usual caution against Pseudo-Mercator does not apply in this particular case. Even if not all frameworks support Mercator spherical, that support should be trivial to add since it can be implemented as synonymous to Pseudo-Mercator + a safety check.

I restrict the above arguments to the case where the datum uses a sphere. The cases where Pseudo-Mercator was applied on ellipsoids differ from the spherical cases in a subtle way, even if the semi-major axis lengths are identical. We can discuss that in a separated thread if needed.

[AndrewAnnex]

okay @desruisseaux I think this is making more sense to me so let me know if the following sounds right to you

For all the projections we have in that list that use the Spherical ellipsoids (currently ending in 90), we'd really want to use EPSG:1026 as we'd want to use a spherical Mercator projection. So for Mars 49990, it would need to be updated to use 1026, just as an example.

For all the projections that use the ellipsoids (have inverse flattening) like 49992 for Mars, we'd use Pseudo-Mercator EPSG:1024.

I think then this allows us to support both cases correctly, for visualizations users would most likely use the ****92 codes (91 is with ographic coordinates).

This would result in a smaller list of projections as many of the bodies only have either spherical or triaxial ellispoids (no ellipsoids with flattening), take Phobos as an example. Although I'd hope this could be corrected for eventually I am not sure if those codes are useable so we could remove the codes ending with 93 or 94 from the proposal for now.

Thanks for carefully explaining all of this @desruisseaux, I think it would be great to see a patch to PROJ result from this conversation.

[desruisseaux]

Thanks Andrew. The above seems correct to me. So I indeed suggest to use "Mercator (Spherical)" for all CRS associated to a spherical ellipsoid in order to make explicit the Mercator properties.

For the CRS associated to a flattened ellipsoid, if the semi-major axis length (the first value in ELLIPSOID) in the CRS ending in 91 is identical to the value in the CRS ending in 90 (which seems to be our case), then the CRS in …90 and in …91 are equivalent with only a subtle difference in when datum shifts are applied. Both series may require datum shifts, but for different target datum. None are implicitly easier or more difficult, it really depends on which datum become most widely used in practice. On Earth, Pseudo-Mercator seems easier to support because so many peoples use WGS84 as the target ellipsoid. But if on some extraterrestrial planet the spherical datum become used more often than the flattened one, then the situation would be reversed.

Given that Pseudo-Mercator is not implicitly easier or more difficult than Mercator spherical as long as no established practice has caused a datum to prevail over the others datum, a careful approach may be to omit the CRS using Pseudo-Mercator for now, and wait and see. If practice shows that the flattened ellipsoids become prevalent over the spheres in visualization applications, then it would be a case for introducing Pseudo-Mercator projections.

To rephrase: Pseudo-Mercator is useful only when we want the simplicity of spherical formulas in a world where the flattened ellipsoid is the dominant datum. If no such dominance has been established yet, it may be careful to not encourage Pseudo-Mercator too fast. It may never be needed (and actually may add chaos) if visualization applications adopt the CRS ending in 90 in practice.

For CRS ending in 92, since they are -ocentric CRS, I'm not sure how Pseudo-Mercator applies to them since I never saw that case before. I will think a bit about it.

For CRS ending in 90, what about omitting the "Ocentric" part in their name? For example simply ""Sun (2015) - Sphere / Mercator (Spherical)". The reason is that in the same way that EPSG:1024 and EPSG:1026 are mathematically equivalent in the spherical case, geographic and geocentric coordinates are also equivalent on a sphere.

[AndrewAnnex]

@J-Christophe may be able to explain the inclusion of the "Ocentric" parts of the names. There is a naming convention the DWG used for the initial collection of CRSs so I am not willing to break from that currently. I think the 92 codes would remain as normally coordinates use ocentric latitudes (like for Earth 3857) so I don't see an issue there currently.

I think I have to be firm at the moment and say that we should retain the Pseudo-Mercator codes because I think it is needed given the points I've made about existing software, the point of adding mercator codes in the first place, speed of adoption by the community, etc. To that point, I think that flattened ellipsoids are the norm because they are assumed and hardcoded into so much software. By not defining them, that just creates the opportunity for a lot of custom CRS should others want to use these software that is the current status-quo in the field and is very difficult/annoying/impossible to work with, or simply complete lack of support for any non earth body because of missing codes. As a member of that community, this is something I want and need from this DWG.

[J-Christophe]

Planetocentric implies that longitudes are counted from -180 to 180 degrees, while planetographic implies that longitudes are counted from 0 to 360 degrees. Currently, this difference has been overlooked because the WKT2 CRS does not handle currently the possibility of expressing an angle from -180 to 180 or from 0 to 360, and software does not handle it either at the moment. This "sphere" datum (for CRS ending in 90) is used to make enable the most interoperable definition for the body using mean radius. In the case of the sphere, ocentric carries the semantic that angles are counted from -180 to 180 rather than from 0 to 360 degrees.

[AndrewAnnex]

@J-Christophe are you sure about that? For example codes 49910-49916 have all combinations (permutations?) of ocentric and ographic equirectangular projections with clon=0 and clon=180.

for example 49911 is clon = 0 ographic and 49916 is ographic clon = 180. while 49912 and 49915 are the ocentric equivalents with both center longitudes

[AndrewAnnex]

see also https://gis.stackexchange.com/questions/428410/what-is-an-ographic-latitude-such-as-in-iau-projection-39916

[J-Christophe]

It becomes a bit late here. Maybe @thareUSGS can complete my answer if needed

I am sure about the definition of planetocentic and planetographic for a non-projected CRS. The IAU definition is the same as NAIF : https://naif.jpl.nasa.gov/pub/naif/toolkit_docs/Tutorials/pdf/individual_docs/17_frames_and_coordinate_systems.pdf (p23, 24, 25). Note1 : The planetodetic CRS is missing in our code Note2 : WKT2 CRS does not handle the way to express an angle

If I remember well, clon=180 is a kind of hack to represent an angle from 0 to 360° as -180 to 180 in GIS tool : https://astrodiscuss.usgs.gov/t/working-with-360-and-180-longitude-domains-in-gdal/889

Currently the IAU code is based on this algorithm:

* 100 + + [] The non_projected_crs : - SPHERE_OCENTRIC = ("Sphere", CrsType.OCENTRIC.value, 0) - ELLIPSE_OGRAPHIC = ("Ellipse", CrsType.OGRAPHIC.value, 1) - ELLIPSE_OCENTRIC = ("Ellipse", CrsType.OCENTRIC.value, 2) - TRIAXIAL_OGRAPHIC = ("Triaxial", CrsType.OGRAPHIC.value, 3) - TRIAXIAL_OCENTRIC = ("Triaxial", CrsType.OCENTRIC.value, 4) The projection codes : - 10 - Equirectangular, clon = 0 - 15 - Equirectangular, clon = 180 - 20 - Sinusoidal, clon = 0 - 25 - Sinusoidal, clon = 180 - 30 - North Polar - 35 - South Polar - ... - 90 Popular Visualisation Pseudo-Mercator The codification is not perfect for several reasons and will cause problems in the future : - No slot to add planetodetic - slots for projection code is closed to be satured (at the beginning, the purpose was just to handle the main projections) - Naif_id (https://naif.jpl.nasa.gov/pub/naif/toolkit_docs/C/req/naif_ids.html) may explose because too much moons have been discovered around Jupyter (For instance 4 is Mars barycenter - 99 the planet - 1-98 the number of slots for moons) - I think we have discovered 95 moons ! So it remains 3 slots The origin of the CRS definition when we started was not to define all possible CRS but to handle most map projections to be able to use WMS/WMTS with the IAU code to project different maps onto a single client.

[desruisseaux]

Hello @J-Christophe, thanks for speaking. Regarding the axis range, a WKT specification amendment is already in OGC and ISO pipeline. See CRS WKT corrigendum section 7.5.7. Section 7.5.8.6 gives the following example:

CS[spherical, 3],
  AXIS["latitude", north, ORDER[1], ANGLEUNIT["degree", 0.0174532925199433]],
  AXIS["longitude", east, ORDER[2], ANGLEUNIT["degree", 0.0174532925199433],
      AXISMINVALUE[0], AXISMAXVALUE[360]],
  AXIS["ellipsoidal height (h)", up, ORDER[3], LENGTHUNIT["metre",1.0]]

Second ISO ballot was from 2023-02-14 thru 2023-05-13 with publication target 2023-12-09. It will be published at OGC (possibly before ISO) as 18-010r8. With this corrigendum, the use of "Ocentric" naming convention for expressing axis range is no longer necessary. Note: this corrigendum also contains the two-dimensional spherical CS which was needed for the "ocentric" cases.

About the following:

This "sphere" datum (for CRS ending in 90) is used to make enable the most interoperable definition for the body using mean radius.

In the current file, the spheres seem to use the semi-major axis length rather than mean radius, or authalic radius, or radius of conformal sphere. Is it intentional?

[desruisseaux]

Hello @AndrewAnnex. I do not object against the inclusion of CRS using Pseudo-Mercator projection for the non-spherical cases. But I'm not sure that they are not missing their goal in the extra-terrestrial case.

I understand that the goal is to use existing software. The key aspect for that is simplicity, and Pseudo-Mercator is widely supported because it is simple. Without that projection, the normal process for using spherical formulas would be to first apply a datum shift from WGS84 to a sphere. Pseudo-Mercator tells to the software to ignore that step and apply spherical formulas anyway.

However the use of Pseudo-Mercator projection does not mean to ignore all datum shifts. It only means to ignore one specific datum shift, the one from the CRS's datum to a sphere. In EPSG:3857, that specific datum is WGS84. Because of WGS84 ubiquity, in practice it removes almost all datum shifts on Earth when the precision does not need to be better than a few meters. This is a key component of Pseudo-Mercator simplicity, because datum shifts are complex (often more than the projection itself).

However in the extra-terrestrial case, we have 2 or 3 datums per planet. A spherical case and an ellipsoidal case in two contexts (conversion between -ographic and -ocentric coordinates is not exactly a datum shift, but needs to be handled in a similar way). Existing software will not handle correctly this variety of datums (unless they are backed by a referencing engine advanced enough, such as PROJ or Apache SIS), and the use of Pseudo-Mercator may give a false sense of simplicity. Since I bet that many software will ignore that datum problem, the consequence is likely to be misaligned data.

If the decision is to include Pseudo-Mercator anyway, the series ending in 91 is well defined but the series ending in 92 seems problematic to me. All map projections in EPSG guidance notes are for geographic coordinates. I think that most of them are invalid for geocentric coordinates. In the particular case of Pseudo-Mercator it may still be valid because that projection uses spherical formulas, but this is an exception rather than the rule. Does the use of map projection on geocentric coordinates have been discussed somewhere?

[J-Christophe]

This "sphere" datum (for CRS ending in 90) is used to make enable the most interoperable definition for the body using mean radius. In the current file, the spheres seem to use the semi-major axis length rather than mean radius, or authalic radius, or radius of conformal sphere. Is it intentional?

@desruisseaux Good question about the radius of the sphere. I had a look in the comments in my code and I have several cases based on the table

• case 1 : mean = -1

Use R_m = (semi_major + semi_minor + axisb)/3 as mean radius. Use mean radius as sphere radius for interoperability.

• case 2 : semi_major == -1 or semi_minor == -1 "Use mean radius as sphere radius for interoperability

• case 3: semi_major < semi_minor: # Hartley case Use mean radius as sphere radius for interoperability.

• case 4: Triaxial case Use mean radius as sphere radius for interoperability

• case 5: semi_major == axisb and semi_minor == axisb # Sun or moon case (No approximation) mean_radius = mean

• case 6: Biaxial case Use semi-major radius as sphere radius for interoperability.

So for Biaxial case, it is written in the remark:

GEOGCRS["Mercury (2015) - Sphere / Ocentric",
    DATUM["Mercury (2015) - Sphere",
        ELLIPSOID["Mercury (2015) - Sphere", 2440530, 0,
        LENGTHUNIT["metre", 1, ID["EPSG", 9001]]],
        ANCHOR["Hun Kal : 20 W"]],
        PRIMEM["Reference Meridian", 0,
            ANGLEUNIT["degree", 0.0174532925199433, ID["EPSG", 9122]]],
    CS[ellipsoidal, 2],
        AXIS["geodetic latitude (Lat)", north,
            ORDER[1],
            ANGLEUNIT["degree", 0.0174532925199433]],
        AXIS["geodetic longitude (Lon)", east,
            ORDER[2],
            ANGLEUNIT["degree", 0.0174532925199433]],
    ID["IAU", 19900, 2015],
    REMARK["Use semi-major radius as sphere radius for interoperability. Source of IAU Coordinate systems: doi://10.1007/s10569-017-9805-5"]]

[desruisseaux]

If the use of semi-major axis as the radius is defined by IAU, then let it be. But if the choice is up to the planetary group, then maybe a better choice would be the authalic radius. An authalic radius is the radius of a sphere having the same surface than the ellipsoid. For a semi-major axis a and a semi-minor axis b, it can be computed as below:

f = 1 - b/a;
e = sqrt(2*f - f*f);
R = sqrt(0.5 * (a*a + b*b*atanh(e)/e));

Authalic radius is what EPSG often uses when they approximate an ellipsoid by a sphere (e.g. EPSG:7048 — GRS 1980 Authalic Sphere). In WKT definitions, ELLIPSOID["Mercury (2015) - Sphere", …] would become ELLIPSOID["Mercury (2015) - Authalic Sphere", …], thus making clear which sphere we are talking about.

[desruisseaux]

Support for EPSG:1026 in PROJ is already in the pipeline (Even has been quick!): https://github.com/OSGeo/PROJ/pull/3741

[AndrewAnnex]

@J-Christophe okay, so now I am understanding things a little better, but to me it sounds like the codes we have so far are not equivalent to NAIF's definition of 'ographic unless clon=180, and are otherwise equivalent to geodetic coordinates (geographic latitude, -180 to 180 longitude).

In that case then yes, the _91 codes would be the ones to use, as they would be using geographic latitude and -180 to 180 longitude (geodetic). But this is really easy to confuse with the other definition of geographic longitude and the current naming convention.

[J-Christophe]

In that case then yes, the _91 codes would be the ones to use, as they would be using geographic latitude and -180 to 180 longitude (geodetic)

I am not sure that we could say odetic in all cases because the sens of the ographic longitude could be different of the odetic longitude. Odetic longitude is always positive to east wheras ographic longitude depends on the rotation sens of the plane.

[desruisseaux]

Do we really need to associate axis ranges or axis directions to "-ographic" or "-ocentric" terms? To me, the only distinction that matter is the fact that "geocentric" measures angles from the center of the planet, while "geographic" uses a line perpendicular to the ellipsoid surface. Axis directions and ranges are independent concepts. Those concepts have (or will have) their own representations in WKT, so I think that they do not need to be associated to "-ographic" versus "-ocentric".

[J-Christophe]

Hi @desruisseaux @AndrewAnnex , I've updated the proposal https://github.com/opengeospatial/Planetary-DWG/blob/main/draft_crs_definitions/proposal001.adoc as defined in our last email. To resume our discussion:

• We keep only the code ending in 90 with a "Mercator (Spherical)" method, knowing that "Mercator (Spherical)" and "Pseudo-Mercator" are equivalent.
• We delete the other codes until the odetic CRS is defined.

Could you please check?

[desruisseaux]

It looks good to me, thanks! On a minor note, CONVERSION["Sun (2015) - Sphere / Spherical Mercator"] could be simplified as CONVERSION["Sun (2015) - Sphere / Mercator"].

[J-Christophe]

Thanks @desruisseaux. Proposal updated with your comment

[AndrewAnnex]

looks good to me @J-Christophe

[thareUSGS]

Back from holiday. Great discussion and method to move us forward. Looks good to me. +1

[J-Christophe]

Implemented in this release : https://github.com/pdssp/planet_crs_registry/releases/tag/v1.0.0