You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's more of a question: is it a problem for the frontend that the taxonomy is not consistent in the amount of levels? e.g. consonant phenomena and traditional classification currently have themselves as a subcategory.
About the dropdown vs. popup discussion: after looking at the personal pronouns and expanding the subcategories and imagining another two menus on the side, I'm even more pro-popup. I think the advantage of seeing everything in the menu and also seeing what you selected on the map immediately kind of disappears if the expanded menus take up most of your screen
this one is just based on how I would use this: There was some discussion about the filtering logic and the use of logical AND or OR and while trying it out, I've been wondering whether it's really necessary to offer this when you're building your query/filtering straight on the map. In general, I don't think you know in advance what combinations might exist anyway, so I think it's enough to be able to select what values you want to see and be able to assign a color. And then, when you see it on the map and see a particular combination of petals, let's call it flower, I think then it would be useful to be able to say "I want to see only the locations that have THIS flower (or partial flower)". (And visually, the petals take care of the AND or OR as well in my opinion)
In this ticket, we collect first feedback on the current draft of the WIBARAB featuredb filter/mapping GUI.
The text was updated successfully, but these errors were encountered: