PJM logo

PJM Price Locations

Every PJM location that carries a price, as three columns: location_id, name, and kind.

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

14,977 rows — load (12,159), generator (2,255), aggregate (293), bus (153), interface (82), zone (23), hub (12). This is the dimension the PJM 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 PJM, location_id is the numeric pnode_id and name is the pnode name (e.g. WESTERN HUB). Join on location_id; report name. 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

Query from your own tools

Use the guarded HTTP endpoint directly, or connect an MCP client and load the dataset contract with describe_data before calling query_data.

HTTP endpoint
POST /api/v1/datasets/pjm_locations/query

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_idnamekind
1PJM-RTOzone
101560795HAYROAD 8CCaggregate
1047909TOSCOGISload
1047910AMTRAKload
1047911AMTRAKload
1047912BETZWOODload
1047913LLANERCHload
1047914LLANERCHload
1047915LLANERCHload
1047916UPPERPROload
1047919EXETERload
1047920EXETERload
1047921HUNLOCKload
1047925POPETALBload
1047926COURTDALload
1047927DALLASload
1047928GLENVIEWload
1047929HANOVERload
1047930HANOVERload
1047932KING UGIload
1047933KING UGIload
1047934KOONSVILload
1047935KOONSVILload
1047936KUNKLEload
1047937LINC UGIload

Coverage

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