The Problem: Why Standard Work Calendars Fail
In Brazilian road infrastructure, work calendars are one of the most critical — and most poorly engineered — inputs to a CPM schedule. The standard practice relies on generic regional assumptions or subjective planner experience, ignoring the actual statistical distribution of precipitation at the specific project site.
The result is systematic optimism bias embedded in the baseline: calendars that overestimate workable days, underestimate soil recovery time after rain events, and produce schedules that are structurally unreliable before construction even begins. The DNIT methodology exists precisely to solve this — but applying it rigorously requires processing years of daily precipitation data station by station, a task too complex to perform manually for every project.
The Engine: Station Selection and Data Pipeline
The system receives a geographic coordinate (latitude/longitude) and a historical window (years) as inputs. It then queries the full ANA federal pluviometric station network via the hydrobr library, computing the Haversine distance to every registered station and filtering the nearest 30.
Proximity alone is insufficient — a nearby station with poor data quality produces worse results than a slightly farther one with a complete series. The engine evaluates each candidate by downloading its full historical series and computing the percentage of missing days within the requested window. Stations with no recorded data after 2018 are discarded as obsolete — regardless of how much historical data they hold — since their series is no longer being updated. Among the remaining active stations, the one with the lowest missing-data ratio within the requested period is selected automatically.
The Methodology: DNIT Recovery Factors
Once the best station is selected and its historical daily precipitation series is loaded, the engine classifies each day into one of the seven official DNIT intensity bands: 0 mm, 0–2 mm, 2–5 mm, 5–10 mm, 10–25 mm, 25–50 mm, and >50 mm.
For each band, DNIT prescribes a recovery factor (Fator de Retomada) — the number of additional non-workable days that each rain event of that intensity generates, beyond the rain day itself. The calculator applies these factors separately for the two service typologies within road infrastructure projects:
- OAC — Obras de Arte Correntes (Earthworks & Drainage): excavation, grading, compaction, and drainage works. Highly sensitive to precipitation — wet soil requires additional drying time before work can resume. Recovery factors range from 0.5 to 3 days per event.
- OAE — Obras de Arte Especiais (Paving & Special Structures): asphalt paving, surface treatments, bridges, and viaducts. Less sensitive to ground moisture conditions, but dependent on the absence of active rainfall during execution. Recovery factors range from 0 to 1 day per event.
Key insight: The calculator applies these factors statistically over the full historical series — not on individual events — producing a probabilistic distribution of workable days per month that reflects the true climatological reality of the site for each service type independently.
The Output: Monthly Practicability Percentages
For each of the 12 calendar months, the calculator delivers two independent sets of results — one for OAC (Earthworks) and one for OAE (Paving & Special Structures):
- Historical distribution of days per precipitation intensity band
- Non-workable days due to rain and soil recovery (calculated separately for OAC and OAE)
- Monthly practicability percentage: workable days ÷ calendar days × 100
- Practicable working hours per day and projected end-of-shift time, ready for calendar configuration in MS Project or Primavera P6
- Average monthly precipitation (mm) from the selected ANA station
These values replace generic regional calendars with site-specific, statistically grounded inputs — enabling the planner to configure one calendar per service type, directly reflecting the climatological reality of the project location.
Architecture & Stack
The application is structured as a decoupled microservice architecture, containerized with Docker and deployed on Google Cloud Run in the South America East 1 region (São Paulo).
- Backend: Python · FastAPI · pandas · numpy · hydrobr · ANA HidroWeb API
- Frontend: React · Vite · TailwindCSS
- Infrastructure: Docker · Google Cloud Run · Nginx
- Data source: Agência Nacional de Águas (ANA) federal pluviometric network