Skip to content
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

Merged
merged 20 commits into from
Mar 4, 2024

Conversation

lukas-phaf
Copy link
Contributor

@lukas-phaf lukas-phaf commented Feb 13, 2024

Also improved the data endpoints to return the same parameter info as the /collections and /locations endpoints.

TODO:

  • Fix integration tests
  • The code is currently hardcoded to get a specific range of data, which corresponds to 1 row in the KNMI dataset. This should be removed and replaced by the "get last value" functionality that Jo is working on (Issue 40 getobservations latest #41)

Copy link

github-actions bot commented Feb 13, 2024

API Unit Test Coverage Report
FileStmtsMissCoverMissing
\_\_init\_\_.py00100% 
datastore_pb2.py584621%24–69
datastore_pb2_grpc.py432347%37–52, 85–87, 92–94, 99–101, 106–108, 112–136, 174, 191, 208, 225
dependencies.py481862%16, 26–27, 34, 41, 52, 62–69, 77–84
grpc_getter.py16850%15–16, 20–23, 27–29
locustfile.py15150%1–31
main.py22386%27, 37, 47
metadata_endpoints.py341265%24, 42–103, 107
custom_geo_json
   edr_feature_collection.py60100% 
formatters
   \_\_init\_\_.py70100% 
   covjson.py50492%71, 86–89
routers
   \_\_init\_\_.py00100% 
   edr.py883758%45–104, 132–144, 173, 184–190, 229–246
   records.py00100% 
TOTAL38716657% 

API Unit Test Coverage Summary

Tests Skipped Failures Errors Time
16 0 💤 9 ❌ 0 🔥 2.278s ⏱️

@lukas-phaf lukas-phaf changed the title Add parameter information to /locations endpoint Add parameter information to /collections and /locations endpoint Feb 15, 2024
api/metadata_endpoints.py Outdated Show resolved Hide resolved
@Jeffrey-Vervoort-KNMI Jeffrey-Vervoort-KNMI force-pushed the issue_20-locations_parameters-python branch 3 times, most recently from 573778f to fc4f794 Compare February 23, 2024 12:12
@Jeffrey-Vervoort-KNMI Jeffrey-Vervoort-KNMI force-pushed the issue_20-locations_parameters-python branch 4 times, most recently from 4822fe6 to 79c4eba Compare February 28, 2024 16:10
@Jeffrey-Vervoort-KNMI Jeffrey-Vervoort-KNMI marked this pull request as ready for review February 28, 2024 16:17
@Jeffrey-Vervoort-KNMI Jeffrey-Vervoort-KNMI force-pushed the issue_20-locations_parameters-python branch from 79c4eba to 0fa9854 Compare February 29, 2024 07:33
@Jeffrey-Vervoort-KNMI Jeffrey-Vervoort-KNMI force-pushed the issue_20-locations_parameters-python branch from e6eed8e to 013bd63 Compare February 29, 2024 08:25
Copy link
Collaborator

@Teddy-1000 Teddy-1000 left a 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.

api/routers/edr.py Show resolved Hide resolved
…roved them to make them unique and more accurate.
@Jeffrey-Vervoort-KNMI Jeffrey-Vervoort-KNMI force-pushed the issue_20-locations_parameters-python branch from 039c706 to 9e766ea Compare March 4, 2024 12:24
@Jeffrey-Vervoort-KNMI Jeffrey-Vervoort-KNMI merged commit 097aa15 into main Mar 4, 2024
6 checks passed
@@ -52,35 +52,43 @@
]
},
"parameters": {
"relative_humidity_2.0_mean_PT1M": {
"wind_speed_10_mean_PT10M": {
Copy link
Contributor Author

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.

Comment on lines +101 to +104
# param_id = ts_mdata.parameter_name
# standard_name = ts_mdata.standard_name
# title = ts_mdata.title
# unit = ts_mdata.unit
Copy link
Contributor Author

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?

Comment on lines +57 to +59
- 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

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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,
Copy link
Collaborator

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.

Copy link
Collaborator

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

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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?

@Jeffrey-Vervoort-KNMI Jeffrey-Vervoort-KNMI deleted the issue_20-locations_parameters-python branch March 14, 2024 13:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants