Crane Wind Window

A phone page for tower crane operators: your crane, your limits, and the wind at the height of the hook, not the ground. Today and tomorrow, hour by hour.

Comment

Inspiration

I drive a tower crane in Prague. The wind decides my day, and I only learn about it from the anemometer once I am already in the cab, forty metres up. Nobody warns me the evening before. Weather apps show the wind at the ground, and the ground is not where the hook is. I wanted one page that tells me, before I climb, when I can lift loads and when the wind will stop me.

What it does

Open the page on a phone. It finds where you are, asks for your crane and your limits, and shows the wind at the crane's height for today and tomorrow, hour by hour.

  • Crane card. Pick the crane from a list of 61 Liebherr, Wolffkran and Comansa models (or type another). The page shows the maker's maximum wind in service from the maker's own manual (20 m/s, 72 km/h, for all three makers' trolley-jib cranes; "not stated" for luffing cranes) and the model's maximum freestanding hook height. Your own limits stay yours: no loads from 15 m/s, warning from 12, both editable. The card is remembered on the phone.
  • The window. A big number: the decisive wind at crane height right now, with the ground value beside it. Then two strips, 24 cells each, hour and number, green, yellow or red by your limits. Past hours dimmed, the current hour outlined. Tap an hour for mean, gusts and ground.
  • One sentence per day you can plan a shift around: "Loads: 00–10, 18–24. No loads: 11–16 (gusts to 18 m/s). Warning: 10–11, 16–18."
  • Plan from home. Tap the location line, pick the site by name, and tomorrow's window is ready before you climb. "Use my location" brings the phone back to automatic.

Live: https://crane-wind-window-7ccfa8.gitlab.io (HTTPS, so the browser shares your location). Planning documents: scope, PRD, spec and the app map are in the repository under devpost/ and published next to the app.

How we built it

Plan first, then code, with the Devpost Learn skill pack: a scope (the kernel: wind at crane height against this crane's limit), a PRD with acceptance criteria for every behaviour, and a technical spec. Each document was reviewed by independent agents before approval; the PRD review caught, for example, that the forecast service has no gusts above 10 m, so the page shows an estimated gust at height and says so.

The app is four files and a data file, no framework, no build step, no server: index.html (the three views), style.css (dark, big numerals, three colours), app.js (location, forecast, place search, drawing, the phone's own storage), wind.js (the maths, tested) and cranes.js (the crane list with sources). Forecast from Open-Meteo (free, no key), place names from OpenStreetMap Nominatim, hosted on GitLab Pages. Built in five slices, each verified with a headless browser run and committed; 21 unit tests pin the PRD's numbers (mean 11 and gust 17 against 15/12 is red and shows 17; "14,9" is accepted as 14.9; the window sentence for the PRD's example day).

Claude Code was the coding agent throughout; I made the product decisions, tried every slice on my phone and sent it back twice (the district name on the location line, and bigger numbers), then asked for the crane list at the final review.

The maths, honestly

  • Wind at your height is interpolated between the forecast's 10, 80, 120 and 180 m levels, so a 40 m crane never gets the ground value.
  • The forecast has gusts only at 10 m. The page carries the ground gust factor up, capped at 2.5, never below the mean at height, and labels it "(est.)" everywhere.
  • The number in each cell is the higher of the rounded mean and gust; the colour follows the same number, so colour and number can never disagree.
  • The crane limits come from the makers' operator and safety manuals, cited in the data file. A claim that one maker's manual warns at 12 and alarms at 15 was checked against the document, found absent, and left out.
  • The page never tells you to weathervane the crane. Your anemometer and your rule decide.

Challenges we ran into

Free forecast services label hours with one fixed UTC offset per response, so on the clock-change day (25 October) every label was an hour off; the page now takes raw timestamps and labels hours itself in the site's time zone. Coordinates alone did not tell me whether the page had found my site, so it reverse-geocodes them to a street and district. And a number input never lets a script see a comma, which is what my phone keyboard types; the limits are text fields parsed by hand.

What we learned

Write the observable result down before building, then make it a test. The PRD's exact window sentence found its own inconsistency at review time, before any code, and now lives as a unit test. And trust the data only after looking at it: two review passes that actually fetched the forecast and the crane manuals changed what the app claims.

What's next

Notifications when the wind rises above the warning level, shift hours instead of full days, a wider crane list, and comparing the forecast with what the anemometer actually showed on site.

Built by Karen Yezzhev with Claude Code (Anthropic) as the AI coding agent. This description was drafted with the agent from the project's planning documents and build log and reviewed by me. The video narration is synthetic (Kokoro TTS).

Built With

Share this project:

Updates

Submission history