-
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
Add parameter information to /collections and /locations endpoint #35
Add parameter information to /collections and /locations endpoint #35
Conversation
API Unit Test Coverage Report
API Unit Test Coverage Summary
|
573778f
to
fc4f794
Compare
4822fe6
to
79c4eba
Compare
…s endpoint in python.
…ontainer, not in the volume.
Used nametuple for clarity.
…the loader to have a unique parameter ID and make the parameters distinguishable.
…l of the parameters for the locations.
79c4eba
to
0fa9854
Compare
…t as step to the ci test-datastore action.
e6eed8e
to
013bd63
Compare
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.
Left a comment regarding the EDRFeatureCollection, otherwise the PR looks good.
cff9b4a
to
039c706
Compare
…roved them to make them unique and more accurate.
039c706
to
9e766ea
Compare
@@ -52,35 +52,43 @@ | |||
] | |||
}, | |||
"parameters": { | |||
"relative_humidity_2.0_mean_PT1M": { | |||
"wind_speed_10_mean_PT10M": { |
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.
What is the order that is used? As this is not alphabetical. Is it fixed? Collection endpoints does seem to be ordered? Should really be the same.
# param_id = ts_mdata.parameter_name | ||
# standard_name = ts_mdata.standard_name | ||
# title = ts_mdata.title | ||
# unit = ts_mdata.unit |
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.
These lines can go, right?
- name: Test client runs without errors | ||
run: DYNAMICTIME=false LOTIME=1000-01-01T00:00:00Z HITIME=9999-12-31T23:59:59Z docker compose run --rm client | ||
|
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.
This is now run twice (see a couple of lines down). Any idea why?
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.
As the client is part of the profile test in the docker compose. I ran into the problem that the integration tests failed because locally they had the client, but in the pipeline not.
I wanted to move it upwards in the pipeline. But instead of moving, I copied it.
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.
Originally client did not leave any data... but now it does, and the integration test depend on this data? Do we want that?
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.
I had my doubts about that too, the reason that I added it is that it shows current issues such as the empty string as default for gRPC instead of NULL. But I can change it as well to not include it.
|
||
for obs in ts_response.observations: | ||
parameter = Parameter( | ||
description=obs.ts_mdata.title, |
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.
Sorry I did not catch this earlies. But I do not think ts_mdata.title
can be used here, as it will most likely be different for every time series. What we really need is the standard_name description from nerc vocab.
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.
We also run in to the same issue in /locations
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.
So you are hitting the "mutiple definitions" 500 error?
Shall we just use standard_name
for description for now?
I am guessing that obs.ts_mdata.instrument
for label (3 lines down) is also not correct.
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.
To get back to this, I don't think the description from the nerc vocab would do, as that is a description of the standard_name, not of this specific parameter.
All the different air_temperatures now have the same description, which doesn't make to much sense. Some measure it at grass height, some at 2.0m. And there can have different average times. The would all be described as "Air temperature is the bulk temperature of the air, not the surface (skin) temperature.".
What we need in the metadata is a field that describes the parameter as measured, independent of the station.
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.
BTW, why are all the ts_mdata.title
different in your case. Do you include the station name in them?
Also improved the data endpoints to return the same parameter info as the /collections and /locations endpoints.
TODO: