Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1541 closed defect (fixed)

Stop relying on private projects.h PROJ header

Reported by: strk Owned by: strk
Priority: high Milestone: PostGIS 2.0.0
Component: build Version: master
Keywords: Cc:

Description

It looks like we've been relying on a private PROJ4 header file for years: projects.h.

The public one is proj_api.h.

An install of current PROJ trunk doesn't even contain projects.h.

More info: http://trac.osgeo.org/osgeo4w/ticket/34

It looks like this was fixed in 1.4 some time ago, see #126

Would be also worth double-checking current 1.5 and 1.4 branches.

Change History (12)

comment:1 by strk, 12 years ago

Component: postgisbuild/upgrade/install
Owner: changed from pramsey to strk
Priority: mediumhigh

comment:2 by strk, 12 years ago

I've checked: 1.4 and 1.5 are immune

comment:3 by strk, 12 years ago

It looks like spheroid_init_from_srid is needing the PROJ internals (source:trunk/libpgcommon/lwgeom_transform.c?rev=9036#L727)

comment:4 by mcayland, 12 years ago

I think we know all of this already; it's something Paul introduced in trunk for #1538 - see the ticket there for more details.

comment:5 by pramsey, 12 years ago

I talked to Frank about this yesterday, and he had no solutions.

See http://trac.osgeo.org/proj/ticket/142

Turns out even the API routine that is supposed to access the internal information doesn't give us the spheroid parameters.

For our purposes, can we retain projects.h for proj ⇐ 4.7 and switch to using only proj_api.h for proj 4.8+?

comment:6 by pramsey, 12 years ago

OK, so here's my proposed solution: For the upcoming proj 4.8, which I will cross my fingers and hope for a legal spheroid accessor API, we'll do full SRID support as currently implemented, but using a public API. For earlier proj releases, which do not have a public API, we have two choices: (a) continue to use the private projects.h header and reading out of the PJ struct for spheroid information. (b) continue to accept SRIDs other than 4326, using the pj_is_latlon method to test that they are geographic systems, but we will fill in the spheroid using the WGS84 parameters, while issuing a notice warning of what we're doing, and only use the public proj_api.h.

comment:7 by strk, 12 years ago

My main goal here is building postgis against proj-trunk, due to a fix in handling gridshift files.

Trunk advertises self as 4.7.1, not 4.8, but already installs without projects.h. Not sure if that's intended.

comment:8 by pramsey, 12 years ago

Not sure what the final version of trunk will be, though I would guess something like changing the API would warrant a larger version bump than 4.7.1. Regardless Frank *does* intend to stop installing projects.h so for trunk support we need to have an API to spheroid info, but there's a ticket on that. The question is what to do for earlier versions of proj. To disable the spheroid SRID support, or to use projects.h.

comment:9 by pramsey, 12 years ago

Resolution: fixed
Status: newclosed

OK, so the fix is in at r9108.

The idea is, for proj ⇐ 4.7 we'll accept any geographic SRID, but fill it in with WGS84 information.

For proj≥4.8 we'll cross our fingers and hope for an API call, which we can fill into that slot when it arrives.

comment:10 by mcayland, 12 years ago

My only concern with this ticket is strk's comment that PROJ.4 trunk is still advertising itself as 4.7 - does this mean we have no other way of determining whether someone is using trunk at the moment other than checking for the existence of projects.h? Can we ask Frank to bump it to 4.8 or 4.8SVN or similar? This would make me feel a lot more comfortable.

comment:11 by strk, 12 years ago

As of current trunk postgis builds fine with PROJ trunk and 4.7.0. Any problem left ?

in reply to:  10 comment:12 by pramsey, 12 years ago

Replying to mcayland:

My only concern with this ticket is strk's comment that PROJ.4 trunk is still advertising itself as 4.7 - does this mean we have no other way of determining whether someone is using trunk at the moment other than checking for the existence of projects.h? Can we ask Frank to bump it to 4.8 or 4.8SVN or similar? This would make me feel a lot more comfortable.

It means that until a proj is release with a larger version number we'll treat it as if it was 4.7. Which just means we won't try to look for any new spheroid access API calls that happen to get added (they haven't yet). Which would be a shame, but at least on release everything would work, and in the meantime as Sandro notes everything works.

Note: See TracTickets for help on using tickets.