Report Q - Generation output by plant - how to identify unique plant, understand duplicates?

  • Last post 07 December 2023
LFNZECS posted this 04 December 2023

I am seeking some clarification in how to analyse the generation output by plant datasets ( Which columns need to be combined to uniquely identify the singular plants data? 


Is it the unique combinations of a Network code, generator code, and POC? Ive included some example combinations below from looking at the dataset 202310_Generation_MD to which I was hoping to get clarification around please.


1. at TWC2201, there is one NW code TRPG, and a dataset for each gen code te_rere_hau, and twf_3. This looks to example that the POC cannot be the sole identifier and that this is therefore two different generation plants that inject as the same NSP?


2. at LTN2201, there is one NW code MRPL, but two data sets for the same gen code turitea. One with a fuel/tech type of wind, one with fuel/tech blank. The kWh data for each set appears identical - is this an error, or is this correct and the two datasets should be combined for the turitea total? (Is one of the sets for turitea north and one for turitea south?)


3. at ARI1102, there is one gen code arapuni, that has two network codes MRPL and POCO. One of which data set appears to be all 0 kWh. Is this the same generation plant and can inject across two networks at the same POC? Or is this a case of a change in network company historically, the old remains and will report as zero? 


Much appreciated


Attached files

Guy Ross posted this 07 December 2023

Hi Laura,

Note: This dataset is an unholy union of three different sources, dating back to the dark ages. There is some value in it's length of service, but the plan is to retire it when we have the time to replace it with something more maintainable and explainable.

To answer your main question? I'd look at the Gen_Code column.

1. Yes, two plants can inject at the same Point of Connection. And conversely, over time, one plant can change which POC it injects at.

2. No. That was a mapping error. Files have been regenerated.

3. That looks like a historical network/connection ownership change. I'll look at scrubbing it out - although that may have unintended consequences, so no promises!