Closed zacharyDez closed 2 months ago
@bpstewar: I'm questioning the necessity for this one. I did some initial design and thought about it. Adding different output formats would complicate the API interface and the underlying implementation. The added overhead for a user to get valid GeoJSON is a single line:
df['geometry'] = df['geometry'].apply(lambda geom: shape(geom))
And even if we were to return a GeoJSON Feature Collection, an end-user would need to perform some data wrangling to get it in the correct format for their analysis (DataFrame).
Based on a discussion with @bpstewar and @andresfchamorro, we let users process the initial summary
response to match their needs. The needs are varied, and developers can transform them to fit their needs.
Currently, the
summary
endpoint returns aList
of the rows for eachhex_id
. We added the optional support for geometries, but a user wanting to generate a GeoDataframe must still convert the Geojson feature for each row into a Shapely point.During code review, @vincentsarago suggested we implement a behavior similar to TiPG, where the output format of the response for
summary
depends on anoutput_format
parameter. When a user requests a geometry to be attached to the response, we could return aFeatureCollection
, which can be read directly by geopandas and other tools.