Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a Category type for layers #1433

Closed
severinmenard opened this issue Nov 26, 2023 · 16 comments · Fixed by #1953
Closed

Add a Category type for layers #1433

severinmenard opened this issue Nov 26, 2023 · 16 comments · Fixed by #1953
Labels
enhancement need infos Missing informations for a pertinent answer
Milestone

Comments

@severinmenard
Copy link

severinmenard commented Nov 26, 2023

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
Copy link
Member

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!

@davidbgk davidbgk added the need infos Missing informations for a pertinent answer label Dec 1, 2023
@differentieel
Copy link

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.

UMAP_Category-Layers-plus

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

@yohanboniface
Copy link
Member

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

#1351

@differentieel
Copy link

differentieel commented Dec 5, 2023

@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
Copy link
Author

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):

Screenshot2144

@differentieel
Copy link

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

@yohanboniface
Copy link
Member

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

@differentieel
Copy link

@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
Copy link
Author

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
Copy link
Member

yohanboniface commented Dec 5, 2023

@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
Copy link
Member

ref #60

@davidbgk
Copy link
Contributor

davidbgk commented Dec 5, 2023

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

@yohanboniface
Copy link
Member

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.

@severinmenard
Copy link
Author

severinmenard commented Dec 5, 2023

@yohanboniface
Copy link
Member

The notion of category in QGis in not clear to me (I'm not a QGis user, apart from very basic uses). The documentation explain how to use them, but not for what use cases.

Can you describe some uses cases ? Maybe even pointing me to a given map and explain what you'd like to be able to do in this map ?

What I understand of your need seems close to other needs I've been aware of, and are something like "be able to change the behaviour/style of some features according to their properties, and not to the layer they belong to". So I'm trying to figure out a generic way to cover those cases. But the more use cases I have, the better will be solution we come with ;)

@severinmenard
Copy link
Author

severinmenard commented Dec 6, 2023

Use cases are typically any data organized in classes: roads, land cover, crops... even a simple yes/no/dontwanttoanswer/nr. These classes can be found in a single field. For the user, it is really easy to choose the Categorize rendering, as it automatically creates all existing classes within the field, and the user can focus on styling each of them. One refinement you will find in QGIS is the ability to delete or hide an existing class, or manually add a class that does not yet exist in your dataset, but this can be added later. Rule-based rendering offers much more refinement, of course, but for the many use cases where you just want to render the different classes of a single field, this is a much simpler and faster way to do it for the users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement need infos Missing informations for a pertinent answer
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants