search

openlayers / openlayers

OpenLayers
https://openlayers.org
BSD 2-Clause "Simplified" License
11.39k stars 3.03k forks source link

Future of feature styles (deprecation pending?) #16037

Open dehmer opened 2 months ago

dehmer commented 2 months ago

Neither a feature request nor a bug report. Just a question.

I just read in the comments of a PR (https://github.com/openlayers/openlayers/pull/14712) that feature styles might get deprecated in favour of vector layer styles with expressions. If that is true this would probably break our application.

Let me explain: The application supports a wide variety of military symbols and other features with complex custom geometries. Which by the way made it necessary to completely rewrite modify interaction to support those geometries. Deriving a style for all but the simplest features, involves up to 20 steps including (temporary) geometry projection to euclidian (UTM) coordinates for precise calculations, label positioning depending on geometry, text and graphics interpolation for labels based on feature properties, label/line clipping, merging CSS-like application styles (global, layer, feature), optional line smoothing and different selection styles.

A feature's style depends on about 7 inputs which all may change individually. For efficiency reasons, only those intermediate products are recalculated, which are affected directly or indirectly by a changed input.

In short, roughly 20% of the code is concerned with styling.

Currently I don't see how style expressions (symbolizer object) can get us there. Even if it does and performance is OK, we won't have the resources for a rewrite.

I want to apologize if I'm going "gung ho" on this, but I'm quite anxious about loosing feature styles in its current form.

Reference: https://github.com/syncpoint/ODINv2

ahocevar commented 2 months ago

No worries for now @dehmer, if any of that happens at all, it won't happen any time soon.

dehmer commented 2 months ago

@ahocevar OK, thanks!

But if you do, please consider the possibility that actual code is necessary for styling. Especially for deriving style geometries which are different from the feature geometry. For instance in the example below the geometry is made of a collection of two MultiPoint geometries.

https://github.com/user-attachments/assets/eaf64a49-dd51-4272-8ad2-6ec9d9953b0f

Closing as 'question answered'.

ahocevar commented 2 months ago

@dehmer We are well aware of the common use case of rendering styles with derived geometries, and we would not drop style functions if their replacement lacks support for that.