[Proj] Navionics projection

[Charles Karney]

On 08/23/16 10:23, Howard Butler wrote:
>
> On Jun 9, 2016, at 8:02 AM, Kristian Evers <kreve at sdfe.dk> wrote:
>
>> #389: +1 on the NOMERGE. The discussion on github makes it clear to me that this is a projection that is made specifically for one particular older proprietary software package which is not in widespread use (so it seems to me at least). On top of that the documentation of the projection is not very good or publicly available (apart from a PDF attached to the github discussion). The submitter of the PR has not been able to explain what the benefits of merging his additions are, except for making it easier for the Navionics company to maintain their codebase.
>>
>
> Matteo,
>
> https://github.com/OSGeo/proj.4/pull/391#issuecomment-241672732
>
> I understand your frustration. Please know that the consensus seems to be to not include the Navionics projection for this release for a number of resolvable reasons:
>
> 1) It is a proprietary projection that appears to be single-use within the context of Proj.4's ecosystem. There is some question about its rigor and validity, but that is beside the point considering it is in use already.
> 2) It is unclear if there is a lot of public-readable data at rest in this coordinate system
> 3) It is unclear who is benefitting by its inclusion in Proj.4 beyond Navionics
>
> The first one is for the Proj.4 project to consider. Do we allow single-use projections? Inclusion of a projection into the codebase assumes the project is responsible for maintaining it going forward. As Thomas and Kristian recently experienced, there are a lot of these if you have to touch them all.
>
> The second one is for Navionics to answer. Are there (or will there be) open source software for reading data in Navionics format(s) that makes open source support of its projection a significant convenience factor for users?
>
> The third is related to the second. Is the inclusion of this projection is simply to ease Navionics use of proj.4 and maintenance of its software stack? If so, it seems too special for inclusion. If it is to ease the transition of letting users' data out of proprietary formats and access to that data to the open source ecosystem, the case for its inclusion is stronger. The ticket traffic on this aspect is ambiguous.
>
> If there is some consensus after more discussion, it is still possible to include this projection into the codebase in a future release. We want to be careful about tossing proprietary projections over the wall into Proj.4 without clear external use cases and when they appear to be single-use in the context of Proj.4 and its ecosystem.
>
> Howard
>

I've read the document on the Navionics projection.  (I've already
criticized this document for giving a false description of the Mercator
projection.)

It seems that this "projection" is a true forward projection (from
geographic to Mercator), but substitutes an approximation for the
reverse projection.

The motivation for the approximation is not clearly spelled out --
perhaps it's to save CPU time, or perhaps whoever formulated the
projection didn't know how to invert it.  However, nowadays, I would say
proj.4 should err on the side of providing accurate results -- in
particular it should normally aim to have the round-trip error close to
zero.

Introducing a new projection inevitably incurs some ongoing maintenance
burden and so should be only be accepted it is meets some real need.
This projection, being a crippled version of Mercator, doesn't make the
cut.

   --Charles