Visual settings is included in the metadata schema, but not explicitly set by fmu-dataio. Legacy usage of metadata rests on a lot of visual settings being set while generating data, and in the JS workflow defaults have been included in global_variables. This is a pattern that could be continued into fmu-dataio possibly, combined with the option of giving visual settings as input argument.
There is a larger discussion here, however, relating to the responsibility of the data producer vs the data consumer. I think it might be a better (?) pattern to let clients decide visual settings as much as possible. That said, however, visual settings could be the result of domain-specific rules and know-how which could be difficult to convey if not explicitly part of the metadata.
Suggestion, for discussion:
Create a separate VisualSettings object to hold (and calculate) visual settings and pass that to fmu-dataio.ExportData as an argument. If not passed, a skeleton version with default values is included. Experience from JS is that this can quickly escalate, which is why I think keeping it as a separate module is wise. Also, given that patterns might change, I think keeping the interface with the rest of fmu-dataio slim is smart.
Visual settings is included in the metadata schema, but not explicitly set by fmu-dataio. Legacy usage of metadata rests on a lot of visual settings being set while generating data, and in the JS workflow defaults have been included in
global_variables
. This is a pattern that could be continued intofmu-dataio
possibly, combined with the option of giving visual settings as input argument.There is a larger discussion here, however, relating to the responsibility of the data producer vs the data consumer. I think it might be a better (?) pattern to let clients decide visual settings as much as possible. That said, however, visual settings could be the result of domain-specific rules and know-how which could be difficult to convey if not explicitly part of the metadata.
Suggestion, for discussion: Create a separate
VisualSettings
object to hold (and calculate) visual settings and pass that tofmu-dataio.ExportData
as an argument. If not passed, a skeleton version with default values is included. Experience from JS is that this can quickly escalate, which is why I think keeping it as a separate module is wise. Also, given that patterns might change, I think keeping the interface with the rest offmu-dataio
slim is smart.