Just to pick a nit, the way I read it the speed decreased because of shallow water at the beginning of the sand; then a number of minutes later they gently ran up on their final resting place. Mate noticed the sudden decrease to under a knot, but was too sleepy or zoned-out to make the obvious connection when the engines are chugging along but the vessel has stopped.
With Transas there is a menu where the items to be “checked” can be selected. Some items are mandatory and cannot be disabled.
I suspect that in the case of the Muros that none of these features were being used.
As an guesstimate I’d say voyage planning can be done with an ECDIS with about 30%-50% of the time/effort of paper charts (transferring track-lines to the various different scale charts takes time).
If the various setting and checks are disregarded voyage planning on ECDIS takes maybe 5% of the time/effort of paper. This is how the Muros was doing it.
Just as Traffic Schemes are strongly “suggested routes” through busy confined waters, agreed upon suggested major shipping routes (that cannot be changed) should be programmed into ECDIS.
Make a new ECDIS route to save a few miles by dodging and weaving thru shoals,rock piles, and fleets of small fishing vessels if you want to, but be prepared to explain why if anything goes wrong.
Once it becomes easier to just take a standard tested route, it will usually be taken.
I have to say – and I mean this sincerely – that I find it fascinating to watch the contributors to this thread develop the Conops that the people who built the ECDIS system should have written before they started pounding code.
You get used to every Tom, dick, and Harry telling you “this is the newest, bestest thing” we developed for you, when you work at sea. Most of them having never stood a watch in their life.
I don’t think I’ve ever been asked how I would like a piece of software to work as the end user in all my years floating around out here.
A lot could be gained if they would simply treat us like professionals and ask for our input.
Before nav equipment was available to compute bearing and distance to the next waypoint formal (not by eye) navigation was done entirely on the chart. Track-lines were laid down, fixes were plotted, the course was adjusted accordingly.
If you switched charts and the was an error in the track-line and the fixes were no longer on the track-line the mate would just adjust the course and get back on track.
Once the GPS came along with screen and “highway” the mates began to follow that instead. No one told them to, they just did.
If the track line in the GPS and on the chart did not match, mates would follow the GPS and assume the paper track-line was wrong.
This can be seen when going GC, the fixes will match the track at the segment ends but arc away between segment ends (unless the 2/m used the steel globetrotter edge-wise). That is because the watch mate is following the GPS screen highway, not truly using the paper plot.
I recall being 2/m and if there was an difference between the paper track-line and the GPS the mate loved pointing it out. Before GPS they just followed the track on the paper and didn’t complain.
EDIT: change “waypoint” to “segment”
Off-topic but why not use a series of rhumb lines to approximate a GC arc?
That’s how it’s done on the chart. You mean in the GPS? You could but it is easier/quicker to cross the ocean with just two waypoints. Especially if you make weather route changes.
There’s not enough difference between the rhumb lines segments on the chart and the GC on the GPS to worry about, it’s more of an observation than a complaint.
EDIT: We sail GC by entering the two waypoints in the GPS and then using Waypoint for Windows to generate the rhumb line segments to plot on the chart between the two waypoints.