Cruisers Forum
 


Reply
 
Thread Tools Search this Thread Rating: Thread Rating: 4 votes, 2.00 average. Display Modes
Old 24-01-2010, 00:52   #481
Registered User

Join Date: Dec 2005
Location: Helsingborg
Boat: Dufour 35
Posts: 3,891
Manimaul

Quote:
Where are some sample TMerc charts? I can play around with gdalwarp and see if this is feasible.
All the large scale NZ charts are Transverse Mercator.
Just one example is NZ5215 Whangarei Harbour.

Thomas
cagney is offline   Reply With Quote
Old 24-01-2010, 02:09   #482
Registered User

Join Date: Dec 2005
Location: Helsingborg
Boat: Dufour 35
Posts: 3,891
I have an earlier version of the "gotaalv_1.KAP" available. This version from 1999 had only three REF:s and the results were worse.
After re-geo-referencing, using 10 points, all the easy lat/long crossings, I got the following values for the reference point
57 43 N ->57 43.018
11 57 E ->11 56.983
Much better than previously.
This is a calibration that is not suitable for the OpenCPN:s polys, the chart is jumping around and difficult to move.
OpenCPN accepted both the original calibration and my recalibration without any protests.
The skew value is
Code:
SK=027
It is strange that an "official" .kap chart omits this value!!

I lean towards the conclusion that, with proper georeferencing, OpenCPN could show this chart with sufficient accuracy.

The question remains, how to treat these charts that exists in the "wild".

Thomas
cagney is offline   Reply With Quote
Old 24-01-2010, 02:59   #483
Registered User

Join Date: Sep 2009
Location: Rome
Posts: 320
Hi Dave, first of all, enjoy you holidays without thinking too much to OCPN development...

Regarding georef probem.

I agree with poly approx. But I don't like making different things wrt projections. The solution shall apply to all cases. I'm working on a solution like this. Starting from the ref points and the chart projection, I assume the following scheme:

ChartRef lat/lon --(chart prj)-> Ref E/N --(unknown poly)-> ChartRef x/y

in the first "->" I apply the exact chart projection formula (mercator/TM/etc.) then I transform the reference lat/lon in Easting/Norting (i.e. I obtain the position of the ref points on a hipotetical chart originating form a generic point in the earth and with a scale 1:1).

Now for the second "->" I use a polinomial approximation (not the final polinomials). I must calculate the best fitting poly by using least square approx. This approximation will include only the real chart origin (zero order coefficients), the real scale (first order x=y coefficients), the skew (x coeff in y poly and -y coefficient in x poly), and then shall take into account any other distorstion due to poor scans (all other poly coefficients). But not the projection, that is taken into account in the first ->. In this way this process works for all projection and for any number of ref points grater or equal to 2 (I skip here some detail)

The problem, as I said in another post, is to accurately coose the order of the poly depending on the number of available ref points and (most important!) the position of the ref points. This is still a problem I'm refining.

But even when I've found a good poly solution, that is not what I was looking for since as in BSB 3 I need a poly that goes directly from Lat/Lon to chart x/y and viceversa.

Anyway now I can make the trick: In fact I can now place a number of new generic ref points using the formula above. For example I can choose a grid of 6x6 ref points that span the whole chart.

NewRef lat/lon --(chart prj)-> NewRef E/N --(calculated poly)-> NewRef x/y

Now I can calculate a new set of polys that goes directly from

NewRef Lat/Lon --(final unknown poly)-> NewRef x/y
NewRef x/y --(final unknown poly)-> NewRef Lat/Lon

This is a simple and well-conditioned problem to be solved again with the least square approx. Those final polys (always of the third order) will authomatically include the projection and the chart distorsions. And these polys are in the same form as the ones included in the BSB 3 charts

All this in theory (so far). I've a piece of C code that solves the whole process in simpe cases... still working on.

My final objective was to include this code in mc2bsbh to generate BSB header containing the polys, but also OCPN could include the same code.

Ciao, Marco.
GPS-Marco is offline   Reply With Quote
Old 24-01-2010, 05:11   #484
Registered User
 
idpnd's Avatar

Join Date: Sep 2007
Location: Almería, ES
Boat: Chiquita 46 - Libertalia
Posts: 1,558
Going to the Bahamas for a bit of chart quilting, you must be insane Shall be looking forward to see it in action nonetheless!
__________________
sv Libertalia
idpnd is offline   Reply With Quote
Old 24-01-2010, 17:15   #485
Registered User
 
manimaul's Avatar

Join Date: Feb 2008
Location: Seattle, WA
Posts: 416
gdalwarp

as i posted earlier about experimenting with gdal_warp to reproject the tmerc charts: you can see the quality loss by warping tmerc to merc projections. I'm not sure, as you can see that this could be acceptable. I'm looking fwd to what the solution will be.

Original TMerc projection


Warped Merc projection
__________________
Marine Navigation for Android:
https://mxmariner.com
manimaul is offline   Reply With Quote
Old 24-01-2010, 22:46   #486
Registered User

Join Date: Aug 2008
Location: Auckland NZ
Boat: Beneteau Oceanis 37
Posts: 33
Marco.. could you work your new magic on NZ5324. The longitude is out a little.

Otherwise a great job. I'm really enjoying using them.

Cam
MechMan is offline   Reply With Quote
Old 25-01-2010, 01:28   #487
Registered User

Join Date: Sep 2009
Location: Rome
Posts: 320
Quote:
Originally Posted by manimaul View Post
as i posted earlier about experimenting with gdal_warp to reproject the tmerc charts: you can see the quality loss by warping tmerc to merc projections. I'm not sure, as you can see that this could be acceptable. I'm looking fwd to what the solution will be.
Manumaul, something does not convince me. Too much difference between the 2 projections. I expect few pixel differece (say 10/20 pixel). not more. Are you sure you have choosen the right TM & Mercator parameters?

Ciao, Marco.
GPS-Marco is offline   Reply With Quote
Old 25-01-2010, 01:42   #488
Registered User

Join Date: Nov 2009
Location: France
Posts: 63
PROJ4 library

Perhaps OpenCPN could use the PROJ4 library ... it seems to be a lot of work to change this now but perhaps not too much. Could be a good solution to provide large capabilities in usage of local projections and WMS maps.
One solution could be the following :
1) one default PROJ4 projection is set into OpenCPN
2) the user can choose another default projection into a list provided by PROJ4 or made with information from Home -- Spatial Reference
3) when loading a new map, if information is provided inside the file, OpenCPN reprojects the map
4) if information is not available, OpenCPN asks the user for parameters to use for reprojection
5) without parameters, the map can't be loaded.
Jean-Pascal
Totobeloeil is offline   Reply With Quote
Old 25-01-2010, 02:22   #489
Registered User

Join Date: Sep 2009
Location: Rome
Posts: 320
Quote:
Originally Posted by MechMan View Post
Marco.. could you work your new magic on NZ5324. The longitude is out a little.

Otherwise a great job. I'm really enjoying using them.

Cam
Hello Cam. happy to know you like the charts.

For NZ5324, I think georef is fine. If you refer to the error (about 30m, mainly in longitude) that is very visible at the 4 corners (please, let OCPN to show the chart borders to see exactly the error), well this is the problem of showing transverse mercator in OCPN (that use mercator for the screen). I already proposed a quick solution [#473 number 2)] but it will be a Dave's decision when he will be back.

Ciao, Marco.
GPS-Marco is offline   Reply With Quote
Old 25-01-2010, 02:27   #490
Registered User

Join Date: Sep 2009
Location: Rome
Posts: 320
Quote:
Originally Posted by Totobeloeil View Post
Perhaps OpenCPN could use the PROJ4 library ... it seems to be a lot of work to change this now but perhaps not too much. Could be a good solution to provide large capabilities in usage of local projections and WMS maps.
One solution could be the following :
1) one default PROJ4 projection is set into OpenCPN
2) the user can choose another default projection into a list provided by PROJ4 or made with information from Home -- Spatial Reference
3) when loading a new map, if information is provided inside the file, OpenCPN reprojects the map
4) if information is not available, OpenCPN asks the user for parameters to use for reprojection
5) without parameters, the map can't be loaded.
Jean-Pascal
Hello Jean-Pascal,

I think that if you can choose a "user default projection" then there is no more complexity in letting OCPN to adapt case by case in real time the screen projection to the chart projection every time a new Raster chart is loaded. This would avoid any reprojection (heavy) work.

I think this is the solution adopted by seaclear.

Ciao, Marco.
GPS-Marco is offline   Reply With Quote
Old 25-01-2010, 05:04   #491
Registered User

Join Date: Nov 2009
Location: France
Posts: 63
What i mean is, for example :
* if OCPN default projection is 'EPSG=4326' (Mercator ?) or 'EPSG=900913' (another Mercator ?! plate carree ?)
* if the map projection is 'EPSG=27572 or 27582' (France, Lambert NTF zone II étendu) or 'EPSG=61546405' (ED50)
* when loading the map, OCPN could calculate (with PROJ4) the equivalent map in OCP default projection
* then, the map could be displayed without any problem.

But if we are really going North or South, we will probably want to use locale default projections (or UTM) instead of 'EPSG=4326', because the deformation of the map would be too much important otherwise.

There are also GPS and probably current, tides and GRIB issues to examine. So, i don't know if there is too much work to do this.

Jean-Pascal

P.S. : Manimaul, i think you should use gdalwarp with 900913 instead of 4326.
Totobeloeil is offline   Reply With Quote
Old 25-01-2010, 19:48   #492
Registered User
 
manimaul's Avatar

Join Date: Feb 2008
Location: Seattle, WA
Posts: 416
Quote:
Originally Posted by GPS-Marco View Post
Manumaul, something does not convince me. Too much difference between the 2 projections. I expect few pixel differece (say 10/20 pixel). not more. Are you sure you have choosen the right TM & Mercator parameters?

Ciao, Marco.
hmmm i warped with like this:

create mercator jpg
Code:
gdalwarp -of vrt -s_srs '+proj=tmerc' -t_srs '+proj=merc' 68.KAP 68merc.vrt

gdal_translate -of jpeg -expand rgba 68merc.vrt 68merc.jpg
create tmercator jpg
Code:
gdal_translate -of jpeg -expand rgba 68.KAP 68tmerc.jpg
edit:
i remove the source definition ...
create mercator jpg
Code:
gdalwarp -of vrt -t_srs '+proj=merc' 68.KAP  68merc.vrt
gdal_translate -of jpeg -expand rgba 68merc.vrt 68merc.jpg
and got closer results as merc jpeg was 6204x8929 pixels compared to original tmerc jpeg that was 6191x8893 pixels.

I think I'm doing this right...if so, the results were very acceptable.
__________________
Marine Navigation for Android:
https://mxmariner.com
manimaul is offline   Reply With Quote
Old 27-01-2010, 06:56   #493
Registered User
 
Don B. Cilly's Avatar

Join Date: Dec 2009
Location: Ibiza, Spain
Boat: At the moment, Chrome on Ubuntu I'm afraid, but I take out lots of little ones
Posts: 59
S57

I tried to add a little directory of S57 charts I had.
They list, but, if I click on one, a window opens that says Ingesting, everything goes "gray" (cpu hog) and there it stays.
I tried leaving that for four hours, and no result.
The log says:
11:08:30 AM: Initializing Chart /home/stkz/ES30048E.000
11:08:33 AM: Initializing Chart /home/stkz/ES30048E.000
11:08:33 AM: Building SENC file for /home/stkz/ES30048E.000 to /home/stkz/.opencpn/SENC/ES30048E.S57

and no more as I had to kill the process to exit.

~/.opencpn/SENC contains 17 files, named ES30048E.000 to .016, .000 being 1 Mb, .002 and .003 2.5 K and the rest 25 bytes long.

1.3.6 on Karmic.

- D.
Don B. Cilly is offline   Reply With Quote
Old 27-01-2010, 08:21   #494
Marine Service Provider
 
bdbcat's Avatar

Join Date: Mar 2008
Posts: 7,387
TMerc

Folks....

Done some more thinking and experimenting on Transverse Mercator projections.

The several Swedish charts which I have seem to have the following characteristics:

1. They are indeed TMerc projections, using a Central Meridian defined in the KAP header. Most often this projection meridian is a constant for all Swedish charts.
2. The breakthrough in understanding for me is this: The charts seem to have been rotated by an unspecified amount to present them "nicely" on paper. The scanned image and resulting KAP file maintain this rotation angle.

That is the funny thing about TMerc: at anyplace other than right on the Central Meridian, the pixel values predicted by the formal equations have an "apparent" skew factor, which is not the same as a constant skew seen on some Mercator charts.

The "presentation" rotation angle is nowhere defined in either the paper chart, or the KAP header, and so must be obtained from the REF points.

So a proposed 2 step georef procedure for these charts is:

1. Going from lat/lon to pix:
a. lat/lon ->Tmerc Projection equations->Apply specified scale(DX value from KAP) = northing/easting at proper scale.
b. Using 2 widely spaced REF points, determine the rotation/translation matrix which will map the REF points properly.

Of course, the reverse process from pix to lat/lon involves de-rotation/translation, and the inverse TMerc, in that order, to get the geo position.

This is very similar to Marco's idea, except that the second step is a rotation only, and not a polynomial fit. In fact, on one of the charts I am looking at, (6144 Sanhamn) there are only 3 REF points, so a polynomial solution with cross terms approximating a harmonic rotation is impossible.

We could, if needed, do a simple linear (or better) transform as a third step to improve the accuracy, depending on the number of REF points.

The overall concept works for "normal" Mercator projections as well, recognizing that the rotation angle is almost always nil for the charts we use.

I plan to implement this algorithm for testing next, and see what happens.

Final comment:
I like Marco's idea of using the defined projection to bootstrap the georef, and then apply least squares polynomial fitting to fine tune the final georef co-efficients. This seems the way to go on the charts which we are converting ourselves, such as the NZ series. It has the advantage that georef is done on a chart-by-chart basis, under control of the cartographer, and that OpenCPN does not need to make value judgments on the quality of the chart. Of course, we must have a way to support charts "in-the-wild", of whatever projection and quality, with appropriate user feedback.

Dave
bdbcat is offline   Reply With Quote
Old 27-01-2010, 12:13   #495
Registered User

Join Date: Sep 2009
Location: Rome
Posts: 320
Quote:
Originally Posted by bdbcat View Post
...
So a proposed 2 step georef procedure for these charts is:
1. Going from lat/lon to pix:
a. lat/lon ->Tmerc Projection equations->Apply specified scale(DX value from KAP) = northing/easting at proper scale.
b. Using 2 widely spaced REF points, determine the rotation/translation matrix which will map the REF points properly.
...
Dave
Dave and all,

I think you should never trust kap parameters apart from REF points. You cannot count on SK=, DX/DY=, etc.

So my proposal is to calculate Scale and Rotation only from REF.

The simplified algoritm I'm refining is:
1) solve projection (go from RefLat/Lon to RefE/N). Yes, you use another info form Kap, the projection. But if this is not available, use a default one, like mercator: no big problem as far as I can see on my experiments...

2) now you need 4 parameters: Zero Easting (ZE), Zero Norting (ZN), Scale (S) and Rotation (R). Note that ZE/ZN represents the position on the projected earth (E/N) of the x,y=(0,0) point on chart (upper left corner).

To solve this 4 unknown system, you need only 2 ref poins (4 equations):

RefE1 = ZE + S * Refx1 + R * Refy1
RefE2 = ZE + S * Refx2 + R * Refy2
RefN1 = ZN + R * Refx1 - S * Refy1
RefN2 = ZN + R * Refx2 - S * Refy2

Note that y has a - sign since while y increases on charts, latitude decrease (y is downward in images).

Of course the real algo will solve the 4 unknowns by the least square solution by using all the available REF points.

I'm now completing the release of the double-checked New Zealand Charts. As soon as I complete that task, I can continue on developing/coding this Idea if you think it's worthwile.

Ciao, Marco.
GPS-Marco is offline   Reply With Quote
Reply

Tags
charts, kml, raster2bsb, tiff2bsb, bsb

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Charts on CD stxboy Navigation 43 28-01-2014 10:40
Charts for BC Charlie Navigation 11 19-04-2007 03:39
Used Charts daven Navigation 2 28-11-2006 16:47
Looking at charts - where to go to next Rippy Other 19 10-03-2006 04:27

Advertise Here


All times are GMT -7. The time now is 18:02.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2024, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.