Add a Category type for layers

[severinmenard]

Sorry if this is being implemented, but I did not find it in the roadmap.

Currently, if you want to have categories in your uMap, you have to create a separate layer for each of them. It would be interesting to allow uMap to add this feature for qualitative data, now that it covers quantitative data with the choropleth feature.
Here is how it looks like in QGIS: https://docs.qgis.org/3.28/en/docs/training_manual/vector_classification/classification.html

[yohanboniface]

Hi Severin, can you elaborate a bit on how this feature should be used ? And maybe add a basic example.

• what you expect to configure on a layer
• what behaviour you expect on the map (only text classification or even style, as I can see in the QGis example)

Also have you tried the new (while quite basic) facet functionality ? It may be on that direction.

If it helps, let's make a visio so you can explain that to me! :)

Hopes you're well!

[differentieel]

Like to support this request with a project I am working on - where the attached image illustrate the need of having CATEGORIES for layers - if that categories are available they should be visible for the visitor by choice ON or OFF.

For the mapmaker that option organizes his or her work in a much better way.

SECOND: how hard I try to reorder the layers - every time I come back to make changes - the order is set for its own - and not the way I had chosen - if you go for Categories (please do), please check the order mechanism.

The project can be found at https://umap.openstreetmap.fr/nl/map/akkrum-nes-gecombineerde-gebiedsvisie_962780#14/53.0355/5.8489

[yohanboniface]

@differentieel thanks for your feedback! From the user point of view, do you mean something like this proposal ?

#1351

[differentieel]

@yohanboniface it is something like that - which probably starts by the mapmakers editing area

but please check the ordering of layers for a bug, please (i know that is something else but it effects the same environment ;)

[severinmenard]

Hello @yohanboniface :) !

No, no, no, I meant something different than group of layers. Typical examples of categorized styles :

• road classes for a single road layer
• land cover classes for a single land cover layer

This kind of layers may have a quite large number of classes, and currently makes their creation in uMap quite complicated. It is super common in mapping software like QGIS (no need to propose color ramps as the example below to start, just the capacity to style every category within a specific field):

[differentieel]

@severinmenard @yohanboniface we are typical talking about two different ways of organizing - that interesting - should we address both request in different issues?

[yohanboniface]

@differentieel Yes, I'd say so. Is your category point related to #939 ? And layer ordering related to #375 ?

[differentieel]

@yohanboniface my second point - the ordering of layers- is related to #375

the grouping of layers request seems to be a new request (according to the response of @severinmenard

[severinmenard]

For me #939 is related to the grouping of layers, not categorizing within a layer. Categories is something you should choose as a layer type (among cluster and co)

[yohanboniface]

@severinmenard here is a "proposal", mainly to see if I understand the need and start a reflexion:

• add a concept of "rules" at the map level and a for any datalayer
• a rule would be a key=value pair (and maybe in a second step something more complex, including >, <, !=, regex…)
• for each rule, we expose the same form used for defining style and behaviour: color, width, icon image, tooltip, etc. (the same we have for map, datalayer and features)
• the rules would be ordered, but non exclusive: i.e if two rules matches, both would be applied; in case of conflict, last rule wins (or first, this has to be defined)
• those rules would integrate the current cascading for a given property (eg. color) more or less like this:
  • if the feature itself has a defined property, use it, otherwise
  • if the layer has rules, apply any matching rules for this property, otherwise
  • if the layer has a defined property, use it, otherwise
  • if the map has rules, apply any matching rules for this property, otherwise
  • if the map has a defined property, use it, otherwise
  • use the default value

What do you think ? (if it's understandable :p )

[yohanboniface]

ref #60

[davidbgk]

I wonder how it would be efficient (performance wise) with many layers to apply these complex rules to each 🤔

[yohanboniface]

The complexity of the rules is the complexity of the selector (key=value or whatever it becomes); once this selector is computed, it's only about reading in another javascript object (eg. the value of color key if any).

Each rule would be evaluated once for each feature displayed in the map each time a datalayer is shown (which is once in general, but can be hidden/shown by a user, or can be computed again when editing styles properties).

I'd say, the time complexity is linear and indexed to the number of rules AND number of features in the map.

Also, if the rule "selector" becomes more complex (eg. a regex, or a combination of rules: key1 > 3 AND key2 != 'value'), the cost will be higher. And the UX in this case would also be harder. I guess we'd have to find the right set of operators. Arbitrate if we allow combining them (x=y AND (a=b OR c=d)) and if we allow complex operators like regex.