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 < [email protected]> 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 > [email protected] > https://lists.osgeo.org/mailman/listinfo/proj >
_______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj
