Current-informed routing plugin

[Maelruan]

I wonder if this topic has elements similar to those discussed 2 years ago under http://www.cruisersforum.com/forums/...-170851-2.html.

See Paul 2's Post #28: "Re. reference to PC Maritime, yes I remember using 'PC Wayplanner' which I think was from them, a pre-Windows 'DOS' program on floppy disk. Apart from the all-important CTS correction, that bargraph was great for quickly illuminating best and worse times to depart - so obviously had a good tidal database - why have we lost all that ?"

The programme used all the UKHO Tidal Diamonds/Harmonics along a route to calculate the bargraph Paul 2 mentions. It last worked on a DOS session of Win 95. Recently it came to mind again while planning the optimum time for a visit to family on the north shore of Long Island Sound who wished to make the trip via Hell Gate & down the East River. By running thru' a few lunar cycles with OTCurrent & studying the tidal arrows I could find the optimum time to pass the critical point, and propose travel arrangements accordingly. PC Wayplanner provided a broader spread than that. I still have the 3.5" floppy disks & can mail them to a recommended developer. I no longer have the hardware for these.

[waltknowles]

Since this is a "real world" problem, it might clarify things (and generate more good ideas) if I shared my actual use case. I mentioned that I moved Braesail from Everett to Anacortes a couple of weeks ago. My wife wanted to know how late she could sleep in, and, even though I know the area like the back of my hand, I wanted to tie up while it was still dusk. With an 8-hour passage time, that meant that departure had to be between 0600 and 1200. Needed to be on Saturday (loosing the slip the next day), and there really are only two routes: up Saratoga Passage or around Whidbey Island. Rather not do Whidbey--it's longer, and I need to allow for a wind vs tide situation off Bush Point. I'm too tall to go under the Swinomish Channel Bridge. Here's the route: (https://drive.google.com/file/d/1YRC...ew?usp=sharing)

And here's what Nobeltec generates (https://drive.google.com/file/d/1UpH...ew?usp=sharing)


Note that big arrow next to Deception Pass. It should be considered impassable when currents get above 2 kts due to turbulence (I've seen the Pass spin and spit out backwards a big planing hull. Depending on winds, it also can develop really nasty standing waves).

There really is no significant optimization here from the standpoint of route. Choose one. What's the best departure for transit time?

If you open up this area, you will notice that there are lots of secondary current stations. However, because of the bathyscape, averaging or nearest station to boat location will actually give incorrect predictions (and may give unsafe prediction as well); the user needs to know (or guess) how seaforms will affect tidal prediction.

Conclusion: I can build something useful, but a perfect solution is impossible (my guess is that's it's an NP problem, but I'm too lazy to figure it out). So the question becomes: "what's the most useful solution for the least work?" It seems to me that proceeding from mariner's knowledge (mark up the route with station data and make a prediction) is pretty close to that mark. The other potential solution is to digitize CHS (https://www.amazon.com/Current-Atlas.../dp/0660608782 ) and UW (https://www.amazon.com/Tidal-Current.../dp/B00LQTGVMU ) data to at least 0.05 degree precision could be useful, but neither of these data sets are public domain.

End conclusion: mark up the route and make predictions for v.1

Cheers,

Walt Knowles
S/V Braesail
Everett, WA

[rgleason]

Ok, so it becomes a powerboat solution, much simpler, and may be useful for sail sometimes.
Dave forget what I said below then.

[rgleason]

I was thinking about this some more.

Sean has made improvements to the Polar Editor such that two data points are needed and an entire polar file can be generated using your boat characteristics. This would possibly make it very easy for a powerboat to build a polar which could be used in WxRte. See his Post Here

So why not let wxRte do what it does well for powerboats too,
and just do the more straightforward tide interpolations, withOut the table modifications for tidal current points that I had I suggested?

That way you'd be improving one plugin, and serving both power and sail, rather than branching the plugin to serve power. Maybe you could even have a follow established route mode?

But then maybe Sean wouldn't like someone messing with his plugin for power? Which needs to be respected I think. But I know Dave "sails" at opportune times with a careful eye on efficiency. That is not at all unlike sailing, so why not have the plugin save powerboat fuel? Oh Well.

I remember Route Planner. I thought it was good at what it did.

I doubt that the tidal current interpolation will know that the least current is often in the shallower areas, but it will certainly be an assistant.

(When Warren said our ideas intersected orthogonally, I guess that is true.)

[bdbcat]

Rick...

At least in the US East Coast ICW, we see many, many "powerboats with masts". Sailing here is often impractical (pace Sean) due to twisting courses, little room to tack, shallow margins, etc. The route to steer is not much subject to interpretation. "Stay between the Reds and the Greens." These sailboats motor up and down the channels, hundreds of inland miles per season between New England and Florida.

I think they know their estimated still-water speed under power quite well. And the tidal current predictions for the ICW are pretty accurate. So, again, the problem of knowing the best time to depart, and ETA calculation, is real.

So I don't exactly see it as a "sail/power" question. In fact, it is even more interesting to a sailboat under power, since they usually really wish to minimize time underway (under power).

But, of course, different cruising grounds bring different challenges....

Dave

[rgleason]

Yes. You flipped the argument, and its equally valid. I would have use for the plugin. Is it an extension of OTcurrents?

I have been hoping to improve coastal tide current data in weather_routing for a long time, so its hard for me to give that up, maybe that will happen in baby steps.

[waltknowles]

Originally Posted by rgleason

Yes. You flipped the argument, and its equally valid. I would have use for the plugin. Is it an extension of OTcurrents?

I have been hoping to improve coastal tide current data in weather_routing for a long time, so its hard for me to give that up, maybe that will happen in baby steps.

I don't see this as a sail/power distinction (other than as a sailor, I think I need it more because I'm slower and have more wetted surface than my power-boating sibs), unless you are just using that as a shorthand for "controlled for speed/direction vectors".

That's part of the reason I posted the use case. If the solution can't tell me "Leave by 0930 or you won't make Deception Pass", I'm not interested in coding it. It would be very handy to know that there is a local maximum of effective current flow on the route from 0800 to 0900, because then I know that I could sail the route (leaving at 0800), rather than hoist the iron genny.

That being said, the idea of preparing a time-based vector field for currents (i.e., a GRIB) that can be used for sailing prediction in these waters really intrigues me. I'd love to have such a tool for a lot of my sailing (longer--4hrs or so--passagemaking does exist, and weather and wind optimization would be great). My concern, after playing with WeatherRoute PI, is that putting my requirements (my "nice to haves" fit pretty nicely) on it just distort it. So maybe you can help me understand:

1. There are lots of tidal features around here in the 1-2 nm distinction range. The prime channel leading to Georges Strait (Hale Passage) from one of my previous marinas flows in opposite direction to Rosario Strait. Lummi Island is less than a mile wide. How do you handle that on a GRIB when it is below reasonable resolution?
2. Features like Deception Pass are obstructions at most times, but for a couple of hours each day are perfectly passable. Again, how would I build a GRIB that conveys that information?
3. While someone suggested that I could do multiple runs of WeatherRoute to find the optimal departure time, it seems that this is exactly the busy work that I want to avoid. Is it computationally effective to run WeatherRoute at 10 minute departure intervals over an 8 hour range to interatively discover minima and maxima of passage time?

And of course, I'm not looking for a tutorial on writing GRIBs, but "go look over there" for features in the specification that WeatherRoute might support to get us to a conclusion.


I took a look at OTCurrents. I'm not entirely certain what it does other than set the time base of OpenCPN. I get the same effect when I use the GRIB plug in with the tide arrows on. It's definitely code I need to check out, but I don't think that this is a fork of that project.


Thanks,
Walt Knowles
S/V Braesail
Everett, WA

[rgleason]

Walt, I have a large NOAA paper fold out of currents in Long Island Sound to Newport I believe, and it may show Buzzards Bay. In 1 hour increments from low to high tide. I'd love to get that information into grib format. That would be a start. I was thinking of doing that for Gulf of Maine too, but I could not find reasonably graphic tools with which to manipulate a grib file. There are some very powerful grib tools for extracting and manipulating data, but I don''t know of any for "creating data" or converting it.

I am no grib guru but I believe wxRte does it's own interpolation of grib data in order to get smaller time intervals in the isochrones. Perphaps that would help, since you may want a small area, finer grained grib for Deception Pass, (as we would for Plum Gut, Race Rock and Watch Hill Point).

Then the other question is how to insert a "Defined Route" mode into the calculations. It would certainly be quicker, it is essentially a subset of what wxRte does now, however there is no need to create all the isochrones, you you just need to create an isochrone for just the route (a lot less calculation).

So that''s basically a button "Defined Route" that pops up a Route Manager choice of routes. Then enter your thru the water speed or have it defined in the routee. Once the route is selected wxRte goes into this simple mode that just calculates the routes isochrones, once complete, you'll have to figure out a new interface to show the results as you want.

I expect Sean will have some interesting things to add. ... of course I am not a programmer so my concepts are very suspect!

Later on after that is working and we've figured out better tools for doctoring gribs from paper. It might become 2D instead of 1D.

One thing I'd like in this, is a way to align the grib files with local experience at certain tide station, it's basically a way to calibrate the grib with time.

Maybe there is some opensource basic fluid dynamics program that that could be used to tie the current harmonics together and create a grib file? That sounds like a pretty complicated thing.

It exists https://www.openfoam.com/
We are just interested in the surface current 2D really. Would you have to do all the calcs for 3d to get good results? IE how much does the depth matter? Isn't the land boundary/constraint the larger influence? Maybe I am trying to simplify too much.

[waltknowles]

Canadian Hydrographic Service and the University of Washington, in two separate projects, generated current mapping for most of the coastal waters of WA and BC, back in the 1980s. Resolution is one hour, and anywhere from about 3nm to 15nm. Total of something like 150 distinct charts of the area with a combination of bathyscapic current prediction and actual observation. Then various entities publish yearly tables to help you figure out which chart fits (let's see, 4pm today is two hours past lower high on a neep tide, with a tide fall at Point Atkinson less that 6' but greater than 3', so you use chart 47B for the San Juans, for example--made up, by the way, but you get the idea) Anybody with a shred of common sense carries these books on their boats and I will often have them in the cockpit.

I haven't found these books in usable electronic format (I actually scanned the Puget Sound and Georges Strait books and wrote a little app to make the task of finding the right chart and looking at it a little easier), and all of it seems to be under copyright. I've poked a couple of friends in the marine instrumentation industry to see if they have any way of getting the data a data, rather than visualization. Don't hold out much hope, but I'll keep trying.

Of course, turning chart 47B from an array of 315º/2kt at 2.5nm grid into a GRIB is a pretty simple exercise (much easier than getting my hands on the data!). Making a computer make sense of it, any way close to what happens in my looking at it for 10 seconds, is the big problem.

The really useful part would be to create a crowd-source editor, allowing user input of observation to add detail and accuracy.

And if we do this for both coasts and Canadian waters (and probably North Sea, and .....), we've got a project bigger than OpenCPN, and all I wanted to know was how late I can sleep in and still get through Deception Pass ;-)

Walt Knowles
S/V Braesail
Everett, WA

[rgleason]

Walt, maybe we should wait for someone else to do it?
Manual entry into Excel? -big job.
Calc distances between points.
Interpolate current between.

[waltknowles]

Rick,
"maybe we should wait for someone else to do it?"
That's why a plugin/expansion of the existing Routes Manager functionality makes the most sense--in the short term--to me. Ultimately, once one has chosen the optimal route (whether by drawing it or using WxRte), you still have to do the vector math for ETA-class calculations, by crossing currents with course. So, the project is:
1. Select and store current relationships
2. Do the vector math
3. Graphically display results
--------end v.1
4. Automate generation of current relationships
5. Graphical editing of current relationships
6. Integrate superclassed routes with GPX and Route Manager storage
---------end v.2
7. Optimize course generation from existing (CHS, UW, etc) data sets
8. Figure out how to provide ranges of of solutions in a computationally finite way
9. Integrate? this project with WxRte?
---------end v.3

Probably sometime in v.3, there will have to be another project that generates GRIBs that can be useful in my Everett to Anacortes use case. However, I don't think that this is necessarily part of this project. My own guess is that this is an enhancement to OpenCPN.org, not to OpenCPN itself (of course, being open source, it could be hosted on a local machine for cruisers who need to generate these independent of the internet.)

Walt Knowles
S/V Braesail
Everett, WA

[rgleason]

Walt, that's interesting:
1. Bdbcat may want to keep this programming separate from the main program, but he's interested in it, so who knows?
2. WxRte optimization already does wind & current gribs, and if you limit its work with a defined route it will be much faster. Perhaps you add some parameters to identify the first and last start time calculation and the interval.
3. Then the problem becomes input of interpolated current stations data and output of results.
4. There are some Feature Requests for Route Manager related to
See Route & Mark Manager Departure Time, ETA planning Date & Time, ETA planning Now, ETA during Passage, and ETA intermediate.
There is still some work to do for the Route Manager interface (imho) and it would be nice if the option to have different speeds at each leg were a little more apparent in the UI with its own dedicated column ( I take that back, it has its own speed column now, when did that happen?)
5. Tracker has a lot of "RM" Feature Requests, (sort it by summary) some of them would apply to this discussion.
https://opencpn.org/flyspray/index.p...mary&sort=desc which is a manual estimation of current, hand entered by leg.
and maybe
https://opencpn.org/flyspray/index.p...desc&pagenum=2

So the first step would be to put a current column in there with speed and direction, but I like your steps.
This makes sense to me: " chosen the optimal route (whether by drawing it or using WxRte)"

[rgleason]

And then there is an opencpn.org grib download site that includes interpolated coastal tidal gribs that have been crowd "verified/modified" which will drive users to site.

[waltknowles]

Rick,
I think I've got a good picture, thanks to your great help. And the scan through flyspray was useful as well.

It's now time for me to hide back under my rock. I need to get a solid understanding of the Route Manager and Tides subsystems in the main product and nohal's tide display plugin. I also need to get at least a cursory understanding of WxRte from both the user and the programmer side. That, and the objects I have most to work with over the next couple of months have names like YanmarFuelInjector instead of CurrentCalculator, means that I'm going to quiet mode. Feel free to toss ideas; it's been incredibly helpful. In a couple of months, I'll hope to come back in the appropriate fora with a proposal or two.

Walt Knowles
S/V Braesail
Everett, WA

[wholybee]

Somewhat related. How hard would it be for Grib_pi to load and use 2 grib files at the same time?

One could be wind data from whatever source you prefer, the other current data, from a source currently unknown. There are other uses for loading multiple gribs as well.

In SF bay (where currents can be 5+ knots), the free tide books everyone hands out also have current data. I've also been to web pages where you give it a time, and it plots the currents at that time. So the data is out there, and predictable enough that you shouldn't need to rely on current stations, but could calculate it for a given time.

My thought would be to use this knowledge to create a grib, and load that with your weather grib.