Charts II: NGA - 2700 Charts

[bcn]

Originally Posted by z.stadler

I've done a few in region 5 in case you want some example to work on :-)

In which part of the 5xxxx series you are working? Just to start at a different set from my side

HUbert

[nohal]

Zeev, Tia Bu, bcn...
For my personal tastes, in cases like 25607, the chart is already composed of 3 panels and it's no different from say 25610 (two charts, 50% each) where the catalog also contains just one panel. We treat everything we have to cut as an inset and thus we have to define it's extents now (The reason for this is for example 52143 where the panel images have to overlap). No special annotation needed for the "main" one. We should be able to do all the remaining charts now.

What I forgot to pinpoint is the importance of setting a different letter for each inset you define (they would overwrite each other if there will be two marked with the same letter) - I will detect such conflicts in the database later and handle them myself, but much better if I don't have to...

The next step is using the same calibration approach we did for the main charts with a little relaxed conditions for chart generation to cover even the non-rectangular insets. That should leave us with a pretty reasonable number of non-rectangular insets to treat "somehow", which probably will mean entering some calibration data from a keyboard instead of using a mouse.

An example chart, treated up to this phase:
NGA Charts Status Region 9 at OpenCPN.info (English)
You can see how the inset imagery looks at Index of /nga-charts/92356

Pavel

[bcn]

Originally Posted by nohal

Zeev, Tia Bu, bcn...
For my personal tastes, in cases like 25607, the chart is already composed of 3 panels and it's no different from say 25610 (two charts, 50% each) where the catalog also contains just one panel. We treat everything we have to cut as an inset and thus we have to define it's extents now (The reason for this is for example 52143 where the panel images have to overlap). No special annotation needed for the "main" one. We should be able to do all the remaining charts now.

To propose the other steps was thought to have the process traceable.
Of course we can see the "Rectangular charts" as a subset of "Composed charts"

Originally Posted by nohal

What I forgot to pinpoint is the importance of setting a different letter for each inset you define (they would overwrite each other if there will be two marked with the same letter) - I will detect such conflicts in the database later and handle them myself, but much better if I don't have to...

In the case of composed charts we will find different approaches:
55048 Bosporus: Panel A & B, chart itself is not represented as 55048
52141 Alcudia, Pollensa and Approaches: Main chart as 52141 plus panel A and B
Due to "charts with insets" and "composed charts/panels".
In case 1 they are at the same scale as well.

Originally Posted by nohal

The next step is using the same calibration approach we did for the main charts with a little relaxed conditions for chart generation to cover even the non-rectangular insets. That should leave us with a pretty reasonable number of non-rectangular insets to treat "somehow", which probably will mean entering some calibration data from a keyboard instead of using a mouse.

An example chart, treated up to this phase:
NGA Charts Status Region 9 at OpenCPN.info (English)
You can see how the inset imagery looks at Index of /nga-charts/92356

Pavel

So let us see if I got you you right:
the task is now
- to take care that all the panels are identified and correctly specified. That implies to check every single chart as we can't suppose that the data base is complete
- to create a rectangular area (x,y = that is lower left and upper right?? - how can we control the result?) for the cut-offs in order to prepare the next steps
- geo-referencing
- gpx envelope

With respect to geo-referencing:
quite a lot if not most of the insets have their corners not geo-referenced.
Would it be sufficient to choose just a pair of grid lines (grid-crossings) near to the lower-left and upper right corners for calibrating? Then we would get the same precision as for the rest of the charts.

Hubert

[nohal]

Originally Posted by bcn

In the case of composed charts we will find different approaches:
55048 Bosporus: Panel A & B, chart itself in not represented
52141 Alcudia, Pollensa and Approaches: Main chart as 52141 plus panel A and B
Due to "charts with insets" and "composed charts/panels".
In case 1 they are at the same scale as well.

55048 is the opposite of the usual case - The catalog says two panels, but the logic says base chart + 1 panel.
My thinking is: If the insets take 100% of any chart edge (52141 case), let's treat everything as panels - it will save us quite a few megabytes in the size of our charts and actually the only difference is the naming of the resulting KAPs and the order of the charts in *.BSB files we generate, which I still haven't seen any chartplotter software using. Both of it can be handled later if it proves important. Which reminds me that I would really need to get in touch with people in possession of non-free chartplotters willing to do some testing of the header format we use.

So to lt's see if I got you you right:
the task is now
- to take care that all the panels are identified and correctly specified. That implies to check every single chart as we can't suppose that the data base is complete
- to create a rectangular area (x,y = that is lower left and upper right?? - how can we control the result?) for the cut-offs in order to prepare the next steps

Yep, all you have to do now is describe the panels and draw the corresponding rectangles - it does not make a difference in which corner you start dragging the mouse, the script takes care of it.

- geo-referencing
- gpx envelope

With respect to geo-referencing:
quite a lot if not most of the insets have their corners not geo-referenced.
Would it be sufficient to choose just a pair of grid lines (grid-crossings) near to the lower-left and upper right corners for calibrating? Then we would get the same precision as for the rest of the charts.

Yes, this is the plan. It has two consequences:

• We will loose some QA options as for the panels we can't be sure that the calibration points are in the corners and sometimes there will even be just 2 or 3 of them. That's why I want to keep insets separated from the base charts a bit more than absolutely necessary, not to loose options to check the quality for as many charts as possible automatically.
• Some of the non-rectangular insets will quilt very badly until the GPX polygon is defined. Obviously there's no chance to know the real shape of the non-rectangular insets before the calibrator defines it.

BTW, especially for those wondering when we will be ready for a release, there's about 2000 insets to be handled, so we have quite a task ahead.


Pavel

[bcn]

Originally Posted by nohal

BTW, especially for those wondering when we will be ready for a release, there's about 2000 insets to be handled, so we have quite a task ahead.


Pavel

Taking bets that with the motivated crew we are we can do the identifying/xy part before end of this month....
so prepare for the geo-ref timely

Hubert

[nohal]

Just a note:
I've just discovered an error I did while generating the thumbnails for this phase, so if it appears rotated by 90, 180 or 270 degrees (for example 21543), just ignore it. Will fix it ASAP.

Pavel

[bcn]

Stumblestones:

52183 - no panels defined in data base
--> define panels makes disappearing the chart (should maintain the reference perhaps)
--> trying to open the charts via "define data for kaps" to get to the data/descriptions will not open: ("tab for chart already open")
--> closing panel definition chart won't change this
--> log-out, clear cookie buffer, start again with paper and pencil at hand to write down data before opening the define-panel-tab

(WinXP, Opera)

Hubert

[nohal]

Hmm...
I've just done 52240 - same case - in Firefox and it worked as I would be expecting. Will have a look what can be done.

Pavel

[bcn]

Originally Posted by bcn

Stumblestones:

--> trying to open the charts via "define data for kaps" to get to the data/descriptions will not open: ("tab for chart already open")
--> closing panel definition chart won't change this

(WinXP, Opera)

Hubert

Once you have closed the "panel definition" window, you will not be able to access to the kap definition window. And closed means closing by pressing the (x) as there is no wayout from that panel

[bcn]

How to eliminate an inset/panel?

52121 (Tarragona) shows an inset in the database that does not exist in the chart.

That might be handy as well if we have to eliminate a wrong panel later on.

Hubert

[nohal]

Hubert...
Just keep a note of it for now. I was a bit worried to make it possible to delete the panels to prevent some unwanted damage, so I have to do it manually. Still thinking about the safest way to make it possible as we need to allow some level of "destructive" changes, like for example resetting the PLY polygons, sooner or later.

Pavel

[bcn]

51158 Guadalquivir and Port of Sevilla:

Insets are named "D" and 3x "X" where it should be A, B, C, D.

Would render identical chart names --> same problem as non existing panels:
have to be edited

Hubert

[z.stadler]

Originally Posted by bcn

Hi Tia Bu,

in this case we have more steps:
- you should change the description to the correct one - "pixels for calibration off bound" so that Pavel can correct this
- when done by Pavel change to "doable with inset", and process the main chart
- 3rd step: go for the insets

Here we go again...

Hubert

My suggestion to Pavel is to enable the creation (with the "+" icon) of an additional panel with "Inset" set to "MAIN" and/or Type set to "MAIN". No need to enter the "Title" or "Scale" entries.

Once this is done, all panels (3 in the case of chart 25607) can be calibrated using the same (to be implemented) calibration mechanism.

For demonstration purposes, I've added the main panel of chart 25607
as a Inset "Z".

Best regards,

Zeev

[bcn]

54362 (and a lot of other Greek insets)
no geo references at al - sketches with depth, but not lat/Lon....

Eyeball navigation

Hubert

[bcn]

Originally Posted by z.stadler

My suggestion to Pavel is to enable the creation (with the "+" icon) of an additional panel with "Inset" set to "MAIN" and/or Type set to "MAIN". No need to enter the "Title" or "Scale" entries.

Once this is done, all panels (3 in the case of chart 25607) can be calibrated using the same (to be implemented) calibration mechanism.

For demonstration purposes, I've added the main panel of chart 25607
as a Inset "Z".

Best regards,

Zeev

Yes,

we will need some mechanism like that as all the datum notes are referenced to the main chart and the insets and panels will inherit those from there.

Hubert