Feasibility of the "dynamic tags" styling mechanism #6331

New issue

Open

opened 2023-10-17 19:13:44 +00:00 by pastk · 0 comments

pastk commented

2023-10-17 19:13:44 +00:00

Member

E.g.

node|z12-[natural=peak][name],
{icon-image: peakt-s.svg;icon-min-distance: 10;}
node|z15-[natural=peak][name],
{icon-image: peakt-m.svg;font-size: 10;}

node|z15-[natural=peak][!name],
{icon-image: peakt-m.svg;font-size: 10;}

makes named peaks icons visible from z12- while nameless ones visible from z15-.

So basically it allows the renderer to pick a different style for the feature based on some run-time condition (currently implemented conditions are name, population and bbox_area).

What's controversial is that the same could be achieved at the generation stage (e.g. add a natural-peak-named type) without a run-time overhead.

(Under the hood, when a "dynamic tag" is used then for this feature type kothic produces additional sets of drules with an added application condition like apply_if: "!name". The renderer loads all features' drules, parses and resolves the condition and filters the drules accordingly.)

E.g. if we decide to make touristic features with a tourism=attraction (heritage=* etc.) more visible then we can either use the "dynamic tags" mechanism for that (check presence of the additional tourism-attraction type at run-time) or add sub-types like historic-castle-attraction.

If we go "dynamic tags" way:
pros:

no need to define sub-types in mapcss-mapping.csv (could be a big deal if there are some sub-types already like -fee/private/etc, but in most cases just a small convenience)

cons:

some run-time overhead
an extra type (tourism-attraction) to store per-feature

Note that both ways will require defining additional attraction styling rules for all features (historic-castle/ruins/monument/etc.) we'd want to differentiate.

So basically this mechanism gives some styling convenience at the expense of run-time overhead.
And styling convenience could be improved at the generator stage instead by refactoring handling of types "attributes", see some thoughts in organicmaps/organicmaps#1312 (comment)).

WDYT?

E.g. ``` node|z12-[natural=peak][name], {icon-image: peakt-s.svg;icon-min-distance: 10;} node|z15-[natural=peak][name], {icon-image: peakt-m.svg;font-size: 10;} node|z15-[natural=peak][!name], {icon-image: peakt-m.svg;font-size: 10;} ``` makes named peaks icons visible from z12- while nameless ones visible from z15-. So basically it allows the renderer to pick a different style for the feature based on some run-time condition (currently implemented conditions are `name`, `population` and `bbox_area`). What's controversial is that the same could be achieved at the generation stage (e.g. add a `natural-peak-named` type) without a run-time overhead. (Under the hood, when a "dynamic tag" is used then for this feature type kothic produces additional sets of drules with an added application condition like `apply_if: "!name"`. The renderer loads all features' drules, parses and resolves the condition and filters the drules accordingly.) E.g. if we decide to make touristic features with a `tourism=attraction` (`heritage=*` etc.) more visible then we can either use the "dynamic tags" mechanism for that (check presence of the additional `tourism-attraction` type at run-time) or add sub-types like `historic-castle-attraction`. If we go "dynamic tags" way: pros: - no need to define sub-types in `mapcss-mapping.csv` (could be a big deal if there are some sub-types already like `-fee/private/etc`, but in most cases just a small convenience) cons: - some run-time overhead - an extra type (`tourism-attraction`) to store per-feature Note that both ways will require defining additional `attraction` styling rules for all features (`historic-castle/ruins/monument/etc.`) we'd want to differentiate. So basically this mechanism gives some styling convenience at the expense of run-time overhead. And styling convenience could be improved at the generator stage instead by refactoring handling of types "attributes", see some thoughts in https://git.omaps.dev/organicmaps/organicmaps/issues/1312#issuecomment-1706344221). WDYT?

This repo is archived. You cannot comment on issues.