-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request/Idea User created Tide/Current Boundary. #337
Comments
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. |
Rick, 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 |
Problem: Solution: 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. |
Rick, 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 |
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. |
Jon I think I'll close this. Just an earlier idea. |
Weather_Routing <-----Plugin API -----> ODraw Boundary
seandepagnier/weather_routing_pi#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:
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!)
The text was updated successfully, but these errors were encountered: