Slow start

[did-g]

Hi,

If started near shore routing is often stuck by land, try to get out of it.

For the first step do a full search with 1° step, it's fast enough.

Regards
Didier

[seandepagnier]

So if land is detected, it switches to an angular step of 1 degree and propagates 360?

This sounds like it would really slow the routing down a lot. I don't think it should be default, or at least shoud be possible option to not do this.

I thought the time step would be reduced in this case rather than angular step.

[did-g]

Hi,

So if land is detected, it switches to an angular step of 1 degree and propagates 360?
No it doesn't, if landing or boundary are set it uses and angular step of 1 and tries 360 for the first step and only this one, following time steps use users selected parameters, the slow down is minor because most new routes are pruned very quickly.

I thought the time step would be reduced in this case rather than angular step.
Yes it'd help but not always and finding the right time step is tricky.

cf.:

[seandepagnier]

I think this is a only a hack so it should be a user option rather than default. Otherwise it's confusing what the program is doing.

[did-g]

Ok;

BTW I'm playing with curvilinear gribs (Lambert and co), what do you think would be best:

• When loading regrid to plate carré

• Work with the native grid: in this case, memoise grid x,y --> lat /lon, lon/lat -- x,y , or do the math every time? Issues with properly rotate UV and overlay .

[seandepagnier]

I would not regrid because of data loss. So the native grid should still give grib data as requested fron a lat/lon. The correct interpolation to use is not obvious.

…

On 6/13/18, didier ***@***.***> wrote: Ok; BTW I'm playing with curvilinear gribs (Lambert and co), what do you think would be best: - When loading regrid to plate carré - Work with the native grid: in this case, memoise grid x,y --> lat /lon, lon/lat -- x,y , or do the math every time? Issues with properly rotate UV and overlay . -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #205 (comment)

[rgleason]

Did-g. Sean wrote:
"I think this is a only a hack so it should be a user option rather than default. Otherwise it's confusing what the program is doing."

Sean thinks it is a hack, but does it help get the routing started in close shoreline situations? Would it help the user or confuse them? Is there a similar way to adjust parameters that might be better?

[seandepagnier]

I think this could be an advanced configuration option, but by default it's confusing.

[seandepagnier]

Can this add the slow start as optional?

[rgleason]

Did-g can you force another appveyor compile? I will test it on windows.

[did-g]

@seandepagnier

Can this add the slow start as optional?

Not yet.

[rgleason]

I don't think this works. I tried two of the appveyor compiled files. Nobody has explaned how to make it work and there are no controls for it that I can find. If you expect us to try these out youll have to enter some information about how to make it work.

I was able to get routing working by

1. reducing the interval to 15 minutes.
2. increasing max diverted course to 180 degrees.
3. increasong max course angle to 180 degrees
4. increasing max diverted angle to 180 degrees.

This is not at all what the plugin did. It failed whenever I had Detect land turned on.

[did-g]

@rgleason
It was the first patch in a serie and it should work out of the box:

• the first step doesn't follow configured parameter but always search full circle.
  If your start in the middle of nowhere you should get output like above.

In its current form it's of limit value, next patches reduce time interval for a number of step.
I'm not sure it's the right think to do.

[rgleason]

Provincetown, Cape Cod is the perfect test example where it should work. I would like to be able to move the boat into the inner hook area and just have WR_pi figure out the right parameters to sail out of there.

Did-g I don't really understand your techno-speak. Sorry. I don't see any evidence of the algorithm working in the example posted above.

• I understand the first step searches in a full 360 degrees, why not have it search a full 360 degrees in subsequent steps, say 10?

• I think you are saying that the time interval is not reduced in this version and that the next version will reduce the time interval for a number of steps.
  -I think you need to relax (increase) max diverted course, max course angle and max diverted angle as well. I don't know how much or which ones make the most difference.

• How would we know that it is working? Just by the output?

• If the routing tries to use slow start, but it does not work, what happens? Perhaps it fails and gives the reason and then says "Slow start used too"

It would be great to get something like this working, as it would eliminate a lot of headaches for new users who don't understand the plugin very well, I think.

[rgleason]

Departing Cape Cod - Provincetown
This worked.

Basic
Max Diverted Course - 180
Time Step - 1 minute
Detect Land yes
Grib yes

Advanced
Max Course Angle 180
Max Search Angle 180
Courses relative to true wind from 0 to 180 by 1 degree

It took awhile.

=================

Basic
Max Diverted Course - 180
Time Step - 2 minute
Detect Land yes
Grib yes

Advanced
Max Course Angle 180
Max Search Angle 180
Courses relative to true wind from 0 to 180 by 2 degree

It took less time.

==================
Basic
Max Diverted Course - 180
Tme Step - 3 minute
Detect Land yes
Grib yes

Advanced
Max Course Angle 180
Max Search Angle 180
Courses relative to true wind from 0 to 180 by 3 degree

It took even less time.

===================

Basic
Max Diverted Course 170
Courses from O to 179 time Step - 3 minute
Detect Land yes
Grib yes

Advanced
Max Course Angle 180
Max Search Angle 180
Courses relative to true wind from 0 to 150 by 3 degree

It took even less time.

====================

Basic
Max Diverted Course - 167 --166 fails.
Time Step - 3 minute
Detect Land yes
Grib yes

Advanced
Max Course Angle 180
Max Search Angle 180
Courses relative to true wind from 0 to 150 by 3 degree

======================
Basic
Max Diverted Course - 167 --166 fails.
Courses from O to 179 time Step - 4 minute
Detect Land yes
Grib yes

Advanced
Max Course Angle 168 - 167 fails.
Max Search Angle 180
Courses relative to true wind from 0 to 150 by 3 degree

========================
Basic
Max Diverted Course - 167 --166 fails.
Time Step - 4 minute
Detect Land yes
Grib yes

Advanced
Max Course Angle 168 - 167 fails.
Max Search Angle 108
Courses relative to true wind from 0 to 150 by 3 degree

OPTIMIZED SETTINGS

Basic
Max Diverted Course - 167 --166 fails.
Time Step 4 minute 40 seconds
Detect Land yes
Grib yes

Advanced
Max Course Angle 168 - 167 fails.
Max Search Angle 108
Courses relative to true wind from 0 to 150 by 4.6 degree

These routines should only be done when the route has failed. Maybe we should try something like this

• 3 degree steps
• 170 Max diverted course
• 120 Max search angle

[rgleason]

Departing Hadley Harbor

Basic
Max Diverted Course - 166
Time Step 1m 43s
Detect Land yes
Grib yes

Advanced
Max Course Angle 168
Max Search Angle 108
Courses relative to true wind from 0 to 150 by 4.6 degree

[rgleason]

I would like to see a third tab next to Basic and Advanced which might be "Slow Start"
a duplicate of Basic + Advanced values:

Basic
Max Diverted Course - 180
Time Step 1 m 30 seconds

Advanced
Max course angle = 180
Max search angle = 120
Course relative to true wind from 0 to 180 by 3 degrees

[Checkbox] Use the slow start feature

Computation when "Fail" is imminent or has occurred,

• Will restart from start or 5 steps back if there are more steps.
• Will use the setting s in the "Slow Start" Tab.
• Will stop using "Slow Start" settings when there has been 5 consecutive steps made in the same direction (10 degrees +/-) or there is no land within 12 steps (averaged)
• When fail occurs again, try "Slow Start" before stopping and showing "Fail"

There should also be an optional checkbox to enable this feature.

[rgleason]

Related to FR #202
Feature Request: Dynamic adjustment of start and end isochrone time interval to complete. #202

[rgleason]

@did-g @seandepagnier

Isn't it possible to do something using did-g's idea (or along those lines) that will improve start and completion near land?

I've provided some good examples above that should help with the problem too.

Users seem to have difficulty with this and something that automatically kicks in is using the computer for what it is best at.

"Slow start and finish" settings override: with user adjustment, perhaps in a third tab titled "Slow start/finish"

Prerequisites

1. Detect Land = Yes (this is the point isn't it, so this has to be ON!)
2. Grib or Climatology Yes (something is required)

Parameter Default Value

1. Max Diverted Course = 170
2. Time Step = 3 minute
3. Max Course Angle = 180
4. Max Search Angle = 180
5. Courses relative to true wind from 0 to 150 by 3 degree

PS: We're going to be adding a bunch of polar files which have been checked and reviewed by Bill B who has been cleaning them up.

[rgleason]

Also when a route goes through an area of islands or is trying to get around a point, when the routing fails, or is getting close to failing, perhaps these settings should also automatically be tried.

[rgleason]

@seandepagnier @did-g
I think that after the "Advanced" Tab there should be a "Slow Steps" (Start, Finish and islands) tab with user adjustable settings for trial if a routing is failing.

Parameter Default Value (User adjustable)
Max Diverted Course = 170
Time Step = 3 minute
Max Course Angle = 180
Max Search Angle = 180
Courses relative to true wind from 0 to 150 by 3 degree

Wish this could be done on top of the current version mauroc/squiddio_pi#151

[sebastien-rosset]

I've also hit similar issues, and I'm exploring options to address this problem. One of the options is to leverage a tessellation using a hexagonal grid with the H3 library.

Pre-calculate a multi-resolution H3 grid:

1. Start with a coarse resolution (large hexagons) covering the entire Earth.
2. For each hexagon, check if it intersects with land:
   1. If it's entirely water, keep it as is.
   2. If it intersects with land, subdivide it into smaller hexagons.
3. Repeat this process for the smaller hexagons, increasing resolution as needed.
4. Continue until it reaches a predefined maximum resolution that can represent the finest details like narrow channels.

This grid could be calculated offline using the OSM dataset and published as a downloadable dataset.

Calculate shortest path(s):
Use the A* search to find the shortest path. Start with the coarsest resolution that provides a valid path. When the path encounters a higher-resolution area (near coasts or in channels), the algorithm would "zoom in" to use the smaller hexagons. The heuristic function for A* could take into account the resolution of the current cell, potentially preferring paths through larger cells when possible.

This approach would handle complex geographic features like islands, peninsulas, and channels more effectively than a simple great circle route.

One sub-variant would be to calculate the top-N shortest paths on the H3 grid, where the paths do not have a homotopy equivalence. Paths that go around different sides of an island or through different channels are not homotopy equivalent, as they cannot be continuously deformed into each other without passing through land.

Build isochrones along the H3 path:

1. By following the H3 shortest path(s), geographic constraints have been considered.
2. Limiting the isochrone expansion to a maximum angular or Euclidean distance from the H3 path could potentially reduce computational complexity. I.e., the maximum search angle could be fairly small because the H3 path(s) would have already determined how to go around peninsulas or how to go through channels.
3. Allow a larger search area in open ocean and a smaller one in complex coastal areas.
4. The isochrone steps could be dynamically adjusted based on the h3 grid resolution along the shortest path. For example, if the path must go through a H3 cell at resolution 10 because there is a very narrow channel ( ~65 meters), then around that point, the isochrone step should be smaller. Conversely, if the path goes through a coarse cell at resolution 1 (~418km), then the isochrone step can be increased, perhaps up to the grib resolution.

At least on paper, it should be possible to plan a route that must go around arbitrarily complex or large land features, without forcing the user to try different angular values. This would yield a simpler user experience, at the cost of increased algorithmic complexity.

I am still exploring and I'm not sure if that would yield good results at reasonable computational costs.

[seandepagnier]

why hexigons? Cant squares work and be simpler to implement and basically the same algorithmic improvement?

It currently is supposed to use binary trees for coastlines broken down in this manner to reduce the computation in detecting coastlines from n to log(n)