typescript
map.addSource('stations', {
  type: 'geojson',
  data: stationsGeoJSON,
  cluster: true,
  clusterMaxZoom: 13,
  clusterRadius: 50,
});


Then you add three layers on top of that source: one for cluster circles, one
for the cluster count labels, and one for individual dots at high zoom. Each
layer uses MapLibre expressions to style by data properties — connector speed in
my case:

map.addLayer({
  id: 'unclustered-point',
  type: 'circle',
  source: 'stations',
  filter: ['!', ['has', 'point_count']],
  paint: {
    'circle-color': [
      'case',
      ['>', ['get', 'maxSpeedKw'], 50], '#0066FF', // rapid — blue
      ['>=', ['get', 'maxSpeedKw'], 22], '#1A7A4A', // fast — green
      '#6B7280',                                    // slow — grey
    ],
    'circle-radius': 7,
    'circle-stroke-width': 2,
    'circle-stroke-color': '#ffffff',
  },
});
The result: 10,000 stations render instantly, zoom and pan at 60fps, and
cluster/uncluster smoothly. The difference versus React markers is not subtle —
it is the difference between a working app and a broken one.

3. The race condition that took three sessions to fix
This one hurt.

After the user enters a route and clicks "Finn rute", the app fetches geometry
from OSRM and tries to draw a blue line on the map. For two full sessions I could
not get the route line to appear. No errors. The fetch succeeded. The GeoJSON was
valid. But the map showed nothing.

Here is the simplified version of what I had:

useEffect(() => {
  const map = mapRef.current;
  if (!map) return;

  const update = () => {
    // remove old layers, add new source + layers with route data
  };

  if (map.isStyleLoaded()) {
    update();
  } else {
    map.once('load', update); // ← this was the bug
  }
}, [route]);
The logic looks reasonable. If the style is loaded, run immediately. Otherwise
wait for the load event.

The problem is that map.once('load') only fires once — at initial startup.
If the user pans or zooms the map before clicking "Finn rute", MapLibre starts
fetching new tiles. During tile fetching, isStyleLoaded() returns false. But
load has already fired and will never fire again. So update() is never called.
The route is silently dropped.

The fix is one word: replace 'load' with 'idle'.

if (map.isStyleLoaded()) {
  update();
} else {
  map.once('idle', update); // ← fires whenever rendering completes
}

return () => {
  map.off('idle', update); // clean up if route changes before idle fires
};
The idle event fires whenever MapLibre finishes rendering — after tiles load,
after panning stops, after anything. It always fires eventually. Once I understood
this, I applied the same fix to the stations effect too, since it had the same
latent bug.

The cleanup map.off('idle', update) in the effect return is also important: if
the route changes before idle fires, you want to cancel the pending callback
and let the next effect run instead.

The lesson: isStyleLoaded() is not a simple boolean. It also checks whether
source data is done loading. 'load' is a one-time startup event. For any
deferred map update, 'idle' is the correct fallback.

4. Layer ordering in OpenFreeMap
A second issue with the route line: even when it did appear, it was sometimes
invisible because it rendered underneath the base map's fill layers.

In MapLibre you can insert a layer before an existing one using the beforeId
parameter. Many tutorials suggest finding the first symbol layer in the style and
inserting before that:

const firstSymbolId = map.getStyle().layers
  .find(l => l.type === 'symbol')?.id;

map.addLayer({ id: 'route-line', ... }, firstSymbolId);
In OpenFreeMap's liberty style, the first symbol layer is positioned quite low in
the stack — below fill layers. The route line appeared to insert correctly but was
hidden under polygons.

The fix was to use a known layer I added myself as the anchor instead:

const beforeId = map.getLayer('clusters') ? 'clusters' : undefined;
map.addLayer({ id: 'route-line', ... }, beforeId);
This inserts the route below the station cluster circles but above all base map
layers. Reliable regardless of how the tile style orders its own layers.

5. The greedy charging stop algorithm
The route planner takes an origin, destination, car range (km) and minimum charge
percentage, then calculates where you need to stop to charge.

The algorithm runs on the OSRM route geometry — a GeoJSON LineString with
hundreds of coordinate points tracing the actual road. The core of it uses
Turf.js:

import { nearestPointOnLine, length, point } from '@turf/turf';

// Project each station onto the route line
const projected = stations.map(station => {
  const pt = point([station.position.lng, station.position.lat]);
  const snapped = nearestPointOnLine(routeLine, pt, { units: 'kilometers' });
  return {
    station,
    kmAlongRoute: snapped.properties.location, // distance in km from route start
    distanceFromLine: snapped.properties.dist,
  };
});

// Keep only stations within 5km of the route
const corridor = projected.filter(s => s.distanceFromLine <= 5);
corridor.sort((a, b) => a.kmAlongRoute - b.kmAlongRoute);
One non-obvious detail: when you call nearestPointOnLine with
{ units: 'kilometers' }, the returned feature's properties.location is the
distance in kilometres from the start of the line — not a 0–1 fraction. This
is not clearly documented. Getting it wrong produces completely nonsensical stop
ordering.

The greedy algorithm itself:

const effectiveRange = carRangeKm * (1 - minChargePct / 100);
let currentKm = 0;
const stops: ChargingStop[] = [];

while (currentKm + effectiveRange < totalRouteKm) {
  // Find all stations reachable from current position
  const reachable = corridor.filter(s =>
    s.kmAlongRoute > currentKm &&
    s.kmAlongRoute <= currentKm + effectiveRange
  );

  if (reachable.length === 0) {
    return { ok: false, error: 'no_station_in_range' };
  }

  // Pick the one furthest along the route
  const best = reachable.reduce((a, b) =>
    a.kmAlongRoute > b.kmAlongRoute ? a : b
  );

  stops.push({ station: best.station, distanceFromStartKm: best.kmAlongRoute });
  currentKm = best.kmAlongRoute;
}

return { ok: true, stops };
"Furthest reachable" is the greedy choice — it minimises the number of stops by
always jumping as far forward as possible. For the Oslo–Bergen route (about 480
km) with a 400 km range and 20% minimum charge, the algorithm correctly picks one
stop at Fortum Eidfjord around km 309.

The Norwegian-specific parts
The data source is Nobil — Norway's national EV charging station database,
operated by the Norwegian Electric Vehicle Association. It is free for
non-commercial use and contains live availability data for ~10,000 stations. I
proxy the API server-side to hide the key and add a 15-minute cache:

// src/app/api/nobil/stations/route.ts
let cache: { data: NobilStation[]; cachedAt: number } | null = null;
const CACHE_TTL = 15 * 60 * 1000;

export async function GET() {
  if (cache && Date.now() - cache.cachedAt < CACHE_TTL) {
    return Response.json({ stations: cache.data, cached: true });
  }
  // fetch from Nobil, parse, store in cache
}
Norway has the highest EV adoption rate in the world — around 90% of new car
sales in 2024. Long-distance route planning with charging stops is a real,
everyday problem for Norwegian drivers, which is what made this worth building.

What I would do differently
Move Turf.js to a Web Worker. With the current 18 mock stations it runs in
under 5ms. With the real 10,000-station dataset, projecting each station onto the
route line becomes a meaningful computation. It should not run on the main thread.

Add streaming to the route result. Right now the panel waits for the full
OSRM response before showing anything. A streaming approach would show the route
drawing progressively, which feels faster even if it isn't.

Real-time availability. The Nobil API includes live connector status but I
used the static snapshot. A polling interval or WebSocket connection would make
the availability dots actually meaningful.

Links
Live demo: stromvei-project.vercel.app
Source code: github.com/adyelmoro/stromvei-project
If you hit the MapLibre idle vs load issue and this helped, or if you're
building something with Norwegian APIs and want to compare notes — drop a comment.

Next up: DokumentAI — a Norwegian business document Q&A app using RAG,
pgvector, and the Claude API. Same stack, very different problem.

---
That's the full article — paste it directly into dev.to, preview it, and publish. A few quick notes:
- The **cover image** line at the top uses your og-image.svg — dev.to will pull it automatically
- The **code blocks** will syntax-highlight automatically on dev.to
- Estimated read time: about **8 minutes** — that's the sweet spot for technical articles that rank well
- The `idle` vs `load` section is the strongest part — that specific problem has almost no good documentation online, so this article will genuinely show up in Google searches