Current-informed routing plugin

[waltknowles]

Originally Posted by 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?

Rick,
And now I understand where the disconnect in our conversation happened. Yes, I theoretically "know" the route ahead of time, and may even have already encoded it as an OpenCPN route. I'm just trying to use/dodge currents along the way.

We are trying to solve orthogonal problems, but I think (and this may be where you were pushing me) there might be an intersection. Wx creates a route, optimizing for obstructions and assistance, I already have a route, and am trying to optimize travel time for obstructions and assistance.

Another way of cracking my problem is to generate a custom GRIB that would be of sufficient precision to be useful. For the most part, this solution would work for the northwest coast where there are sufficient published models. I could digitize the published CHS and UW models of hourly current flows, add in the harmonic data, and generate a GRIB (theoretically--I haven't looked at the file fomat in a long while) that models surface currents at 1nm / 15 minute. For this kind of coastal planning, it probably would normally not be larger than 30x30nm.

So some questions:

• What level of obstacle detection does WeatherRouting PI do? And if I hand it 40 GRIB charts (10 hrs at 15 minutes), half of which have a current obstacle (eg., the Skookumchuck Rapids are unpassable except at +/- 40 minutes of slack) and half have various currents from +/-4 kts, what will the router do? (Mind you, I don't even know how I'd code that on a GRIB at present. About all I know is "wind at position")
• Coincidentally, can one set up rules for coastal obstacles (don't get within 50 yards of that rock) that are distinct from open water (miss that island by a mile)?
• It looks like WeatherRouting PI lets me set a start time, origin, and destination. Reading through the user docs, a start range would seem to be a substantial distortion of the user model. Were I to take this approach, it seems that a code fork to a new plug in would be a better approach than enhancing WeatherRouting. Am I seeing that correctly?

Also, what's the time frame for WeatherRouting on Android? And it looks like Dave Register is restarting version numbers for the Android port. It's at 1.10. Is it compatible with the 4.8.2. demand of WeatherRouting?

Thanks!

Walt Knowles
S/V Braesail
Everett, WA

[waltknowles]

Originally Posted by boat_alexandra

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

boat_alexandra,

RTOFS is wonderful, but it's not inshore (but you know that).

We've got 150 years of prediction in the NW that's sigma 4 within 20 minutes and 15% of current speed accuracy on hundreds of points. 'Taint perfect, but it's good enough for this sailor.

And having used the Nobeltec implementation for 25 years, it's "good enough". I'm just trying to figure out how/whether to write something "good enough" for OpenCPN.

Walt Knowles
S/V Braesail
Everett, WA

[nohal]

Originally Posted by waltknowles

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

Well, I wonder where this the "most of the work is done on Windows" comes from. As far as I can tell there is exactly 0 of the active contributors to the core application using it as their primary platform.
Yes, something like 75-80% of the OpenCPN userbase is on Windows, so we must target it primarily and we get most of the user testing feedback from it, but my primary development platform is currently macOS and the rest of the devs regularly contributing to the core app are running Linux most of the time. Not that there would be much difference, the code is still C++...

Pavel

[waltknowles]

Originally Posted by 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.

Thanks, Rick.
I'm told that there is reasonable data for other areas (Japan, Northern Europe, etc) where substantial (diurnal) currents are navigation issues.

It will take a while to fire this up--heck, I haven't even downloaded sources to start reading, and I think I have a compiler somewhere on this box--and I'm also pondering whether this is an independent project that may merge sometime in the future with WeatherRouting PI or is a fork. I'll probably be back with nubee questions later on.

Is there a best practice for submitting design documents for support/review/rotten tomatoes in this project? The developer docs are a bit sketchy on procedure (as would be expected for something that grew from a single developer scratching his own itches).

Thanks!

Walt Knowles
S/V Braesail
Everett, WA

[nohal]

Originally Posted by waltknowles

Is there a best practice for submitting design documents for support/review/rotten tomatoes in this project? The developer docs are a bit sketchy on procedure (as would be expected for something that grew from a single developer scratching his own itches).

Thanks!

Walt Knowles
S/V Braesail
Everett, WA

0) Fork on github


1a) If you need to discuss something, open a github issue or discuss it on this forum if you also want end user input.
1b) If you need to describe something bigger, describe it in the wiki in your fork and open a github issue or discuss it on this forum if you also want end user input.

[waltknowles]

Originally Posted by nohal

Well, I wonder where this the "most of the work is done on Windows" comes from. As far as I can tell there is exactly 0 of the active contributors to the core application using it as their primary platform.
Yes, something like 75-80% of the OpenCPN userbase is on Windows, so we must target it primarily and we get most of the user testing feedback from it, but my primary development platform is currently macOS and the rest of the devs regularly contributing to the core app are running Linux most of the time. Not that there would be much difference, the code is still C++...

Pavel

Pavel,
It was a completely unscientific impression from scanning the documentation and a random selection of forum posts. That most are working on Linux is good news, as that was my last dev platform before going all medieval. And I may come pester you about macOS issues, if you don't mind.

Is anyone besides Dave Register actively targeting Android (and is anyone working on a future IOS port?)

Walt Knowles
S/V Braesail
Everett, WA

[nohal]

Originally Posted by waltknowles

if you don't mind.

I don't, someone has to do it

Is anyone besides Dave Register actively targeting Android

No

(and is anyone working on a future IOS port?)

No. And as it is impossible to distribute GPL licensed SW through the Appstore, unlikely someone ever will.

[bcn]

Walt,

Android - and here the plug-in architecture - is completely done by Dave.

iOS is not in reach until Apple changes their legal conditions for the App store. GPL licensed Apps are not accepted.

Hubert

[waltknowles]

Thanks!

Walt Knowles
S/V Braesail
Everett, WA

[rgleason]

Originally Posted by waltknowles

Rick,
And now I understand where the disconnect in our conversation happened. Yes, I theoretically "know" the route ahead of time, and may even have already encoded it as an OpenCPN route. I'm just trying to use/dodge currents along the way.

We are trying to solve orthogonal problems, but I think (and this may be where you were pushing me) there might be an intersection. Wx creates a route, optimizing for obstructions and assistance, I already have a route, and am trying to optimize travel time for obstructions and assistance.

Another way of cracking my problem is to generate a custom GRIB that would be of sufficient precision to be useful. For the most part, this solution would work for the northwest coast where there are sufficient published models. I could digitize the published CHS and UW models of hourly current flows, add in the harmonic data, and generate a GRIB (theoretically--I haven't looked at the file fomat in a long while) that models surface currents at 1nm / 15 minute. For this kind of coastal planning, it probably would normally not be larger than 30x30nm.

So some questions:

• What level of obstacle detection does WeatherRouting PI do? And if I hand it 40 GRIB charts (10 hrs at 15 minutes), half of which have a current obstacle (eg., the Skookumchuck Rapids are unpassable except at +/- 40 minutes of slack) and half have various currents from +/-4 kts, what will the router do? (Mind you, I don't even know how I'd code that on a GRIB at present. About all I know is "wind at position")
• Coincidentally, can one set up rules for coastal obstacles (don't get within 50 yards of that rock) that are distinct from open water (miss that island by a mile)?
• It looks like WeatherRouting PI lets me set a start time, origin, and destination. Reading through the user docs, a start range would seem to be a substantial distortion of the user model. Were I to take this approach, it seems that a code fork to a new plug in would be a better approach than enhancing WeatherRouting. Am I seeing that correctly?

Also, what's the time frame for WeatherRouting on Android? And it looks like Dave Register is restarting version numbers for the Android port. It's at 1.10. Is it compatible with the 4.8.2. demand of WeatherRouting?

Thanks!

Walt Knowles
S/V Braesail
Everett, WA

"Wx creates a route, optimizing for obstructions and assistance, I already have a route, and am trying to optimize travel time for obstructions and assistance."

1. WxRte does "Land Detection using GSSHG using High Resolution.
2. I believe Did-g has written an algorithm to extend that an make it more flexible so that distances can be set. It may even look at depth of vector charts. Hopefully that wil appear at some point.
3. Yes, WxRte can optimize your route for the current too, Sean or Pavel would be best to answer your questions about the greater resolution of the grib files that would be needed. I know WxRte does interpolation of gribs to do the routing calcs.
4. The way WxRte can be used to determine departure time is to set up identical configurations with departures 15 minutes or 30 minutes apart bracketing the departure time you eyeball as best and then just run them and select the best time. It will compute multiple configurations at the same time and uses multiple threads.
5. So you'll get the optimal route and the optimal departure time.

Regarding your other good questions about programming Pavel is obviously a good resource, but there are others too.. Sean, Tdan, Stelian, Ptulp (Mac). Also there is another programmer interested in getting plugins migrated to Android, his name is Oliver [mini-transat]. He has programming experience and I don't know if he uses the Mac. There are many others I've not mentioned.

I think you've connected with the community now, and I hope Mini-Transat will too as this additional programming experience will help!

[seandepagnier]

[*]What level of obstacle detection does WeatherRouting PI do? And if I hand it 40 GRIB

You can draw boundaries on the chart as polygons using the draw plugin.

Originally Posted by waltknowles

We are trying to solve orthogonal problems, but I think (and this may be where you were pushing me) there might be an intersection. Wx creates a route, optimizing for obstructions and assistance, I already have a route, and am trying to optimize travel time for obstructions and assistance.

Now maybe "good enough" means you never play the currents to your advantage, but intend to sail the same route regardless of conditions. You could draw a narrow boundary around your route,

If you care about sailing powered by wind, and current, then you definately do not "already have" the route because it changes _every_ time. Even in narrow inshore waters.

Another way of cracking my problem is to generate a custom GRIB that would be of sufficient precision to be useful.

EIther that, or improve weather routing to use tidal stations

It's a possible start to make gribs. Maybe a good one because it allows you to better visualize the current data spatially in the way the route uses it.

You should know this will be very innaccurate near land. There just aren't enough tidal stations when the current is a few knots different 50 meters away. Maybe design it so you can tweak it to improve results with time.

Also it covers only tidal currents... here we have wind driven tides which is completely different and much more difficult to predict. There is also river outflow.

Another interesting problem is to record your route exactly, and somehow analyze it using the best grib data from just before you left. You need wind and water sensors as well as gps. From there, you can improve the polar, and build up corrections to gribs for both local wind and current variations. If you sail the same waters enough times (perhaps hundreds) you could begin to get better corrections, the same way as experienced human learns.

[bdbcat]

Sean...

This is a reasonable project.

Consider an east coast route that you just took, and I take twice a year:

Cape May, NJ, up the Delaware Bay, through the C/D canal (motoring), and into the Chesapeake to maybe Bohemia River.

If one assumes a reasonably constant cruising speed, then there IS an optimal time at which to leave Cape May in order to minimize the transit time. It is only a matter of finding it. The current reporting stations are dense enough to allow an iterative calculation. There are only a few critical waypoints to consider. The route is too long to do in one tide cycle, which complicates things. Resulting transit time can vary by at least 30%, depending on when in the tide cycle you leave and your cruising speed.

But the problem has a solution, and I would like to see it automated.

Manually, I spend about 20 minutes building test runs on paper, and then eye-ball interpolating to get a reasonable solution. Not perfect, but better than random.

So, Good Luck, Walt. I look forward to your progress.

Dave

[seandepagnier]

Originally Posted by bdbcat

Sean...

This is a reasonable project.

Consider an east coast route that you just took, and I take twice a year:

Cape May, NJ, up the Delaware Bay, through the C/D canal (motoring), and into the Chesapeake to maybe Bohemia River.

If one assumes a reasonably constant cruising speed, then there IS an optimal time at

Despite motoring, I'm guessing wind still affects your speed, and you have polars to account for this?

which to leave Cape May in order to minimize the transit time. It is only a matter of finding it. The current reporting stations are dense enough to allow an iterative calculation. There are only a few critical waypoints to consider. The route is too long to do in one tide cycle, which complicates things. Resulting transit time can vary by at least 30%, depending on when in the tide cycle you leave and your cruising speed.

But the problem has a solution, and I would like to see it automated.

Manually, I spend about 20 minutes building test runs on paper, and then eye-ball interpolating to get a reasonable solution. Not perfect, but better than random.

I am probably biased, but I still favor a weather routing solution. The problem of optimal start time is already well supported. Additionally, you can easily compare alternate routes, that might avoid adverse currents at certain times which is not possible with a fixed route.

This certainly exists in the delaware bay, as the current is not the same everywhere, and a longer route might be faster. The weather routing plugin also supports anchoring in adverse currents, and much more.


In any case, to perform this calculation, you need to find the current at any location.

I never really did this for weather routing as I am not sure how to interpolate between them. There are many possible options:

1) use nearest station if it is within half mile
2) find 3 closest stations you fall in the triangle of, and interpolate them, and maybe extrapolate if outside?
3) average all tidal stations within a 2 mile radius, weighting each one by the inverse square of their distance.

Other ideas?

[rgleason]

Certain locations with restrictions, both by land or depth with high velocity currents, are also situated with quickly widening or increasing depths so the current velocity drops quickly or increases quickly.

Could there be a user/adjustment for this factor? Maybe a lookup Current Table?
Examples at the mouth of Long Island Sound:
Plum Gut between Orient Point and Plum Island.
Race Point off the west end of Fishers Island, NY.

[bdbcat]

Rick...

I think this is becoming way too complicated. We will never have the detailed knowledge of conditions that will allow optimization of a route in inshore areas subject to strong, variable tidal flows.

For the problem at hand, we already know the route. There really is not much choice from Cape May to Bohemia. Stay in or near the channel, steer to avoid crab traps and large ships. Avoid obvious adverse conditions.

What we want is to know the best time the leave Cape May for minimum transit time, using the selected route and estimated still-water boat speed.

I'm sure the same question applies from, say, Nantucket to Onset.

And that is a useful question to answer.

Thanks
Dave