Mercator Scale

There are two schools - at least - to plot a line of position with enough details.
Mercator templates are one, plotting sheets are another one.
The plotting sheets rely on the Mercator scale, available at the bottom right corner of the document above. It gives graphically the ratio between one degree of latitude and one degree of longitude.
The Mercator projection relies on the concept of "Increasing Latitude", that gives the value of the latitude, in degrees of longitude...
The increasing latitude λ, for a latitude φ is given by the following formula:

λ(φ) = ln(tan(π/4 + φ/2))

The Mercator scale gives the the ratio between one degree of latitude and one degree of increasing latitude at the given latitude. In consequence, its formula is

ratio = (φ - (φ - 1)) / (λ(φ) - λ(φ - 1))

simplified as

ratio = 1 / (λ(φ) - λ(φ - 1))

also written

ratio = (λ(φ) - λ(φ - 1))^-1

That's it!
The main difference I can see between the two methods is that the Mercator templates can be reused, just like a chart, and the plotting sheets are just a draft, to be dropped after used. That's just my opinion. Whoever has a better - or other - one is welcome to speak up.

True Wind calculation, SOG+COG vs BSP+HDG

It is a commonly admitted fact that you should calculate the true wind with the apparent wind speed and angle (a vector), to which you add the vector of the boat speed and heading.
The trick is that the boat speed and heading should not be the one taken on the water, but on the ground. That means that you need COG & SOG coming from the GPS, and not the Boat SPeed and HeaDinG returned by the instruments (like speedometer and compass).
Imagine that:
You are sailing is absolutely NO wind at all, and you have a current of 3 knots, taking you to the 270° true. The apparent wind you feel comes from the 270° true, at 3 knots. We assume that your boat speed - returned by the speedometer - is 0 knots, and we just don't care about the heading.
If you combine this apparent wind vector with the data returned by the GPS (COG=270°, SOG=3), than you appropriately find that the TWS is zero, as it actually is.
But if you use the Boat Speed returned by the speedometer, then you find a TWS of 3 knots, which is absolutely wrong!
I believe most of the stations computing the True Wind for you are in fact using the data coming from the instruments (and not the GPS). I need to check that..., but is that is the case, then there is a problem.

Routing Slicing

Just like we had a GRIB Slicing feature, you can now visualize the conditions at the routing level.

Drag the mouse on the top pane, and that tells you where you are on the chart, with a big red dot.

Beside that, it was so windy today in Oyster Point that the wind blew my glasses off my nose... I just could see them sinking 30 feet away from the dock. Rats!

Dynamic Java compilation, from a String

Kind of out the the scope of this blog, but as it made me sweat, it might be interesting for some people... The main goal was initially to be able to dynamically override a method of some (Java) class, compile and run it.

I used it for Unit Testing (JUnit), to have the setUp() method of some generic test object to initialize some System variables, context dependent (defined by some properties file).
It's about being able to dynamically generate the code to compile into a String (or StringBuffer, or byte array, or whatever...), compile, load and run it. It is not as trivial as it sounds.
Here is the code I used.

And it is possible not to write the class on the file system. Everything happens in memory.

Moving to Google Code

I'll be moving the code to the Subversion repository of Google Code.
We will have at least the following projects:
- javanmeaparser
- coreutilities
- chartcomponents
- weatherwizard
- fullnmeaconsole
This way, the code will be safe. I am using Oracle's JDeveloper and its Subversion extension, that works like a charm. The Weather Wizard is using a Swing graphical interface. This is not managed nicely by an IDE like Eclipse.
The last project is this NMEA Console I have been working on.

Fax crawler, for SailMail users

I wanted to get something more dynamic for the patterns that can be used at sea...

When ashore, no problem, the faxes are pulled out from the Internet.

At sea, that's different, you have GetFax (from SailMail) downloading the faxes from the SSB onto your hard drive, and when it's about putting the faxes together in a composite, that used to be a painful experience, you had to locate the faxes one by one... Baaaaad.

There is now a new kind of dynamic pattern. If the protocol used to get the fax(es) is not http, then there is a surprise. There is a "search:" protocol implemented like in:

search:chartview.util.SearchUtil.findMostRecentFax(".*500.*", "${fax.path}")

That allows the soft to crawl the directory where the faxes are downloaded.

It does not look that friendly, but that is quite powerful, and extendable. After the "search:" keyword is the name of the Java class and method used to find the right fax. That method must be static, take two String parameters, and return a String value, that's all. The first parameter is a regular expression to match the description of the fax to find. SailMail appropriately stores this information when a fax is downloaded through GetFax... The second parameter is the root directory to start the search from, to find the most recent, matching the regular expression pattern. In the example above, it is the value of the path stored in the Weather Wizard preferences.

It is extendable in the sense that you can write your own crawlers, in Java. It just needs to be put in the classpath.

The same kind of syntax and method is available for the GRIBs as well.

search:chartview.util.SearchUtil.findMostRecentFile(".*\.(grb|grib)$", "${grib.path}")

The idea when at sea is to have GetFax running in "auto" mode for a while, and then to use this kind of composite pattern in the Weather Wizard. This way, this rendering is just one - I said "one" - click away:

Even fuzzy faxes make sense. Click the image... Cool!

To learn how to use this feature the best way, just Google "Regular Expression", this is soooooooooooo kewl!

Contour detection

I just finished big improvements in the contour detection of the GRIBs. The performances are now correct (a few milliseconds per GRIB layer, for a full Pacific GRIB 2 degrees by 2 degrees).
Now the contour detection can be part of a GRIB Animation.
In addition, there are now new check boxes to show and hide already computed contour lines, just like for the faxes.
The picture shows PRMSL and 500HGT contours detected in a South Pacific GRIB. Notice that there is now an option to show only the detected contours (with no wind or other GRIB data).

Kick-ass Processing

That has been on my todo list for quite a while, rendering a GRIB with the Processing framework. Here is a first glance at what it can look like

Move the mouse on the figure to move the light. Drag the mouse to rotate the figure.
It is a 3D representation of the Pressure at Mean Sea Level on 2010-Feb-11.
I finally understood how the thread model of Processing is done. Once you get it, it's all downhill!

Archives 2009 available

From this page, you can now reach several kinds of archives, along with real-time data. We had in the past the composites archives - which can be opened and rendered by the Weather Wizard - we now have images generated after the composites, they can be visualized from your browser.

Check out this link for details.

Color Faxes

We can now integrate color faxes, like this one.
It is a bit special in the sense that

• It's a square projection (Anaximandre)
• It is in several colors.

Anaximandre never was a problem, but the multiple colors is something that was not managed.
We now have the possibility to just make a fax transparent, without changing the black to another color (which is a possibility that still remains).
Having the colored fax transparent allows as usual superimposition with other data, like GRIBs or charts.
We can produce a rendering like this:
Some improvements in the image processing have been done too, regarding the transparency, and the sharp and blur. Looks much nicer. I had the idea of doing it by looking at what OpenCPN was doing for their charts rendering, which is much nicer than Maptech, based on the same data files.