Consider a Google Maps alternative

[axeluhl]

Google Maps has worked great and still works great. In the past we had discussions about wind-up display and needed to work around a lack of vector-based maps. Since vector-based Google Maps support we have a native wind-up implementation, only it cannot handle satellite view while rotated.

There are two issues with using the Google Maps API:

• Google logo: this may be an issue for some usage scenarios, such as for Olympic Summer Games when showing any branding is not an option, especially for non-sponsors (as reported, e.g., by @radek-masnica)
• need for an API key and usage limits with the free tier may make consumption for low-budget but high-visibility events a problem

As of this writing, we have already conducted a few steps towards a prototype that provides an alternative map implementation. The work has been massively supported by AI (in particular PiDev + GPT 5.6, as well as Claude Code + Opus 4.8) (thanks, @kohlermsap). It can be found on branch maplibre-runtime-loader and is based on the idea that we can provide a JavaScript adapter that makes the MapLibre API look and behave like the Google Maps API, thus fitting in nicely with our GWT wrapper we use for accessing the Google Maps JavaScript API from our GWT client application.

The prototype on the maplibre-runtime-loader branch activates the MapLibre map when the RaceBoard.html entry point is used with the "maps=maplibre" URL query parameter. This currently needs to be added manually to each such RaceBoard.html page load, which already points to one piece of remaining work.

Remaining work, as far as we see it so far:

• make a single feature flag or maybe setting or user preference regarding map provider selection, so that map selection works without repeated manual user intervention or manual URL editing
• clarify impact of https://openfreemap.org/ attribution requirements regarding de-branded usage scenarios
• clarify open issues in the prototype's code (@kohlermsap), such as the new FixesAndTails.synchronizeTailPath(...) method and its usage

[axeluhl]

Profiling shows that FixesAndTails.synchronizeTailPath(...) is called frequently, but strangely, compared to the high effort of, e.g., drawing the wind streamlets with plenty of heavy-weight wind averaging operations, all in all consuming 6800ms in the profile, the synchronizeTailPath method in total consumed only 43ms.

The method itself may be improved by first checking for a size difference and then constructing the MVCArray and filling it only when sizes actually differ.

But the underlying problem seems a different one, and we see it also on main / production. When a user switches metrics to use for tail colors, it seems one or more invariants in FixesAndTails get violated, ultimately leading to an IndexOutOfBoundsException occurring. I'll raise another issue on this. See #6286.

In the meantime, until issue #6286 is solved, we may consider placing this workaround onto main...

[axeluhl]

#6286 (comment) explains how commit 7304bae fixes the issue that FixesAndTails.synchronizeTailPath(...) is working around. I'll merge that commit into the maplibre-runtime-loader branch now and then remove the sychronizeTailPath method.

[axeluhl]

See commit 3b1fa21, which removes the now obsolete FixesAndTails.synchronizeTailPath(...) method. Local tests look god. Activating a metric for tail colors doesn't cause the IndexOutOfBoundsException anymore.

[axeluhl]

Commit 289c9ee on branch maplibre-runtime-loader introduces a system property "map.provider.type", mapped to the new MapProviderTypes enumeration and fed by the MAP_PROVIDER_TYPE environment variable. This removes the maps=maplibre URL hack. The system property is read by the Activator of the com.sap.sailing.gwt.ui bundle and obtained by MapsLoader through a GWT RPC call.

Regarding issue #6286, the news are good: local tests show that the corresponding patch has fixed the IndexOutOfBoundsException and hence the FixesAndTails.synchronizeTailPath(...) method was removed, while we're still waiting for green builds (the builds seem to have failed solely for a YellowBrick server update that affects our corresponding integration tests...).

[axeluhl]

@kohlermsap Funny detail: when in wind-up mode, showing the nautical chart overlay draws all elements of that layer rotated.

Was this to be expected? Any chance to have these symbols rotated, too?

[axeluhl]

@kohlermsap We should consider renaming maplibre-test-utils.js to something less "test-like" because it is being used by the production code in google-maps-maplibre-compat.js:

import { applyRaceStyle, createArrowSvg, createRaceStyle, lngLat, setSatelliteVisible } from './maplibre-test-utils.js?v=race-map-feedback-9';

Would you agree? What's a good name for it? Can test logic be separated from other things relevant in production, and should we split the file into two?