Weathersight

Returns observations with 1991–2020 baseline comparisons at daily, weekly, or monthly granularity for a location and period. <br><b>When to use:</b> Graph or tabulate recent anomalies at a location for a specific period — e.g. 'how did last month compare to normal?' <br><b>Date format:</b> YYYYMMDD for ymd; use groupby (day/week/month) to control granularity. For 'last week' use YYYYMMDD of 7 days ago. For 'last month' use YYYYMM of prior month. <br><b>Performance:</b> Computed on demand; moderate speed. <br><b>Prerequisites:</b> Use /location to obtain a locid first. <br><b>Investigate:</b> Use after /anomalies or /breaking. Identifies a city of interest; provides per-day/week detail for drill-down. Combine groupby=DAY/FULL_DAY with a recent date range for 'recent days with departure from normal' queries. <br><b>Augment:</b> Provides the per-period anomaly series for prose ('temperatures were above normal for 12 of the past 14 days'). Returns: loc, ts, vals, N, vals_ts, baseline.

Returns precomputed anomalous observations for locations in a given time period and scope. <br><b>When to use:</b> Survey anomalous weather at regional or global scale quickly without specifying individual cities. <br><b>Date format:</b> YYYY[MM[DD]]: YYYY for annual anomalies (scope=year), YYYYMM for monthly (scope=month), YYYYMMDD for weekly or daily (scope=week/day). <br><b>Performance:</b> Fast — retrieves precomputed data. <br><b>Prerequisites:</b> None; global or country-filtered. Use /countries for country IDs. <br><b>Investigate:</b> Good early call to identify which locations experienced anomalies before drilling into specifics with /anom or /dailycomp. <br><b>Augment:</b> Use for a first-pass global scan to identify story-worthy anomalies before fetching per-location detail. Returns: anomalies, anomaly.locid, anomaly.lat, anomaly.long, anomaly.obs_start, anomaly.obs_end, anomaly.obs_dur, anomaly.base_start, anomaly.base_end, anomaly.base_dur, anomaly.obs_period, anomaly.base_period, anomaly.outliers, outlier.obs_metric, outlier.percentile, outlier.obs_N, outlier.obs_X, outlier.base_N, outlier.base_X, outlier.obs_val, outlier.base_val, outlier.base_mean, outlier.base_stddev, outlier.min, outlier.max, outlier.max_key, outlier.min_key, outlier.obs_min_key, outlier.obs_max_key.

Given a single week, month, or day, ranks locations whose weather best matches a set of criteria (most optional criteria met first; all MUST criteria satisfied by every result). Filter by lat/lon+radius or countries. <br><b>When to use:</b> Answer 'where has the best weather for week/month/day X?' <br><b>Date format:</b> scope=day + time=YYYYMMDD (forecast); scope=week + time=MMDD; scope=month + time=MM. Defaults: week of today+14, month today+1, day today+1. <br><b>Performance:</b> Filter by area/countries to keep fast. <br><b>Prerequisites:</b> None; supply lat/lon+radius_km or a country list. <br><b>Investigate:</b> Rank places for a given time window. scope=day uses forecasts. <br><b>Augment:</b> Find the best destinations for a target week/month. <br><b>Notes:</b> Every criterion metric name is literal and fully qualified: the 'avg:' prefix, then the metric base (observation metrics keep their 'obs.' segment), then the attribute — e.g. avg:max_t.p50, avg:obs.rain.sum, avg:obs.is_rain.count. Dropping 'avg:' or 'obs.' is an error; the criteria parameter below lists every valid name. scope=day queries forecasts; week/month query the 1996-2025 historical baseline. Returns: scope, time, baseline, results, locid, location, criteria_met, criteria_met_count, record.

Given a location, ranks the weeks or months whose historical climatology best matches a set of weather criteria (most optional criteria met first; all MUST criteria satisfied by every result). <br><b>When to use:</b> Answer 'when is the best time to visit X for weather like Y?' Choose when_type=week or month over the 1996-2025 baseline. <br><b>Date format:</b> when_type: week|month|day. Historical basis only for week/month. <br><b>Performance:</b> Sub-second per location. <br><b>Prerequisites:</b> Use /location to obtain a locid first. <br><b>Investigate:</b> Rank a location's calendar by weather suitability. For a specific upcoming day's forecast, use /api/anom with period_type=FUTURE_DAY. <br><b>Augment:</b> Find the typical best window for an activity at a place. <br><b>Notes:</b> Every criterion metric name is literal and fully qualified: the 'avg:' prefix, then the metric base (observation metrics keep their 'obs.' segment), then the attribute — e.g. avg:max_t.p50, avg:obs.rain.sum, avg:obs.is_rain.count. Dropping 'avg:' or 'obs.' is an error; the criteria parameter below lists every valid name. For daily forecasts use /api/anom (period_type=FUTURE_DAY). Weekly/monthly forecasts are planned. Returns: location, baseline, when_type, results, time, criteria_met, criteria_met_count, record.

Returns anomalous weather conditions (breaking news) across the world or specified countries in the very recent past (observations) or immediate future (forecast). <br><b>When to use:</b> First call when looking for current or upcoming notable weather events globally or by country. <br><b>Date format:</b> No date params — always returns the most recent ~3 days of observations (breaking_type=obs) or next 7 days of forecast (breaking_type=forecast). <br><b>Performance:</b> Fast — retrieves precomputed anomaly snapshots. <br><b>Prerequisites:</b> Use /countries to get country IDs for filtering. <br><b>Investigate:</b> Start here for any 'what's happening right now?' or 'what's forecast this week?' query; follow up with /anom or /dailycomp for per-location detail. <br><b>Augment:</b> Primary source for identifying breaking weather news stories globally; use ctryid to narrow scope by country. Returns: anomalies, anomaly.locid, anomaly.name, anomaly.city, anomaly.country, anomaly.lat, anomaly.lon, anomaly.geohash, anomaly.elevation, anomaly.obs_start, anomaly.obs_end, anomaly.obs_dur, anomaly.pt, anomaly.anomalies, outlier.obsm, outlier.comps, comp.obsm_f, comp.oq, comp.bq, comp.scope, comp.val, comp.bval, comp.min, comp.max, comp.med, comp.mean, comp.std, comp.min_dt, comp.max_dt, comp.intensity, comp.intensity_f, comp.rp, comp.summary, comp.period, comp.base_N, comp.N, comp.ut, comp.start, comp.end.

Returns monthly distributions of selected metrics for locations compared against a baseline period. <br><b>When to use:</b> Compute normalized and absolute deviations from a baseline, inter-annual and intra-annual variations within months and seasons. Check base_N and obs_N to assess data completeness. <br><b>Date format:</b> obs_years as YYYY or YYYY-YYYY range; months as MM or MM-MM (e.g. '06', '06-08', 'All' for annual). <br><b>Performance:</b> Bulk query — can be slow for global or large-area queries. Filter with locids, lat_lon/radius_km, or countries. <br><b>Prerequisites:</b> Use /location to obtain locids first for point queries. <br><b>Investigate:</b> Use to compare a recent season or year against the long-term baseline across many locations simultaneously. Combine with /climatetrends for trend context. <br><b>Augment:</b> Identifies which locations had the most anomalous season compared to their historical distribution. <br><b>Notes:</b> Metric format: 'max_t' = distribution of daily Maximum Temperature over the period; 'max_t.means' = distribution of annual means of max_t (1 value per year); 'rain_sum' (accumulations) and 'obs.is_thunderstorm' (counts) follow the same pattern. Returns: results, comp.locid, comp.geohash, comp.lat, comp.lon, comp.elev, comp.area, comp.country, comp.src_type, comp.metric, comp.obs_years, comp.base_years, comp.month, comp.obs_N, comp.base_N, comp.obs, comp.base, comp.obs.{q} / comp.base.{q}.

Returns monthly timeseries of selected climate trend metrics for one or more locations, suitable for long-term trend analysis. <br><b>When to use:</b> Retrieve long-term monthly timeseries for statistical trend analysis across any number of locations including globally. Use num_years and avg_N to filter sparse records. <br><b>Date format:</b> years as YYYY- range (e.g. '1975-' for 1975 to present); months as MM or MM-MM range (e.g. '06' for June, '06-08' for June–August, 'All' for annual). <br><b>Performance:</b> Bulk query — can be slow for global or many-location queries. Filter with locids, lat_lon/radius_km, or countries to improve speed. <br><b>Prerequisites:</b> Use /location to obtain locids first for point queries. <br><b>Investigate:</b> Use for global or regional trend analysis. Metric name format: 'agg_func:metric_id.attribute' (e.g. 'avg:max_t.p50'). Check num_years to confirm data completeness before citing a trend. <br><b>Augment:</b> Backs trend claims with long-term data across many locations (e.g. 'temperatures rising across Southeast Asia'). <br><b>Notes:</b> Example metrics: avg:max_t.p50, avg:obs.temp.mean, sum:obs.is_rain.count. See /api/metrics for full list. Returns: results, trend.locid, trend.geohash, trend.lat, trend.lon, trend.elev, trend.area, trend.country, trend.src_type, trend.metric, trend.years, trend.month, trend.num_years, trend.avg_N, trend.mvals, trend.mvals.xvals, trend.mvals.yvals_by_metric.

Compares a location's observed weather period against the corresponding periods in a historical baseline distribution. <br><b>When to use:</b> Quantify how extreme a specific period was across all metrics at once — e.g. how anomalous was March 2025 at New York vs the 1991–2020 baseline. <br><b>Date format:</b> YYYY[MM[DD]]: YYYYMMDD for a specific day or short window (period_type DAY/WEEK), YYYYMM for a month (period_type MONTH), YYYY for an annual comparison (period_type YEAR). <br><b>Performance:</b> Computed on demand; fast for short periods. <br><b>Prerequisites:</b> Use /location to obtain a locid first. <br><b>Investigate:</b> Best for 'how unusual was [period] at [location]?' — returns percentile and z-score across all metrics simultaneously. Set baseline_offset=1 for the standard 1991–2020 baseline. <br><b>Augment:</b> Provides the precise statistical framing ('the hottest March in 30 years') before describing the anomaly in prose. Returns: comparisons, comparison.locid, comparison.lat, comparison.long, comparison.obs_start, comparison.obs_end, comparison.obs_dur, comparison.base_start, comparison.base_end, comparison.base_dur, comparison.obs_period, comparison.base_period, comparison.outliers, outlier.obs_metric, outlier.percentile, outlier.obs_N, outlier.obs_X, outlier.base_N, outlier.base_X, outlier.obs_val, outlier.base_val, outlier.base_mean, outlier.base_stddev, outlier.min, outlier.max, outlier.max_key, outlier.min_key, outlier.obs_min_key, outlier.obs_max_key.

Returns countries with their canonical country IDs used in all other API calls. <br><b>When to use:</b> Resolve country names to canonical IDs, or obtain the full list of supported countries. This list rarely changes. <br><b>Performance:</b> Fast — static data; safe to cache across calls. <br><b>Prerequisites:</b> None. <br><b>Investigate:</b> Call once if country-level filtering is needed; cache the result for the session. <br><b>Augment:</b> Fetch country IDs before making country-filtered calls to /anomalies or /breaking. Returns: countries, country.ctryid, country.name, country.regions.

Returns per-day observed values with percentiles and z-scores vs a sliding N-day window over a historical baseline. <br><b>When to use:</b> Graph heatwaves, cold spells, and other streaks by showing daily departures from normal. Also compare two separate periods or locations using z-scores or percentiles for normalized severity. <br><b>Date format:</b> YYYYMMDD for ymd_start and ymd_end. Keep ranges ≤30 days for fast response; up to 90 days is feasible. <br><b>Performance:</b> Computed on demand; slower for long date ranges. <br><b>Prerequisites:</b> Use /location to obtain a locid first. <br><b>Investigate:</b> Best for detailed day-by-day anomaly investigation once approximate dates and location are known. Use separate calls for two periods to compare heatwave severity via z-score. Do NOT use for ranking top-N events across years — call /events with criteria for that and post-process the response. <br><b>Augment:</b> Provides the daily series needed to describe the arc of a heatwave or cold snap in a news narrative. Returns: locid, lat, lon, dates, num_years, avg_coverage, metrics, metrics.{key}.values, metrics.{key}.pcts, metrics.{key}.sigmas, metrics.{key}.p1 … p99, metrics.{key}.bmin / bmax, metrics.{key}.mean, metrics.{key}.stddev, metrics.{key}.coverage.

How often a compound daily weather condition happens, per location: for every location in an area, the average number of days per year that met all the criteria, with the count, the days that had data, and the percentage. <br><b>When to use:</b> Map where a condition is common or rare, e.g. 'where are summer days between 20 and 30 C most frequent' or 'where did heatwave nights occur in the last five summers'. <br><b>Date format:</b> Either ymd_start and ymd_end (YYYYMMDD, at most 31 days) or year_start, year_end with optional mm_dd_start and mm_dd_end for a season across years (at most 5 years). Defaults to the last 30 days. <br><b>Performance:</b> Full counts need a geo scope (ctryid, latlon, or a bbox of at most continent size) or a date range of at most 30 days. Anything wider is sampled automatically to about 200 locations (see sample), because an open-ended multi-year count takes over a minute; pass sample=0 to be refused instead. With a geo scope, year windows up to 5 years run fast. <br><b>Prerequisites:</b> None; without a geo scope, windows over 30 days are sampled. <br><b>Investigate:</b> Use min_count_pct to keep only locations where the condition is frequent, or min_count 0 with max_count to find where it is rare or never happens. <br><b>Augment:</b> Support statements about how common a condition is across a region with avg_count and count_pct. <br><b>Request format:</b> HTTP GET, query parameters; criteria is URL-encoded JSON. Example: /api/dailycountbyloc?token=TOKEN&ctryid=IN&year_start=2021&year_end=2025&mm_dd_start=0601&mm_dd_end=0831&criteria=[{"metric":"max_t","lb":35}] <br><b>Response format:</b> JSON. results is a list of objects, one per location, highest avg_count first: locid, lat, lon, city_name, country, avg_count, count, days_with_data, count_pct. sample is null unless the result was sampled (then auto is true when the server sampled on its own). <br><b>Notes:</b> avg_count is matched days divided by years in the window; count_pct divides

For one location, the number of days per year that met all the criteria within a month-day window, for every year with data, plus a trend line (days per decade) with R squared and p-value. <br><b>When to use:</b> Answer 'is this condition becoming more frequent here?', e.g. hot summer days or frost nights per year over decades. <br><b>Date format:</b> The window is mm_dd_start and mm_dd_end (MMDD), or the month-days of ymd_start and ymd_end; years are not a filter, every year with data is returned. A window crossing the year end (1201 to 0228) belongs to the year it starts in. Defaults to the month-days of the last 30 days. <br><b>Performance:</b> Fast: filtered to one location in the index. <br><b>Prerequisites:</b> locid from /api/location (ICAO and WMO ids also resolve). <br><b>Investigate:</b> Compare the trend across nearby locations, or across absolute and percentile criteria for the same condition. <br><b>Augment:</b> Back 'more frequent than it used to be' claims with slope_per_decade and its p_value. <br><b>Request format:</b> HTTP GET, query parameters; criteria is URL-encoded JSON. Example: /api/dailycountbyyear?token=TOKEN&locid=725030_14732&mm_dd_start=1201&mm_dd_end=0228&criteria=[{"metric":"min_t","ub":-10}] <br><b>Response format:</b> JSON. years, counts, days_with_data and in_trend are parallel lists of equal length: index i describes the season starting in years[i]. trend is an object (slope_per_decade, r_squared, p_value, n) or null with under 3 usable years. <br><b>Notes:</b> Years with under 80% of the window covered are listed (in_trend false) but excluded from the trend. Returns: locid, location, criteria_desc, mm_dd_start, mm_dd_end, total_days_per_year, years, counts, days_with_data, in_trend, trend, note, error.

How good Weathersight's own forecast was at one location, at one or more lead times: a daily series of the observed value, the forecast made lead days earlier, and RMSE, MSE, ACC and ETS over a trailing window ending on each day. <br><b>When to use:</b> Answer 'how reliable has the 3-day forecast been here lately?' or 'how fast does skill decay from 1 to 7 days ahead?'. This scores the forecast Weathersight serves (after model choice and bias correction); fcastevalbylocation scores the raw vendor models. <br><b>Date format:</b> start_date and end_date are YYYYMMDD, at most 31 days apart (forecast retention). Defaults to the 31 days ending yesterday. <br><b>Performance:</b> Fast: two small lookups for one location, whatever the number of lead_times. <br><b>Prerequisites:</b> locid from /api/location (ICAO and WMO ids also resolve). <br><b>Investigate:</b> Ask for lead_times=1,3,7 at once to see how skill decays. <br><b>Augment:</b> Quote recent forecast error at the article's location. <br><b>Request format:</b> HTTP GET, query parameters. Example: /api/dailyfcasteval?token=TOKEN&locid=725030_14732&metric=max_t&lead_times=1,3,7&start_date=20261001&end_date=20261020&time_window=5 <br><b>Response format:</b> JSON. lead_times is the ascending list of leads served (the FIRST axis of every per-lead series); xvals is the list of dates (the SECOND axis). yvals.obs is ONE list aligned with xvals (observations do not depend on lead). yvals.forecast, yvals.rmse, yvals.mse, yvals.acc and yvals.ets are each a list of lists: yvals.rmse[i][j] is the RMSE for lead_times[i] over the window ending on xvals[j]. Every inner list has one entry per xvals date, null where there is no value. <br><b>Notes:</b> ETS is reported for rain, snow and hourly rain only, and rain has no ACC (it carries no z-score). Scores need at least 3 days with both a forecast and an observation in the window. Returns: location, metric, lead_times, time_window, xvals, yvals, note, error.

One day's weather across an area: every location matching the criteria on that date, with one or more metrics' values, anomalies (z) and percentiles. Observed days, or Weathersight's forecast for the next 7 days. The result is columnar: columns names each position, and every entry of rows is a list aligned with columns (null where absent). <br><b>When to use:</b> Map a single day, e.g. 'where was it over 40 C yesterday' or 'where is tomorrow forecast to be unusually humid'. <br><b>Date format:</b> date is YYYYMMDD. Observations exist up to yesterday; forecasts from tomorrow to 7 days ahead, and are kept for 31 days. <br><b>Performance:</b> Fast: at most one row per location. <br><b>Prerequisites:</b> None. <br><b>Investigate:</b> Pair with dailycountbyloc to show whether today's extremes are common there. <br><b>Augment:</b> Report the hottest or wettest places on the article's date. <br><b>Request format:</b> HTTP GET, query parameters. Example: /api/dailyweather?token=TOKEN&date=20261019&metric=max_t,min_t&ctryid=IN&sample=200 <br><b>Response format:</b> JSON, columnar. columns names each position once; rows is a list of lists, one per location, each aligned with columns, null where absent. columns are locid, city_name, country, lat, lon, final, then per requested metric m: m, m.z (absent for rain and snow) and m.ptile. units maps each metric to its unit. Rows are sorted by the first metric, highest first. <br><b>Notes:</b> For src=fcast, lead is days from the forecast's issue to the date. It defaults to date minus today plus 1, clamped to 1 to 7: the newest forecast from yesterday's run (today plus 7 exists only once today's run has landed). Rows with final false are yesterday's preliminary values, before the official daily record merged. Returns: date, src, lead, metrics, units, criteria_desc, count, truncated, columns, rows, sample, note, error.

Returns cumulative degree-day indicators (heating/cooling/growing) for a location and period using ERA5 reanalysis data. <br><b>When to use:</b> Estimate energy demand anomalies or agricultural stress in a recent or upcoming period. <br><b>Date format:</b> YYYYMMDD for ymd_start and ymd_end. Maximum interval is 14 days per call. <br><b>Performance:</b> Computed on demand using ERA5; moderate speed. Keep intervals to ≤14 days. <br><b>Prerequisites:</b> Requires lat/lon directly — no locid needed. <br><b>Investigate:</b> Use when the query involves power grid strain or energy demand. For forecast context, use future ymd dates. <br><b>Augment:</b> Adds quantitative energy-demand context to heatwave or cold snap stories. Returns: meta, indicators.

Finds days matching one or more compound weather conditions (e.g. hot + humid, rainy + windy) for a location. Returns up to 5000 most-recent matching events plus the total count. <br><b>When to use:</b> Count occurrences of compound weather events across years, study extreme or unusual day combinations, or identify streaks of such events. <br><b>Date format:</b> year_start/year_end as YYYY; month_day_start/month_day_end as MMDD for seasonal filtering within each year. <br><b>Performance:</b> Computed on demand; returns up to 5000 most-recent matches. <br><b>Prerequisites:</b> Use /location to obtain a locid first. <br><b>Investigate:</b> Use when the query involves compound conditions — 'how many days had both extreme heat and thunderstorms?' Combine numeric and condition metrics with AND/OR logic. <br><b>Augment:</b> Provides event frequency counts for framing rarity in a story ('only 3 such days in the past 20 years'). <br><b>Notes:</b> Numeric metrics: cloudiness, dewp, dpd, gust, hail_size, hi, insolation, max_dewp, max_dpd, max_hi, max_t, max_wbgt, max_wbulb, max_wind, min_dewp, min_t, min_wchill, rain, rain_12hr, rain_1hr, rain_3hr, rain_6hr, snow, snow_12hr, snow_1hr, snow_3hr, snow_6hr, snow_depth, temp, visibility, wbgt, wbulb, wchill, wind, wind_dir. Condition metrics: is_drizzle, is_dust, is_duststorm, is_fog, is_frozen_rain, is_funnel_cloud, is_hail, is_haze, is_heavy_rain, is_heavy_snow, is_ice_pellets, is_mist, is_rain, is_smoke, is_snow, is_squall, is_thunderstorm. Do not specify lower or upper bound when dealing with absolutes unless it is required. Sensible defaults are populated automatically and if the values provided fall out of those, the request is deemed invalid. Returns: locid, name, total_events, events, datestamp, max_t, max_t_complete, min_t, min_t_complete, rain, rain_complete, snow, temp, dewp, wind, max_wind, gust, conditions, criteria_met.

Returns extreme value analysis (return periods) for a specified location and metric. <br><b>When to use:</b> Quantify the statistical rarity of a record or near-record value. Typically called after other APIs establish that an observation is anomalous. <br><b>Performance:</b> Computed on demand; moderate speed. <br><b>Prerequisites:</b> Use /location to obtain a locid first. Prefer level='area' over 'city' for better recall and longer period of record. <br><b>Investigate:</b> Use after /recentextremes or /anom establishes a high value; provides the return-period framing ('a once-in-50-year event'). <br><b>Augment:</b> Provides the statistical rarity framing needed for record-event stories. Try both src_types 'Obs' and 'ERA5' for non-US locations to account for discontinuous station records. Returns: locid, period, months_covered, window_size, N, coverage_pct, results, result.metric, result.value, result.return_period.

Scores how well each forecast model actually performed at each of many locations, by comparing what the models predicted against what was then observed. Returns one score matrix per location, models by evaluation metrics, for a single weather metric at a single lead time, plus the winning model per location. <br><b>When to use:</b> Answer 'which forecast model is most accurate here?' at scale — to map the best model by region, to check whether a specific model is worth using over the default blend, or to compare physical and AI models across the world. <br><b>Date format:</b> ymd_start and ymd_end are YYYYMMDD and inclusive. Inclusive day range as YYYYMMDD. Defaults to the 14 days ending yesterday; today is never included because it has not been verified yet. At most 180 days, which is also how much history the index retains. <br><b>Performance:</b> Filter by ctryid, latlon+radius_km or a small sample_pct to keep it fast; a global 5 percent sample over 14 days is a few hundred locations. <br><b>Prerequisites:</b> None. Supply locid, name, latlon+radius_km, ctryid, or nothing at all with a sample_pct for an unbiased global sample. <br><b>Investigate:</b> Use this to find where a model is strong or weak. Ask for one metric and one lead_time at a time; compare models by reading across each row of evals, and use winners for the answer at a glance. <br><b>Augment:</b> Back a claim about forecast reliability with the measured error of the named model at that place over the recent past. <br><b>Notes:</b> Forecasts come from Open-Meteo. Lead time is the number of days ahead the forecast was issued, so lead_time 1 is yesterday's forecast for today; only the indexed lead times are available. The WN2 model is an ensemble mean, which is smoother than the deterministic models and so tends to score slightly better on mae and rmse and slightly worse on extremes. A score is null, never zero, when its sample was too small to measure: fewer than 5 verified days for mae, rmse, mse, bi

Scores how well each forecast model performed at ONE location, across several forecast lead times and across a sliding time window. Shows both how fast accuracy decays as the forecast reaches further ahead, and how accuracy at a given lead time has varied over recent weeks. <br><b>When to use:</b> Answer 'how far ahead can I trust the forecast here?' or 'has the forecast been unusually poor here lately?' Use fcastevalbygroup instead to compare many locations at one lead time. <br><b>Date format:</b> ymd_start and ymd_end are YYYYMMDD and inclusive. Inclusive day range as YYYYMMDD. Defaults to the 14 days ending yesterday; today is never included because it has not been verified yet. At most 180 days, which is also how much history the index retains. <br><b>Performance:</b> Fast: one location. The cost grows with the number of lead times and the length of the range. <br><b>Prerequisites:</b> A location: locid from /api/location, or name, or latlon. <br><b>Investigate:</b> Ask for several lead_times at once (e.g. 1,3,5,7) to get the skill-decay curve in one call. Set window to get a moving average and see the trend over time rather than one number. <br><b>Augment:</b> Quantify how reliable a forecast for this place actually is at the lead time being written about. <br><b>Notes:</b> Forecasts come from Open-Meteo. Lead time is the number of days ahead the forecast was issued; only the indexed lead times are available. A score is null, never zero, when its sample was too small to measure: fewer than 5 verified days for mae, rmse, mse, bias and ets, or fewer than 10 for acc. Returns: locid, location, metric, unit, ymd_start, ymd_end, days, window, num_windows, windows, lead_times, models, eval_metrics, scanned, count, truncated, error, evals, n, n_days, error_basis.

Returns meta information for a location given a name, locid, or lat/lon. <br><b>When to use:</b> Obtain the canonical locid needed by all location-specific API calls. Typically the first call in any workflow. <br><b>Performance:</b> Fast — precomputed lookup. <br><b>Prerequisites:</b> None — this is the entry point. <br><b>Investigate:</b> Call first whenever the user names a city or region; cache the locid for all subsequent calls in the session. Use 'City, State Country' format (e.g. 'Austin TX USA'). <br><b>Augment:</b> Resolve city names from the article to locids early; reuse them throughout augmentation to avoid repeated name lookups. Returns: name, locid, friendly, lat, long, country, icao, elevation, timezone, wmo.

Returns the catalogue of all supported weather metric identifiers with units and categories. <br><b>When to use:</b> Resolve metric IDs to human-friendly names, units, and categories. Call once and cache per session. <br><b>Performance:</b> Fast — static data; safe to cache for the lifetime of a session. <br><b>Prerequisites:</b> None. <br><b>Investigate:</b> Call once at session start; use metric.id as a lookup key throughout the conversation. <br><b>Augment:</b> Translate metric IDs into readable labels for article text and chart axes. Returns: metrics, metric.id, metric.name, metric.cat, metric.type, metric.dist.

无需输入参数。

Returns recent weather records (all-time or period-of-record extremes) for the world or specified countries. <br><b>When to use:</b> Find which locations have broken or nearly broken records in a recent date window. Set history_years ≥ 15 to ensure a meaningful period of record. <br><b>Date format:</b> YYYYMMDD for ymd_start and ymd_end. Keep windows ≤ 3 months per call for reasonable performance. <br><b>Performance:</b> Computed on demand; slower for large date ranges. Start with scope='monthly' or 'yearly'; fall back to 'weekly' for near-records. <br><b>Prerequisites:</b> Use /countries for country IDs; use /location for locids. <br><b>Investigate:</b> Use after /breaking identifies a record-breaking event to get precise extreme-value context. For US locations use period_type='DAY'; for non-US use 'FULL_DAY'. Hourly-derived metrics (wet bulb, wind gusts) for non-US require period_type='DAY'. <br><b>Augment:</b> Provides the 'record' framing for a story — 'hottest day ever recorded at this station.' Note: FULL_DAY and DAY expose different metric sets. Returns: results, extreme.locid, extreme.name, extreme.country_code, extreme.lat, extreme.lon, extreme.elev, extreme.period_type, extreme.metric, extreme.ymd, extreme.anomaly_type, extreme.scope, extreme.value, extreme.history_years.

Seasonal (monthly) forecast anomalies for the next six months, with the local climatology they are measured against. Each result gives, per metric: the ERA5 baseline mean (means), its interannual standard deviation (std), the predicted anomaly (anom, in degrees C / mm / km/h) and how unusual that is, both as standard deviations (norm) and as a percentile rank among the last 30 years (perc). <br><b>When to use:</b> Answer 'will next month be hotter/wetter than normal here?' or 'where is the coming season predicted to be most unusual?' <br><b>Date format:</b> ym_start and ym_end are YYYYMM, inclusive. For a single month set both to the same value. Defaults to next month through next month + 5. <br><b>Performance:</b> Filter by locid, ctryid or latlon+radius_km to keep fast; a whole-world month slice is about 4000 rows and fits in one page. <br><b>Prerequisites:</b> None; supply locid, name, latlon+radius_km, ctryid, or nothing at all for a global query. <br><b>Investigate:</b> Rank places by how abnormal the coming months look. Use sort=perc:obs.rain.sum for rainfall and sort=norm:max_t.mean for heat. <br><b>Augment:</b> Back claims about the coming season with the predicted anomaly and how it compares with the local 30-year normal. <br><b>Notes:</b> Monthly resolution only — for daily forecasts use typicalweather. The forecast is ECMWF SEAS5; its anomalies are relative to SEAS5's own 1991-2020 model climatology, so means + anom approximates rather than equals the predicted absolute. Returns: ym_start, ym_end, baseline, metrics, count, truncated, note, error, next_cursor, results, locid, location, ym, run_ymd, basis_type, means, std, anom, norm, perc, criteria_met, criteria_met_count.

Returns aggregated metric values as a yearly or monthly timeseries for a location. <br><b>When to use:</b> Detect long-term trends and compute statistical significance (r-squared, p-value). Best suited for multi-decade spans. <br><b>Date format:</b> mm_dd_start/mm_dd_end as MMDD (day-of-year window, not a calendar year); year_start/year_end as YYYY. Note: Use mm_dd_start/mm_dd_end as MM when months are specified and MMDD when week-level granularity is needed. When day-level info is needed use /events or /dailycomp. <br><b>Performance:</b> Computed on demand; slower for large date ranges or many metrics. <br><b>Prerequisites:</b> Use /location to obtain a locid first. <br><b>Investigate:</b> Use for trend analysis ('Is max temperature at location X increasing over decades?'). Combine with r-squared post-processing for significance. <br><b>Augment:</b> Provides decadal trend context alongside current anomalies ('temperatures have risen 1.5°C over 40 years'). Returns: locid, lat, lon, xvals, yvals.

Returns statistical distributions of weather attributes (temperature, precipitation, wind, etc.) for a location and time period. <br><b>When to use:</b> Establish the climatological baseline — what is 'normal' for this location and period. Use before discussing anomalies. <br><b>Date format:</b> YYYY[MM[DD]]: YYYYMMDD for a specific week, YYYYMM for a month, YYYY for a seasonal or annual overview. Note: YYYYMMDD does not give info about daily obs. If a date is specified it corresponds to the week. Use /events for daily history. <br><b>Performance:</b> Computed on demand; moderate speed. Avoid date spans wider than one year. <br><b>Prerequisites:</b> Use /location to obtain a locid first. <br><b>Investigate:</b> Good for grounding anomaly claims — e.g. 'Is 35°C in July unusual for Madrid?' Check distributions before asserting extremeness. <br><b>Augment:</b> Use to provide climatological context before describing observed anomalies in an article. Returns: duration, observations, conditions, probs, pcps, means, >>.