I didn't know that EPSG contained some engineering CRSs (it doesn't make so much sense to me, but that doesn't matter). I hope people do not start adding their own engineering CRSs, because that could definitely exhaust the IDs.

Will these new systems appear in the lists, either from projinfo or pyproj? That can be a problem for applications parsing the type from the json (I am thinking I will have to fix it in spatialreference. Probably I will not include engineering crss there).

Will these new systems appear in the lists, either from projinfo

yes, $ PROJ_DATA=data bin/projinfo --list-crs | grep Christma
EPSG:6715 "Christmas Island Grid 1985"

I hope people do not start adding their own engineering CRSs

I was thinking more of that being useful for a custom authority where people define their custom engineering CRS and a transformation to a more "standard" one.

a custom authority where people define their custom engineering CRS and a transformation to a more "standard" one.

That sounds like the derived projected I did some time ago, but in the database, not as wkt ;)

@ other maintainers: good idea / bad idea ?

@ other maintainers: good idea / bad idea ?

Could you elaborate a bit on the idea? I'm not sure I understand it. Is this a proposal to put the already included EPSG EngineeringCRS's under new authority? Or a mechanism for users to that themselves instead of going to the trouble of submitting stuff to the EPSG? If it's the last one, what would that look like?

Is this a proposal to put the already included EPSG EngineeringCRS's under new authority? Or a mechanism for users to that themselves instead of going to the trouble of submitting stuff to the EPSG? If it's the last one, what would that look like?

• This adds the database structure to register engineering datums & CRS, with content compatible of 19111 / EPSG / our C++ model
• This imports the few existing records from EPSG under the EPSG authority
• This adds missing bits in existing APIs to integrate EngineeringCRS in the same way other types of CRS (geographic, projected, vertical, compound) are already handled
• If anyone wants to customize their own proj.db with new engineering CRSs, they can of course. Or use the extra DB mechanism to union official proj.db with their supplemental one

That sounds like a description of this PR. I don't think any of it is controversial and can in my opinion be merged as is.

I was under the impression you were referring to a different idea, as hinted at by

I was thinking more of that being useful for a custom authority where people define their custom engineering CRS and a transformation to a more "standard" one.

but I must have misread that.

Just curiosity: do all the engineering systems in EPSG have a transformation associated?

do all the engineering systems in EPSG have a transformation associated?

apparently not. On the 15 added, only 3 have a transformation to a projected CRS.

My initial surprise was that EPSG had engineering systems in the database. For me an engineering system is the opposite of what EPSG is for. But it is there. If we want to replicate the structure of EPSG, it is ok to include them.

The use case of users customizing their database to add their own engineering systems, ok. And better if they add a transformation to a "proper" one (and we support that).
Having some "examples" already in EPSG to test the integration is definitely a good thing.

(and we support that).

I wouldn't bet my hand that it works for all transformations (as some of them might have expectations on the nature of the source/target CRS), but at least it works with "Cartesian Grid Offsets" and "Similarity transformation".