Current-informed routing plugin

[waltknowles]

Hi, all.

I've been using OPENCPN as a placeholder for "when someone finally builds what I want for Mac and Android", but it is becoming more and more clear that OPENCPN is pretty close to that and it may be up to me to write a (rather complex) plug in to finish making it what I want.

Don't know if this is the right forum, but let me describe what I want to do, and (imformally) the sorts of data I need, and ask those of you who know the guts of OPENCPN to give me a "that sounds doable" or "you might be able to do it, but I don't think the program support is there."

Nobeltec's Time Zero and Rose Softwares charting program both do this, so it's not a new invention and you may have seen it there.

What I want to do is to link current data (from either primary or secondary current stations) to way points on a route for prediction purposes. Once a route is linked to currents, given a starting date and time, you can iteratively calculate tide-influenced ETA, times of best departure in a range of times, how fast you will have to travel over water in order to make the passage at certain times, and any number of other useful bits. This sort of calculation is everyday in the Pacific Northwest, where a passage from my marina to one of my favorite anchorages can vary fom 4 to almost 8 hours (in a 5 kt boat) with as little as one hour difference in departure time. Other parts of my sailing ground may be effectively unreachable, with currents allowing for only an hour's clear time in 12.

To do this, I need to have access to all pertinent parts of route data; locate current stations along that route; create and store data structures associating current stations and waypoints; it would be nice to (in some future version) to access own boat data and polar along with GRIB wind data to make intelligent sailing predictions. Additionally, I probably need APIs to the tide prediction models to apply current predictions in 1 to 5 minute intervals. It would probably be nice to store the results for future use, and possibly to use for real-time route predictions.

So--is the infrastructure more or less there or am I tilting at a programmatic windmill? Is there a better way than plug in to go at this (ie, should I make a proposal to add this to core functionality instead?)

Thanks for reading and for your help in defining this project.

Walt Knowles
S/V Braesail
Everett, Washington

[nohal]

The existing weather routing plugin does use surface current data from gribs (and from the climatology plugin), if available.
There currently is no API for providing the current prediction information you talk about to the plugins, but it would be simple to add.
You should probably think about contributing to the WR plugin and ask for additions to the API as you step on stuff you need and is not yet available.
No, there is no better way to implement this than a plugin.

Pavel

[rgleason]

Here are several Tracker Requests regarding Coastal tides and possible ways to capture and use that data in routing:

1. NOAA is always improving their data, however RTOFS do not include coastal tidal data, in fact they do not include tidal data from such places as Gulf of Maine and Bay of Fundy! There are other good grib sources for current data, particularly for Europe, but in our area I've found this is the best we can get. NOAA works hard to improve its data products, so this may change, provided it is funded.

2. Use of Tide Harmonics for Routing Tracker #2313:
https://opencpn.org/flyspray/index.p...r=id&sort=desc

3. User Created Tide/Current Boundary using Ocpn_Draw: Github Issues #337
https://github.com/jongough/ocpn_draw_pi/issues/337

4. Feature Request: User Created Tide Boundary used in Weather_Routing: Github Issue #109 https://github.com/seandepagnier/wea..._pi/issues/109

5. Very Active Weather_routing Cruiser Forum Thread (put your posts about this here please) : http://www.cruisersforum.com/forums/...ng-100060.html

It would be helpful to have your thoughts represented in this thread and posted in Tracker. (you need to register first) Thanks.

[seandepagnier]

Originally Posted by waltknowles

Hi, all.

What I want to do is to link current data (from either primary or secondary current stations) to

Which data exactly?

Your best bet may be to find the best grib file that has the current data. Otherwise, it would be possible to add tidal current station support to the WR plugin.

Tidal currents are really difficult, especially with tidal stations, because they widely vary over a short distance. The typical tidal stations you a basic idea of tidal flow.

When the tide is above 4 knots, the tide may change on one side of the channel before the other. There can be back eddies. Above 8 knots, and anywhere with upwelling the current is basically unpredictable. None of this is shown in tide stations.

In these areas winds are highly variable as well.

So maybe you can use weather routing to find a useful prediction for start time, but actually calculating the route accurately depends on accurate input data for wind/tide and boat polar.

Such data basically does not exist in the scenario you describe.

[rgleason]

Sean, you have written this before, but it is good to remind us of the problem using Tide Data. Isn't it better to have something even if it isn't perfect?

For example, in crossing the Gulf of Maine, I looked all over for grib files that I could use for tidal data. I wrote University of Maine etc. I am sure they exist because this area has been studied a lot and also modeled with fluid dynamics because of tidal electrical generation possibilities (which I hope they won't do because it will change the ecology and flows). I could not get them.

But, the tides encountered are reasonably simple and shown in the tidal charts, so I wanted to get them into a grib format that Opencpn - WxRte could use, buy making a handmade representation. So then I thought why not use Boundaries with additional data to make the grib files needed. In rough approximation, you enter a boundary for an area and attach hourly time and current vector information (direction and magnitude). You just approximate that for the whole boundary then make more adjacent boundaries as needed along the route also with time and current vector. When the guid are used in weather_routing they get changed to grib format and used in the routing for tidal current.

It is certainly an approximation, no doubt, but it is better than what we have now. RTOFS gribs mission is to represent coastal tides but the model is a long way off from that still.

[waltknowles]

rgleason,
"All" I'm looking to do is use the harmonic data and standard prediction models (what comes from ../SharedSupport/tcdata/HARMONIC.IDX). I haven't looked at tidal predictions on NOAA GRIBs, because the time intervals are so wide as to be useless for the Salish Sea problem. Probably should for the Fraiser River freshet problem. Thanks for the reminder.

I probably shouldn't have even mentioned GRIBs, but I like to architect ahead, and in general. For first try, my features are so small as to allow me to pretend I don't have that resource.

I definitely will take a look at the code for weather routing, and do a bit of playing with it. However (and the proper answer may be RTFM), while it's built for OSX, it doesn't show for Android. Is there a quick and dirty "how to build plugins for Android" somewhere?

Thanks again. I'll lurk the weather forum, though probably not participate that much.

Walt Knowles
S/V Braesail
Everett, WA

[waltknowles]

nohal,

Thanks!

Walt Knowles
S/V Braesail
Everett, WA

[waltknowles]

boat_alexandra,

GRIBs are definitely a future enhancement, not a current requirement. Actually, for what I want to do, I'm not even sure that they'll ever move out of the "would be nice" column.

And do I ever know that current and tide stations aren't the whole shebang. In these waters, experienced mariners say that the current stations "are never correct, but usually useful". That is the goal for this plug in.

I'd give my windvane for raw access to the data and math behind the Canadian Hydrographic Service Current Atlas or the UW Puget Sound model, but haven't been able to get my hands on it. They, of course, show much more continuous detail, based on the dynamics of seafloor and size of water movement, and were that raw data available, it's probably interpolatable both in time and location. But even there, Local knowledge always wins.

Walt Knowles
S/V Braesail
Everett, WA

[rgleason]

Walt, we have gribs and they do work in WxRte. We don't have good coastal tidal current data in grib format.

What is your point?

[waltknowles]

Originally Posted by rgleason

Walt, we have gribs and they do work in WxRte. We don't have good coastal tidal current data in grib format.

What is your point?

My point is "We don't have good coastal tidal current data in grib format." And any interaction with weather data from a GRIB is v.2 or later, I'd guess.

My experience on the West Coast US may be different from yours, but I've not seen a GRIB (not saying they aren't there--I may not know how to ask for them) that has a grid resolution below 5 mi. I also don't remember a GRIB prediction set with less than 2 hour resolution. For weather, that's way more than adequate (at least for me), so I'm not complaining. But I just moved Braesail from close to our apartment a little north of Seattle to its summer berthing in Anacortes. For the first 20 miles of the move, 5 miles/2hours would be just fine. But the next 10-15 miles, I need to work with <1mi location and under 30 mins time resolution. At the end of the 15 miles, there is a tidal rapids where the main current can exceed 8 kts (that means Braesail, with throttle wide open can just stand still for the 7 hours or so of main flood). Not a good use of time or fuel. To cross that rapids in any reasonable way, I have about a 45 minute period on either side of slack that I have to hit. And then I have a passage between two smallish islands that can hit 3kts (about 1.5nm from the rapids), and then 4 nm on a tidal river that ebbs away from the marina.

So what I have to do is calculate the earliest time in the dying ebb to cross the Deception Pass, choose which of the little island passages will have a back eddy, and get around Fidalgo Island to pick up the flood about a mile into Gumes Channel. Miss that by 30 minutes, and I can add almost two hours to the last 10 nm of the trip. Miss is by an hour and a half, and I get to set on the hook for six hours, waiting for the next chance.

That one's easy, and I've done it enough times, I could probably do it with a Seattle tide table. Around the middle of Vancouver Island, it gets really complex.

So I have to use harmonic tides, a bit of local knowledge, and (if it's an area I don't know that well) a bit of math and my Excel spreadsheet (or, to be honest, I fire up the VM and my old trusty copy of Nobeltec, running on Windows XP).

If I can get to the data and the API, on the other hand, this isn't a really hard programming problem. It's really a storage (I want to store that this leg of the trip is governed more by harmonic station A and the next by station B) and UI task (how do I link station A to leg 3 and station B to legs 3 and 4, and then how do I report how the projected time of travel changes over time--that's probably just a graph to start out). That sound to me like a plug in for OpenCPN, and I'm looking for people with more experience to tell me that I can probably pull that off, because they think that the data structure can be subclassed and the API is robust enough to probably support the plugin. Then I get the fun task of scraping the rust off my C++ chops, and learn how to do native programming on Mac and Android (instead of architecting and building big database/web systems in *nix, which was where I was last coding.)

Make sense?

Walt Knowles
S/V Braesail
Everett, WA

[nohal]

Originally Posted by waltknowles

My point is "We don't have good coastal tidal current data in grib format." And any interaction with weather data from a GRIB is v.2 or later, I'd guess.

My experience on the West Coast US may be different from yours, but I've not seen a GRIB (not saying they aren't there--I may not know how to ask for them) that has a grid resolution below 5 mi. I also don't remember a GRIB prediction set with less than 2 hour resolution. For weather, that's way more than adequate (at least for me), so I'm not complaining. But I just moved Braesail from close to our apartment a little north of Seattle to its summer berthing in Anacortes. For the first 20 miles of the move, 5 miles/2hours would be just fine. But the next 10-15 miles, I need to work with <1mi location and under 30 mins time resolution. At the end of the 15 miles, there is a tidal rapids where the main current can exceed 8 kts (that means Braesail, with throttle wide open can just stand still for the 7 hours or so of main flood). Not a good use of time or fuel. To cross that rapids in any reasonable way, I have about a 45 minute period on either side of slack that I have to hit. And then I have a passage between two smallish islands that can hit 3kts (about 1.5nm from the rapids), and then 4 nm on a tidal river that ebbs away from the marina.

So what I have to do is calculate the earliest time in the dying ebb to cross the Deception Pass, choose which of the little island passages will have a back eddy, and get around Fidalgo Island to pick up the flood about a mile into Gumes Channel. Miss that by 30 minutes, and I can add almost two hours to the last 10 nm of the trip. Miss is by an hour and a half, and I get to set on the hook for six hours, waiting for the next chance.

That one's easy, and I've done it enough times, I could probably do it with a Seattle tide table. Around the middle of Vancouver Island, it gets really complex.

So I have to use harmonic tides, a bit of local knowledge, and (if it's an area I don't know that well) a bit of math and my Excel spreadsheet (or, to be honest, I fire up the VM and my old trusty copy of Nobeltec, running on Windows XP).

If I can get to the data and the API, on the other hand, this isn't a really hard programming problem. It's really a storage (I want to store that this leg of the trip is governed more by harmonic station A and the next by station B) and UI task (how do I link station A to leg 3 and station B to legs 3 and 4, and then how do I report how the projected time of travel changes over time--that's probably just a graph to start out). That sound to me like a plug in for OpenCPN, and I'm looking for people with more experience to tell me that I can probably pull that off, because they think that the data structure can be subclassed and the API is robust enough to probably support the plugin. Then I get the fun task of scraping the rust off my C++ chops, and learn how to do native programming on Mac and Android (instead of architecting and building big database/web systems in *nix, which was where I was last coding.)

Make sense?

Walt Knowles
S/V Braesail
Everett, WA

Walt...

Yes, you can do it. Not everything you will need has a public API at this moment, let us know when you need something added to it or implement it yourself and send a patch - it really is not rocket science to extend it most of the time.
If you will wait until someone else magically does implement all your prerequisites before you start actually doing something, your wait will be eternal - we usually do have other stuff to play with that is also fun...

Pavel

[rgleason]

I like the idea of linking the harmonic data for a station to a "leg", but doesn't this then define the route? You've already got the leg, or are you instead suggesting that WxRte will use a certain tide station from point A to point B and make an optimal route from point A to B? I think the later.

I had suggested using Ocpn_Draw boundaries, and manually entering vector data, but Walt's idea could be used too. Tie a certain Current station to a Boundary. There are lots of Tide/Current stations in the US, but are there enough to be useful? They are not always accurate due to moon and pressure etc, but they are reasonably plentiful.

Another way to think of this is as Sean suggests, the tidal current stations may represent a restriction point where the current is particularly fast and drops off quickly as you get through or away from it. Other tidal currents are more representative of the overall conditions, in an area. Perhaps there is a way of making a mode that creates virtual "boundaries" of influence for tidal stations which defines extent of influence and how fast the particular current drops off by distance from the point? Maybe the user selects the one or two tidal current points to use for this calculation? A new current grib is made. Then wxRte uses the resultant current data somehow through the grib interface?

This would be a completely separate plugin to create a grib file from tidal current data.

If this is possible, then the user could pick point A at Seattle and point B at Anacortes and run a series of routing starting at various times, of course there is the 5 hr pause to consider... anyway. This is probably difficult to do.

PS my point about RTOFS is exactly your point. Do you by any chance know Tony Howe?

[seandepagnier]

The simplest option would be to either generate grib files from tidal stations, or add support to weather routing to use tidal stations for current.

Claiming other programs support this "feature" is misleading, because they may do something, but whatever they calculate is flawed due to insufficient data.

We just don't have accurate current predictions near land in 2018 at high enough resolution. Especially true for strong currents. Local knowledge, and experience are needed.

For off-shore current with very high resolution, try RTOFS, already supported

[rgleason]

Sean, I think you are right about lack of tidal current data for large areas of our coastline. However because it is such a large factor in the Puget Sound, there are many stations.

This is the perfect reason to develop this aspect of weather_routing, and because it is suited best for Puget Sound / Vancouver it is appropriate that Walt develop it with some advice from others. It may be useful elsewhere but the best reason to develop it is in Walt's home grounds.

All the more power to him. Go for Walt! I will be a willing tester.
PS: The NE is pretty dense too.

[waltknowles]

Originally Posted by nohal

Walt...

Yes, you can do it. Not everything you will need has a public API at this moment, let us know when you need something added to it or implement it yourself and send a patch - it really is not rocket science to extend it most of the time.
If you will wait until someone else magically does implement all your prerequisites before you start actually doing something, your wait will be eternal - we usually do have other stuff to play with that is also fun...

Pavel

Pavel,
Thanks! And thanks for the reminder that since this is open source, I can make addition to the API when I need them (mind you, no one else will be able to use the plug in until they are accepted!).

This is basically the "go ahead" to start diving in. A quick scan through the postings here lead me to believe that most of the work is being done (as one might expect) on Windows. Are there a list/registry/subgroup for OSX or Android developers. Since I'm spinning back up from a long time away from a text editor, it would be nice to have conversation partners for specific platforms.

Thanks again,
Walt Knowles
S/V Braesail
Everett, WA