GeoJSON vs WKT for the footprint geometry

[cholmes]

In the JSON spec we use WKT for the geometry of the footprint. This is the most compact representation, and works decently well. But it requires a parser to understand WKT.

Another option would be to use geojson geometry, or even make the whole metadata representation be a geojson. DG uses WKT, Urthecast uses a GeoJSON geometry (but not a geojson document), and Planet makes it all geojson. Making it all geojson would mean sticking all the values that aren't 'geometry' or 'id' under 'properties' if we want them to be parsed.

The benefit would be easy visualization in like geojson.io, and a bit easier for parsers. The downside would be a bit more complexity and it would not be quite as intuitive to non-geospatial developers.

[matthewhanson]

GeoJSON is certainly attractive here, at least for the geojson geometry. However, as discussed in #7 if the geometries are not given in 4326 then we'd be using non-comforming GeoJSON and that's certainly not desirable. On the other hand, perhaps BBOX could be given a GeoJSON geometry, while the more precise footprint geometry stays as WKT in order to support potential non 4326 CRS'.