Charts II: NGA - 2700 Charts

[recri]

Something very odd is happening with 76071, Wellington Harbor. The coordinates look right and the corners look right. It's rotated in the image but the chart area is rectangular by my tests. But aspect ratio is way off, and the kap looks very odd in opencpn, latitudes correct only at the N and S edges, longitudes coming in and out of registration as you scroll around.

Is it a transverse mercator, even though labeled as a mercator?

[cagney]

Originally Posted by recri

Something very odd is happening with 76071, Wellington Harbor. The coordinates look right and the corners look right. It's rotated in the image but the chart area is rectangular by my tests. But aspect ratio is way off, and the kap looks very odd in opencpn, latitudes correct only at the N and S edges, longitudes coming in and out of registration as you scroll around.

Is it a transverse mercator, even though labeled as a mercator?

Why bother with 22 year old charts when fresh NZ charts updated in May this year (for Wellington) is readily available. All US charts for this area are based on NZ charts anyway. I suggest that we skip the NZ and SW Pacific area covered by NZ charts. Thanks to GPS-Marco, the NZ charts are kept updated regularly, when new releases or editions are available.

The same really holds for Brazilian charts, but I can understand if some people prefer English language charts.

Thomas

[HappySeagull]

I 've been wondering about that too.I guessed it explains why these areas are lagging in completion.

[recri]

Originally Posted by cagney

Why bother with 22 year old charts when fresh NZ charts updated in May this year (for Wellington) is readily available.

Because I want to be confident that our chart entry procedures and the chart conversion software really work. When they don't work for something as unlikely to be a bad chart as Wellington Harbour, it makes me nervous.

That there are high quality New Zealand charts is an opportunity to enter the NGA charts and compare the conversion results to a high quality chart.

Of course if we wanted comparisons to high quality charts, we could enter a sample of NOAA charts from Index of /OnLineViewer, assemble the chart images from tiles, put them through web calibration, produce the kaps, and compare them to the NOAA BSB's.

That would be a waste of time, of course, simply reproducing high quality charts that are already available for free, but some people might be interested to see how the exercise turns out.

[recri]

NGA 2700 chart summary for Wed Sep 28 22:19:28 GMT 2011
processed: 1612 charts, evaluated: 1606 charts
pxhoriz: mean 1.00009 stddev 0.00116
>10*sd: 43101 (1.02285) 43064 (1.02096) 43263 (1.01462) 43161 (1.01381) 43371 (1.01295)
>9*sd: 43343 (1.01084) 43344 (1.01082)
pxverti: mean 1.00000 stddev 0.00036
pxsquare: mean 0.99999 stddev 0.00028
ratio: mean 1.00476 stddev 0.02052
>25*sd: 73271 (0.41599) 38630 (1.56405)
notdone: skipped 1 charts: 43041
notmercator: skipped 5 charts: 17421 18419 43378 56191 76181

I got tired of looking at all the cruft I was posting, so here's a new format. These are the charts which are more than 1% out of square, the ones with big problems are usually much further out, like 73271 and 38630 on the 'ratio' test. The (value) next to the chart number is its actual score on the test. Perfect charts would score 1.000000000 on all four tests. If a chart gets checked and marked as okay, then it will have a * next to its number if it gets listed again. I'm measuring the transverse mercator charts now, too, so there are only a handful of notmercator not included in the statistics. 43378 turned out to be Gauss Conformal Cylindrical projection, which is another name for Transverse Mercator.

[recri]

38630 - corrected two misprinted corner coords
43064 43101 43161 43263 43343 43344 - all look ok
73271 - corrected corner coord, ok
73471 - corrected corner coord, 10" correction to lng apparent, ok
73481 - corrected corner coord, ok
76015 - corrected corner coord, ok
76071 - misprinted north edge lat, repeated 3 times, ok
92260 - corrected corner coordinate, ok
92429 - corrected to not doable non-rect composition, ok

43041 - entered corner coords, wonky
43371 - adjusted corner points, wonky

The problem with the Wellington chart was that the N edge coordinate was misprinted, in the NE corner, on the left chart edge, and on the right chart edge.

43041 and 43371 are northern Norwegian in transverse mercator, both are more or less right, but the opencpn parallels bow away from the chart parallels and the chart edges.

[HappySeagull]

sometimes,the corner positions are outside the insets...
(Chart 92420)

[recri]

I corrected corner coordinates on 93022 and 43063.

I marked a few Lambert Conformal Conic up in Greenland as "meaningless to calibrate" like the large Transverse Mercators up there. When the meridians and parallels start coming out as curves, opencpn won't be able to display it.

[recri]

NGA 2700 chart summary for Fri Sep 30 16:26:58 GMT 2011
processed: 1705 charts
evaluated: 1701 charts
pxhoriz: mean 1.00021 stddev 0.00193
pxverti: mean 1.00000 stddev 0.00037
pxsquare: mean 0.99999 stddev 0.00028
ratio: mean 1.00597 stddev 0.04965
>25*sd: 93030 (3.04907)

A lot of the 43xxx charts are showing up as outliers on pxhoriz, but they all look okay.

[recri]

Someone mentioned simply applying a datum correction to the chart corners, as opposed to entering it as a datum correction.

93022 looks like the NGA did that: the corners look to be exact minutes on the edge graticule, but the corner coordinates are printed with a seconds correction, and when you load the KAP into opencpn, the opencpn grid misses the map grid by seconds.

[phiggins]

Regarding the datum adjustments, unless you only want these charts to work on OpenCPN, you need to put GD=Local as well as the DTM/ data in the KAP header. Only OpenCPN will accept just the DTM data, other navigation programs such as Fugawi and SeaClear will ignore the DTM data without having GD=Local.

[phiggins]

Chart 93022 should have a DTM/46.140,5.940 . Even though the chart doesn't indicate this its off by this amount. A lot of the charts in that area are off quite a bit and need to have DTMs.

[HappySeagull]

Originally Posted by recri

Someone mentioned simply applying a datum correction to the chart corners, as opposed to entering it as a datum correction.
etc.....

...I think that's how my old Canadian charts were done....the Refs are adjusted.(they didn't use just corners though)to WGS.There's no DTMs despite many charts many being "Datum NAD1927".OpenCPN's grid reflects this,versus the inked Lat Long.

[z.stadler]

I'm getting this error:

'Corrects Chart Datum to' is set to 'other' - please enter the datum the chart is corrected to (required)."

although I've entered the "other Datum".

Chart 93047 has this note:

TO THE NAVIGATOR
Operational Datum Adjustments
To position Luzon coordinates on this chart:
Subtract 04.06 seconds from Latitude.
Add 04.45 seconds to Longitude.

Which I've tried to capture like this:

A similar note exists on chart 93044.

Am I doing something wrong or is there an issue with the validation checks on the server?

P.S., in the mean time, I've saved it with a "No DATUM NOTE given on chart"

[recri]

NGA 2700 chart summary for Sat Oct 01 16:42:02 GMT 2011
processed: 1793 charts
evaluated: 1784 charts
pxhoriz: mean 1.00027 stddev 0.00212
>10*sd: 43081 (1.02339) 43083 (1.02302) 43062 (1.02300) 43101* (1.02285) 43058 (1.02283) 43082 (1.02214) 43063 (1.02201)
>9*sd: 43064* (1.02096)
>7*sd: 43041 (1.01666) 43084 (1.01616) 43122 (1.01615) 43123 (1.01572) 43121 (1.01553) 43141 (1.01514)
>6*sd: 43142 (1.01501) 43265 (1.01482) 43263* (1.01462) 43161* (1.01381) 43202 (1.01313) 43126 (1.01307) 43371 (1.01304)
>5*sd: 43204 43225 43264
>4*sd: 43343* 43344*
pxverti: mean 1.00001 stddev 0.00059
>25*sd: 43143 (1.01974)
pxsquare: mean 1.00001 stddev 0.00049
>25*sd: 43143 (1.01704)
ratio: mean 1.01750 stddev 0.49416
>25*sd: 43264 (21.77725)
>4*sd: 93030
notmercator: skipped 9 charts: 17421 18419 43186 43249 43252 43262 43285 56191 76181

Most of the northern Norwegian charts have been pxhoriz outliers, so I haven't bothered to mention them after checking some of them.

But it looks like 43143 and 43264 may have another problem.