Stop relying on private projects.h PROJ header

[strk]

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.

[strk]

I've checked: 1.4 and 1.5 are immune

[strk]

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

[mcayland]

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

[pramsey]

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+?

[pramsey]

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.

[strk]

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.

[pramsey]

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.

[pramsey]

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.

[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.

[strk]

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

[pramsey]

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.