feature request #10323
openPreference for IUCN status list states
10%
Description
When editing an IUCN status of class type "Distribution" it is necessary to allow filtering the available IUCN status. In particular it is necessary not to show ordinary distribution status (e.g. "present", "absent", ...).
Data side it should be possible to use the existing preferences model by adding the IUCN feature to the subject (together with the area if necessary).
Related issues
Updated by Andreas Müller 10 months ago
- Related to feature request #10310: Add IUCN status as feature added
Updated by Andreas Müller 10 months ago
- Related to task #10308: Show IUCN "distribution" data separately added
Updated by Andreas Müller 10 months ago
- Related to task #10326: EuroMed mosses remaining issues added
Updated by Andreas Müller 10 months ago
- Related to feature request #10343: Full implementation for showing IUCN "distribution" data separately added
Updated by Andreas Müller 10 months ago
- Description updated (diff)
- Priority changed from New to Highest
- Target version changed from Release 5.44 to Release 5.38
As editing IUCN data is currently not possible or difficult I increase priority. I add it to current milestone in case there is time left for implementation before release. It fits well to the current release contentwise.
Updated by Andreas Müller 10 months ago
- Related to feature request #10335: Allow editing supplemental data for TermNodes added
Updated by Katja Luther 10 months ago
Maybe another idea is to allow defining distribution state vocabularies in the feature?
Updated by Andreas Müller 10 months ago
- % Done changed from 0 to 10
Katja Luther wrote in #note-8:
Maybe another idea is to allow defining distribution state vocabularies in the feature?
This is an interesting idea. However, for complex problems it will not fully work. This is because we need 2- or 3-dimensional dependencies.
The first dimension is the feature itself, the second is the area (e.g. area Euro+Med allows different states then the subareas), and the third might be a taxonomic focus/subtree.
Of course we could handle the first with a general supportsXXX attribute similar to categorical and quantitative data. But then one needs to define the other filters at another place which might not be intuitive.
But, the longer I think about it using supportsXXX might be a first general filter to define the type of states that are generally available for a feature.
We should further discuss this.
Updated by Katja Luther 10 months ago
Andreas Müller wrote in #note-9:
Katja Luther wrote in #note-8:
Maybe another idea is to allow defining distribution state vocabularies in the feature?
This is an interesting idea. However, for complex problems it will not fully work. This is because we need 2- or 3-dimensional dependencies.
The first dimension is the feature itself, the second is the area (e.g. area Euro+Med allows different states then the subareas), and the third might be a taxonomic focus/subtree.
Of course we could handle the first with a general supportsXXX attribute similar to categorical and quantitative data. But then one needs to define the other filters at another place which might not be intuitive.
But, the longer I think about it using supportsXXX might be a first general filter to define the type of states that are generally available for a feature.
We should further discuss this.
Yes I think we should add an attribute which defines the general vocabulary or vocabularies providing the terms for the IUCN status and in the preferences we can define subsets for subareas and/or subtrees. This is similar to the preference already existing for areas and the available status. The preference page for this preference also needs some "improvement".
The subject could look like this /Feature[uuid]/TaxonNode[uuid]/NamedArea[uuid]/ maybe with a short label to distinguish between subtree and area if only one is available.
Updated by Katja Luther 10 months ago
- Status changed from New to In Progress
- Target version changed from Release 5.38 to Release 5.44
I move this ticket to 5.39 because it is needs some more time to implement the preference page.