geo_types

[jayvdb]

Would this project accept support for geo_types ?

Or should I instead be trying to get utoipa support added to geo_types? I note that they dont have other similar types of support features in their https://github.com/georust/geo/blob/main/geo-types/Cargo.toml

[juhaku]

I believe it would be better if geo_types would be able to provide a feature flagged functionality to add ToSchema derives over their types.

Otherwise the support for geo_types need to be implemented manually and may get out of sync with development cycle of geo_types. Though I am not against this if there is willingness to maintain these types. I believe it should be another crate like utoipa-geo_types etc that would depend on utoipa and geo_types and then implement the meta types for the geo_types based on utoipa.

That said, I am not at least at the moment able to take a lead to maintain and add support for these types but if no volunteers are to be found, perhaps I will eventually add support for these types.

[jayvdb]

I have done a simplistic implementation using derive(utoipa::ToSchema) at jayvdb/geo@9b2c876 , and the results are problematic. Even for the basic type Coord, the json shows utoipa is confused by the generics

{
  "openapi": "3.0.3",
  "info": {
    "title": "geo-types",
    "description": "Geospatial primitive data types",
    "license": {
      "name": "MIT OR Apache-2.0"
    },
    "version": "0.7.9"
  },
  "paths": {},
  "components": {
    "schemas": {
      "Coord": {
        "type": "object",
        "description": "A lightweight struct used to store coordinates on the 2-dimensional\nCartesian plane.\n\nUnlike `Point` (which in the future may contain additional information such\nas an envelope, a precision model, and spatial reference system\ninformation), a `Coord` only contains ordinate values and accessor\nmethods.\n\nThis type implements the [vector space] operations:\n[`Add`], [`Sub`], [`Neg`], [`Zero`],\n[`Mul<T>`][`Mul`], and [`Div<T>`][`Div`] traits.\n\n# Semantics\n\nThis type does not represent any geospatial primitive,\nbut is used in their definitions. The only requirement\nis that the coordinates it contains are valid numbers\n(for eg. not `f64::NAN`).\n\n[vector space]: //en.wikipedia.org/wiki/Vector_space",
        "required": [
          "x",
          "y"
        ],
        "properties": {
          "x": {
            "$ref": "#/components/schemas/T"
          },
          "y": {
            "$ref": "#/components/schemas/T"
          }
        }
      },
      "Point": {
        "$ref": "#/components/schemas/Coord"
      }
    }
  }
}

And when including both Coord<f64> and Coord<u64> in the schema components, the result is only one entry.

[jayvdb]

I was able to workaround those problems by manually writing the ToSchema impl. georust/geo@3cdb6b4

[jayvdb]

Created #574

[juhaku]

Cool, the manual implementation can be done bit easier way as well nowadays. https://docs.rs/utoipa/latest/utoipa/trait.PartialSchema.html

struct Coord<T = f64> {
  x: T
  y: T
}

impl<'s, T> ToSchema<'s> for Coord<T> where T: PartialSchema {
  fn schema() -> (&'s str, RefOr<Schema>) {
    let  schema = ObjectBuilder::new()
        .property("x", T::schema())
        .required("x")
        .property("y", T::schema())
        .required("y");
    
    ("Coord", schema)
  }
}

[jayvdb]

Thanks for that clue - I've updated my local copy, and it is much neater now using T::schema(). I need to do a bit more before I push.

[juhaku]

Closing this for now, since there is new generics implementation coming up in #1034 and external schemas is bit out of scope or more or less near impossible.