Issues modeling GeoJSON spec with rescript@11 types

[glennsl]

I've been trying to model GeoJSON using rescript@11 types, just to see if I can, and am stumbling on just a few issues that I think should be feasible (though not easy) to fix since all the necessary features do exist in various forms. So I figured I'd document this as a prominent use case.

See the full TypeScript type definitions for reference.

The big problem is that a GeoJSON document can be either a single geometry object (of which there are several kinds), a "feature" which contains geometry, or a feature collection. These all use a type tag, but because geometry objects are included in several different types, modeling this requires structural typing. And unfortunately @tag only works on nominal variants, not structural (polymorphic) ones. This is also the case with inline records, which is necessary for @tag to be useful, so that's another hurdle.

Essentially, I'd like to define the types like this:

@tag("type")
type rec geometry = [
  | #Point({coordinates: pos})
  | #MultiPoint({coordinates: array<pos>})
  | #LineString({coordinates: array<pos>})
  | #MultiLineString({coordinates: array<array<pos>>})
  | #Polygon({coordinates: array<array<pos>>})
  | #MultiPolygon({coordinates: array<array<array<pos>>>})
  | #GeometryCollection({coordinates: array<geometry>})
]

@tag("type")
type feature = [
  | #Feature({geometry: geometry})
]

@tag("type")
type t = [
  | geometry
  | feature
  | #FeatureCollection({features: array<feature>})
]

Another minor problem is that positions and bounding boxes are arrays of different arities. These could be modeled with an unboxed tagged variant containing tuples of different arities, and possibly a constructor an array to cover the remaining arities. E.g.:

@unboxed
type pos = 
  | LatLng((float, float))
  | LatLngAlt((float, float, float))
  | M(array<float>)

Lots of edge cases to consider though. A further improvement could be to (optionally) model inline records in unboxed variants as arrays, so that it could be:

@unboxed
type pos = 
  | LatLng({lat: float, lng: float})
  | LatLngAlt({lat: float, lng: float, alt: float})
  | M(array<float>)

[cristianoc]

Multiple object shapes are not currently supported.
It's not impossible, just it adds complexity for an initial implementation.

Is my understanding correct? That we're talking about objects with multiple shapes?
If so we can mark this as feature request.

[glennsl]

No, I don't think that would help much. @tag does most of the job already, but I need structural typing to have the same constructors inhabit several different types. I've updated the original post with a code example that might help illustrate.

[cristianoc]

Could you write the explicit TS type for the runtime representation? So the number of types and their relationship is spelled out.

[glennsl]

They're in the TypeScript definition file linked above. Is that not sufficient?

[cristianoc]

[cristianoc]

I think what we're talking about here is the ... notation and type coercion, which is currently only supported for records.
So you'd have:

type t = ...t1 | A(int)

and the usual syntax expr :> typ for coercion.

So ... would avoid repeating long type defs, and coercion would play the role of subtyping which is implicit in TS and poly variants.

[zth]

@glennsl both variant spreads and coercion are now available in 11.0.0-beta.4. It'd be interesting to see if you get further with them.

[glennsl]

Variant spread and coercion from subtype to supertype works great, but not the other way around. Which means, for example, that I can't write a function that operates on geometries, and use that for the geometry subset of geojson objects. E.g.:

  let coords = (obj: GeoJSON.t) => {
    let rec geomCoords = (geom: GeoJSON.Geometry.t) => ...

    switch obj {
    | Feature(feature) => ...
    | FeatureCollection({features}) => ...
    | geom => (geom :> GeoJSON.Geometry.t)->geomCoords // ERROR: Type GeoJSON.t is not a subtype of GeoJSON.Geometry.t 
    }
  }

Also still can't unbox the variants or coordinates of course, but that's a relatively minor issue.

[zth]

I've been loosely exploring what it'd take to support this for variants:

let coords = (obj: GeoJSON.t) => {
  let rec geomCoords = (geom: GeoJSON.Geometry.t) => ...

  switch obj {
  | Feature(feature) => ...
  | FeatureCollection({features}) => ...
  | ...GeoJSON.Geometry.t as geom => geom->geomCoords
  }
}

So essentially the same feature that exists for polyvariants, but for regular variants.

That would work for this problem as well, right?

[glennsl]

Yes, exactly! That would be really cool 😃

[zth]

This was finally merged in #6721. @glennsl please take it for a spin after the next v12 alpha is out.