Skip to main content

Successfully plans a round trip via ferry in one direction, unexpectedly fails to use correct ferry in the other direction.

Feedback

Hi,

ABRP appears to have trouble reversing a round trip that includes a ferry. That is, after successfully planning a trip that needs only a one-way ferry trip, the reverse plan adds a lengthy, unnecessary, and undesirable detour to additional ferries.

This trip,

https://abetterrouteplanner.com/?plan_uuid=589069b2-053d-4a11-b6d3-ed90ae1dbed6 , crosses exactly one ferry in one direction only and is is successfully planned when travelling in the clockwise direction, but when the plan is reversed, ABRP adds a long and unnecessary detour that includes two additional ferries. This routing mistake is made regardless of whether the EV has short range (<100mi) or long range (>200mi), so the distance between charging stops does not appear to be the root cause.

Clockwise waypoints (successful plan):

  1. Lynnwood, Washington

  2. Mukilteo-Clinton Ferry (from Mukilteo to Clinton, one way)

  3. Coupeville, Washington

  4. Deception Pass Bridge, Washington

  5. Lynnwood, Washington

Reversing this clockwise plan should have only needed to reverse the sequence of the clockwise plan. Instead, the reverse plan contains a lengthy detour and two extra ferries.

Counter-clockwise plan (undesirable):

  1. Lynnwood, Washington

  2. Deception Pass Bridge, Washington

  3. Coupeville, Washington

  4. Mukilteo-Clinton Ferry

  5. Mukilteo-Clinton Ferry again? ← why did ABRP recommend a round trip?

  6. Clinton to Port Townsend ← undesired detour

  7. Port Townsend-Coupeville Ferry, one way ← undesired detour

  8. Edmonds-Kingston Ferry, one way ← undesired detour

  9. Lynnwood, Washington

For the counter-clockwise route, ABRP should have only needed a one-way ferry crossing from Clinton to Mukilteo at Step #4 and the last leg, Step #5, should have been Mukilteo to Lynnwood.

Posted by M Johnson ·
Status: Completed8 comments

Log in to comment and vote

Comments8

  • Katya S. changed status to In Progress
    Team•

    Apr 8, 2025

    Pinned

    Hi @M Johnson,

    Looks like it was a footpath connected to the ferry that somehow caused odd results concerning speed, and this resulted in the routing engine deeming one direction taking too long time to be considered an alternative.

    We’ve made some edits to the map in OCM, and we hope to see this resolved by Monday.

    • M Johnson

      •

      Apr 8, 2025

      @Katya Skog, I appreciate the time you took to dive into the details to find the root cause of the problem and submit a fix. Thank you very much!

      Washington State’s ferries are an important gateway to Whidbey Island, one of many beautiful sights to see in the Pacific Northwest. Unfortunately, Whidbey Island does not have enough DC fast chargers, so ABRP is essential for EVs with lower range like older EV cars and current EV motorcycles (~160 km per charge).

      With your fix, visitors to Whidbey Island using the Mukilteo Ferry Terminal will be able to more confidently plan their journeys using ABRP regardless of which direction they travel.

  • Katya S. changed status to In Review
    Team•

    Apr 7, 2025

    Pinned

    Hi @M Johnson,

    Looking at the result, this is not related to ABRPs planning but rather a piece of the road/map not permitting us to plan in one direction in the Mukilteo Ferry Terminal.

    Possibly this is due to the ‘service road’ from the ferry only permitting access for ‘customers’. It is possible for users themselves to help update maps over at openstreetmap.org if you know what is correct for these roads.

    • M Johnson

      •

      Apr 7, 2025

      Hello @Katya Skog,

      thank you for taking a look at this problem and explaining that the problem is not in the algorithm but in the map data.

      I am not familiar with OpenStreetMap but this will be a good opportunity for me to learn about it.

      —

      Best regards,

      Michael

      • M Johnson

        •

        Apr 8, 2025

        While comparing OpenStreetMap with ABRP, I noticed a mistake in ABRP’s address for “Mukilteo Ferry Terminal”. ABRP resolves it as an address that is almost 5 years old.

        News: “New Mukilteo ferry terminal opens”:

        https://www.seattletimes.com/seattle-news/transportation/new-mukilteo-ferry-terminal-opens-inspired-by-coast-salish-longhouse/

        Washington State Department of Transportation - Mukilteo terminal address:

        https://wsdot.com/ferries/vesselwatch/TerminalDetail.aspx?terminalid=14

        Old address: 614 Front Street, Mukilteo, WA 98275

        New address: 910 First Street, Mukilteo, WA 98204 (starting December 2020)

        Note that ABRP draws the correct dashed line for the updated ferry route and displays a ferry terminal icon with the correct label at the new address, but adding “Mukilteo Ferry Terminal” as a waypoint in ABRP adds the wrong (old) street address.

        OpenStreetMap and Google Maps put a pushpin at the correct new address for the ferry terminal.

        • M Johnson

          •

          Apr 8, 2025

          Notice that ABRP draws a blue path to the old terminal address instead of the new terminal address.

          • M Johnson

            •

            Apr 8, 2025

            To try to find evidence that the data is at fault instead of the algorithm, I created an account with OpenStreetMap and used their editor to experiment with their three routing algorithms: GraphHopper, OSRM, and Valhalla.

            Experiment 1 -- Only the ferry crossing.

            From: Mukilteo Ferry Terminal

            To: Clinton Ferry Terminal

            Result: GraphHopper, OSRM, and Valhalla successfully plotted the minimal one-way journey across the Mukilteo-Clinton ferry route from terminal to terminal, and could also successfully plan the reverse journey.

            However, ABRP unexpectedly avoided the ferry route and took an 180km detour to Burlington and Everett instead. This happened in both directions.

            In ABRP, after right-clicking the ferry route and adding it to the planner, a different undesirable detour of length 121km was suggested, crossing two other ferries.

            Experiment 2 -- Includes a short distance from each ferry terminal, so that local two-way roads are included.

            From: Ivar's Mukilteo Landing, Mukilteo, WA

            To: Commercial Street, Clinton, WA

            Result:

            • Good: GraphHopper and OSRM algorithms successfully plotted a short (6.5km) one-way journey across the ferry route, and its reverse.

            • Bad: Valhalla successfully plotted the short (6.5km) one-way journey across the ferry route, but its reverse plan took a 180km detour to Burlington and Everett. ABRP failed to use the ferry in either direction, instead recommending Valhalla's 180km detour in both directions.

            Conclusion: From a casual user's view, it doesn't appear that the ferry terminal data is preventing all algorithms from successfully planning a journey across the ferry route in both directions. It appears that other algorithms are handling the same data better.

            • Katya S.

              Team•

              Apr 8, 2025

              Here’s what Valhalla (which ABRP uses) does for the Clinton to Mukilteo direction:

              The opposite direction with Valhalla works fine:

              We can get off the ferry but approximately here…

              …we cannot get past and the detour is created.

              Unfortunately, it is still not really clear to me what map element it is that prevents us/Valhalla from routing in this direction.