Case Study: How Urban Sun Finder Scores Sunlight Using OSM Building Footprints
How a real Nordic sunlight-prediction app uses OSM building heights and footprints for shadow analysis, and why the Features API beats vector tiles.
Urban Sun Finder is a sunlight-prediction service for venues in Nordic countries, where short winter days and low sun angles make the question "will this cafe actually be sunny" genuinely useful. It combines solar position calculations, live weather data, and shadow analysis from buildings, which is where the OSM Features API comes in.
The app fetches building polygons for the users bounding box, then uses that GeoJSON to calculate the sunlight score for each venue to determine if sun beams will hit the venue. This matters a lot in winter in many northern areas of the world.
Why real building geometry matters for shadow casting
Shadow math needs analysis-grade geometry with full polygons, stable topology, and attributes like height and building:levels. In theory, vector tiles can serve building polygons if it exposed raw geometry queries, but they are a poor source for physics calculations because geometries can be clipped at tile boundaries and simplified by zoom. Stable topology means the polygon's rings are valid (closed outer ring, proper inner holes), no self-intersections or broken geometry, vertex order and edges are consistent, features are not arbitrarily split at tile boundaries, and geometry is not simplified by zoom. Bounding box chunking is needed for potentially very large areas to avoid huge payloads.
For Urban Sun Finder, the safer input is full polygon geometry from the OSM Features API. It fetches buildings from the area that covers the candidate venues, then evaluates sun incidence along polygon edges and vertices to estimate shadow impact, including self-occlusion of the venue footprint.
How the sunlight score is built
The final 0-100 score is a weighted combination, not a single lookup:
- 40% combined shadow: nearby building shadows and the venue's self-occlusion, merged multiplicatively rather than simply added.
- 35% solar elevation: the sun's current elevation, normalized against that day's local solar noon.
- 25% cloud cover: live weather data.
- Precipitation penalty: a multiplicative reduction based on current weather conditions, applied after the weighted score.
Built for Nordic latitudes
The scoring model is tuned for the 55°N-71°N range: very short winter days with low sun angles where any direct sunlight is valuable, and long summer days where the sun can stay low even at solar noon in the far north. That is exactly the regime where precise building footprints and heights change the answer. At low sun angles, a single building's real height and orientation can be the difference between a sunny terrace and a shadowed one.
In summer, the sun is higher in the sky and the scoring model is less sensitive to building height and orientation. But then you want to find shaded areas to avoid the heat.
The takeaway
Urban Sun Finder is a concrete example of what "reason about the map" looks like in practice: fetch real OSM geometry and tags once, and build application-specific logic. In this case a physics-based sunlight score. That is the gap a rendering-focused vector tile can't fill, and the reason MapLark returns full geometry and tags instead of a pre-rendered basemap layer.
Ready to build?
Get unlimited free access during public preview.