Charts

[bdbcat]

GPS-Marco...

Thanks for your comments.

I have done some more study on non-WGS84 BSB charts and PLY points.

This is what I find:
Leaving the chart-stack question aside for a moment.....

We currently draw the red chart outlines using the DTM offsets found in the KAP header. In other words, we assume that the PLY values are specified in WGS84, and need to be offset by DTM before drawing on the screen. We then find that the drawn chart outlines do not nicely correspond to the borders of the chart. What is the reason?

If, the other hand, we assume that the PLY values are in the datum of the chart, we then need to convert them to WGS84 before storing in the database. Later, they will be converted from WGS84 to chart datum before drawing. If we do this as an experiment, all is well for the chart outlines.
Further, the PLY values in the database will be known to be WGS84 referenced, so the chart stack will be correct for all other WGS84 calculations also.

So, after all, I agree with your logic, although we arrive from different directions. All these pluses and minuses make my head hurt...

I'll make the change in the next version.

Thanks for the reminder to look at this more closely.
Dave

[sinbad7]

Thomas,Dan,Marco..

FINALLY managed to convert another NZ map all by my self..he he, with a little help from my friends.. However,the tif2bsb utility only did part of the job,omitting to insert the template file. I had painstakingly prepared using a variety of tools. The resulting nz5323.kap file came without the header which I inserted manually using a hex editor.

I have no idea why the tif2bsb utility did not automate the job. At least I now have a template I know will work. See attachments.. Thanks everybody for your help and ideas.

[GPS-Marco]

Originally Posted by sinbad7

Thomas,Dan,Marco..

FINALLY managed to convert another NZ map all by my self..he he, with a little help from my friends.. However,the tif2bsb utility only did part of the job,omitting to insert the template file. I had painstakingly prepared using a variety of tools. The resulting nz5323.kap file came without the header which I inserted manually using a hex editor.

I have no idea why the tif2bsb utility did not automate the job. At least I now have a template I know will work. See attachments.. Thanks everybody for your help and ideas.

Hi, compliments for the map!

I saw your template and I found that some commas/CarriageReturn are missing and that DX and DY are 0. Well, I don't know if it is the problem, but try the attached one.

Ciao, Marco.

[sinbad7]

Marco et all...

Still having problems displaying my last map of Hamburg port. Can not see what I am doing wrong?

See the binary editor copy of the template part of the map.

[cagney]

Originally Posted by sinbad7

Marco et all...

Still having problems displaying my last map of Hamburg port. Can not see what I am doing wrong?

See the binary editor copy of the template part of the map.

It very much depend on the settings in your hex-editor, but it doesn't look right to me. Lets have a look at how nz53 looks like as text and in a hex-editor.
The attached nz53.txt is a copy of the relevant text at the header of the .kap file.
The picture nz53.png is the same file in my hexeditor set at viewing text. Where you see a . (one red dot) it is ascii 010 which is "linefeed". Where you see .. (two red dots) the first is ascii 013 which is "carrige return", the second dot is again a "line feed".
Where you see a space it is ascii 032 "space".
Compare this with your own file, and you ought to be able to edit it, so it works.
At the same time have a look at the REF coordinates. They don't look right when comparing to the PLY:s.

Thomas

[cagney]

A lot of the NZ tiffs are charts filled with harbor plans.
In the past I have not cared about splitting such charts up in individual tiff pictures before converting to a .kap chart. See post #103 for an example.
But to crop these pictures down to individual pictures is not that difficult (once you found out the command). This works:

$ convert nz945.tif -crop 5650x5221+6769+2851 -compress LZW +repage penhryn.tif

nz945.tif original picture
5650x5221 is the coordinates of the upper left corner of final cropped picture on the original nz945.tif.
+6769+2821 is the size of the Penhryn picture from the start-point above
penhryn.tif is the result.

"convert" is part of ImageMagic.

Thomas

[sinbad7]

Thomas...

Thanks for the orientation..I will check it out.. For the first time the tif2bsb utility created the .kap file without any warning comments,AND,with the header. Earlier,I had to add the header manually. So this is at least some progress.

I earlier did exactly as you suggested,copying the header steps of the previously successful NZ53.kap file. When running the OpenCPN map installer,only the red frame was visible and when doing a mouseover it disappeared. Later it turned into a triangle?

Perhaps I've mis-understood the functions of REF and PLY. I didn't think they had to be the same. One defines the geo loc of the 4 corners of the map and their x,y, position, whilst the other are created reference points selected from convenient locations such as lights,printed map co-ordinates etc.

I must admit I do not fully understand all the mnemonics of the headers and perhaps have some set wrongly for the .tif chart used.

[cagney]

My recommendation at this stage (in my knowledge ) is for one REF in each corner for large scale charts, for example Penhryn a couple of posts above. As scale gets smaller sprinkle in a few more REF:s at intermediary latitudes along the extreme longitudes.
For real small scale charts, as NZ14051 and NZ14061 (1:10.000.000), it is not yet clear which is the best approach. Dave is pondering new algorithms. This is an area where the present approach is not the best. This may be sorted out in next beta, I suppose.

For PLY:s the general recommendation is one in each "corner" of the perimeter of the chart, in a clockwise direction. Normally that leads to 4 x PLY. But if you look at NOAA 541 "Hawaiian Islands"
you will find the following 8 PLY:s

PLY/1,5.0000000,-179.000000
PLY/2,14.250000,-179.000000
PLY/3,14.250000,-179.333333
PLY/4,14.750000,-179.333333
PLY/5,14.750000,-179.000000
PLY/6,30.000000,-179.000000
PLY/7,30.000000,-154.000000
PLY/8,5.0000000,-154.000000

The reason...? see below.

Thomas

[sinbad7]

Thomas..

On further scrutiny of the Hamburg.kap header in my hex editor I found I had reversed the roles of REF and PLY. I have now corrected this and have ensured that all spaces and commas etc. are EXACTLY like the header in the previously successful NZ5323.kap file. For the PLY points I have used geo loc's from clearly definable points inside the map positioned roughly as a square. I will later try using the map corners for the PLY positions as suggested by you.

All the same,the revised Hamburg.kap chart or it's frame does not show up in OpenCPN when ingested. Can there be something unacceptable with the Hamburg.tif file itself?

[sinbad7]

12 out of 10 for perseverance,managed at last!!

This time I converted successfully the NZ5324.kap file but again had to enter the prepared header file manually,having first created a 'header less' .kap file.

The reason why it didn't work initially was because I had reduced the downloaded .tif file by 50% and making sure it was converted to palette format. Using the file as downloaded solved the problem.

I have given up converting a Hamburg port .tif file as it does not seem to be of an acceptable format. It doesn't seem possible to convert from just any scanned raster file even if you ensure it is in palette format.

[sinbad7]

Can anyone see a reason why these .tif files should not be compatible for conversion to .kap files?

The .tif files contained in the NZ Gov. site are of a high quality but what else separates them from these files?

[sinbad7]

Good night all...

"The time has come," the Walrus said,
"To talk of many things:
Of shoes--and ships--and sealing-wax--
Of cabbages--and kings--
And why the sea is boiling hot--
And whether pigs have wings."

[dacust]

Well, after 3 days of coding, I just finished my first automated run creating B&W photo charts. 150 charts in less than an hour. Actual time was the time to create the region in USAPhotoMaps (2-3 minutes) and 48 minutes for the batch processes. And that is on an old 2.4gh P4 machine.

634mb, about 4.5mb each.

Before I go further, this requires Windows and MinGW/MSYS. So if you're on *nix, sorry (Unless you got wine or the like). And if you have issues installing a *nix type emulator and packages on your Windows machine, sorry there, as well.

I'd be a little surprised if anyone wants this, but I'll be posting it on my website sometime in the next few weeks after I get it cleaned up a bit.

Requirements

• Windows
• USAPhotoMaps (no *nix version that I am aware of)
• TerraFetcher (no *nix version that I am aware of)
• MinGW/MSYS
• tif2bsb (Windows version)
• ImageMagick

(Everything above is free - except Windows...)

As I have it set up, it uses 3 directories.

• conversion - the conversion tools
• work - the working directory. In the end, it is empty
• BSB_ROOT - for the finished charts

Here are the steps. I said almost totally automatic. There is no coding or number ciphering. Just 5 separate steps. (This assumes you've already downloaded the images with either USAPhotoMaps or TerraFetcher)

1. Use USAPhotoMaps to create a TerraFetcher.txt region file of the area you want the charts to cover. This is just a click and drag to define the region.
2. Copy TerraFetcherRegion.txt to the /conversion directory
3. From MSYS, run custom program cvtdrv.sh to create some driver files. It generates the file names based on the UTM positions, so there will never be a duplicate file name. It will create /conversion/crtbatch.sh and /work/terrafetcher.txt.
4. Run TerraFetcher and select JPEG, then select /work/terrafetcher.txt as the batch file. Run it. This creates all the jpegs in the /work directory.
5. From MSYS, run cvtbatch.sh

It cleans up after itself, so all that's left on disk are the .kaps in /BSB_ROOT.

There is debugging information that is controlled by a parm, also the cleanup is parm controlled. I plan to make that be in an ini file, along with the directories. Right now, it only handles the high resolution B&W photos. I'll add support for the other types.

Knowing the way I code, and the fact that this is the first time I ever coded more than 10-20 lines in C, it may be a while before I'm ready to post it.

The reason I say I'll be surprised if anyone wants this, is this. Look at the screen shot below. That little block of red outlines is 634mb. Lot of disk space for a little area. I'm gonna do Lake Lanier and Charleston Harbor, next.

Click here for the full size gif (107k)



-dan

[bdbcat]

Dan...

How about a zoom-in?

Dave

[dacust]

Originally Posted by bdbcat

Dan...

How about a zoom-in?

Dave

You ask for it, you got it.

This shows the chart outlines:
Click here for the full size gif (176k)



As you can see, they don't line up perfectly. Got a little tweaking to do. I figure they are off a bit, but since, as the title of the chart says "not for navigational use"

Amd this is at max zoom.
Click here for the full size gif (439k)





-dan