Add date range to overpass query

[kellyi]

Overview

Although the UI had a date range dropdown, making a selection there previously did not change the overpass query. This PR adjusts things such that selecting one of the date range options will change the query using the newer option:

https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#newer

I brought in the momentjs library to handle structuring the dates more easily and ensure they would work on different browsers. Unfortunately, however, its toISOString method did not output exactly the format expected by Overpass -- so the code here manually formats it.

Connects #38

Notes

First commit here fixes a minor style issue whereby the geocoder coordinate inputs would overextend their horizontal bounds. Glance at the coordinate inputs to verify that they no longer do.

Testing Instructions

• get this branch, then ./scripts/update
• visit the app, select a bbox, then select "Amenties" and click "Extract"
• verify that data returns
• with the same bbox, select "Amenities" and try out each of the date range options in the dropdown, verifying that each of them returns results and that the visual set of results differs slightly for each date range period.

[kellyi]

Hold off on reviewing this for now. I noticed two things I need to fix.

[kellyi]

Ok! This is ready for review. It turns out I had a stray ( in one of the functions to create a query with a newer:date addition. Extraction should now work for all queries and date combinations.

I did notice that there's not much good feedback for the user when a query completes successfully but does not return any features -- such as looking for Emergency Infrastructure in the last month. That request will 200 but since there are no features, no shapefile gets generated. I'm going to make an enhancement card for adding a visual indication that "No features were found".

[kellyi]

#40 is for handling the "No features found" indication

[mmcfarland]

Works and looks good. Got a little tripped up on the construction of the functions for generating the query, but seems to be a thing that makes sense after you spend some time parsing it. I'm satisfied with it if it's reasonably conventional.

[mmcfarland]

Is this common syntax for functions that return functions? Took me a bit of scrolling up and down to put in all together wrt to declarations and usage.

[kellyi]

Yeah, it's the ES6 way to do currying or partial application. The lodash version of this would read a little more nicely but this project doesn't have that library and it didn't seem worthwhile to bring it in just for this.

I suppose these could be named more clearly to indicate that the initial functions are partially applied, but we can revisit if it becomes necessary.

[kellyi]

Thanks for your help with this!