Comments (7)
Oh, it must be a bug, that store.ref()
does not work in the array. I'll look at this.
from hybrids.
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
from hybrids.
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,
}
};
from hybrids.
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)],
};
from hybrids.
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.
from hybrids.
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.
from hybrids.
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/[email protected]"
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/[email protected]"
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
from hybrids.
Related Issues (20)
- Add a helper for assigning component properties HOT 3
- Dynamic columns not showing when render a html table HOT 4
- '"hybrids"' has no exported member named 'property'. Did you mean 'Property'? HOT 8
- Add support for "TypeScript v5" HOT 3
- I can't create an arbitrary number of nested forms: HOT 6
- Small Type Inferencing Issue with Property<E, V> HOT 6
- Cannot pass an object to the API via the "list" method HOT 7
- version 8.2.17 backwards compatibility is broken! HOT 9
- Expand the functionality of drafts
- sync() with nested models is broken HOT 4
- Allow storing an object in a component property HOT 4
- Add partial loading of model data HOT 3
- Why do you remove the lastValue? HOT 2
- The store logs a lot of errors HOT 4
- Convert a Whole Component to Web Component HOT 8
- Scoped CSS HOT 6
- lagging update glitch HOT 2
- Component properties cannot be setted until they are observed HOT 2
- `store.set()` is very slow HOT 5
- Store loads items data when iterating the list of items HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hybrids.