You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a smoke alarm request is made, process (and store) the latitude and longitude of the requestor's address so that it can be pushed to allReady along with rest of the request data.
The text was updated successfully, but these errors were encountered:
Hey, @OhMcGoo. We could manage this by taking the address we receive from the user, sending it out to a mapping service (e.g. the Google Maps API), getting the lat/long back, and then including that info in the request we send to AllReady.
If, however, AllReady is already using some kind of mapping service then maybe we should just send the address to them. There's no particular advantage or disadvantage to doing the mapping on our end or theirs as far as I know. @MisterJames, it sounded on the last standup like someone was working on mapping capabilities in AllReady. Is that right? How does AllReady currently handle finding latitudes and longitudes, if it does at all?
@cecilia-donnelly, I think we should do this on the getasmokealarm side. Here's why: We don't know if everyone will choose to use allReady. We do know that everyone (except Kansas-Nebraska) is using getasmokealarm. Thus, I think it would be most useful to calculate lats and longs before the data gets pushed to allReady. Better, would be a way of validating that the address entered is real. I looked at all of the smoke alarm requests over the weekend and a lot of the entries are pretty messy or simply unintelligible.
When a smoke alarm request is made, process (and store) the latitude and longitude of the requestor's address so that it can be pushed to allReady along with rest of the request data.
The text was updated successfully, but these errors were encountered: