Sun layer for maps
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.
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.
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.
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.
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°.



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.


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.

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.
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.
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.
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.