darkhelm/notifications-api
1
0
Fork 0
mirror of https://github.com/GSA/notifications-api.git synced 2025-12-21 07:51:13 -05:00
Code Issues Packages Projects Releases Wiki Activity
Files
efde271c5ab7655667d1dbf3ae23efeb6e9fc7f3
notifications-api/app/broadcast_message/translators.py

38 lines
1.2 KiB
Python
Raw Normal View History

Add translators from CAP to dict Other systems we’re working with won’t easily be adapted to emit JSON instead of CAP, so it’s less work for us to do that conversion. This commit adds to code to parse the XML and turn it into a dict that we can work with, including converting the polygon string into native Python lists.
2021-01-18 10:01:45 +00:00
from bs4 import BeautifulSoup
def cap_xml_to_dict(cap_xml):
# This function assumes that it’s being passed valid CAP XML
cap = BeautifulSoup(cap_xml, "xml")
return {
Don’t accept cancel or update via broadcast API We don’t support these methods at the moment. Instead we were just ignoring the `msgType` field, so issuing one of these commands would cause a new alert to be broadcast 🙃 We might want to support `Cancel` in the future, but for now let’s reject anything that isn’t `Alert` (CAP terminology for the initial broadcast).
2021-02-15 09:32:33 +00:00
"msgType": cap.alert.msgType.text,
Add translators from CAP to dict Other systems we’re working with won’t easily be adapted to emit JSON instead of CAP, so it’s less work for us to do that conversion. This commit adds to code to parse the XML and turn it into a dict that we can work with, including converting the polygon string into native Python lists.
2021-01-18 10:01:45 +00:00
"reference": cap.alert.identifier.text,
Return 400 if references missing from cancel broadcast If someone tries to cancel a broadcast but the references don’t match and existing broadcast we correctly return a 404. If they don’t provide any references then we get an exception. This commit catches the missing references and returns a 400. I think this is more appropriate because it’s malformed request, rather than a well-formed request that doesn’t match our data. It also lets us write a more specific and helpful error message.
2022-02-14 12:22:54 +00:00
"references": (
# references to previous events belonging to the same alert
cap.alert.references.text if cap.alert.references else None
),
Store the `event` field from CAP XML broadcasts We don’t store everything that comes in the CAP XML when someone creates a broadcast via the API. One thing we do store is `<identifier>` (in a column called `reference`) which is a unique (to the external system) identifier for the broadcast. We show this in the front end instead of the template name, because broadcasts created from the API don’t use templates. However this ID isn’t very friendly – the Environment Agency just supply a UUID. The Environment Agency also populate the `<event>` field with some human readable text, for example: > 013 Issue Severe Flood Warning EA (013 is an area code which will be meaningful to the Flood Warning Service team) We should show this in the UI instead of the reference. The first step towards this is storing it in the database and returning it in the REST endpoints. Later we can have the admin app prefer `cap_event` over `reference`, where `cap_event` is present. We can’t backfill this data because we don’t keep a copy of the original XML. Seems like `<event>` is a mandatory property of `<info>`, so we don’t need to worry about the field being missing (`<info>` is optional in CAP but we require it because it contains stuff like the areas which we need in order to send out the broadcast`). *** https://www.pivotaltracker.com/story/show/176927060
2021-10-18 11:42:18 +01:00
"cap_event": cap.alert.info.event.text,
Add translators from CAP to dict Other systems we’re working with won’t easily be adapted to emit JSON instead of CAP, so it’s less work for us to do that conversion. This commit adds to code to parse the XML and turn it into a dict that we can work with, including converting the polygon string into native Python lists.
2021-01-18 10:01:45 +00:00
"category": cap.alert.info.category.text,
"expires": cap.alert.info.expires.text,
"content": cap.alert.info.description.text,
"areas": [
{
"name": area.areaDesc.text,
"polygons": [
cap_xml_polygon_to_list(polygon.text)
for polygon in area.find_all('polygon')
]
}
for area in cap.alert.info.find_all('area')
]
}
def cap_xml_polygon_to_list(polygon_string):
return [
[
float(coordinate) for coordinate in pair.split(',')
]
Pass polygons through if they’re small already If a polygon is smaller than the largest polygon in our dataset of simplified polygons then we’re only throwing away useful detail by simplifying it. We should still simplify larger polygons as a fallback, to avoid sending anything to the CBC that we’re not sure it will like. The thresholds here are low: we can raise them as we test and experiment more. Here’s some data about the Flood Warning Service polygons Percentile | 80% | 90% | 95% | 98% | 99% | 99.9% -----------|-----|-------|--------|---------|---------|--------- Point count| 226 | 401.9 | 640.45 | 1015.38 | 1389.07 | 3008.609 Percentile | 80% | 90% | 95% | 98% | 99% | 99.9% --------------|-----|-------|--------|---------|---------|--------- Polygon count |2----|3------|5-------|8--------|10-------|40.469
2021-11-18 15:48:45 +00:00
for pair in polygon_string.strip().split(' ')
Add translators from CAP to dict Other systems we’re working with won’t easily be adapted to emit JSON instead of CAP, so it’s less work for us to do that conversion. This commit adds to code to parse the XML and turn it into a dict that we can work with, including converting the polygon string into native Python lists.
2021-01-18 10:01:45 +00:00
]
Reference in New Issue Copy Permalink