added new projection function for Navionics Mercator

[mpasquini]

Hi all, thanks to everyone of you.

This is the adding of a really new and quite uncommon projection function called "Navionics Mercator"

The projection uses it's own fixed "KC" constant.
Changes are very few so long explanation seems to be not needed

It is expected to have an error (10E-5 degrees) using e_inverse,
something can be corrected using the '-w6' option while calling proj
For use and precision needed this is considerable acceptable.

Please comment and feel free to offend me, also using weapons if you like that way,
from my side I'm quite excited doing this thing...

Thanks.

[micahcochran]

Is there some documentation on this projection (such as a link)? Is it intentional that all four of the test points are exactly the same?

[coveralls]

Coverage decreased (-0.03%) to 72.362% when pulling 4b67ca7 on Navionics:develop into 933eaf7 on OSGeo:master.

[mpasquini]

Is there some documentation on this projection

I have a pdf documentation that I can share no links,
can you suggest a solution to correctly use the pdf ?
...meanwhile I can attach it here.

PJ_nav_merc_NAVIONICS.pdf

[micahcochran]

+a=6378388.0 +rf=297 could be replaced with the shorthand +ellps=intl. This is a slight preference.

Here is how I looked that up from the command line.

$ proj -le
[..snip..]
  helmert a=6378200.       rf=298.3         Helmert 1906
    hough a=6378270.0      rf=297.          Hough
     intl a=6378388.0      rf=297.          International 1909 (Hayford)
    krass a=6378245.0      rf=298.3         Krassovsky, 1942
    kaula a=6378163.       rf=298.24        Kaula 1961
[..snip..]

[coveralls]

Coverage decreased (-0.03%) to 72.362% when pulling 100a2d9 on Navionics:develop into 933eaf7 on OSGeo:master.

[busstoptaktik]

Could you elaborate a bit on the intended use of this? It seems to be an mercator-approximation with hard coded ellipsoidal parameters. What is gained by not just using proj=merc ellps=intl?

[mpasquini]

Hi, @busstoptaktik
Basically proj=merc ellps=intl it doesn't work for our projections.
I'm only a GIS tech but for what I've tested merc doesn't work.
For the rest I've translated to C the 2 set of function as for attached documentation, and chosen the most precise combination.
Looking at the code you'll see the KC constant used.. quite unusual? that my thought.

The initial intention, from the original developer, was to have a internal projection system compatible with our SDK and protect the data, now 17 years later doesn't make any sense. So we ask to move to open projects and become a little more standard.

[micahcochran]

What is gained by not just using proj=merc ellps=intl?

The calculations are close but there are 10s of meters difference for Y calculations comparing +proj=merc and +proj=nav_merc (using +ellps=intl). X is calculated exactly the same with Navionics Mercator as Mercator.

I assume that Navionics uses this projection for navigation charts and I, also, assume that Navionics is one of just a few companies in that market. Are their other maps or applications that is projection is used for?

This seems like a single use projection. calcofi seems to be another single use projection, which is really only applicable in one area for a handful of organizations. Satellite projections are single use, but many use that data.

Is there a better approach to accomplish this while maintaining precision?

[mpasquini]

Yes, it is. We cannot permit our clients to crash against marine rocks while sailing, worst case...
X is identical to +proj=merc.

We cannot. We have no proj4 at the moment, so we are forced to transform before market in half cases.
We are a few yes, Navionic (actually Navionics ) had a great part inventing a electronic cartography moving centered on a GPS point.
Actually only Global Mapper 16+ and my personal postgis are capable to use nav_merv.

Most of the projections have limitations or specific usage.

I don't know if there is, for what I've tested there isn't.
In any case, we cannot tolerate 10s meter erros.

Thanks.

[cffk]

I'm sorry to see that PJ_nav_merc_NAVIONICS.pdf has a bogus
interpretation of the Mercator projection (Figure 9 in Section 3).
Mercator is not a central projection onto a cylinder!

[micahcochran]

@mpasquini You answered the questions to my satisfaction.

Is there a better approach to accomplish this while maintaining precision?

That question was not specifically directed to you. I was asking everyone if there is a better approach.

Actually only Global Mapper 16+ and my personal postgis are capable to use nav_merv.

So, if nav_merc were to be integrated into the PROJ.4 repository, it would be a projection that would be usable in GDAL, PostGIS, and other projects that rely upon these libraries (QGIS).

[mpasquini]

... whatever,
thanks for support.

[kbevers]

Closing this, since the submitter has not responded with further information as requested on the mailing list.