Skip to content
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

When a smoke alarm request is made, process the latitude and longitude of the requestor's address so that it can be pushed to allReady #206

Open
jim-mcgowan opened this issue Jun 4, 2016 · 3 comments
Labels

Comments

@jim-mcgowan
Copy link
Member

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.

@cecilia-donnelly
Copy link
Contributor

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?

@jim-mcgowan
Copy link
Member Author

@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.

@cecilia-donnelly
Copy link
Contributor

@OhMcGoo, makes sense. Let's prioritize this with @kfogel. I think this could be a great task for GiveCamp.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants