Charts II: NGA - 2700 Charts

[cagney]

Nohal

As an alternative to coding a special solution for charts with a wide border.......
allow users to specify the pixels for the corners of the full size picture in the comment box. Specify a format that is easy to parse for you.
I just tested to open a 100 mb file in GIMP at 200%. No problems, but a wee bit slow on my box.It is easy to get the pixel position with the cross hair.

Thomas

[bcn]

Thomas, Pavel

from my side ok - it's just another open window on the desktop...
And you need to download the complete full size picture/chart file.

Hubert

[r.fairman]

I am having problems opening the calibration section of the NGa storage area. Either I am prompted to login or register when I have already done this My user name is displayed to confirm I am logged in If I click on a chart link to open the calibration section of a chart the link does not work. I am using Firefox 6. I have tried clearing the cache but the problem persists.

[HappySeagull]

Whining and crying but I "calibrated" this chart and I know I didn't put the corners here....can anyone say what am I doing wrong?

What is the best calibrator guide? the zoom window? or the smaller drag-the-mark window?They often seem not to agree....

[bcn]

Richard,

this happens if you close the tab of the calibrating process manually or closing the browser without exiting formally from the tab.
Sometimes it seems to happen also after a timeout - after lunch for example....

In my case I have to purge the cache (all type of cookies), close the browser and restart it.

That's a little messy as one has to enter also the password for a bunch of other applications that are relying on cookies. This page for instance.

Hopefully Netsurfer will find a moment to change this, but probably that is low on his list.

Hubert

[bcn]

Happy,

for me the 10x zoom window is the relevant one.
Yes, if one comes back later to the already calibrated chart, the browser can show the mark 1px displaced, as it will round as well.

As Pavel stated earlier we have and can live with that type of errors.

Hubert

[nohal]

Happy,
I suppose this is a screenshot from OpneCPN, right?
Then the answer is pretty simple - the PLYs are defined by latitude and longitude and not pixel coordinates - thus the location on screen is calculated while OpenCPN renders the chart canvas. Especially for the charts that are not perfectly rectangular, perfectly north-up aligned, which the NGA ones are usually not, the disagreement of 1 or two pixels at this zoom level is normal - observe how the alignment of the red chart boundary rectangle moves relative to the raster chart as you zoom in and out and move around as a result of the math involved.
All the KAPs behave like this - even the Maptech produced ones I have seen where the bitmaps are usually close to perfect geometric quality.

Conclusion: this tells us more or less nothing about the quality of your work on calibration or the computations done during the production process.

For the calibration, technically the read-only textboxes above the pictures are the interesting part. The right picture with bigger zoom is the place to do the exact positioning.

Pavel

[wdkester]

Shoould we report bad downloads like 28142?

[bcn]

Definitely, yes

Hubert

[HappySeagull]

OK,thanks all for the feedback.thanks Nohal -I was noticing a quilting shift in O
...oh,I went back and redid a chart(61150) in Mapcal/Imgkap here,and online comparing the "small view" and of course, as you say,the Right zoom is the one to use!

BIG COMPLIMENTS TO YOU GUYS!
1)my mapcal/imgkap attempt was worse quality...and more work.
2)the chart image jpeg downloaded as 0.65 degrees skewed so you guys have auto-straightening working well!

[HappySeagull]

Firefox note?if you are using Firefox (Mine is from PortableApps,based on FF5.0),there's an option for "Private Browsing" under "tools".

Since I engaged this,I haven't had any choking at the Calibration site,however many charts I do at a sitting.FF also has an option to clear cookies on quitting which I also (always) have engaged.

[recri]

Hi gang.

Roger, here, often going by rec or recri.

I found this project mentioned on the opencpn website yesterday afternoon, read through the thread yesterday evening, registered, and entered a few charts last night.

This is great! It's just awesome what you've accomplished. I'm sorry I didn't stumble in sooner so I could help with the tile assembly.

One question, though maybe I missed the answer while scanning the thread: why are we using the wrong pixel locations for the chart corners?

Every longitude and latitude line on the charts that I can see is drawn so the center of the line marks the coordinate. The labeled corners of the chart are at the point where the centers of the edge lines meet, not the inside corner, not the outside corner. By using the inside corners as georeferencing points we're guaranteeing that every chart is going to be a little off. How much off depends on how thick the border lines are at the map scale and how consistently the corners get picked.

One can argue that the error is negligible, and sure, it's small, but it's a systematic error which means that the projection computed from corner coordinates can never exactly agree with projections computed from interior intersections of meridians and parallels.

Or, more simply, the problem is that if we digitize corner coordinates the way we are and redraw the map edge lines according to the projection we compute, then the new edge lines lines all move inward from their original positions on the chart image, about half a line thickness, more or less. If we measured at the edge line centers and redrew according to the projection computed, then the new edge lines would go over their original positions on the chart image, at least when the edge lines are actually straight lines.

Line centers are also easier to consistently align onto. When positioning cross hairs it's much easier to center in the black density, which is finding a maximum, than it is to pick where black becomes the chart background color, which is choosing some arbitrary point on a slope which has been fuzzed out by ink bleed and jpeg compression and eyes tired of looking at blurry magnified pixels.

I apologize for bringing a harsh word like "wrong" as my first contribution. But I've made some bonehead decisions as a programmer myself and had to go back and fix them. Better sooner than later, especially with all the contributors involved here and the potential consequences of errors.

And it's entirely possible that I missed something essential and I'm actually "wrong" about this, too.

-- rec --

[bcn]

A question to the team and and call for help:

After finishing the first turn through the 50000<54nnn series with about 120 kap charts generated and a for me unknown number of charts with some calibration data defined I would like to have a possibility to have an overlook about the status of the charts involved.
Something like a possibility to make a query against the data base or generating a spec sheet (or even a csv) with the relevant data: the general data in a structured format with the comments in the last place.
That would help to get an idea how to tackle the rest of the charts and as well to identify the most urgent problems.

And this is also a call to have a look at the resulting charts to optimize quality. It's more than probable that there are mistakes in the calibration data. I'm looking forward for feedback!

The tools are really easy to use and it is a fun to work with them. Take some 5 minutes per chart if you want to generate a complete one or much less for just checking the calibration data for the generation of the kap files.

Hubert

[bcn]

Roger,

there a some arguments from Pavel/Nohal about precision already. He is the person to discuss your concerns on a conceptual level.

From a practical point of view: take the charts and have a look how they behave either in OpenCPN or in any other system that accepts .kap charts.

We are talking about +/- 1px or perhaps 2. I have observed today what happens if you scroll with two aligned maps with a different resolution as they are hopping up and down at the connecting points then you pan the canvas.

Would you think you are 10m correct with any paper chart?
The funny thing is that in the moment the paper chart is scanned and base of a navigation system this is forgotten.

This is a call for be critical about the quality and precision of the complete chain of data you have.

You are talking about 1px perhaps. It is not that difficult to place the cursor within that margin, but I doubt a lot about the underlying charts to be at that level.

We are far away with automatic mooring on base of the chat material we have - even with the vector charts (or Google Earth).

I think this is an important discussion to get a clear idea about the quality of data we are dealing with - GPS is another topic to discuss - and would invite for more opinions.

Hubert

[cagney]

Originally Posted by recri

...
One question, though maybe I missed the answer while scanning the thread: why are we using the wrong pixel locations for the chart corners?
.....

-- rec --

We're not. The lat&long on the inside of the chart borderline, printed in the SW and NE corners represents the the positions of the visible chart area, without any frame. That is indicated by the way the positions are printed, which differs from all other lat & long printed on the chart. Mind you, the printing accuracy is probably around 1mm on the original paper chart, and the maximum accuracy of the chart itself you can count on is about 1.5 mm at the scale of the paper chart, near the coast and much worse offshore. Charts based on very recent surveys are probably better, but this holds for the vast majority of charts we are dealing with.

Thomas