[Proj] Proj Release

[Roger Bivand]

Frank Warmerdam <warmerdam <at> pobox.com> writes:

> 
> On 12-02-20 05:04 AM, Jeff McKenna wrote:
> > On 12-02-09 3:40 PM, Smith, Michael ERDC-CRREL-NH wrote:
> >> Frank,
> >>
> >> I would like to request a Proj release in the next couple of months. We
> >> are going to be doing security testing of our Lidar system which makes
> >> use of trunk proj for PDAL. I'd imagine that we will have a much easier
> >> time having a released version.
> >>
> >
> > Regular releases of Proj would also help package maintainers.
> 
> Jeff / Mike,
> 
> I have made a pass through the open PROJ.4 tickets and taken action on most
> of the recent ones.  I'm hoping to get some feedback on a couple of them.
> 
> Two outstanding issues I'd like to address before a final release:
> 
> 1) Resolve whether it is appropriate for us to have switched from using
> +datum= to a detailed definition in the EPSG init file.  The GRASS folks
> have raised cain (cane?) about this.

I certainly feel that this change is premature. All I can see on the web page is
a note that "refinement of datum shifting support" may happen sometime. I don't
think that removing a functioning mechanism used by many - not just in GRASS,
also in R/rgdal - without clear RFC handling, and without fallbacks or
transitional mechanisms - is justified. What will happen is that a release of
PROJ now, without this "mistake" being corrected, will mean that scripts running
a given +init=epsg:<> may end up with different results, not because the current
EPSG file is buggy and needed fixing. When spatial data are used analytically,
as in the GRASS and R communities, reproducibility really does matter.

I suggest that this needs an RFC, and should be held off until some 4.9.0, if
the RFC process concludes that switching from +datum= is on balance justified.
The alternative is to advise users to stay on 4.7, but many cannot control their
build trains well enough for this to be feasible.

Roger


> 
> 2) Build internal handling for +nadgrids=@null.  It seems most of the
> performance problem Thomas was seeing with projections in mapserver related
> to using an actual file for this null transformation.
> 
> I see it has been around 2.5 years since the last release.  My, how time
> flies.  Anyways, I have prepared a snapshot of the current state for those
> willing to do some quick testing:
> 
>    http://download.osgeo.org/proj/proj-4.8.0b1.tar.gz
> 
> Best regards,