-
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
DRAFT: Change /locations logic #101
base: main
Are you sure you want to change the base?
Conversation
…tual stations, making the connection only by parameter_name.
API Unit Test Coverage Report
API Unit Test Coverage Summary
|
for group in ts_response.groups: | ||
ts = group.combo | ||
parameter = make_parameter(ts) | ||
all_parameters[ts.parameter_name] = parameter |
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.
Is it possible that there is a duplicate parameter name? If so should then an exception be raised that it already exists?
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.
Yes, that is probably the right way/place to do 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.
I don't think it is possible. make_parameter
creates the definition from variables used for parameter_name.
}, | ||
) | ||
all_parameters[obs.ts_mdata.parameter_name] = parameter | ||
# TODO: How to check for inconsistent parameter definitions between stations |
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.
Is this possible to do on lines 76-79? Because if a parameter_name exists that is not unique, it is likely impossible to distinguish between them for stations.
I think it is an improvement that we can request more data. I am curious how it impacts the API performance. Especially now that is less likely that we hit the gRPC limit. |
FYI: Based on discussions I added this issue. Feel free to comment! |
This PR is just to discuss an idea.
Change /locations to first get all unique parameters, and then the actual stations, making the connection only by parameter_name.
Advantage is that it there is less data to transfer. For the KNMI test data set:
Before: One request of 220 KB
After: One request of 4 KB followed by request of 132 KB.
Disadvantage is that we can no longer check for inconsistent parameter definitions (i.e. different parameters that have the same
parameter_name
).I think a better way of doing this would be to do this approach in the
store
directly, which means the filtering is done in thestore
, and significantly less data would be send to the API.