Home/Ideas/Sun layer for maps
Idea · 005  ·  Unsolicited concept

Sun layer for maps

September 2026 5 min read MapLibre → working prototype → this page Personal exploration. Not affiliated with Google, Apple or Yandex.

Madrid in summer has two cities on every street: the shaded side and the one that cooks you. Google, Apple and Yandex draw them identically. Here is a layer that doesn’t — and a working prototype on real Madrid buildings.

Not a mockup: the same shadow engine, one day playing on Calle del Príncipe de Vergara. Real building heights from OpenStreetMap; the card names the building that shades you.
01

The problem

From June to September the two sides of Calle de Ayala are 10 degrees apart. Every map app already knows my position, the time, and the height of every building around me. Sun azimuth and elevation fit in ten lines of trigonometry. The shadow is computable on the device, right now, with no new data. It’s just never drawn.

02

What already exists

This is not a blank space, and pretending it is would be dishonest.

  • Shadowmap and ShadeMap: standalone 3D shadow simulators, built for architects and photographers. Nobody opens a third app before crossing the street.
  • Cool Walks (Barcelona, 2021): shade-optimised walking routes from LiDAR — one city, a municipal project.
  • Google Maps: a “Prefer shade” toggle for walking routes surfaced in the app’s code in November 2025. No launch I could find.

So the direction is right. What’s missing is the layer where the decision actually happens.

03

Why routing is the wrong layer

“Prefer shade” answers one question: give me a cooler route. Most walks aren’t routed at all — I know where I’m going, I only need to know which side to walk on. Routing hides the shadow inside an algorithm and gives me a number. A map layer shows me the shadow and lets me decide, the way Traffic doesn’t reroute me — it paints red and I choose.

The design bet: shadow is map information, like traffic and elevation. Not a route preference.

04

Four iterations

1 · Sun on the compass

A dot on the existing compass ring marks where the sun is. Zero clutter, zero data. One glance: sun on my left, so I take the right side. Crude — it ignores building height — but it fixes most cases for free.

2 · “Sun” layer

A toggle next to Traffic and Transit. Buildings cast a shadow for the current time from heights the map already uses in 3D mode. Off by default; on by default where the forecast passes 30°.

09:00 — the card reads: in the shade of a 5-floor building
14:00 — the card reads: in the sun
19:00 — the card reads: in the sun, with long shadows across the street
Same street, three times of day. At 09:00 that spot is shaded by a 5-floor building; by 14:00 it is not.

3 · Walking navigation

The shaded sidewalk is highlighted along the route with a split: “14 min in sun / 3 min in shade”. No rerouting unless asked — this is where “Prefer shade” belongs, as the second step, after the map has shown you why.

08:30 — the card recommends exit A, 100% of the walk in shade
14:00 — the card recommends exit B, 46% of the walk in shade against 0% for the shorter exit A
Two exits of one metro station, same destination. Every number on the card is computed, not written in: the shaded share is sampled along the path with the same test the layer uses for a single point, the distance is the real length of the line, and the minutes come from it at 1.35 m/s. At 08:30 everything is shaded, so the layer sends you out of the near exit; at 14:00 the short way has no shade at all and the extra minute is what buys it. There is no temperature here on purpose — see below.

4 · Time scrubber

Drag time forward: “at 17:30 this terrace is in shade”. The layer stops being a walking tool and becomes a decision tool for restaurants, playgrounds, meeting points.

20:00 — the card reads: in the shade of a 3-floor building
Scrubbed to 20:00: the same spot is now behind a 3-floor building, and the layer says which one.
05

The prototype

Real streets, real buildings, real heights from OpenStreetMap; the sun is your cursor, your phone’s tilt, or the actual sun for the map centre. Click anywhere to see whether you’d be in shade and which building casts it. Built in one evening on MapLibre with ~200 lines of shadow geometry: each footprint is swept along the shadow vector, height ÷ tan(elevation), and the roofs are cut back out so only the ground darkens.

Live. Drag the map, move the sun, tap to check a spot. Open full screen →
06

What I don’t know

An unsolicited concept is worth exactly as much as its honesty about the other side’s constraints.

  • Building-height coverage outside major cities may be too sparse to draw shadows without lying. In the prototype, buildings with no height get 6 floors and are labelled “height assumed”.
  • Trees are the main source of street shade, and tree canopy is missing from most map data. A building-only shadow can show a sunny street as shaded — or worse.
  • Rendering shadows per tile per minute has a cost at Google’s scale; a static layer regenerated every 15 minutes may be the real constraint.
  • Sidewalk-level geometry (iteration 3) doesn’t exist in most cities. The map knows the road centreline.
  • For half of Google’s users this layer is noise for half the year. Defaulting it on is a market decision, not a design one.
  • Temperature is what people actually feel, and it is not in map data. The layer can say where the shadow falls; it cannot promise degrees. A card claiming “6° cooler this way” would be a guess wearing the clothes of a measurement, so the prototype shows shade, distance and minutes — the three things it can actually compute.
07

How I’d validate before building the full thing

Ship iteration 1 only — the sun dot on the compass — to walking sessions in five hot cities for one summer month. Watch whether people switch street side after glancing at the map, and whether the layer toggle gets repeat use. If a dot on a compass moves the numbers, shadows are worth rendering. If it doesn’t, the concept is a nice-to-have and shouldn’t be built.

08

Limits

Synthetic sun mapping in mouse mode is a demo device, not a UI proposal. Shadows ignore trees, terrain and neighbouring taller blocks outside the viewport. This is a design argument with a working model, not a product.