-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refine results schema #22
Conversation
… its respective list of results
Here is a simplified example of what the wind resource assessment section of a JSON document could look like. Note that I left out the {
"wind_resource_assessments": [
{
"results": {
"air_density": [
{
"dimensions": [
"measurement",
"height"
],
"statistics": [
{
"statistic_type": "mean",
"values": [
[
[
"BF_M1",
120.0
],
1.234
]
]
}
]
}
],
"probability": [
{
"dimensions": [
"wind_from_direction",
"wind_speed"
],
"statistics": [
{
"statistic_type": "mean",
"values": [
[
[
0.0,
2.5
],
0.1
],
[
[
120.0,
2.5
],
0.2
],
[
[
240.0,
2.5
],
0.3
],
[
[
0.0,
10.0
],
0.1
],
[
[
120.0,
10.0
],
0.2
],
[
[
240.0,
10.0
],
0.1
]
]
}
]
}
],
"temperature": [
{
"dimensions": [
"measurement",
"height"
],
"statistics": [
{
"statistic_type": "mean",
"values": [
[
[
"BF_M1",
120.0
],
1.234
]
]
}
]
}
],
"wind_shear_exponent": [
{
"dimensions": [
"measurement"
],
"statistics": [
{
"statistic_type": "mean",
"values": [
[
[
"BF_M1"
],
0.18
]
]
}
]
}
],
"wind_speed": [
{
"dimensions": [
"measurement",
"height"
],
"statistics": [
{
"statistic_type": "mean",
"values": [
[
[
"BF_M1",
120.0
],
6.83
],
[
[
"BF_M1",
125.0
],
6.85
],
[
[
"BF_M1",
148.0
],
6.93
],
[
[
"BF_M1",
150.0
],
6.94
],
[
[
"BF_M1",
158.0
],
6.96
],
[
[
"BF_M1",
160.0
],
6.97
]
]
},
{
"statistic_type": "standard_deviation",
"values": [
[
[
"BF_M1",
120.0
],
0.27
],
[
[
"BF_M1",
125.0
],
0.27
],
[
[
"BF_M1",
148.0
],
0.29
],
[
[
"BF_M1",
150.0
],
0.29
],
[
[
"BF_M1",
158.0
],
0.31
],
[
[
"BF_M1",
160.0
],
0.31
]
]
}
]
}
]
},
"wind_resource_assessment_id": "BfWF_WRA_1"
}
]
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No dealbreakers here, so just some comments on requirements files:
With requirements files, it's usually best to specify the exact versions in a constraints file
Additionally, we could have a top level requirements.txt file that sits in the root directory that specifies the 3 different requirements file we currently have, makes installation a bit easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cubico-craig, thanks for the feedback and excuse the delay in reverting back.
As discussed during the last meeting, I have now implemented the new data model for results across the EYA DEF and pushed those updates to the branch of this PR.
I have opened #23, for the topic of whether we should specify requirements in a constraints file. I have not had a chance to look into that properly yet. Under that issue I also put some background on the current setup.
Refine the schema for results to take the measurement quantity out of the results object and instead map each measurement quantity to a list of results objects.