Opened 2 years ago
Last modified 2 years ago
#5188 reopened enhancement
heads-up: PROJ_LIB is now deprecated (use PROJ_DATA instead)
Reported by: | jmckenna | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS PostgreSQL |
Component: | postgis | Version: | 3.2.x |
Keywords: | windows | Cc: |
Description
- PROJ_LIB will now be deprecated, and PROJ_DATA should be used instead
- see PROJ changes at https://github.com/OSGeo/PROJ/pull/3253
- I believe some builds of PostGIS point to PROJ_LIB
- likely both PROJ_LIB and PROJ_DATA should be checked, for now (similar to how MapServer will handle this, see https://github.com/MapServer/MapServer/pull/6573 )
- the big change will be part of the upcoming PROJ 9.1 release, but it's good for all projects to be ready for this
Change History (4)
comment:1 by , 2 years ago
Milestone: | PostGIS 3.2.2 → PostGIS 3.3.0 |
---|
comment:2 by , 2 years ago
comment:3 by , 2 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
I think that was needed in some CI when GDAL needed to know the PROJ_LIB. Since GDAL 3, which requires direct binding, that lib path I think is ignored. But anyway not a PostGIS issue.
comment:4 by , 2 years ago
Keywords: | windows added |
---|---|
Milestone: | PostGIS 3.3.0 → PostGIS PostgreSQL |
Resolution: | worksforme |
Status: | closed → reopened |
Agree though that is a packaging concern, So I'll move this to packaging since I think I need to make changes to the windows packaging which tries to register PROJ_LIB.
Note:
See TracTickets
for help on using tickets.
Did a quick code search and only found PROJ_LIB in a CI script, one time. I think it's something people use in packaging scripts maybe? The start-up environment might sometimes want to have it?