Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/adrianaarang/climapp/llms.txt

Use this file to discover all available pages before exploring further.

The /consulta route serves the historical records view and exposes simple filtering by municipality and date. A plain GET request returns every record currently stored in data/registros_climaticos.json. A POST request with form fields allows narrowing the results by municipality name and/or observation date. Municipality matching is case-insensitive and supports partial strings, so "mad" will match "Madrid". Dates submitted through the form use the HTML-native YYYY-MM-DD format and are converted internally to DD/MM/YYYY before being compared against stored records.

Endpoints

GET  /consulta
POST /consulta
GET /consulta accepts no parameters and always returns all records. POST /consulta reads filter values from the HTML form body (application/x-www-form-urlencoded).

Filter parameters

municipio
string
Municipality name to filter by. Matching is case-insensitive and uses a substring (contains) check, so partial names are accepted. Omit or leave blank to return records for all municipalities.
fecha
string
Observation date in YYYY-MM-DD format (the HTML <input type="date"> default). ClimApp converts this to DD/MM/YYYY internally before comparing against the stored fecha field. Omit or leave blank to return records for all dates.

How filtering works

When a POST request arrives, the view controller applies the following logic before querying storage:
  1. Municipality — the value is stripped of leading/trailing whitespace. If blank it is treated as absent (no filter applied). The repository compares municipio.lower() against each record’s municipio field converted to lowercase, returning only records where the filter string is a substring of the stored name.
  2. Date — the raw YYYY-MM-DD string from the form is parsed with datetime.strptime(fecha_raw, "%Y-%m-%d") and reformatted to DD/MM/YYYY using strftime("%d/%m/%Y"). If parsing fails, the date filter is silently ignored. The repository then performs an exact string match against each record’s fecha field.
Both filters are applied together when both are provided, meaning the result set must satisfy both the municipality and date conditions simultaneously.

Example requests

Return all stored records:
curl "http://localhost:5000/consulta"
Filter by municipality and date via form POST:
curl -X POST http://localhost:5000/consulta \
  -d "municipio=Madrid&fecha=2026-04-29"

Response record fields

The endpoint renders an HTML template (consulta.html) populated with the filtered records. Each record in the registros list passed to the template contains the following fields:
estacion_id
string
AEMET station identifier for the observation location.
fecha
string
Observation date stored in DD/MM/YYYY format.
temperatura
number
Air temperature in degrees Celsius (°C).
humedad
number
Relative humidity as a percentage (%).
viento
number
Wind speed in kilometres per hour (km/h).
lluvia
number
Accumulated rainfall in millimetres (mm).
municipio
string
Municipality name associated with the record.
fuente
string
Origin of the record. "manual" for entries saved via /api/registrar. May differ for records ingested from other sources.

Storage location

All records queried by this endpoint are read from data/registros_climaticos.json, relative to the application root. The file is created automatically as an empty JSON array if it does not exist. The JSONRepository class manages all reads and writes to this file.

Build docs developers (and LLMs) love