Option to format API Results as GeoJSON

[vforgione]

The city data team actually uses this feature quite a bit with the current API, and I thought it's actually pretty slick.

Stuff in this PR:

• Fixed all of our wonky geom parsing to be correct lon/lat tuples
• Fixed bbox computing to use built in PostGIS functions to create a real bbox as a convex hull
• Added optional formatting param to the API

Closes #427

[vforgione]

If I weren't alright with it, I wouldn't have pushed it.

[HeyZoos]

Then shouldn't we change the name?

[brlodi]

BBoxes are specifically of the form [min_lon, min_lat, max_lon, max_lat], so I agree we shouldn't be using that name (even internally) if we're not actually dealing with a true bbox.

[vforgione]

My rationale for changing it from an explicit rectangle to any polygon is that when users want the GeoJSON format for their responses for metadata, I would assume that they want to plot the exact shape on a map.

I also would like to limit false positives in the explorer app -- naive rectangles could leave, and most often do, large blank spaces.

I'm down for leaving bbox and as a box and having a new hull field, but then I wouldn't know what the point of maintaining the box would be...

[HeyZoos]

I'm alright with ditching the box field.

[brlodi]

GeoJSON format for their responses for metadata, I would assume that they want to plot the exact shape on a map.

I agree, but that's not a bbox so we shouldn't call it that (it doesn't look like you're sending it in the GeoJSON as such, but to avoid confusion we should also use a different name internally).

I'm down for leaving bbox and as a box and having a new hull field, but then I wouldn't know what the point of maintaining the box would be...

BBox is useful for quick short-circuit intersection queries, so you can see if two complex shapes even possibly overlap before doing a more expensive operation. If we decide we don't care enough internally, it could still be useful to generate and provide on demand in the GeoJSON response.

[vforgione]

I kind of like the using the bbox and a simple, first pass filter and then refining using the hull. Overall it may be slightly overkill, but it may also cut out a lot of complexity involved with hull intersections.

We also need to add and idex for this (and time_range and state).

So, add a hull field to the metas table?

[vforgione]

Ok, I've added hull as its own field to both Meta and AotMeta and I've updated the general search strategy to start with bbox and refine with hull.