Feature Request/Idea User created Tide/Current Boundary.

[rgleason]

Weather_Routing <-----Plugin API -----> ODraw Boundary https://github.com/seandepagnier/weather_routing_pi/issues/109

This idea would be a manual way to bridge the poor inshore tide/current representation of RTOFS and other ocean current gribs and the Tidal Stations and harmonic file, which is not easily interpolated because currents drop off and change fast.

The idea would require agumenting the Plugin API to include the User Current information I think, or perhaps that could be done in Weather_routing, but that application does not handle gribs really. The other way is to involve the Grib_pi program with boundaries....

Here is what I would like to be able to do:

1. Draw a boundary.
2. Attach a simple current matrix to the boundary.
3. Have Weather_routing recieve the tide/current boundary and include that grib data in its calculations for optimal route.
4. The Tide/Current Matrix would be a Table representing time + tide/current vector ( velocity and direction). Table | Time | Direction | Velocity | | __ | ___ | __ |

Would there be a limit on how many time entries? It would be nice if it could be flexible about time intervals (1hour, 2hr, 3hr, 6hr, 12hr) and would allow a large number of time records.

Also it would be useful if you could make 2 or three of these along the general route expected.

That's the idea anyway. (It does use vectors with ODraw!)

[rgleason]

Jon, is this idea to allow the user to define a boundary with lets say, hourly current vectors to be used with weather-routing?

You could add multiple boundaries adjacent for changing conditions say near a point where the currents are more aggressive, or where the velocity changes. I understand that these user entered gribs would only be approximations.

If you think this is nuts, I can close it. Best Rick

[jongough]

Rick, Not quite sure I get how the boundaries get the tidal information, or even if they do or should. The weather routing uses tidal information from gribs but does it interact with the grib_pi, I didn't think it did, but....

Anyway, I am trying to keep OD for drawing so I could get it to draw vectors within a boundary, possibly, and then this 'information' could be access via the API. The next question is how many tidal information points are to be maintained in a boundary, how would any more than one be handled from an API perspective. I really don't have a feel for this requirement as I don't use weather routing or gribs, so I am really a complete newbie at it. Is it possible for you to draw (photo of a hand drawing, use some simple drawing program with simple boundaries and tides, etc.) what you think you want and a quick flow of how you think the information should be handled? This may give me a better understanding of what you are asking for.

Regards Jon

[rgleason]

Not quite sure I get how the boundaries get the tidal information, or even if they do or should. Jon. It would be from direct user input of the Vector Direction and Vector Amplitude (knots).

Problem: Current and Tidal information that is in the harmonic tables in OpenCPN is useless to Weather_routing. Weather_routing does not use it and cannot use it. The "currents" in Climatology are for known ocean currents such as the gulf stream. Weather_routing will use these currents. As a result Coastal and Inshore routing does not have any information for a most critical factor, Tides.

Solution: Provide a simple boundary with vector (direction & knots) for expected tides. The boundary perimeter and the "Vector" would be entered by the User. The user will have to determine manually and by estimation, what the tidal current vector will be.

This "Boundary-Vector" would have a time dimension, so a "Vector" can have a direction and speed field for each hour, let's say, up to 24 hours. The boundary-vector could be read and interpreted by grib-pi or weather_routing_pi at any resolution needed.

I can draw something for you too. Quite obviously, Sean will have to think about it too.

[jongough]

Rick, I am working on OD 1.5 beta (as well as fixing up many things in 1.4). Currently 1.5 will have a new import capability, i.e. importing CSV files to define boundaries and boundary points (effectively the same as the gpx import, but in a simpler format so spreadsheets can be used to generate the import). This change could go in 1.5 as it will change the potential contents of a boundary and may need a different display to show its intent, i.e. it is not one of the current types but would be of type 'tide vector' (for want of a better word) and would need to have a display that is time dependant (i.e. defaults to current time but could display future time states). This would then allow for a new API (JSON and direct) to query the tide vector.

Does this seem reasonable?

One other thing to think about is tying the vectors to the cyclic tidal predictions. This would then enable a 'static offset vector' to be tied to the current tide cycle. I am not sure how to do this, but then you would build the tide vector with reference to the cyclic tide, i.e. number of hours before or after high water giving the direction and strength. This may need further thought as spring and neap tides 'may' have different vectors relevant to them.

Jon

[rgleason]

Yes, it does. My hesitation is that I am thinking about some of the details of how to do it, which there are not answers for yet, and we're going to have to figure out some things, but I really like the idea!!!

Thanks for taking the time to consider this and come up with some great ideas.

[rgleason]

Jon I think I'll close this. Just an earlier idea.