I think it might be too early for collecting polars for OCPN... perhaps it is still better just to note the existing repositories serving well their well understood purposes.
As I mentioned in an earlier post, I am trying now to build a tool helping in cruising passage
- estimating time to complete a given route under a given forecast, including comparison of different routes
- viewing the GRIB from the route progress perspective rather than from time perspective only
- providing a wind forecast summary along the route
Essentially this is ready in 2.5.1010. Still some small improvements to come.
A polar diagram of boat performance vs. wind is nice to have, but does not result in dramatic improvement - on a longer passage
a fixed cruising speed estimate gives surprisingly good approximation, and average upwind VMG is just about equal to
But yes, the polar has to be there.
1. The syntax of polar specifications is just one aspect.
2. The method of approximation used is another aspect.
3. The interpretation of chosen items (beat angle, run VMG, etc.) is yet another aspect.
4. The requirements for data (specific items need/need not be present) is yet another one.
5. Depending on the application, there might be a need for specifying only real sailing speed, or a passage average, perhaps combined with motoring speed.
6. The convenient method, by which the polar is constructed, may be different for many classes
ad. 1. The syntax : Easy enough, the format accepted here is syntactically the same as for Bluewater Racing
and Expedition, and similar enough to ORC Certificate contents and (I think) MaxSea
. The other formats (e.g. Euronav, VRTool) are meant rather for use just with the respective programs. Rich as they are, I do not believe adopting any one of them would be a good move now.
ad. 2. Method of approximation: There seems to be no standard on this, yet it makes a big difference on end result. If splines are used, the curve looks nice end-to-end, but the speed forward of the beat angle falls down faster or slower, depending on what is the first point provided. Bluewater suggests that it should start ideally at 0 degrees, but at the same time requires the 2nd value to be the optimal beat angle. This results in rather smooth transition from beat angle down to 0, inviting sailing much closer to the wind, than is possible in reality. I have chosen the linear interpolation, applied only after the 2nd point of the polar, i.e. after the beat angle. This results in a sharp line distinguishing between the course which is "possible" and "impossible" to sail. To acheive the same kind of sharp line with spline approximation, it is necessary to put the first data point much closer to the beat angle, than to 0. So many programs will give very different results with the same polar...
ad. 3. Interpretation of chosen items : These values are of greatest use to the optimizing algorithms, not implemented here (yet). Still, it would be nice to use the existing polar files in unmodified form as much as possible.
ad. 4. Requirements for data : For weather-routing algorithms the polar needs not be complete (through 360degs), it may leave some angles unspecified (never to be used), for hand-made real planning this is not acceptable. A polar must give some reasonable speed value for any angle in any wind speed. The no-go values may be represented by just very low speed (I use now 0.11 kt, which means - "we will not really sail this way"). This difference means that the polars prepared for racing simulation and automatic route optimization may need to be adapted, before being used in manual passage planning. There is also the issue of "zero speed" which will wreak havoc in any manual plan. The ready-made, existing polars may differ widely as to what is assumed about their "unspecified" sectors, and they not always cover all the 0-360 deg range as well as higher wind speeds.
ad. 5. Application : I see broadly three kinds of polars, all fitting in the same syntax:
- pure "racing" or "sailing" polars
- tactical passage planning polars - requiring the user to explicitely plan the beating legs and tacking points
- strategic passage planning polars - just showing the average passage speed (speed with wind-on-the-nose is 0.4-0.5 of the speed on a closest reach, so what?)
(both planning polars may, to a different degree, express the motoring capability or preference)
Within the current
simple syntax there is no way to specify configurations (spinnaker or jib
, motoring or sailing, etc.), yet the motoring option is so important in passage planning, that it is necessary to include it somehow. It is a bit of a hack, but currently I use the decimal fraction of 0.11 to visibly mark a motoring speed. 0.11 means "dead in the water" and 1.11, 2.11 3.11 4.11... all mean "motoring at XX knots". These values are usually not lost
in interpolation, and are well visible in Route Properties passage plan.
ad. 6. Polar construction method : I believe that for the cruising sailor the polar is built entirely by owner's experience with his specific boat and his specific sailing style. It could be built automatically by analyzing the Voyage Data Recorder logs
, but more often is just drawn up by the owner, asking himself: well, with such wind and such point-of-sail I usually make xx knots on a passage. (S)he will not be choosing interpolation nodes to suit best the spline drawing. (S)he will just record
a number of points well remembered from past experience. This means that the polar should be built without additional tools - it should be just a list of points easy to record
So, perhaps too early yet to label any given file "OpenCPN Polar File".