Comments (6)
Hi!
In the Maplibre style spec which is the main inspiration for the operators in OpenLayers expressions, the get
operator actually allows this with a second argument: https://maplibre.org/maplibre-style-spec/expressions/#get
Note that the get
operator in OL expressions takes a typeHint as 2nd param so this would also have to be handled. Type hints are string literals and not expressions so differentiating between an object and a type hint should be doable.
Would you be willing to provide a PR if that solution fits your needs? I'd be happy to provide guidance the best I can.
from openlayers.
I agree it makes sense to support deeply nested feature property values. I'm not sure that the nested
expression is really the best way to do this.
I think the most natural / guessable syntax would be for the get
operator to take multiple arguments representing the nested path.
So for a feature with properties like
{some: {deeply: {nested: {value: 42}}}}
the expression
// my ideal syntax
['get', 'some', 'deeply', 'nested', 'value']
would evaluate to 42
in the context of the feature.
If instead we followed the Mapbox style convention and accepted an optional object as the second argument to the get
operator, accessing the value above would look like this:
// following mapbox
['get', 'value', ['get', 'nested', ['get', 'deeply', ['get', 'some']]]]
Both of these approaches conflict with the current signature for get
that accepts a type hint as the second argument. I think it is worth revisiting that decision (and changing it in a breaking release if we agree on something else). I feel like the type hints should be replaced with type assertions like the existing number
and string
operators. @jahow, are there cases where a type assertion could not be used instead of a type hint?
I'm not clear on what the proposed nested
operator expression would evaluate to. And I'd like to have a bit more discussion on how to best handle nested property access before committing to something.
If we want to stick close to the Mapbox style spec, then accepting an object as the optional second argument to the get
operator would make sense. And if we really needed to keep the existing type hint support, we could say the second argument must either be a string literal (type hint) or an expression that evaluates to an object (like another get
expression). Implementing this (with or without the type hint support) would complicate the way the get
operator currently works (which is to signal which feature properties are added to the evaluation context).
The simpler alternative to implement would be the ['get', 'some', 'deeply', 'nested', 'value']
syntax. This would also be my preference for being intuitive/guessable. I know it breaks from the Mapbox convention, but we already do in other ways.
from openlayers.
Hmm, I still like the Mapbox approach quite a bit, it might be more verbose but it also makes things more explicit. This would also let your read from an array in an object using at
and this sort of things. Wouldn't that be a bit awkward with just a list of string? I guess one could allow integers like so: ['get', 'array', 2, 'object', 'value']
but it feels quite implicit IMO.
About the type hint, once type assertions are available in the gpu compiler we can very likely get rid of them, yes!
from openlayers.
I agree with @tschaub that the nested
proposal is a bit awkward, I figured it would be a way to minimise breaking changes to the API. It would overload get
instead of changing the original call signature.
I really like the variadic API @tschaub suggests. It feels to me like very clean and intuitive API design. I'm not too keen on the verbose nature of ['get', 'parent', ['get', 'child', ['get', 'grandchild']], 'someTypeHint']
that the MapLibre spec implements, but it would be a bit easier to implement I guess, when Array.isArray(arguments[1])
we can traverse the JS object.
I'm not quite sure what the type hint argument does. Is there any documentation I could read? I'd be more than happy to help refactor something to get rid of it!
from openlayers.
The type hint is there because the get
operator has no clue what type of value it will output on its own. Other operators are usually able to infer their type by various means, but the get
operator isn't and in some situations, having no informating about the output type will make parsing/compiling impossible. Because a user normally knows what type a feature attribute is, providing a type hint is an easy solution this.
from openlayers.
The thing I'm not clear about with the type hint is where it is actually required. I understand how it works currently, but am uncertain where it is required. When parsing, we start with the top-most expression and we can know what output types are expected. For example, when parsing an expression for stroke-width
, we expect a number. In the simple case of 'stroke-width': ['get', 'some-property']
, we don't need a type hint. As we traverse the expressions, ideally we can narrow the types we expect. This works well if our operators are not polymorphic (for example, if +
only accepts numbers and we have a separate operator like concat
if we want to "add" strings together).
I know that the current implementation might need the type hints. But I'm still unclear if they are really "required" (if we change the current implementation or if we tighten up the syntax/operators).
from openlayers.
Related Issues (20)
- The new Google Maps source in v9 doesn't comply with Google's policies by default (missing logo and attribution) HOT 10
- hi
- Flickering map when using webview on a NOTHING phone HOT 25
- WebGLBaseTileLayerRenderer causes flickering when source or source key changes.
- Default Styles for Modifying Feature Broke in Upgrade from 8.2 to 9.0 HOT 9
- this.fill_.loading is not a function in ol/style/RegularShape.js HOT 1
- Reload individual tile HOT 2
- Type 'WebGLTileLayer' is not generic. HOT 1
- The rendering of highlighted stroke on the map is inconsistent HOT 2
- Add setter method for the View.projection_ field. HOT 3
- setOpacity on Vector Layer with 'declutter' set causes layer to disappear. HOT 3
- Move attributionsCollapsible to collapseAttributions HOT 1
- Add https://github.com/openlayers/openlayers/pull/15448 to breaking changes of OL `v9.0.0` HOT 2
- small (<256x256 size), multi-band, colored GeoTIFF fails to be displayed
- GML format always returns 3d geometries HOT 6
- WebGL rendering of large data sets is not without memory and performance issues (OpenLayers 9).. HOT 3
- minZoom on 'ol/layer/Vector' with 'declutter' set causes error HOT 1
- "CommonJS or AMD dependencies can cause optimization bailouts" warnings on Openlayers dependencies HOT 1
- Tile offset/overlap? HOT 1
- COG GeTIFF is not recognized HOT 5
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 openlayers.