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
