Charts II: NGA - 2700 Charts

[paulr]

I have been (rather randomly) checking 'finished' charts for various problems using the project stats output in Excel.

Soundings datums:

Half of the MLLWS turned out to be MLWS

Most of the inputs referencing some form of High-water-based datum were incorrect. Either misselections from the dropdown or misreadings of the chart.

There are a substantial number of "other: Indian Spring Low Water", so this would be a useful preset option in the dropdown. Conversely, other selections in the dropdown have not been used much or at all: MLLWN, MLWN, HAT, HHWLT (this has been set several times by mistake for LAT, the next one in the list).

A little rationalisation of the options in the soundings datum dropdown would help accuracy.


Scale/Scale at:

For scales 100,000+, i.e. small-scale charts, the absence of a "scale at" latitude is rare. A number of the DB entries were missing this, even though clearly on the chart. Perhaps worth reinforcing this in the manual.

Paul

[bcn]

Originally Posted by paulr

I have been (rather randomly) checking 'finished' charts for various problems using the project stats output in Excel.

Soundings datums:

Half of the MLLWS turned out to be MLWS

Most of the inputs referencing some form of High-water-based datum were incorrect. Either misselections from the dropdown or misreadings of the chart.

There are a substantial number of "other: Indian Spring Low Water", so this would be a useful preset option in the dropdown. Conversely, other selections in the dropdown have not been used much or at all: MLLWN, MLWN, HAT, HHWLT (this has been set several times by mistake for LAT, the next one in the list).

A little rationalisation of the options in the soundings datum dropdown would help accuracy.


Scale/Scale at:

For scales 100,000+, i.e. small-scale charts, the absence of a "scale at" latitude is rare. A number of the DB entries were missing this, even though clearly on the chart. Perhaps worth reinforcing this in the manual.

Paul

Taking note!
Hope to pull in the next days an update of the manual together.

Hubert

[recri]

I've been puzzling over the mess of overprinting in the corners since my first post, and I've finally decided that it's just a mess.

What I think is that the multi-pass printing presses were set to overprint all the colors on the corners so they could check the four corners to see if all the colors were properly registered. They'd print a test sheet, check the corners for registration, and realign the plates until it was close enough. When the charts get scanned at 300dpi, or whatever, and then magnified 10x, close enough is often a horrible mess.

The true corner is in there. It is where the edge lines meet and we want to position the REF point at the inside of the true corner. But there are charts where there's nothing but overprinting visible in the 10x positioning window and you have to guess where the edge lines lie in the mess.

If the chart edge lines don't match well when you proof a chart in opencpn, then it may be that you need to tweak a corner REF point location. But it's also possible that the corner lat/lng coordinates are off, since opencpn computes the chart outlines using both the lat/lng coordinates and the REF point pixel locations.

Any other theories?

[HappySeagull]

mmm.Some are very hard to be happy with.Not sure exactly how they scanned these or all that went between(zoomify etc.) 'til we have the jpegs-But I rely on the "outside" marks and the diagonal,too,where I can,which I like to get centred(aimed) to my crosshairs.Then,there's the problem of the lines themselves not being straight across the chart..jagged.so I have to refer to the linked NGA image....Looking for a really heinous example but quickly,l find this:




Note i had to zoom in on the NGA image to make up my mind!and could still be wrong...
It was tempting me to watch the calibration pixel numbers and try to get em to match better but I think Nohal would say NO!(and he'd be right of course)It's too much thinking anyways
PS
I see these same marks on other chart sets I have,but the overprint of colors is a good theory!Likely the original digital charts had the same problem to contend with,using scans

[HappySeagull]

this is a different corner same chart,shown for interest but I wanted to show the pixel numbers too,which I do glance at as I'm going to see just how "off" the chart may be.But I don't adjust the chart to make them agree.

[Tia Bu]

How much difference are you guys talking about in the real world? Remember, we're talking about graphical representations of a wind-blown, moon-pulled fluid washing over shifting sand and mud-- to be used in the field by seasick, sleep-deprived human beings.

EVERY time I get in trouble navigating, it's because I THINK I know my location too precisely.

For what it's worth...

[bcn]

My interpretation of the marks is different:
they don't stem from printing, they are marks for scanning the charts - a first indication of how many mm the scan will be off as well.
You will find charts - from 200x on - that do not show those "ink drops" at all. Most probably these are vector charts transformed into pixelelated/bitmap charts.
And when you get the pixel co-ords for this charts they are exactly on pair - pure logic..

That is then I'm going philosophical about the nonsense detour we have to take to have a public knowledge at hand.

Hubert

[r.fairman]

i think we in danger of contemplating our own pixel navels.exactly what errors or we talking about if we are a few pixel off due to poor scanning printing. for each scale of chart for 1 pixel error what does this mean in terms of meters. Our GPS already has an error which we accept and are aware of. Are we trying to seek an accuracy of better than the GPS. This make us feel smug but liitle else.These are paper charts what accuracy would we get plotting using transits. I seem to remember the triangle of uncertainty from my navigation training days.

Regards

Richard

[HappySeagull]

After scrutinising 600+ corners,I am a connoiseur of corners.

[HappySeagull]

anyways,I like recri's take.I have the originals of some of these in "original" colours.But the actual charts and borders would be black ink.These are the copies (the meat)from US allies,mostly British Commonwealth.The text and badges,a black overlayby the US.The loran/omega UTM and buoys,lights,purple,corrected as the US sees fit.The shoals,land etc another colour(differing from the source country's livery and even normal US colour).

It's just the borders,soundings and coastlines that are copies.The rest are overlays by the US printers.
These are likely considered study charts to plan CIA pecadillos..

[recri]

Here's the new statistical summary report intended to explain itself, so I'll explain it.

I scan the database at a particular time pulling all the charts with status that makes sense to check. Some of these get skipped for various reasons and the rest get evaluated. The ones that get evaluated get ranked by how far they are from the population mean and the ones beyond 3 standard deviations are listed, those furthest from the mean first.

One of the reasons to be skipped is the censored list which I've been building up by checking charts. If a chart gets listed as an outlier but I can't find any error in data entry, then it gets added to the censored list so it won't get called out again. Either there's a subtle data entry error, or I'm getting tired, or the chart is just plain crooked.

Suggestions for improving the report and candidates for the censored list are welcome.
-----
NGA 2700 chart summary for Sun Sep 18 20:48:57 GMT 2011
processed: 1277 charts
evaluated: 1194 charts
pxhoriz: mean 1.00001 stddev 0.00047
>5*sd: 43263
>3*sd: 92030
pxverti: mean 0.99999 stddev 0.00018
>5*sd: 91407 29325 83039 91030 61003 82025
>4*sd: 91096 83105 82534 83495 91060
>3*sd: 53290 56190 22533 71018 92140 24444 53287 301 53266 701 524 43340 81796
pxsquare: mean 0.99999 stddev 0.00020
>5*sd: 92140
>4*sd: 91096 61003 83392
>3*sd: 82025 92030 83020 29325 63361 82304 63354 91020
ratio: mean 1.00484 stddev 0.00246
>5*sd: 92100 92060
censored: skipped 59 charts: 62 70 105 121 124 125 145 521 522 526 532 623 707 800 21141 21161 21621 21641 22314 22404 22440 22528 22541 22542 22549 23051 23121 24511 26125 29282 29322 29324 37242 54289 54303 57022 63015 71009 73034 74024 76201 81145 81303 81329 81511 81563 81565 81576 81729 81737 81791 82384 83052 83218 83555 91314 91326 92025 96036
notmercator: skipped 24 charts: 14221 17421 18419 24055 28164 29323 43064 43344 43363 43371 43377 43378 43386 44192 44310 54362 54364 54368 55064 56191 76181 81327 82071 91286
-----
Processed all charts with status:
+ 'Rectangular, doable'
+ 'Rectangular, partly doable - rectangular insets'
+ 'Rectangular, partly doable - non-rectangular insets'
+ 'Rectangular, not doable in Phase 1 because of special PLY's needed'
+ 'Chart done, checked and locked'
'processed' is the number of charts processed
'evaluated' is the number of processed charts that didn't get skipped
'pxhoriz' compares the lengths of the N and S edges, which should be equal
'pxverti' compares the lengths of the E and W edges, which should be equal
'pxsquare' compares the lengths of the NE-SW and NW-SE diagonals, which should be equal
'ratio' compares the aspect ratios of the REF point rectangle and the projected corner
+ coordinates, which should be equal
All those 'shoulds' are assuming a rectangular chart area in mercator projection.
'>n*sd' charts are greater than n standard deviations from the mean
'>5*sd' should be none
'>4*sd' should be none
'>3*sd' should 3/1000 of the population
All those 'shoulds' are assuming a normal distribution.
'censored' are outliers previously checked and looked 'okay',
+ there may still be a problem with data entry, or the chart may just be crooked.
'notmercator' are charts that aren't mercator or unknown

[paulr]

Originally Posted by recri

Here's the new statistical summary report
-----
NGA 2700 chart summary for Sun Sep 18 20:48:57 GMT 2011

Inputs checked and verified OK:

91096 projection unknown (ancient chart)
92140 projection unknown (ancient chart)
91060 projection unknown (ancient chart)

91030 Mercator, unknown datum, no datum adjustment stated or input
91020 Mercator, unknown datum, no datum adjustment stated or input

Inputs checked and corrected:

92030 Mercator projection, unknown datum, minor adjustment made to corner refs
92100 Lat/Lon mis-entry, corrected

Input not verified:

91407 Mercator, unknown datum, no corner lat/lon printed and no edge scale, so the corner refs that have been input must have been calculated otherwise
(I'm doubtful of the value, at this stage of the project, of working out missing corner lat/lons where there are insufficient edge markings - it's nearly impossible to check what has been done. Here it could be a guess or an accurate interpolation - no way of knowing, and no way of knowing therefore why recri's routine has flagged the chart up. Such charts ought to be allocated a status and form part of a defined sub-process. At the very least, a note should be entered into the Comments field as to how the values were arrived at.)

Paul

[recri]

Originally Posted by paulr

Inputs checked and verified OK:

Moved those, and a few more, into censored.

[wdkester]

I can't get 26145 (2011-09-13) to load in Opencpn. It does load in Seaclear. Would somebody else give it a try?

[cagney]

Originally Posted by wdkester

I can't get 26145 (2011-09-13) to load in Opencpn. It does load in Seaclear. Would somebody else give it a try?

It does load on 19 N x 17 W !! Wrong longitude 17w instead of 71W.
Corrected now!
Don't know about SeaClear.........

Thomas