Project

General

Profile

Actions

feature request #9502

open

Implement subarea preference rule and fallback areas for areas with complex hierarchy

Added by Andreas Müller almost 2 years ago. Updated almost 2 years ago.

Status:
New
Priority:
Highest
Category:
cdmlib
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Severity:
normal
Tags:

Description

#5050 defines the subarea preference rule and also describes implements it for areas Ju, Cz, IJ and LS which are relatively easy to handle in the hierarchy.

Some more areas are more difficult to handle:

  • SM and Sr as they are not on first level and they have already a fallback parent => fixed by #9521
  • Cc as subarea Rf(CS) has another parent
  • Tcs as it is not on first level => fixed by #9521
  • Bt as subarea Rf(K) has another parent
  • Cm (still to decide if the hierarchy should stay as it is) => fixed by #9521, UK => UC, UK(K) => UK, UC becomes fallback-area

Most of these issues can be solved by using a term tree (of areas). This will also make hidden areas obsolet (they simply do not appear in the tree).
Fallback areas should then be marked in the tree not in the area (as it is a publication decision not a data property).

Areas with >2 parents can be handled twice in the tree (allowDuplicates=true).

A problem with this solution might be the ordering. If ordered via the natural tree order areas may show up at the wrong place if they have fallback parents.
Maybe this can be solved by having fallback children >1x in the tree. Once at the correct position and once with at the fallback parent position with a convention that the fallback position is only for computation of the fallback area, not for handling the subarea itself. The children list then can always be flat (e.g. in case of Ju/CM).

See also duplicate #9486

The remaining issues are probably blocked by #6794


Related issues

Related to EDIT - task #8671: Distribution in E+M (BM) on different levelsRejectedAndreas Müller

Actions
Related to EDIT - bug #8297: Fix condensed distribution string for E+MClosedAndreas Müller

Actions
Related to EDIT - feature request #9500: Allow removing certain distribution status from distribution publicationIn ProgressAndreas Müller

Actions
Related to EDIT - feature request #5050: revise the subAreaPreference rule for filtering DistributionsClosedAndreas Kohlbecker

Actions
Related to EDIT - feature request #3904: EuroMed: Implement filtering rules for distributionsClosedAndreas Müller

Actions
Related to EDIT - bug #4409: fallback areas are not adressable in the shape fileClosedAndreas Kohlbecker

Actions
Related to EDIT - bug #8310: Issues to solve in E+M shapefileClosedAndreas Kohlbecker

Actions
Related to EDIT - bug #9367: E+M shapefile Baltikum subarea borders always visibleNewAndreas Kohlbecker

Actions
Related to EDIT - bug #7107: "Omit level" (TDWG Level2) in distribution hierarchy should not supress distributions source referenceNewAndreas Müller

Actions
Related to EDIT - feature request #9521: Fallback areas in textual representation should always stand aloneClosedAndreas Müller

Actions
Related to EDIT - feature request #6794: Improve term structureIn ProgressAndreas Müller

Actions
Related to EDIT - bug #9526: Sort order in E+M distribution string should be strictly alphabeticClosedAndreas Müller

Actions
Has duplicate EDIT - bug #9486: Fallback areas not handled in area hierarchy are not showing up correctly if subarea data existsDuplicateAndreas Müller

Actions
Blocks EDIT - feature request #9503: Handle term tree of areas and distribution status for distributionInfo in dataportalNewAndreas Kohlbecker

Actions
Actions #1

Updated by Andreas Müller almost 2 years ago

  • Related to task #8671: Distribution in E+M (BM) on different levels added
Actions #2

Updated by Andreas Müller almost 2 years ago

  • Related to bug #8297: Fix condensed distribution string for E+M added
Actions #3

Updated by Andreas Müller almost 2 years ago

  • Related to feature request #9500: Allow removing certain distribution status from distribution publication added
Actions #4

Updated by Andreas Müller almost 2 years ago

Actions #5

Updated by Andreas Müller almost 2 years ago

Actions #6

Updated by Andreas Müller almost 2 years ago

  • Related to bug #4409: fallback areas are not adressable in the shape file added
Actions #7

Updated by Andreas Müller almost 2 years ago

  • Related to bug #8310: Issues to solve in E+M shapefile added
Actions #8

Updated by Andreas Müller almost 2 years ago

  • Related to bug #9367: E+M shapefile Baltikum subarea borders always visible added
Actions #9

Updated by Andreas Müller almost 2 years ago

  • Has duplicate bug #9486: Fallback areas not handled in area hierarchy are not showing up correctly if subarea data exists added
Actions #10

Updated by Andreas Müller almost 2 years ago

  • Description updated (diff)
Actions #11

Updated by Andreas Müller almost 2 years ago

  • Blocks feature request #9503: Handle term tree of areas and distribution status for distributionInfo in dataportal added
Actions #12

Updated by Andreas Müller almost 2 years ago

AM:

Problematisch sind derzeit ja noch die Fallback-Areale, die viele Hierarchiestufen haben oder überlappen. Also konkret

• Bt, wegen der doppelten Zugehörigkeit von Rf(K) zu Bt und Rf
• Cc, wegen der doppelten Zugehörigkeit von Rf(CS) und wegen der mehrfachen Hierarchie
• SM, wegen der mehrfachen Hierarchie
• Cm, wegen der doppelten Zugehörigkeit zu Uk und Rf

Erstmal zu den Mehrfachzugehörigkeiten:

Ich gehe davon aus, dass Bt im CondensedDistributionString nur angezeigt werden soll, wenn weder Rf(K) noch ein anderes Subareal Daten hat. Und Rf(K) wird immer als Subareal von Rf angezeigt. Bt wird in der textuellen Darstellung dann angezeigt, wenn es Quellen besitzt, auch wenn es für die Subareale Daten gibt. Die Subareale werden dann aber selbständig angezeigt, nicht in Klammern hinter Bt.

Gleiches wie für Bt und Rf(K) gilt für Cc und Rf(CS).

Bei Cm ist es derzeit noch anders. Dies hat zwar ein neues Label, wird derzeit aber noch genauso behandelt, wie ein normales Unterareal von Uk. Zudem hat es keinen Einfluss auf Rf (zudem es ja theoretisch ebenfalls Unterareal ist). Soll das erstmal so bleiben?

Zu den mehrfach Hierarchien:

Die Hierarchie von SM ist derzeit noch nicht richtig dargestellt. Das wäre aber leicht machbar. Ich würde dann von folgender Regel ausgehen. Wenn es Daten für Ko oder Se gibt, wird Sr nicht angezeigt im CondDistrStr bzw. nur als selbständiges Areal mit Quellen im Volltext. Entsprechend, wenn Sr oder Cg Daten hat (Sr als Fallback oder vertreten durch Ko und Se), dann wird SM nicht angezeigt im CondDistrStr bzw. nur als selbständiges Areal mit Quellen im Volltext. Entsprechend für SM und alle Unterareale von Ju.

Entsprechendes gilt dann auch für Cc, Tcs, Ab, Ar, Gg + Unterareale von Ab und Gg, aber mit der Ausnahme, dass Ab und Gg immer angezeigt werden, nicht nur wenn es keine Daten für die Unterareale gibt. Und mit der Besonderheit, dass Cc im CondDistrStr nur angezeigt wird, wenn auch Rf(CS) keine Daten hat, da es nicht nur Unterareal von Rf sondern auch von Cc ist.

Dies sollte dann zur Folge haben, dass für Ju immer nur eine Hierarchiestufe angezeigt wird, keine Klammern, weder im CondDistrStr noch in der textuellen Darstellung.
Beim Kaukasus hingegen werden Ab(X) und Gg(X) auf zweiter Hierarchiestufe angezeigt, alle anderen ebenfalls nur auf der ersten Stufe, egal ob das darüberliegende Areal Daten besitzt (die dann ja ausgeblendet werden, bis auf die Quellen).

Eigentlich scheint mir das alles so jetzt recht logisch bis auf den Krim-Fall. Trotzdem wäre es gut, wenn du es nochmal bestätigst.

Actions #13

Updated by Andreas Müller almost 2 years ago

  • Related to bug #7107: "Omit level" (TDWG Level2) in distribution hierarchy should not supress distributions source reference added
Actions #14

Updated by Andreas Müller almost 2 years ago

  • Related to feature request #9521: Fallback areas in textual representation should always stand alone added
Actions #15

Updated by Andreas Müller almost 2 years ago

ERS:

mir scheint, Du hast die Probleme nun richtig erfasst und dargestellt.

Zur Krim:

Eigentlich ist gewünscht, dies als eigenes, rein geographisch definiertes Unterareal ohne Bezug zu einem Überareal – weder Ukraine noch Russland- darzustellen. Analog wie Sardinien oder Korsika, die ja per se ebenfalls keine Bezüge zu Italien bzw. Frankreich haben. Wollte man etwa eine Checkliste Italiens inclusive Sardiniens und Siziliens erstellen, müsste man dies gesondert kalkulieren.

Bisher hatten wir Krim noch als Unterareal der Ukraine belassen, weil wir ja noch sehr viele Daten für Uk (Ukraine with Crimea) haben, vor allem aus der Checkliste der gesamten Ukraine. Ich dachte, so wäre der Zusammenhang besser sichtbar, aber vielleicht muss das nicht sein.

Wir hätten dann Crimea Cm, Ukraine Uk(U) und Ukraine, with Crimea Uk jeweils als eigene Areale. Wenn Crimea kein Unterareal der Ukraine with Crimea mehr sein soll, ist es verwirrend, wenn Uk(U) immer noch Unterareal von Uk ist. Eine rein logische Lösung könnte sein, Uk in UC umzubenennen (Ukraine+Crimea) und Uk(U) in Uk (Ukraine without Crimea)…

AM:

ja, ich denke die Umbennung in UC macht Sinn. Ich denke, das ist dann auch die Lösung. Wir machen UC nach der Umbennung zu einem Fallback-Areal, es wird im CondDistrStr also nur angezeigt, wenn keine Daten auf Unterareal-Ebene existieren. Im Text werden die Areale auch gleicher Ebene angezeigt (sofern Daten existieren). In den Karten bleibt es wie es ist, UC wird nur angezeigt, wenn keine Unterareal-Daten existieren.
Das ist dann ähnlich wie bei Ju, SM, Sr, Bt, IJ, etc.

Actions #16

Updated by Andreas Müller almost 2 years ago

  • Description updated (diff)

All issues not related to areas with direct multiple parents are fixed with #9521. Now deeper hierarchies with multiple fallback areas are possible.

Actions #17

Updated by Andreas Müller almost 2 years ago

Actions #18

Updated by Andreas Müller almost 2 years ago

  • Description updated (diff)
Actions #19

Updated by Andreas Müller almost 2 years ago

  • Related to bug #9526: Sort order in E+M distribution string should be strictly alphabetic added
Actions #20

Updated by Andreas Müller almost 2 years ago

  • Target version changed from Release 5.22 to Release 5.38
Actions

Also available in: Atom PDF