FeatureCollection support

[mattbretl]

For web mapping purposes, the data returned from Connections will generally have to be transformed into a FeatureCollection (https://tools.ietf.org/html/rfc7946#section-3.3). It's a trivial amount of client-side JS, but as GeoJSON datasets can get very large, it can impact performance/memory use. It would be nice to receive the GeoJSON FeatureCollection directly, with selected fields under properties:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [102.0, 0.5]
      },
      "properties": {
        "prop0": "value0"
      }
    }
  ]
}

FeatureCollections can be fed directly into mapping libraries. Example: https://docs.mapbox.com/mapbox-gl-js/example/geojson-markers/

This is a stretch goal.

[benjie]

We could maybe add this using an aggregate field on the connection itself? “asFeatureCollection”

[mattbretl]

Good idea. Is this the best example to go by? https://github.com/graphile/pg-aggregates/blob/master/src/AddAggregatesPlugin.ts

[mattbretl]

I started down that path, and then realized I was making this way too complicated. Some aliasing plus a little nesting/hoisting should do the trick. Consider this:

{
  allGisDebugs {
    features: nodes {
      geometry: geogPoint {
        geojson
      }
      id
    }
  }
}

{
  "data": {
    "allGisDebugs": {
      "features": [
        {
          "geometry": {
            "geojson": {
              "type": "Point",
              "coordinates": [
                30,
                10
              ]
            }
          },
          "id": 1
        }
      ]
    }
  }
}

Adding static "type": "FeatureCollection" and "type": "Feature" properties to that is obviously trivial (either via GraphQL or client-side). All that's left is to:

• Hoist { "type": "Point", "coordinates": [30, 10] } up a level. I can extend nodes to include a geometry field when geography/geometry columns exist. If there's more than one, a mandatory enum field arg would specify which column to use.
• Nest id and any other selected fields under properties. It's the same thing you did with the query field to support Relay 1. Easy.

Those two additions would allow queries like this (ignoring the field arg case):

{
  allGisDebugs {
    features: nodes {
      geometry
      properties {
        id
      }
    }
  }
}

Add the static type strings and you're done. Pagination and sparse fieldsets under properties should Just Work. 😀

[benjie]

Impressive! I think it might make sense to give the user an explicit field that returns a feature collection though, rather than expecting them to construct a specially formatted GraphQL query. Also don't forget that Apollo would put __typename all over the place.

[TBA-Lucas]

Hi, did anything from this discussion make it into the plugin? As trivial as it may be to create a client side transformation of a query result into a GeoJSON FeatureCollection, having it ready made by Postgraphile would be awesome! It would also enable users (and devs) to easily iterate on queries and the spatial data in the database with the /graphiql UI. Just copy paste the query result and drop it onto a map, GIS, etc, done... - I think that would be pretty neat.

[benjie]

I don't think anyone ever added this feature. The PostGIS plugin hasn't been ported to PostGraphile V5 yet, but that would be a great opportunity for someone to do so if anyone were interested.

[lcalisto]

It could be interesting to support this in V5. If implemented this could open the door to the new OGC API Features Standard