Hi, On 27/10/2025 14:11, Regina Obe wrote:
I vaguely recall someone complaining about this 15 years ago, but not since then.
I guess the ones complaining at the time was because French IGN defined their own SRS and chose for very unknown reasons to allocate their own reeeeaaaaaally long SRID, therefore not compatible with PostGIS limitations. And in the end there was a lot more complaints against IGN for doing that, than against PostGIS for its limitations. I do not know who your authority is, but there is a good chance that it is easier for them to change their ID than PostGIS to lift the constraint, given the consequences. Good luck with that though. Vincent
Paul can better speak for the reason, but I think it was because we needed to fit it into the header of the geometry and still have enough bits left for the geometry type etc and 2 bits extra for growth. So I would say it’s very unlikely we’d lift this restriction. *From:*G. Allegri <[email protected]> *Sent:* Monday, October 27, 2025 5:46 AM *To:* [email protected] *Subject:* Why PostGIS sets a max value for SRID IDs? Hello list, I'm working on two projects where custom CRSs, with custom authorities and IDs are provided. Both projects use IDs with numbers beyond SRID_USR_MAX=998999 [1], which is hardcoded in PostGIS for the spatial_ref_sys id field values. I can use the auth_id, of course, but having to reassign an id < 998999 is a bit problematic for two reasons: - I have custom transformation pipelines defined inside the proj.db, where the custom IDs are defined for CRSs. - other softwares (QGIS, Geoserver) can use the custom IDs but they cannot match the geometries SRIDs returned PostGIS I wonder if there's a technical reason for the SRID_USR_MAX constant, and if there's any change to remove it in the future. And I wonder if others have faced the problems I'm having due to this, and what are the solutions they came up with. Thanks, Giovanni [1] https://github.com/postgis/postgis/blob/5dc95f1bc3047b048128616d4543b603b8bbdca7/configure.ac#L1554
