Add grouping to URL

[simonhac]

currently we can specify range and interval on the URL for the energy view.

eg. https://dev.opennem.org.au/energy/nem/?range=30d&interval=1d

would be good to add the grouping (if it's not Default):

[simonhac]

would also be ideal to capture the selected/deselected series (and chart settings) in a manner that doesn't make really ugly URLs, but i suspect that's a much bigger task.

[aleith]

capturing states for selected/deselected series for graphs would be pretty useful for sharing and personal convenience storing often used settings. to keep the urls from spawning an ungodly amount of suffixes listing all the selected technologies one buy one this is a suggestion to keep it all neat (even if it's a bit less human readable for the url)

there are currently about 19 different energy technologies that generate or dispatch power, from brown coal to battery charging (including export and import which only shows up in when energy graph is state based).

this means (if my rusty maths is correct) that there are 2¹² (2^19) combinations of on/off states for each energy category (or technology or whatever is the correct way to identify this). That's only 524,288 different combinations of how the graph technology series selection states could be in. this could be reflected in a lookup table deserialising the integer code into these 524,288 combinations of on/off states, or it could be auto-generated with a conversion of the url integer to a base2 number and checked bitwise against the table of known generation/dispatch technologies to be shown in the data series.

https://dev.opennem.org.au/energy/nem/?range=30d&interval=1d&selected=72

this url would show wind, rooftop PV but not coal, OCGT, CCGT or Solar Thermal (CTS) if the energy technology assignment was as follows (checks and crosses indicate including in above url)

1. Coal (=1) ❌
2. OCGT (=2) ❌
3. CCGT (=4) ❌
4. Wind (=8) ✅
5. Solar Thermal (=16) ❌
6. Utility PV (=32) ❌
7. Rooftop PV (=64) ✅

new technologies could be accommodated into this scheme easily simply by a putting new entries into the known generation/dispatch technology list. then new codes with numbers > 524,288 would be auto-generated to accommodate the new technologies in the "Show" state and old numbers =< 524,288 would cover any new technologies in the "Don't Show" state. Whatever these new technologies might be I'm not sure (other than thermal storage charging at industrial plants using free or cheap power), but I can think of subsets of demand side categories for DSM/flexible demand, like delayed EV charging, V2G-VPP dispatch, thermal storage in heat batteries used mainly for heat but also to generate power (with low heat to power conversion efficiencies, just like thermal power stations) at high price events of peak demand).

Given that there are also Simplified, Coal/Gas/Renewables, Flexible, Renewable/Fossil, Solar/Residual graphs also and potentially new grouping states, there's a few other combinations to consider that have things like "Fossil" and "renewable" groupings, but this is a smaller set of combinations and still the numbers would be well under 524,288 x 2 I would think.

[simonhac]

@aleith i like this. We'd need to be super careful to never change the order of fuel-techs. i guess this is what unit tests are for!

i'd convert the selection to base64 — eg. 13342347 → 6ZqL — and only include if it's not the default (all selected).

[aleith]

@aleith i like this. We'd need to be super careful to never change the order of fuel-techs. i guess this is what unit tests are for!

yes to unit tests.

if you think there's a danger of it needing to change at some point, (probably isn't) i guess you could embed a version number in the prefix or suffix of the selections token.

the version index would simply point to the version of the table used to make the url link. the index would point to the correct version of the table.

so,

where selections_token is "1234", current version of lookup table is 03,
token → "03_1234" or
token → "123403" or whatever. 

thinking about it some more, having seperate tables for the reduced complexity groupings (eg renewables vs fossil fuels) would reduce the sum of potential combinations for the reduced selection groupings rather than adding more technology labels (of groups) to the long list of (individual) technologies.

also you wouldn't have potential tokens for impossible selections like True state for rooftopPV && all RE showing on the same graph (double counting of rooftopPV).

the parser of the url would first see what groupings token is set to (if there's no token defaults to the first table with every technology and zero groupings) then the version prefix/suffix and use the grouping to identify the table then lookup the selections token on the relevant table.

i'd convert the selection to base64 — eg. 13342347 → 6ZqL — and only include if it's not the default (all selected).

that's much more tidy, especially if you have a prefix or suffix in the token to carry the version history lookup.