[PROJ] EPSG release once more busted

[SIMON Nicolas]

Hello,

Another aspect of the problem is the stability of the official definitions already in place.
For the Belgian Lambert 2008 projection (EPSG:3812), the EPSG has defined a new projection with epochs (EPSG:11219).
This is a good approach. However, the following problems arose:

- The definition of EPSG 3812 was modified by replacing geocs 4258 with a new geocs 12063.
- This is problematic because the transformations
BD72 to ETRS89 (1) (EPSG:1652)
BD72 to ETRS89 (2) (EPSG:15928)
BD72 to ETRS89 (3) (EPSG:8369)
were based on geocs 4258, and EPSG proposed a new mix of transformations
BD72 to ETRS89-BEL [BEREF2002] (1) (EPSG:1652) based on geocs 11063
BD72 to ETRS89-BEL [BEREF2002] (2) (EPSG:15928) based on geocs 11063
BD72 to ETRS89-BEL [BEREF2011] (3) (EPSG:8369) based on geocs 11215

As you can see, the EPSG codes (1652, 15928, and 8369) have been reused with new, inconsistent definitions, and in the process, EPSG:3812 no longer functions as originally defined.

Therefore, the new transformations associated with the new projections should be carefully defined without impacting existing systems, which, it should be noted, are the official geographic systems of our countries.

Sincerely,

Nicolas

-----Message d'origine-----
De : PROJ <proj-bounces at lists.osgeo.org> De la part de Martin Desruisseaux via PROJ
Envoyé : mercredi 22 juillet 2026 11:51
À : Javier Jimenez Shaw <j1 at jimenezshaw.com>
Cc : proj at lists.osgeo.org
Objet : Re: [PROJ] EPSG release once more busted

Hello Javier

Le 22/07/2026 à 11:26, Javier Jimenez Shaw a écrit :

> We are aware of the "geodetic" problems you mention. However Even is
> not referring to this kind of consistency problems. The problems we
> usually encounter are more related to the consistency "inside" the
> database. Fields that are wrongly filled that cause problems when a
> user tries to get information from the database.

Indeed, I encountered issues such as some unperseable dates in a column where the dates are stored as texts (maybe for storing dates with different precision). Those issues are annoying, but since they are relatively easy to adapt, I though that the reported inconsistencies were something else.


>  For instance (I don't know if this actually happened), the steps of a
> concatenated operation should be consistent with the operation itself.

I don't know if it was the case, but if the reported inconsistency was the source CRS of the concatenated operation not being the source CRS of the first step, and being instead the target CRS of the last step, then this is intentional. This is a way to specify that the *reverse* of the operation chain shall be applied. This is admittedly not obvious, and the ISO 19111 group also discussed about making that clearer.

     Martin

_______________________________________________
PROJ mailing list
PROJ at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/proj