[un energy] scaling issues with energy generation data about data HOT 9 OPEN

It would be nice to have a "preferred" unit for energy related import and check it in the import tool? @pradh

from data.

I agree it is nicer to have the same unit for a given StatVar.

But we probably shouldn't plot different units in a single bar/line chart ? Also, in this case, are we able to prefer UNEnergy as the source, given US has both: https://screenshot.googleplex.com/Aj6PeKqb4ovWHv3 ?

from data.

Ah, I missed that there are two datasources plotted together! Sorry @ajaits.

We should be able to do this conversion easily if we understand these units. But we can prefer UNEnergy for now

from data.

Bo, to generalize your suggestion to have some check in import tool, instead of picking a specific unit, we can perhaps lookup the "StatVarSummary" cache for a stat-var and Warn if a new unit (not part of the existing series) gets added for a pre-existing stat-var.

WDYT?

from data.

From a API client point view (in this case website is a client), it would be nice that we can convert data to a unified common unit if possible.

If there are multiple source series with different unit, then mixer would ideally pick the most used unit, then some places are dropped. Or, website would have a the logic to do number conversion. In either case, I think conversion in the source is better, as users have to do the conversion any way.

from data.

Bo, to generalize your suggestion to have some check in import tool, instead of picking a specific unit, we can perhaps lookup the "StatVarSummary" cache for a stat-var and Warn if a new unit (not part of the existing series) gets added for a pre-existing stat-var.

WDYT?

That works. But still feel a unified unit is better.. It should happen somewhere before the data is given back to users. Common data (with common unit) :)

from data.

Bo, to generalize your suggestion to have some check in import tool, instead of picking a specific unit, we can perhaps lookup the "StatVarSummary" cache for a stat-var and Warn if a new unit (not part of the existing series) gets added for a pre-existing stat-var.
WDYT?

That works. But still feel a unified unit is better.. It should happen somewhere before the data is given back to users. Common data (with common unit) :)

Unless we support conversion capability in the schema/API, we can only notify the importing user to unify it. And that's what this does?

from data.

If there are multiple source series with different unit, then mixer would ideally pick the most used unit, then some places are dropped. Or, website would have a the logic to do number conversion. In either case, I think conversion in the source is better, as users have to do the conversion any way.

Conversion is source is better, but we probably have this and other diverging cases in the KG now. For these, might be nice to include conversion support in API layer. For now perhaps the logic can be hard-coded/config-driven, but eventually it can perhaps read the schema to do conversions (b/197723426 talks about schema for this).

from data.

I will do this in API for now datacommonsorg/mixer#631. When conversion schema is available, we can move the conversion during import time.

from data.