Charts II: NGA - 2700 Charts

[cagney]

Originally Posted by HappySeagull

Well Done,Thomas!
It works.
We,-well,I mean you, interpreting seagull cluckings, have found a very strange pimple of a bug!
The same strange thing can be replicated on another CHS NAD83 kap (353801)...I don't know think it'll ever pop up in these NGAs as NAD83! But someday,somewhere...?

Happy
Just so we don't forget!
FS#700 : Odd NAD83 problem
Thomas

[HappySeagull]

...I even hope the problem might apply to 81737 ,here, which is still screwed up and on my last try,still unfixable as to borders.

It has large DTM corrections (DTM/15.6,-21.6),but GD is WGS84...but the real trouble shows up is in the multiple PLYS for any border point.It's the script that is affected,somehow,somewhere,because it apparently can't be fixed by redoing the borders or even recalibrating(which I tried several times)
It keeps writing the border as in:
"PLY/1,7.08725211,168.58077041
PLY/1,7.00266667,168.50600000
PLY/1,7.18220067,168.50008900
PLY/1,7.18220067,168.50008900
PLY/1,7.18864567,168.50600000
PLY/2,7.67121467,168.50600000
PLY/2,7.67092637,168.50025106" etc...

maybe a new approach might fix it...

edit:also 81329

[cagney]

Originally Posted by HappySeagull

...I even hope the problem might apply to 81737 ,here, which is still screwed up and on my last try,still unfixable as to borders.

It has large DTM corrections (DTM/15.6,-21.6),but GD is WGS84...but the real trouble shows up is in the multiple PLYS for any border point.It's the script that is affected,somehow,somewhere,because it apparently can't be fixed by redoing the borders or even recalibrating(which I tried several times)
It keeps writing the border as in:
"PLY/1,7.08725211,168.58077041
PLY/1,7.00266667,168.50600000
PLY/1,7.18220067,168.50008900
PLY/1,7.18220067,168.50008900
PLY/1,7.18864567,168.50600000
PLY/2,7.67121467,168.50600000
PLY/2,7.67092637,168.50025106" etc...

maybe a new approach might fix it...

edit:also 81329

I think the PLY problem is as simple as - Nohal just resets the charts to square one. My guess is that someone by mistake entered some PLY:s that made a loop and this caused the script to throw a fit. For 81329 it could possibly even be my fault.
I know I was trying some DTM:s on 81329, but found it impossible to find a value that was good for the whole chart, comparing with 81327. The interesting situation is a chart with a local Datum,81329, embedded in a WGS84 Tmerc chart,81327.
Thomas

[navMonkey]

Just to prove it can be done on Android:




GJ guys!

[navMonkey]

Here is a link to the android charts provided above: RG01_W_Mexico.zip

Created with MTCW from manimaul. Thanks!

Unzip and drop two files in /sdcard/mxmariner if you have mxmariner.
It looks like locus map free for android also supports this format but I haven't tested.

Brad

[HappySeagull]

Originally Posted by cagney

I think the PLY problem is as simple as - Nohal just resets the charts to square one. My guess is that someone by mistake entered some PLY:s that made a loop and this caused the script to throw a fit. For 81329 it could possibly even be my fault.
I know I was trying some DTM:s on 81329, but found it impossible to find a value that was good for the whole chart, comparing with 81327. The interesting situation is a chart with a local Datum,81329, embedded in a WGS84 Tmerc chart,81327.
Thomas

noo,it was me,alright,unless we were both fiddling with it at the same time!-hey, that's a thought!- but I actually remember that when I downloaded the existing border gpx and began editing it-for no real good reason ecept to block out a text block or something),I noticed the direction of the arrows (being really a route, in OPCN ) was odd....they went both ways!I should have puzzled a little harder over that,and it had something to do with the "hidden corner"too...the 5th wpt in a 4-cornered border I think...but now,this about the DTMs recalls to me that I also saw a border without a chart on opencpn when I was rebordering trying to fix my mess of these two charts in the same area....
a mystery.

[nohal]

Howdy gang...
Hope you enjoyed the Christmas and your local Santa variations brought enough new toys to keep you happy for another year.
I finally managed to polish the inset definition tooling to be usable and put it online.
The data Zeev was able to extract from the catalogs are imported to the database - they are not perfect, sometimes not all the sub-charts are there, sometimes no data is available for a particular chart at all or something is simply wrong. In such cases, use the icons in the lower left corner of the grid to add/edit the insets.
As usually, report any problems you encounter.

Happy new year

Pavel

[bcn]

And I thought to have still a very relaxing week ahead....

Pavel, thanks and will give it a try from tomorrow on.

Hubert

[z.stadler]

Hi Pavel,

Would you like us to start marking the bounding boxes for the insets?
I assume that afterwards we'll be able to calibration the insets and create their PLYs, as was done for the existing maps.

Right?

Zeev

[nohal]

Zeev,
exactly. You can start defining the insets now - it's necessary to process the images server-side before the calibration can be done, so it will be another two step operation

Pavel

[z.stadler]

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

[Tia Bu]

Great work, Nohal! Thanks!

I did a couple of charts in Region 2. It worked great. Then I ran into a chart with a non-rectangular inset and got confused. Can we do non-rectangular insets with this tool, or should those wait until later?

[Tia Bu]

And what do we do with one like 25607? We classified it as composed of rectangular charts, but on closer examination, it is really one chart with two rectangular insets printed below it. I tried creating a KAP for the main chart, but since its two lower corners don't run down to the bottom of the page, I couldn't calibrate it. We don't have the main chart listed as a potential inset to define.

[z.stadler]

Tia Bu,
At this stage, all we need is to set the "bounding box" - the rectangular that contains the entire inset. It may also include area outside of the inset, but that does not matter. At a later stage the exact shape will be entered.

Another stage not yet implemented is calibration. I agree that when the chart is composed of non-overlapping panels, the calibration of the "main" panel will require the same calibration mechanism as each of the insets.



Pavel,
In that case, would you like us to add a "main" inset to the inset list? Would you like a special annotation for it?

Zeev

[bcn]

Originally Posted by Tia Bu

And what do we do with one like 25607? We classified it as composed of rectangular charts, but on closer examination, it is really one chart with two rectangular insets printed below it. I tried creating a KAP for the main chart, but since its two lower corners don't run down to the bottom of the page, I couldn't calibrate it. We don't have the main chart listed as a potential inset to define.

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