[PROJ] EPSG release once more busted

[Javier Jimenez Shaw]

Hi Martin.

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. For instance (I don't know if this actually
happened), the steps of a concatenated operation should be consistent with
the operation itself.

We have the impression that EPSG is not running consistency checks (or not
enough). PROJ is an open source project, they can just go there an see what
we do... and copy it! (and even improve it ;) Their developers will be much
more relaxed modifying their database knowing they have a safety net
looking for mistakes. Not every possible mistake, but a lot of them.

Our consistency check script is
https://github.com/OSGeo/PROJ/blob/master/data/sql/consistency_checks_triggers.sql


Note that those tests are implemented once and run many times. It is a
great investment of time!

Cheers
Javier.

PS Another issue is that EPSG is publishing the database to the public
without any "release candidate". So we report them those issues once they
are official. But in any case, if they do release candidates, they should
also be consistent.



On Wed, 22 Jul 2026 at 01:24, Martin Desruisseaux via PROJ <
proj at lists.osgeo.org> wrote:

> Le 21/07/2026 à 21:43, Even Rouault via PROJ a écrit :
>
> > I'm trying to integrate the latest EPSG 12.059a release and there are
> > *again* consistency errors. Not necessary big deals, usually I deal
> > with that directly with them in a diplomatic way, but I'm fed up of
> > that. What kind of pressure can we apply on EPSG so they implement
> > them on their side ? I've pointed them multiple times to our sql
> > scripts but it seams to fall on deaf ears.
>
> Disclaimer: I'm not a member of the EPSG team, but I'm regularly in
> touch with an EPSG maintainer in the context of ongoing ISO 19111 revision.
>
> EPSG is in a position between developers and mapping agencies. I do not
> know for 12.059a, but some issues reported as inconsistencies in
> previous versions were actually explicit demands from mapping agencies
> rather than errors. For example, there is the case of a missing epoch
> for the CRS of a northern country (I forgot the details, sorry). It was
> not an EPSG error, but a demand of that mapping agency who felt that in
> their particular case, providing a single epoch would be misleading and
> preferred to provide none rather than a misleading information. This
> case has been discussed at length during the meetings of the ISO 19111
> revision group a few months ago. The EPSG representative reported that
> they were struggling about how to conciliate both developer's grief and
> mapping agency concern in same time, and the group was considering
> whether a change of ISO 19111 model would help.
>
> The vast majority of the debate in the ISO 19111 group is about how to
> improve our representation of the physical world, and whether a
> perceived "improvement" of ISO 19111 is really correct. After an
> agreement has been reached on geodesic grounds, the translation into
> data structures (UML of classes and attributes) tends to be quite
> consensual. While I do not know the internal of EPSG team work, I think
> that they also focus mostly on the geodesic content, maybe at the cost
> of compromises when a particular case does not fit nicely in the
> database schema. I think that the bar for changing the schema is also
> quite high, a little bit like changing a public API.
>
>      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/20260722/7c6d65f1/attachment-0001.htm>