Charts

[brak]

Marco,

I understand that part about creating polynomials.

Now, presumably the aim of the chart package is to, eventually, draw charts on screen (or something like that). I know it is relatively easy to build a simple affine transformation (the usual 2D matrix) and show the image as appropriate while applying this transformation. This stuff is found in almost any image handling library.

If the application uses polynomials instead, wouldn't it have to basically implement an entire set of graphic handling functions to actually use those polynomials instead of a simple affine transform? Or am I not understanding it (perhaps I am not).

Originally Posted by GPS-Marco

Well, this process adds the 4 polynomials to the KAP header. Those polys are one of the ways to go from chart X/Y to geographic Lat/Lon and viceversa.

Those polys are calculated (as brifly described in the previous posts) from the ref points. But of course any application can decide to ignore them and to use directly the ref points to make an internal process to go from chart XY to Lat/Long and viceversa. Polys are anyway widely used since BSB charts version 3.0 foresee as an option theese kind of polynomials precalculated and placed in the KAP headed.

Unfortunately those polys are not always optimal. As I wrote they fail on charts with high extention in latitude/longitude (ten(s) of degrees) since they cannot reproduce the complex formulas that are behind the projections.

So, at the end, the objective of my work is another: it is to develop a process that can become the internal process of OCPN to calculate from Ref Points the Georef tansformation functions. And the code I posted is just the rough implementation of such ideas and (partly) of such process.

Ciao, Marco.

[GPS-Marco]

Originally Posted by brak

Marco,

I understand that part about creating polynomials.

Now, presumably the aim of the chart package is to, eventually, draw charts on screen (or something like that). I know it is relatively easy to build a simple affine transformation (the usual 2D matrix) and show the image as appropriate while applying this transformation. This stuff is found in almost any image handling library.

If the application uses polynomials instead, wouldn't it have to basically implement an entire set of graphic handling functions to actually use those polynomials instead of a simple affine transform? Or am I not understanding it (perhaps I am not).

Sorry but I'm really not an expert of rendering. What do you mean for affine transformation? is it a scale + rotation matrix?

Anyway we shall agree some basic terms (sorry if I'm not precise):
what does the screen represents? For our applications the screen always represents a flat (2D) map (just to be clear, google earth is an exception since it represents a 3D map..). Well this means that we must apply a projection.

2 possibilities here:

1) the screen always represents one type of projection (OCPN only represents mercator so far). This means that any screen x/y point represents a Lat/Lon point on earth as derived from the mercator projection formulas (and viceversa from lat/lon to x/y). You can see this formulas at work looking at the "Cursor" value when you move the mouse on the x/y point of screen. Of course this approach is perfect for Vector maps since all data is stored through the object lat/lon and you can "build" the map in real-time appling mercator projection to transform lat/lon to screen x/y. Things are much different for raster maps since they are already "projected".

2) the screen represents the projection of the raster map that is actually rendered on screen (Seaclear uses this approach). This means that any screen x/y point represents a Lat/Lon point on earth as derived from the active projection formulas.

In the first 1) case we can analize the simple case that is when we have to show a mercator chart: in this case all we need to do is to find the scale and the rotation transformation that perfectly map the chart points X/Y to the screen points x/y (note that even in this simple case, OCPN is unable to rotate the picture so it only applies a scale and then the screen represents a rotated mercator). But the general case is that the chart is not mercator (or is mercator but distorted by a bad scan). In this case the program shall find the "optimal" scale and the "optimal" rotation to better map the chart points X/Y over the screen points x/y. Distorsions will be unavoidable. Polynomials help you since those formulas describes how to go from chart X/Y to chart Lat/Lon so it's up to you to find the best affine transformation to map that piece of the chart on the screen. As you can see we are never speaking of real-time reprojection of the chart that migh be a solution for a "super"computer, we are just speaking of how to find the best affine transformation for that chart in the area showed by the screen.

In the second 2) case, things works in the opposite way: the master is the chart. I take the chart and I apply a scale and a rotation just as the user request (zoom in/out) and I show what I get on screen. Finished. Well, almost since I want to know the lat/lon of any x/y screen point to place the ship, to place the WPs or to read the objects' position. Then immagine the mouse over a screen x/y point: I use the inverse affine transformation to get the chart X/Y relative to that x/y, than I use polinomials to calculate the Lat/Lon the chart pixel refers to. This simple process of course always represents on screen the projection of the chart! Errors can be really minimized to the errors of the georeferencing polinomials. Straight and simple but with a problem: quilting adjacent charts with different projection is really hard since there is not a common "screen projection": they simply do not agree on wich lat/lon is represented by a x/y pixel.

Of course this is theory. All Programs will implements theese processes in differet manner. But always you will need a way to go from chart X/Y to earth Lat/Lon and viceversa. Polinomials or other solution (like chart projection+polinomial) will do the job at this point. Nothing related to the final rendering that is always a scale + (hopfully) rotation

Lets stop here...

Ciao, Marco.

[brak]

Originally Posted by GPS-Marco

What do you mean for affine transformation? is it a scale + rotation matrix?

Yep, that's what it is.

But the general case is that the chart is not mercator (or is mercator but distorted by a bad scan). .

Ah, that explains it. I deal pretty much exclusively with NOAA BSB's which are fairly well projected. With these I find that for non rotated charts once I fit the scaling matrix, the other two members tend to be either exactly 0 or, occasionally on a scale of E-5 or less, though there were few exceptions. In any case, I see your point now.

I think from the applied point of view (sorry, I am a developer, that's the only way I can think ) it may be best to apply all the needed transformations once, bringing the chart to whatever projection that is native to the product, then storing it - so that in repeated use it is back to the basic scale+rotation. But that's a side issue, of course.

[HamishB]

Hi,

I am looking for anyone who has offically issued BSB charts using LAMBERT or TRANSVERSE MERCATOR projections.
Currently OpenCPN does not support them properly.

I'd like to see what the first few lines of the file look like so we can understand the needed map projection parameters which are given in the header text.

All of the ones I can find from NOAA are either Mercator or Polyconic (Great Lakes overview).

The NOAA projection translator is not enough, I'd need to see a map using the projection natively.


thanks,
Hamish

[johnar]

I have Maptech with the BSB4 files is that what you are looking for?

Dutch

[HamishB]

If you open one of the .KAP files in a text editor the first dozen or so lines will be in plain text, and then the map data follows in binary. I'm looking for maps which are listed there as using something other than PR=MERCATOR as the projection on the KNP/ line. BSB/2 is limited to those 4 projections, so I'm starting with them.

The on-map text will typically tell you things like the map projection and projection parameters (e.g. central lat/lon)

I'd note that the NZ6823 (that's Pat.Inlet, Stewart Island, right? [great place!]) used in prior tests on this thread is actually in Transv. Merc. so will not position itself >correctly< in OpenCPN without reprojection to plain Merc first. It will get close, but not enough to be useful in a fog.


Hamish

[GPS-Marco]

Originally Posted by HamishB

If you open one of the .KAP files in a text editor the first dozen or so lines will be in plain text, and then the map data follows in binary. I'm looking for maps which are listed there as using something other than PR=MERCATOR as the projection on the KNP/ line. BSB/2 is limited to those 4 projections, so I'm starting with them.

The on-map text will typically tell you things like the map projection and projection parameters (e.g. central lat/lon)

I'd note that the NZ6823 (that's Pat.Inlet, Stewart Island, right? [great place!]) used in prior tests on this thread is actually in Transv. Merc. so will not position itself >correctly< in OpenCPN without reprojection to plain Merc first. It will get close, but not enough to be useful in a fog.


Hamish

NZ6823...: are you speaking of the maps that I have georeferenced and that you can collect here MCE66? If so, just try to use mc2bsbh-poly to generate the map with the georef algo I implemented (see #531). Many charts works much better in OCPN (I'm not sure about this specific one). You will be surprised...

Sorry, I will not be available in next days (for 1 week more or less).

Ciao, Marco.

[HamishB]

Originally Posted by GPS-Marco

NZ6823...: are you speaking of the maps that I have georeferenced and that you can collect here MCE66?

The maps by name/number only, I have independently downloaded and geoferenced them for myself into GeoTiffs a long time ago. I am only aware of the -poly version of mc2bsbh now that you point it out- I'll take a look...

If so, just try to use mc2bsbh-poly to generate the map with the georef algo I implemented (see #531). Many charts works much better in OCPN (I'm not sure about this specific one). You will be surprised...

I am keen to know more about how it works (not about the projection math or C++, just curious about the method) and it's a lot of code to digest quickly.

Is there somewhere I can read more about what WPX/ and PWX/ (&Y/) are and how these polynomial coeffs are applied, versus a collection of REF/ points? Are they used together with REF/?


(also any idea what DTM/ does? "degrees to minutes"??)


thanks,
Hamish

[HamishB]

(reading this thread as I go which explains some...)

[HamishB]

Marco:
by the way, there was trans. merc code posted to the PROJ.4 mailing list in the last week which claims nanometer round trip, and plenty more from PROJ.4 directly or Gerald E's new libproj code. (all usable MIT/Xish licensed)

but fundamentally tmerc. will get horribly distorted as you move away from the center +lon_0 (really should try to stay within ~6deg).


still learning,
Hamish

[HamishB]

Originally Posted by brak

I think from the applied point of view (sorry, I am a developer, that's the only way I can think ) it may be best to apply all the needed transformations once, bringing the chart to whatever projection that is native to the product, then storing it - so that in repeated use it is back to the basic scale+rotation. But that's a side issue, of course.

(an issue already solved by `gdalwarp` by the way)
GDAL: GDAL - Geospatial Data Abstraction Library

[HamishB]

(and cs2cs for x,y points, and ogr2ogr for vector maps)

[brak]

Originally Posted by HamishB

(an issue already solved by `gdalwarp` by the way)
GDAL: GDAL - Geospatial Data Abstraction Library

Yep, there are a few programs out there that would do that.

GDAL in it's original form is extremely "heavy" though, and not really suitable as a module for a desktop program. It's academic and very versatile, but the code is written with absolute disregard of efficiency.

[HamishB]

Originally Posted by brak

GDAL in it's original form is extremely "heavy" though, and not really suitable as a module for a desktop program. It's academic and very versatile, but the code is written with absolute disregard of efficiency.

I've been using libgdal as part of desktop apps every day for years without any complaint. shrug. The dependency tree can be huge if you build it with all the bells and whistles, but you don't have to do that.


To the point though- quilting is only ever going to be useful for maps which share a common native map projection, for the rest you'll have to be happy with a reprojected PLY-style bounding polygon (perhaps filled 75% alpha transparent) showing where the map is. As 90% of the nautical charts out there are Mercator, this isn't a huge tragedy, although it does mean switching out of quilt mode when you enter some harbours (where trans.merc can be found) or when you zoom to the continental scale (where polyconic projections can be used).

No matter how fast computers/cell phones get, transforming the mouse cursor position and the boat's position (and perhaps 10,000 track points) between lat/lon, screen x/y, and projected Mercator eastings/northings is always going to be way more efficient that trying to reproject a raster chart to match the geographic/screen/projected coordinate system.

For a 300dpi scan of an A0 chart the raster might be 10000x8000 pixels (80M cells).
for my example 10,003*3 reprojection calculations versus 80M*3 calculations.
It's not even close - trying to project raster maps of any substantial size on-the-fly is just nuts. (even true for a 1024x768 cut-out of the larger raster image)


I had a look at the problematic NZ14065 chart (NZ to Antarctica) talked about earlier in this thread. It's standard Merc with a latitude of true-scale at the equator, so no special transform is needed or should be done. By knowing the projection is merc, the datum is wgs84, the dpi (from tiffinfo), and the scale & +lat_ts from what is printed on the map, we have everything we need to georectify the map perfectly. Using poly fits for raster maps which are not distorted will only degrade and confuse matters. If the map is thought to be correct and things don't line up, then it's time to blame the software I haven't actually tried to georeference it yet, so this is just chatter.


regards,
Hamish

[HamishB]

by the way, historical background re. the pedigree of the KAP file header format can be found in this document:

http://geology.usgs.gov/tools/metada...ard/940608.txt

perhaps it is useful to answer some unanswered questions.