Open Travis-Simmons opened 4 days ago
Thanks @Travis-Simmons - I can see this being possible in two ways, curious what you expect/prefer to see:
@nikki-t I think both options would require setting up another GSI on the nodes table to allow querying by reach_id, though it looks like node_id contains the reach_id of the associated reach, so maybe there's some tricky ways around this by doing something like using the granuleUR output from the reach query to find the associated node granule, and filtering to the right node features by allowing a partial node_id to be entered. We'll need to do a feature analysis to sort out the details.
The first option is exactly what I am looking for! If I could do the equivalent of something like feature=Reach&Node and get the csv (we are using csv) returned for all of the nodes and the reach that would be perfect.
Right now, we are grabbing the features we need for a reach, then doing separate calls to grab those features for each node in the reach. It would be great for the number of calls, speed, and AWS costs on our end to be able to submit a request and get all of the reach and node data back. Please comment if this is not the standard format for feature requests and I will update the issue.