Charts

[dacust]

Originally Posted by GPS-Marco

Hello,

KapGen beta05 is ready for download from my web site (well, its just a 2 pages site....).

Anyway download from here

Chages are: More practical use of the interactive mode (loops without exiting). Displays copyright information. Bug fix. The new CHARTCAL-V12 included with 115 Maps data.

Have a nice day. Marco.

Very nice! I'll add a link to it this evening. I'll steal some of your descriptions.

-dan

[cagney]

Well, I've been chewing those kiwi charts for a while, so it was refreshing this evening to find a slightly different menu .

As well as having a demo ENC cell the Aussies also have an "GeoTIFF Evaluation Sample Data Cell" available here.
Interestingly these tiffs are anti-aliased, while the kiwi charts are not. A really good feature for over-zoom fans .

You are nor allowed to use the sample tiffs for navigation, but I have no plans to go cruising around Heard Island anyway. If I ever planned such a destination, the Admiral would fire me

Thomas

[bdbcat]

Cagney/Marco.....

Marco and I have been having an email discussion regarding 1.3.5 georef performance for scanned charts with various patterns of REF points.

We have found that some patterns of REF points are unsuitable for the opencpn curve fitting algorithms. In most cases the right solution is obvious to the eye, but obtuse to the code.

I have about come to the conclusion that if the chart is really a Mercator projection, as most are, and has minimal scan skew (say 1-4 pixels), then 4 REF points will do an adequate job for any scale chart. In this case we can imagine that opencpn simply overlays an exact Mercator plotting sheet, if you will, on the chart canvas.

In fact, we could do it with just 2 (!) ref points. Optimally, we need a point near the center of the chart, and one more point at the same latitude on the right or left edge of the chart.

This is just what opencpn does today for 4 point solution. We search for the point nearest the center, and also find two points which are at the same latitude.

We use the center point as an "anchor" point, and the edge point to calculate the "pixels_per_meter" factor. Thats all we need for a Mercator overlay.
We can also handle DTM datum offset in this scenario.

Of course we still need 4 PLY points.

I have been testing this with hacked code. Seems to be OK as far as I have looked.

Comments?
Dave

[GPS-Marco]

Ciao Dave,

as you know I don't like too much making maps specifically for the OCPN algorithm. I like much more to find an algo in OCPN that handles all calibration patterns that can be found. Moreover I don't like making an algorithm that only work for perfectly scanned maps (not rotated, not distorded, same scale x and y, etc.).

Of course 2 points are enough if you know it's a perfect mercator map (not rotated by any angle, not distorted in any way) but those 2 points should be placed at the maximum distance apart for minimum error so opposite corners of the map should be the best choice. With those 2 points you can easily calculate the coefficients for mercator formula solving the following 2 linear systems for the 2 reference points.

x = Cx0 + Cx1 * Lon
y = Cy0 + Cy1 * ln(tan(pi/4+Lat/2))

This handles also a non perfectly scanned map were Cx1 != Cy1

Having 3 points (at the 3 corners) I'd solve the 3 coefficients linear problem (still considering the mercator correction for latitude) adding cross coefficients and with more points I'd still solve the linear problem at the least squares (3 coefficients). In fact 3 coefficients are enough to handle also rotated charts.

As you know, with many more refs (>9/12) I'd go for second order solution (if the problem is not ill-conditioned).

Ciao, Marco

[bdbcat]

Marco....

Good points, thanks for the comments.

1. Opencpn supports Mercator projections only. The assumption is pervasive in the code, so that some day we can more easily move to quilted and overlay charts. Scanned charts of any other projection will not ever display properly on opencpn, since we do not edit the raster bitmap in any way except by scaling uniformly in x and y. Further, the ratio between lat and lon scale is implied by latitude, so can never be properly displayed or georeferenced as a raster image if not scanned with equal scan resolutions in both dimensions. So, I can see no problem assuming that the scanned chart is a Mercator projection. If it is truly an unskewed Mercator, more REF points are simply redundant.

Skewed charts, whether intentional or not, are a different animal. Clearly for highly skewed charts which are common in the NOAA folio, cross terms are required. A cubic least squares match is probably best, as provided by BSB3. This of course requires carefully selected REF points.

Then we come to the small scale charts. Here, a 2nd order solution is not a good match to

ln(tan(pi/4+Lat/2)) + eccentricity terms

over large latitude ranges.

For the small scale NOAA charts with 100+ REF points, we fortunately have BSB3 coefficients.

It is a complicated problem in the general case.

Anyway, my overall opinion is this:
1. Third order solution is unreliable without careful manual checking. The solution may fail by exhibiting an inflection point between REF points, and so cannot be checked programmatically unless one assumes Mercator.
2. 2nd order solution is not better than Mercator solution for Mercator charts.
3. Slightly skewed Mercator charts probably should be handled by Mercator projection with linear cross terms.
4. Non-Mercator charts: probably 2nd order with 2nd order cross terms is the best we can do. If it is significantly different than Mercator, we need to signal a warning to that effect. For example, course lines in Routes and Tracks will not be straight lines....

For the difficult cases, another approach of course is to develop an interactive application that produces the full set of cubic coefficients for a scanned chart as used in BSB 3. In this case, opencpn will simply follow the wishes of the cartographer. No guesswork involved.


2. Not to quibble with the main point, but Lat equation needs eccentricity terms for small scale charts. Doesn't change the algorithm, just adds more complexity to the curve fit equations.


Still thinking, not coding yet
Dave

[cagney]

This is an interesting discussion. I'm learning a lot, but don't have that much to say in detailed technical matters.

We have found that some patterns of REF points are unsuitable for the opencpn curve fitting algorithms. In most cases the right solution is obvious to the eye, but obtuse to the code.

A more detailed explanation would be interesting. Describe the patterns please.

With the present algorithm I get a good fit with 4 REFs at 14S in scale 1:446,000 , NZ86. Trying a 4 REF points solution at 40.5 S in 1:200,000, NZ61, is a 'disaster'. NZ14605 40 S - ~79 S displays very good with the new 4 points small scale algorithm.
I can find a discrepancy of max ~ 0.6' of latitude.

I have found two kind of projections in the NZ charts, apart from Mercator, Transverse Mercator and UTM. These projections are used in rather large scale charts and don't seem to bad even though the are forced into a Mercator mold. The Transverse Mercator charts are often slightly skewed. An example, in NZ 4423 that is 1:20,000, the lower, southern part of the chart is
8 pixels shorter than the top.

When is a Mercator not a Mercator? Any way to determine this with the new solution?

So, let's try your suggested solution , Dave, and see how it works out.

Thomas

[bdbcat]

Thomas...
Could you send me your disastrous NZ61 4 point chart?

Thanks
Dave

[sinbad7]

WOWW!! Didn't know there was so many problems calibrating a scanned raster chart.
I have over the years scanned and calibrated literally hundreds of charts I have used on my many cruises in the North sea,the Baltic,Scandinavia,Germany,Holland,the English East coast and the English Channel without any obvious map errors.

The raster charts were either scanned from relevant parts of paper charts or prepared from downloaded raster charts or as screendumps of charts. I normally used .jpg format which I compressed before final calibration, using three points,avoiding similar lat and lon.

I have used a variety of nav progs with their own in-built calibration facility,my preferrence beeing Fugawi Marine ENC and have to date never put my boat aground.

In most cases,using the chart corners as calibration points simply were not possible as my charts were for the most cut outs and lacked the lat/lon graduation frame entirely. To also use the chart corners,it was neccessary to first do a three point calibration and later pick out the geo references of the corners from the calibrated chart.

What I am saying is it seemed so simple then and I did not realize what complicated programing had taken place beforehand in order to perfect the calibration feature.

[sinbad7]

Interesting AIS target from MT Jasmine Knutsen on her way across the Atlantic.
The data is relayed over permanently connected internet via satellite to Siitech's servers in Vancouver. Cheap satellite solution using equipment already onboard most modern ships today.

[st599]

Hi,

Where abouts in the OpenCPN code is the curve fitting done.

I've been playing with the idea of creating a bit of software to create BSB files, and am struggling with creating the WPX, WPY, PWX and PWY polynomials listed in libbsb as required in the header. The rest seem relatively easy to generate.

Stunning bit of software by the way.

Simon

[Psyches]

Originally Posted by sinbad7

Interesting AIS target from MT Jasmine Knutsen on her way across the Atlantic.
The data is relayed over permanently connected internet via satellite to Siitech's servers in Vancouver. Cheap satellite solution using equipment already onboard most modern ships today.

Cool. I don't often get to see the words "permanently connected internet", "satellite", and "cheap" in the same paragraph when referring to marine environs

Seriously, I do think that someday it will be common and cheap. At least I hope. About 10 years ago I had satellite internet in a rural area - can't say it was really reliable but it was fairly inexpensive (and the only access aside from ISDN or dialup - before WiFi existed). I'm not sure why it wouldn't be cheap now - maybe I just need an education?

Mark

[dacust]

Originally Posted by st599

Hi,

Where abouts in the OpenCPN code is the curve fitting done.

I've been playing with the idea of creating a bit of software to create BSB files, and am struggling with creating the WPX, WPY, PWX and PWY polynomials listed in libbsb as required in the header. The rest seem relatively easy to generate.

Stunning bit of software by the way.

Simon

You might want to look through the threads in this sub-forum. We have several people creating BSB charts in here.

• Some people have created them by hand, creating the header.
• Some have used MapCal and mc2bsbh.
• And then there's KapGen that is set up for a limited (but growing) set of charts.

Among other things, there are many things in the header that say they are required, but not needed. And if you use MapCal, it sets several things automatically while calibrating.

In various threads there is a lot of discussion about the header file.

And I can't resist the smart-ass answer - Try reading the thread you've posted in. It starts talking about the header file about the 2nd or 3rd post and continues on for a hundred posts...

-dan

[st599]

Originally Posted by dacust

You might want to look through the threads in this sub-forum. We have several people creating BSB charts in here.

• Some people have created them by hand, creating the header.
• Some have used MapCal and mc2bsbh.

I have used MapCal and have written them by hand - but don't really want to run wine and another plotter just to use this plotter.

I've got a Java GUI which you input data to and produces the .kap file, but what I haven't managed to do is create the polytrans coefficients used by libbsb:

static double polytrans( double* coeff, double lon, double lat )
474 {
475 double ret = coeff[0] + coeff[1]*lon + coeff[2]*lat;
476 ret += coeff[3]*lon*lon;
477 ret += coeff[4]*lon*lat;
478 ret += coeff[5]*lat*lat;
479 ret += coeff[6]*lon*lon*lon;
480 ret += coeff[7]*lon*lon*lat;
481 ret += coeff[8]*lon*lat*lat;
482 ret += coeff[9]*lat*lat*lat;
483 ret += coeff[10]*lat*lat*lat*lat;
484 ret += coeff[11]*lat*lat*lat*lat*lat;
485 return ret;
486 }
487
499 extern int bsb_LLtoXY(BSBImage *p, double lon, double lat, int* x, int* y)
500 {
501 /* change longitude phase (CPH) */
502 lon = (lon < 0) ? lon + p->cph : lon - p->cph;
503 double xd = polytrans( p->wpx, lon, lat );
504 double yd = polytrans( p->wpy, lon, lat );
505 *x = (int)(xd + 0.5);
506 *y = (int)(yd + 0.5);
507 return 1;
508 }
509

So my question is basically asking if the data is actually needed, and if so does anyone have a routine?

[GPS-Marco]

Hi all, here you can find a new chartcal.dir. It now contains 173 New Zeland charts data. Please use KapGen beta05 (if you don't have already) available at MCE66 - Software for MAP building. This new Chartcal.dir is available also at the above link as individual download.

The data base now contains all the:
NZ2*, NZ3*, NZ4*, NZ8*, NZ9*, NZ14*

Still not included are:
NZ5*, NZ6*, NZ7*

Let me know about errors, suggestions, etc.

Ciao, Marco.

[manimaul]

GPS-Marco,

Thank you very much for your hard work on the NZ georeferencing. I created every single bsb in v14 last night (12/2/2009). A couple observations:

1. Diffferent NZ22, md5sum has changed
2. 404 error on wgetting NZ223F & NZ224F (NZ223 and NZ224 are present however)
3. Different NZ4265, md5sum has changed
4. Different NZ4314, md5sum has changed

Thanks again,

Will