I can't write a polymorphic model definition for GeoJson objects

[Qsppl]

The "coordinates" property of a GeoJson object can have different structures.

But in the model definition I can only write { coordinates: [Number] }:

And if I return data like Position[], it is serialized into [NaN, NaN, ...].

I couldn't figure out how to write a correct model definition for GeoJson objects. It seems that such a model definition cannot be written because a field cannot have multiple types.

GeoJson spec: https://geojson.org/

example: https://codepen.io/qsppl/pen/WNmMpjr?editors=0011

[smalluban]

The strict structure of the model is a design choice. It helps avoid conditions in the code, which you would need when looking at your case - if your model can have a different structure of the coordinates there is always the possibility that something goes wrong, and the model has a different structure that is expected.

However, there is a way to design your case, but it won't reflect directly the data source (which I think is 100% fine). Instead of an array, you can create a linked list:

const Position = {
   data: [Number],
   next: [store.ref(() => Position)],
};

const Geo = {
  id: true,
  type: "Point",
  coordinates: Position,
  ...,
};

For example, for MultiPoint in your get() method you should return the following structure:

coordinates: {
  data: [123, 345],
  next: {
    data: [567,897],
    next: [],
  }
}

EDIT: If the multi and other cases are common, you can even set coordinates initially to an array of Position

[Qsppl]

This is suitable when the value is of type Position[] like [[number, number], [number, number]] or type Position[][]. But I don’t understand how to receive data like Position[][][] in this way.

{
  // Position[][][]
  type: "MultiPolygon",
  coordinates: [
     [ [ [ -73.958, 40.8003 ], [ -73.9498, 40.7968 ], [ -73.9737, 40.7648 ], [ -73.9814, 40.7681 ], [ -73.958, 40.8003 ] ] ],
     [ [ [ -73.958, 40.8003 ], [ -73.9498, 40.7968 ], [ -73.9737, 40.7648 ], [ -73.958, 40.8003 ] ] ]
  ]
}

Also, the same value can be either Position, or Position[], or Position[][] or Position[][][] and we do not know in advance what geometry each individual model will have.

It is also assumed that the same model can have arbitrary geometry. Here is an example from business logic: One group of investment projects can be either a point (when we only have the approximate location of the projects) or a group of points (when we know the exact location of the projects included in the group).

const ProjectsGroupStore = {
    id: true,
    feature: FeatureStore, // feature.geometry should be Point or MultiPoint
};

const FeatureStore = {
    id: true,
    geometry: PointStore || MultiPointStore, // This is impossible
    properties: {
        color: number,
        label: string,
        opacity: number,
        zIndex: number,
    }
};

Or for each type of geometry we must create a storage and a property.

const ProjectsGroupStore = {
    id: true,
    approximatePosition: FeatureWithPointGeometryStore
    projectsPosition: FeatureWithMultiPointGeometryStore
};

const FeatureWithPointGeometryStore = {
    id: true,
    geometry: [Number],
    properties: {
        color: number,
        label: string,
        opacity: number,
        zIndex: number,
    }
};

const Position = {
   data: [Number],
   next: [store.ref(() => Position)],
};

const FeatureWithMultiPointGeometryStore = {
    id: true,
    geometry: Position,
    properties: {
        color: number,
        label: string,
        opacity: number,
        zIndex: number,
    }
};

[Qsppl]

I couldn't write a linked list definition in the store

example: https://codepen.io/qsppl/pen/JjzpqNV?editors=0011

const Position = {
   data: [Number],
   // Uncaught TypeError: The array item for the 'next' must be one of the primitive types constructor: String, Number, or Boolean
   next: [store.ref(() => Position)],
};

[smalluban]

Oh, it must be a bug, that store.ref() does not work in the array. I'll look at this.

[Qsppl]

According to the GeoJson specification, the value of the geometry field of a Feature object can be of various types. (null | Point | MultiPoint | LineString | MultiLineString | Polygon | MultiPolygon | GeometryCollection)

We can only define a nested object as a specific model:

const Model = {
  externalModel: ExternalModel,
};

But we cannot determine that the nested object must be any of the following models:

const Model = {
  externalModel: store.some(ExternalModel1, ExternalModel2, ExternalModel3),
};

Most likely the problem is that it is impossible to know which model each individual object belongs to. This problem can be solved by defining a separate field by which objects will be compared with storages:

const Model = {
  externalModel: store.some({
      compare: { byProperty: "type" },
      models: [ExternalModel1, ExternalModel2, ExternalModel3],
  }),
};

Perhaps this solution is not enough for some tasks, then you can make it possible to compare objects with models using a custom function.

const Model = {
  externalModel: store.some({
      compare: { byFunction: (object) => {
          if (object._qwe === 9) return ExternalModel1
          return ExternalModel2
      } },
      models: [ExternalModel1, ExternalModel2, ExternalModel3],
  }),
};

This logic is quite simple. If the key field matches a similar field in one of the models, then this is the model we need.

P.S. Perhaps I approached the problem incorrectly and for each individual case you just need to create your own Feature subtype that has geometry of a certain type.

[smalluban]

I checked the store.ref, and it works fine, my mistake, the array must be putted inside of the function - then it works:

const Position = {
   data: [Number],
   next: store.ref(() => [Position]),
};

const Feature = {
  geometry: [Position],
  ...
};

With the above approach, without nested items (using next) you have support for the null | Point | MultiPoint, as you can reflect the [ [1,2,3....], [1,2,3,...]] or simple [[1]]. However, when using next you can support all of the types.

I know that this will not reflect one to one the type of the GeoJson, but this API is not designed very well, as it overuses polymorphic structures.

[Qsppl]

I store data like Position, Position[], Position[][], Position[][][] in storage as json-strings. To store Geometry, I created a shared Geometry storage. I do not use the GeometryCollection and FeatureCollection types.

Works. This can be implemented better if you add support for fields with multiple types to the ORM.

// feature.store.ts
'use strict'

import { Feature } from "geojson"
import { Model, ModelIdentifier, store } from "https://esm.sh/hybrids@8.2.8"
import GeometryStore, { IGeometryStore } from "./geometry.store.js"

export interface IFeatureStore<G extends IGeometryStore = IGeometryStore> extends Omit<Feature<never>, "geometry"> {
    id: Extract<ModelIdentifier, string | undefined>
    geometry?: G
}

const FeatureStore: Model<IFeatureStore> = {
    id: true,
    type: "Feature",
    geometry: store.ref(() => GeometryStore),
    properties: {
        color: "",
        opacity: 0.2,
        zIndex: 0
    }
}

export default FeatureStore

// geometry.store.ts
'use strict'

import { Geometry, GeometryCollection } from "geojson"
import { Model, ModelIdentifier } from "https://esm.sh/hybrids@8.2.8"

export interface IGeometryStore extends Omit<Exclude<Geometry, GeometryCollection>, "coordinates"> {
    id: ModelIdentifier
    coordinates: string
}

const GeometryStore: Model<IGeometryStore> = {
    id: true,
    type: "Point",
    coordinates: "[0, 0]"
}

export default GeometryStore