-
Notifications
You must be signed in to change notification settings - Fork 34
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
Google Floods Part 1: Adding backend + creating Gauge Points; COUNTRY=cambodia #1328
base: master
Are you sure you want to change the base?
Conversation
Build succeeded and deployed at https://prism-1328.surge.sh |
api/app/main.py
Outdated
@@ -412,3 +413,10 @@ def post_raster_geotiff(raster_geotiff: RasterGeotiffModel): | |||
return JSONResponse( | |||
content={"download_url": presigned_download_url}, status_code=200 | |||
) | |||
|
|||
|
|||
@app.get("/google-floods-gauges") |
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.
If we're gonna add a bunch of integrations, it will be worthwile to think about a standardized approach and common architecture. And maybe expose them through a sub endpoint of the API to keep things cleaner. wdyt @lowriech ?
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 think that's a good question, @ericboucher. Do you see other APIs we're already leveraging fitting into this integration category (kobo, hdc stats, others)? Or are you thinking just for new integrations?
I'm wary of premature abstraction and trying to determine if I think now is the right time to align on this standardized approach.
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.
It seems like low-hanging fruit to abstract once we decide on a pattern. So yes, agree we should think about it, but not sure about the velocity of adding entirely new providers. Would vote to wait until we see more pattern around this.
"title": "Google Flood Gauges", | ||
"type": "point_data", | ||
"hex_display": false, | ||
"data": "http://0.0.0.0:80/google-floods/gauges/?region_code=MZ", |
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.
Note: need a better development set up
Set to a relative path, make sure we're using DEFAULT_API_URL for these requests
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.
@ericboucher have you all deployed the prism-api out in surge-like deployments before for testing?
@lowriech and @ericboucher, there are a couple outstanding issues (noted in the PR description) but this ready for initial review |
if ( | ||
itemProps.visibility === FeatureInfoVisibility.IfDefined && | ||
!properties[item] | ||
) { | ||
return obj; | ||
} |
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 have some feature properties that may or may not be defined by the google api (for example: site name, river name). This allows us to hide the property from the pop up if it's not defined
api/app/googleflood.py
Outdated
"river": ( | ||
data["river"] if "river" in data and len(data["river"]) > 1 else None | ||
), |
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.
"river" can come in as a string with just 1 space (" "
). This ensures there's a real value
}, | ||
"gaugeId": { | ||
"type": "text", | ||
"template": "Gauge ID: %s", |
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.
Let's think of a way to make this template translatable?
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.
How have we done this in other parts of the app? Can we use a translate wrapper function within the tooltips?
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 haven't really used templates in PRISM yet. We usually consider the template as a title and then handle the title and the data separately. So instead of template you would just have "title": "Gauge ID"
. and then append the value. You can have a look at the PopupContent file for examples. If we think the structure will be simple like that, they that's probably ok.
Another option is to use the translation mapping and have the template be: Gauge ID: {id}
, then use it like this:
<Trans values={{ id }}>
<Typography>{t(template)}</Typography>
</Trans>
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.
Thanks @ericboucher! I'm leaning towards the latter option (translation mapping). We used these templates in react-i18next pretty extensively in the distant past (my Hilton Hotels days). Once we started using them, it gave us a ton of flexibility in terms of copy. If you're ok with it, I'll implement it this way.
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.
Updated
Note: I'm adding pytest-recording to store our google flood responses in local tests and use them in CI/CD. That will fix the failing API test in this PR |
api/app/tests/cassettes/test_google_floods_api/test_get_google_floods_gauges_api.yaml
Outdated
Show resolved
Hide resolved
Great to see this nearly complete - thanks @gislawill. I mentioned the map interaction bug that's preventing a full test but hopefully that is resolved soon. In the meantime, in addition to displaying the gauge ID, can we first show the river name? I see that in Flood Hub interface, hopefully it's also exposed via the API. Note, we'd need to translate that text as well. I see that Flood Hub offers several language options including Khmer. Ex: https://sites.research.google/floods/e/l/10.96043262736797/103.63535499532549/8.45328318786621/g/hybas_4121148610?layers&hl=km
|
Hey @wadhwamatic, the river name is sometimes provided by the API but often it is not. I've currently set this up so we display the site name if it's provided. If not, we display the river name if it's provided. If not, we display the gauge id (which is always provided). How does that logic sound to you? Here's how it looks:
I tried to find the translated names in the API but unfortunately there's no option in the API documentation and the API fails if the hl parameter is included in the request. I'll update this title component so that at least "site name:" and "river:" can be translated even in the API provided name won't be. |
That logic sounds good - thanks! Is there an example of site name in Cambodia? That's too bad about the translation via the API but thanks for noting it regardless. |
There is not unfortunately. A bunch of rivers but no site names |
Heads up @wadhwamatic, the today "Date" is now set on these layers I'll work with @ericboucher to get a new server deployment out for testing |
Server deployment containing the updates is out (thanks @ericboucher for walking me through it). @wadhwamatic you can resume testing |
@gislawill - thanks for adding the time dimension here. I tested date intersections a few ways and this is looking good from my side, as does the river gauge info noted in this PR |
Remaining todo items:
|
* Adding graph for google flood data * Merge conflict resolution and units * Updating tests * formatting * Using superscript * Supporting rbd * Add support for Cambodia * Updating url for data * api lint * Fixing date logic on graph look up * Updates to chart to denote past vs future * Adding translation to 'future' label * Fix chart tests using mock * Requested changes: descriptive labels
Description
This fulfills step 1 of 3 for #1317 (see plan).
In this PR, we're fetching flood status by gauge from Google's Floods API for the entire country (10-100 gauges per country). We're displaying these gauges as points on Prism. They're color coded by flood status and provide additional insight when clicked.
This PR also adds support to provide a popup title in the layer config. Because these gauges are typically located on rivers that server as the boundary between two regions, using the region title for the pop up doesn't make much sense. Instead, we're adding an approach that allows one to use formatted feature properties as the title.
Forecasts for each gauge are added here: #1330
How to test the feature:
Checklist - did you ...
Test your changes with
REACT_APP_COUNTRY=rbd yarn start
REACT_APP_COUNTRY=cambodia yarn start
REACT_APP_COUNTRY=mozambique yarn start
Screenshot/video of feature: