Closed GregorDeCillia closed 2 years ago
Update: this problem also occurs in the following cube from the environmental accounts
x <- STATcubeR::sc_table_custom(
db = 'str:database:deeehh02',
measures = "str:statfn:deeehh02:F-DATA:F-EEGJ:SUM",
dimensions = c(
"str:field:deeehh02:F-DATA:C-ENEETRAEG0-0",
"str:field:deeehh02:F-DATA:C-C57-0",
"str:field:deeehh02:F-DATA:C-ENEZEIT-0",
"str:field:deeehh02:F-DATA:C-ENEVERW-0"
)
)
For now, it is probably best to use the following workaround
sc_table(json_file, add_totals=FALSE)
This will make sure that $tabulate()
falls back to aggeegating via sums and the above issue is resolved if unweighted sums are an appropriate way of aggregating the data
It would be useful if STATcubeR would do this fallback automatically in certain situations, but the danger here is that "real missings" could be replaced by sums in situations where this is not meaningful.
national accounts cubes such as
sc_example("foreign_trade")
do not provide values for total codes.https://github.com/statistikat/STATcubeR/blob/8416f6325e2cb80098b2b19826cda6a5fed81ec2/inst/json_examples/foreign_trade.json#L2
Therefore, they should be aggregated directly in
$tabulate()
because otherwise the result would be a table filled with NAs in all measure columns.In one of our internal projects, we currently use the condition
to determine wether a direct aggregation via
rowsum()
should be applied.