[macsolve]

As I understand it, "waypoit arrival" is defined as arriving to a circle around the waypoint (red in my image). I'd like to see an option to instead define it as passing a line at half the intersecting angle (green line), as I think this can be more suitable in some cases.

Is this something to add to MacEnc/GPSNavX?

[bobetter]

Actually, there exists a NMEA standard for this case and deals with WP arrival ( or WP passed as in your case) by using the perpendicular of the course line

AAM - Waypoint Arrival Alarm

Status of arrival (entering the arrival circle, or passing the
perpendicular of the course line) at waypoint c--c.

$--AAM,A,A,x.x,N,c--c*hh<CR><LF>
| | | | |
| | | | +---------------Waypoint ID
| | | +------------------Units of radius, nautical miles
| | +---------------------Arrival circle radius
| +------------------------Status: A = perpendicular passed at waypoint
+--------------------------Status: A = arrival circled entered

[bobetter]

sorry, that didn't format correctly, see attached .png for the correct sentence format...

[macsolve]

Thanks for your insight, but I was mainly targeting how it works within MacENC when following a route with Auto Next (yes, I meant WP passed), so it's not exactly involving NMEA.

I think my handheld Garmin Etrex gps works as I described.

[bobetter]

What happens if you're on the on the "outside" of your turn?

It is also worth considering the basic difference between an arrived at WP and a missed WP. An arrived at WP and it's corresponding circle means you've been able to navigate a previously laid out course that avoided hazards and or danger and Auto Next would continue that. A missed WP means all bets are off and whatever method you chose to deal with a missed WP it's probably not a good idea to have Auto Next kick in as a result.

[macsolve]

On the outside of the turn the same rule would apply - half intersecting angle. See it as the green line continues on the other side of the WP.

I find that for example when creating a route to navigate along a coast with few obstacles (mostly to be able to see remaing distance and ETA and not so much to navigate after), "half intersecting angle" would be much more useful than a circle since the waypoints can safely be passed at rather large distance, and making the circle larger to compensate for this would make it arrive to the WP too early.

I'm not suggesting that MacENC/GPSNavX default behavior should change, I'm just suggesting this alternate behavior for WP arrival/WP passed as an option.

[bobetter]

On the outside of the turn the same rule would apply - half intersecting angle. See it as the green line continues on the other side of the WP.

I find that for example when creating a route to navigate along a coast with few obstacles (mostly to be able to see remaing distance and ETA and not so much to navigate after), "half intersecting angle" would be much more useful than a circle since the waypoints can safely be passed at rather large distance, and making the circle larger to compensate for this would make it arrive to the WP too early.

I'm not suggesting that MacENC/GPSNavX default behavior should change, I'm just suggesting this alternate behavior for WP arrival/WP passed as an option.

I think I'm starting to get your general idea but I'm not sure that I see the practicality of it over existing standard practice. If you can't keep the course you've laid out, why don't you just move the WP such that you can? If the goal is get accurate ETA data, a LOP (line of position-your "green line") won't accomplish that.

BTW, have you experimented with the SailTimer function?

[macsolve]

I guess this is a case of having the map adjust to reality automatically instead of having to take steps such as advancing to the next waypoint manually or even to move the WP... I don't want to interact with the computer more than necessary while I'm busy sailing, I just want it to follow and adjust to reality in a (to me) intelligent manner so I can glance quickly at the display and not get crazy readings like when it's still trying to bring me to a waypoint that we passed half an hour ago, but happened to pass the WP just a little bit too far away because we tacked a bit off route...

As I think more of this, I think it could be relevant to always use half intersecting angle as "waypoint approach" condition, but in combination with a distance circle. To cover my needs I could set a fairly large circle radius (purple in my updated illustration, I tried to get it to show inline without success) if the conditions permit, but still take advantage of the "half intersecting angle" to not reach the waypoint too early. Best of both...

I haven't looked too close at SailTimer yet, but I'm not sure how it would cover these needs. It seems to be more aimed at windward optimization.

[bobetter]

I guess this is a case of having the map adjust to reality automatically instead of having to take steps such as advancing to the next waypoint manually or even to move the WP... I don't want to interact with the computer more than necessary while I'm busy sailing, I just want it to follow and adjust to reality in a (to me) intelligent manner so I can glance quickly at the display and not get crazy readings like when it's still trying to bring me to a waypoint that we passed half an hour ago, but happened to pass the WP just a little bit too far away because we tacked a bit off route...

If the chart and the boat's instruments are accurate, the "map" IS always showing reality. I think what you are looking for is perhaps beyond the scope of most straight up nav programs and gets into the field of routing and race software, you're looking for the computer to exhibit a bit of intelligence and to make decisions based on some rather large variables. I think it's an intriguing idea but would be very difficult to implement successfully as you'd have to start using some fuzzy logic with systems that are primarily designed to achieve precision.

As I think more of this, I think it could be relevant to always use half intersecting angle as "waypoint approach" condition, but in combination with a distance circle. To cover my needs I could set a fairly large circle radius (purple in my updated illustration, I tried to get it to show inline without success) if the conditions permit, but still take advantage of the "half intersecting angle" to not reach the waypoint too early. Best of both...

Yes, I agree that a method to deal with a missed waypoint would be useful and as I said previously, that method exists already in the NMEA standard with the course perpendicular (the problem with the "half intersecting angle" is that on the outside of your turn, you end up sailing further than you need to to "pass" the WP-additionally, if you're at the end of a route or just going to 1 WP, you can't calculate the 1/2 intersecting angle). The question then becomes how does the boat's autopilot deal with that, does the AP (and/or the Mac) treat it as an "end of route" situation and just keep on at the present heading or does it give you the option to go "Auto Next"? I believe that Raymarine systems would deal with it as an end of route but I'm not sure...

I haven't looked too close at SailTimer yet, but I'm not sure how it would cover these needs. It seems to be more aimed at windward optimization.

SailTimer plots WPs and laylines that are optimized based on a boat's polars(both up and down wind) given a course A -> B. It'll calculate and create new WPs and then "move" them based on wind direction/speed in theory alliviating this entire problem.