Ontario (IESO) Price Locations

Every Ontario (IESO) location that carries a price, as three columns: location_id, name, and kind.

Infrastructure data

Download data

Native record

one row per priced location and kind

slow-moving dimension, refreshed every 6 hours publication cadence

Evidence

Reference data

Stable context used to interpret other datasets

Time basis

Point-in-time records

UTC · static reference

Overview

1,097 rows — node (1,069), intertie (18), virtual_zone (9), zone (1). This is the dimension the Ontario (IESO) price, and where applicable constraint, tables join to, and it is the one place a location's type is decided: resolve "which hubs exist", "is this a zone or a node", or "give me the readable name for this id" here rather than inferring a type from a name prefix. For Ontario, name equals location_id except the zone row (Ontario), named Ontario zonal price. Nodes join ieso.lmp_system.location, virtual zones ieso.lmp_virtual_zonal.zone_name, interties ieso.lmp_intertie.intertie_name. IESO's price feeds are the registry: a location appears once priced in the last 30 days. Virtual zones (EAST:HUB, TORONTO:HUB) are trading hubs, not Ontario's ten demand regions, and no location here has a verified map position. The same three columns exist for every market, so the equivalent question in another ISO is the same query against that ISO's table.

Query contract

Treat (location_id, kind) as the row identity. This is a current dimension snapshot, not a history: it describes the locations that exist now and carries no validity dates.

Analysis rules

Counting rows by kind describes the market's current location inventory. It does not describe how many locations were priced on some past date.
Join fact tables on location_id, and add kind to the join when the fact table also carries kind — the pair, not the id alone, is the identity.

Interpretation

A location existing here does not mean it has a price in any particular interval; check the price table for that.
kind is a classification of the priced object, not of the physical equipment behind it, and carries no capacity, voltage, or geography. Location geography lives in grid.entities.

Access

Need the full history of this dataset in Snowflake, Databricks or your own storage? Data services delivers it on a schedule.

Schema3

Column

Type

location_idLowCardinality(String)

nameLowCardinality(String)

kindLowCardinality(String)

Sample data

location_id	name	kind
ABITIBISF-LT.AG_T1	ABITIBISF-LT.AG_T1	node
ABKENORA-LT.AG	ABKENORA-LT.AG	node
ABRASIVE-LT.T1_LF_DRA	ABRASIVE-LT.T1_LF_DRA	node
ADAMSBLVD-LT.L1_LF	ADAMSBLVD-LT.L1_LF	node
ADELAIDE-LT.AG_T1	ADELAIDE-LT.AG_T1	node
AGIMAKDS-LT.TT_LF	AGIMAKDS-LT.TT_LF	node
AGINCOURT-LT.LFBY	AGINCOURT-LT.LFBY	node
AGUASABON-LT.AG12	AGUASABON-LT.AG12	node
ALANBRG28KV-LT_H1	ALANBRG28KV-LT_H1	node
ALBION-LT.LFBJQY	ALBION-LT.LFBJQY	node
ALCOCAN-LT.TT1_LF	ALCOCAN-LT.TT1_LF	node
ALEXANDER-LT.AG_T1	ALEXANDER-LT.AG_T1	node
ALEXANDER-LT.AG_T2	ALEXANDER-LT.AG_T2	node
ALEXANDER-LT.AG_T3	ALEXANDER-LT.AG_T3	node
ALEXANDER-LT.AG_T4	ALEXANDER-LT.AG_T4	node
ALGOMAEAF-LT.EAF1	ALGOMAEAF-LT.EAF1	node
ALLANBURG-LT.DRCTENGY_DRA	ALLANBURG-LT.DRCTENGY_DRA	node
ALLANBURG-LT.ENERCORP_DRA	ALLANBURG-LT.ENERCORP_DRA	node
ALLANBURG-LT.ENERNOC_DRA	ALLANBURG-LT.ENERNOC_DRA	node
ALLANBURG-LT.ENPOWINC_DRA	ALLANBURG-LT.ENPOWINC_DRA	node
ALLANBURG-LT.NRGCS_DRA	ALLANBURG-LT.NRGCS_DRA	node
ALLANBURG-LT.NRSTORCI_DRA	ALLANBURG-LT.NRSTORCI_DRA	node
ALLANBURG-LT.RODANCI_DRA	ALLANBURG-LT.RODANCI_DRA	node
ALLANBURG-LT.VOLTUS_DRA	ALLANBURG-LT.VOLTUS_DRA	node
ALLISTON-LT.LFT2	ALLISTON-LT.LFT2	node

Coverage

No time-indexed data — coverage isn’t applicable to this dataset.

Related infrastructure data

Related infrastructure data
Dataset	Description
Advanced MetersEIA · annual (report year)	EIA-861 advanced metering: AMR, AMI and other meter counts, AMI energy served and customer access, by utility and customer class. Advanced_Meters, one row per utility, state, balancing authority and customer class. customer_class is residential, commercial, industrial, transportation (direct_connected in the distributed generation tables) or EIA's own total, so summing classes without excluding total counts everything twice. event_time is 1 January of the report year. release is final or early_release: EIA posts an early release of a year in August and replaces it with the final file in the autumn, and the mirror keeps the newest row per key. A key cell EIA leaves blank is '' or 0, and duplicate_index numbers rows that still share a key, in workbook order.
AESO Asset ListAESO · daily snapshot	AESO's registry of market assets: asset code, name, pool participant, operating status and asset type (source, sink and others), including retired assets.
Alberta (AESO) Price LocationsAESO · slow-moving dimension, refreshed every 6 hours	Every Alberta (AESO) location that carries a price, as three columns: location_id, name, and kind. 1 rows — system (1). This is the dimension the Alberta (AESO) price, and where applicable constraint, tables join to, and it is the one place a location's type is decided: resolve "which hubs exist", "is this a zone or a node", or "give me the readable name for this id" here rather than inferring a type from a name prefix. For Alberta, the one location_id is SYSTEM: the pool price (aeso.pool_price) and system marginal price (aeso.system_marginal_price) are system-wide and carry no location column. Alberta has no nodal, zonal or hub prices; do not look for one. Generating assets are identified by AESO asset code in aeso.unit_status and aeso.asset_list, not here. The same three columns exist for every market, so the equivalent question in another ISO is the same query against that ISO's table.
Baja California (CENACE) Price LocationsBCA · slow-moving dimension, refreshed every 6 hours	Every Baja California (CENACE) location that carries a price, as three columns: location_id, name, and kind. 4 rows — zone (4). This is the dimension the Baja California (CENACE) price, and where applicable constraint, tables join to, and it is the one place a location's type is decided: resolve "which hubs exist", "is this a zone or a node", or "give me the readable name for this id" here rather than inferring a type from a name prefix. For Baja California, location_id is CENACE's load zone (TIJUANA, MEXICALI, ENSENADA, SANLUIS) and joins cenace.zonal_prices.load_zone; name is the city it is named for. CENACE prices Baja California by load zone only; there are no nodes or hubs in this dimension. The same three columns exist for every market, so the equivalent question in another ISO is the same query against that ISO's table.