znmeb
commented
5 years ago - PostGIS is in the database container - see https://github.com/hackoregon/backend-examplar-2018/blob/staging/DOCKERFILE.db.development. So is pgRouting - that's one of the tools I wanted to have available for Transportation Systems, although we ended up not using it.
- GeoDjango is in the API container, and it requires PostGIS.
A bit o' history - we didn't know whether we'd have PostGIS on the AWS server until about halfway through the season, so we made sure we'd be able to do GIS calculations offline and upload processed data as GeoJSON or just lat-long pairs.
Do we want add PostGIS support to the backend-exemplar's service?
I implemented it successfully in my disaster-resilience backend service, and its not too hard. It does not require any changes to the DB, just the Django app. As far as geojson responses, they will not automatically be parsed out of the wkb_geometry fields, but only after the endpoint is created and setup to take advantage of the Geometry Fields encoded in a table's model's wkb_geometry column/field.
I figured I would ask since we are currently focussed on bringing the backend_exemplar up-to-date.
The advantage would be that people spawning new backend repos would be automatically set up out-of the-box to take advantage of PostGIS columns that may exist in the DB schema. As mentioned above, they would not be automatically returned in the endpoint responses, so the creator could decide at that point whether to enable geojson responses or not. As @AraOshin has advised in the past, decoding and returning geoson from wkb_geometry fields can be expensive and bandwidth/response time intensive so I think its important to not enable them on the endpoint responses by default, but rather let the creator decide on case by case basis.
@znmeb @AraOshin @BrianHGrant @MikeTheCanuck