Project

General

Profile

task #8671

Distribution in E+M (BM) on different levels

Added by Andreas Müller 11 months ago. Updated 3 months ago.

Status:
In Progress
Priority:
Highest
Category:
cdmlib
Target version:
Start date:
11/09/2019
Due date:
% Done:

30%

Severity:
normal

Description

We may need to solve the below problem in Euro+Med (Berlin Model) with new functionality in CDM.

=====

AM:

Ich versuche gerade die „Transmission Engine für Verbreitungsdaten“ bzw. jetzt „Distribution Aggregation“ im CDM von Fehlern zu befreien.

Dabei ist mir folgender Berlin Model Fall aufgefallen:
http://ww2.bgbm.org/EuroPlusMed/PTaxonDetail.asp?NameCache=Morus%20nigra&PTRefFk=7300000

Mit den Verbreitungen:

Ga France cultivated Calculated
Ga France introduced: naturalized Reference
Ga(C) Channel Is. cultivated Reference

Auf der Karte wird aber Frankreich nicht eingefärbt, obwohl es zum Areal Ga native Daten gibt.
Ich nehme an, dass das daran liegt, dass es auch Daten für ein Unterareal gibt, und damit die Anzeige für das Überareal wegfällt. Korrekt? In diesem Fall allerdings nicht unbedingt so schön. Daher die Frage: ist das so gewollt oder ist es ein Fehler in der Ausgabe beim Berlin Model bzw. bei der Kartenerstellung in Helsinki?

Im CDM haben wir ja evtl. noch bessere Möglichkeiten Areale übereinander zu legen bei der Ausgabe, so das man zumindest andeuten könnte, dass es da Informationen auf 2 Leveln gibt. Oder ist es, zumindest für E+M grundsätzlich so gewollt, immer nur den untersten Level darzustellen? Bei der textuellen Ausgabe wird dann ja exakt aufgeschlüsselt für jeden Level.

@Norbert: Weichen die Anforderungen für die Cichorieen hier evtl. ab von E+M?

Anm.: In #8670 ist ein ähnlicher Fall, allerdings handelt es sich hier um ein aggregiertes Areal auf höherem Level. Das dieses nicht in der Karte angezeigt werden soll, ist klar. Das muss im CDM gefixt werden.


Related issues

Related to Edit - bug #8670: Unwanted distribution aggregation/display on 2 levels Resolved 11/09/2019
Related to Edit - task #8651: Unify description aggregation methods (distribution and structured descriptive data) Closed 11/05/2019
Related to Edit - feature request #5050: revise the subAreaPreference rule for filtering Distributions In Progress 06/30/2015

History

#1 Updated by Andreas Müller 11 months ago

  • Related to bug #8670: Unwanted distribution aggregation/display on 2 levels added

#2 Updated by Andreas Müller 11 months ago

  • Tags changed from transmission-engine-distribution to transmission-engine-distribution, euro+med

Eine Lösung für dieses Problem könnte sein, dass man nicht (wie in #8670) die Areale aufwärts aggregiert sondern abwärts. Das könnte so aussehen, dass,

  • wenn der Status des Gesamtareals gleich oder prioritärer ist als für alle Unterareale, wird der Status für das Gesamtareal behalten, die Unterareale werden nicht weiter berücksichtigt - jedenfalls nicht für die Kartendarstellung
  • wenn der Status des Gesamtareals geringere Priorität hat, wird das Unterareal behalten wie es ist. Zudem wird eine "All other areas" Verbreitung erzeugt, die allen anderen Unterarealen des Überareals den Status des Überareals zuweist. Allerdings muss man hier aufpassen, da es ja nicht so ist, dass für jedes dieser Areale dieser Verbreitungsstatus existiert, sondern nur für die "Gesamtheit aller anderen" Areale. Diese Berechnung eignet sich also gut für eine Kartenanzeige, sofern dort nicht klare Grenzen zwischen den Unterarealen aufscheinen. Bei einer textuellen Darstellung müssten diese Areale als "others" (oder ähnlich) benannt werden, so das klar ist, dass hier nur die Gesamtheit aller anderen Unterareale gemeint ist. Wobei bei der textuellen Darstellung zu bevorzugen ist, wie im Berlin Model, die Verbreitung jeweils auf der zugehörigen Ebene darzustellen und ggf. 2 Status für das Überareal anzugeben, den primären und den berechneten (höherer Status aus dem Subareal).
  • wenn es sowohl Subareale mit höher prioritärem Status als auch mit tiefer prioritärem Status gibt, wird es kompliziert. Dann ist zu entscheiden, ob für die Subareale mit tieferer Priorität, dennoch der Status vom Überareal geerbt werden soll, oder ob der Status des Subareals Verwendung findet. Logik für letzteres: lieber eine gesicherte Vorkommensaussage für das Subareal anzeigen, als eine vom Überareal übernommene, von der man nicht weiß, ob das Vorkommen überhaupt als auch der Status für das Unterareal überhaupt stimmt.

Grundsätzlich ginge es bei dieser Abwärtsberechnung primär um die Kartendarstellung, nicht so sehr um die textuelle Darstellung. In E+M wird der Status bei der textuellen Darstellung derzeit sowie nur im "Condensed Distribution String" angezeigt, in der Langform nicht. Bei den Cichorieen wird der Status textuell überhaupt nicht angezeigt.

Zudem könnte das Problem eventuell auch durch eine bessere Überlagerung bei der Anzeige der Daten gelöst werden. Wenn diese nicht mehr auf Transparenz angewiesen ist, sondern die Unterareal z.B. grundsätzlich in einer nicht transparenten Layer oberhalb der Hauptareale angezeigt würde, käme in etwas das gleiche Ergebnis heraus, wie bei dem oben beschriebenen Algorithmus. Bei Anzeige von Grenzen zwischen den Arealen wäre dies sogar die bessere Lösung, da sie Zusammengehörigkeit der Restareale besser darstellen könnte.

#3 Updated by Andreas Müller 11 months ago

SQL to find such cases in E+M BM:

SELECT occ.SummaryStatus, n.FullNameCache, pt.PTRefFk, n.NameCache
FROM emOccurrence occ
INNER JOIN PTaxon pt ON occ.PTNameFk = pt.PTNameFk AND occ.PTRefFk = pt.PTRefFk 
INNER JOIN Name n ON pt.PTNameFk = n.NameId
WHERE occ.AreaFk = 636 AND pt.PublishFlag = 1 AND occ.SummaryStatus < 350 AND  EXISTS (
SELECT *
FROM emOccurrence occ2
INNER JOIN PTaxon pt2 ON occ2.PTNameFk = pt2.PTNameFk AND occ2.PTRefFk = pt2.PTRefFk 
INNER JOIN Name n2 ON pt2.PTNameFk = n2.NameId
WHERE occ2.AreaFk = 141 AND pt2.PublishFlag = 1 AND occ2.CalculatedFlag = 0 AND occ.SummaryStatus < 350 AND occ.SummaryStatus <> occ2.SummaryStatus
AND pt.PTNameFk = pt2.PTNameFk AND pt.PTRefFk = pt2.PTRefFk)
ORDER BY occ.SummaryStatus

#4 Updated by Andreas Müller 11 months ago

  • Related to task #8651: Unify description aggregation methods (distribution and structured descriptive data) added

#5 Updated by Andreas Müller 10 months ago

  • Status changed from New to In Progress
  • Priority changed from New to Highest

#6 Updated by Andreas Müller 10 months ago

ERS:

die Anzeige ist so korrekt. Wenn ein Unterareal vorhanden ist, soll das höhere Areal nicht angezeigt werden, auch nicht in einer weniger satten Farbe oder so.

Der Fehler liegt also in den Daten. Das Areal sollte in diesem Fall Ga(F) heißen, nicht Ga.

#7 Updated by Andreas Müller 10 months ago

AM

Die Regel klingt erstmal sinnig und einfach. Ich habe allerdings gerade mal eine DB Abfrage gestartet, wie viele Verbreitungsdaten von Subarealen ebenfalls eine Verbreitung beim Überareal haben mit dem selben Status. Das sind >40000. Gut, andersherum mögen es etwas weniger sein, wenn Daten zu mehreren Subarealen pro Überareal vorkommen. Dafür gibt es noch die Fälle mit unterschiedlichem Status.

Im Anhang ist eine Tabelle mit den Ergebnissen dieser Abfrage.
Stimmt da was nicht oder kann das schon sein, dass es so viele Fälle gibt?

SELECT n.titleCache nameTitle, n.nameCache, a.titleCache subarea, a.idInVocabulary subareaId, par.titleCache supraArea, st.titleCache statusTitle,
sec.titleCache sec
FROM DescriptionElementBase deb INNER JOIN DescriptionBase db ON db.id = deb.inDescription_id
INNER JOIN TaxonBase tb ON tb.id = db.taxon_id
INNER JOIN TaxonName n ON n.id = tb.name_id
INNER JOIN DefinedTermBase a ON a.id = deb.area_id
INNER JOIN DefinedTermBase st ON st.id = deb.status_id
INNER JOIN DefinedTermBase par ON par.id = a.partOf_id
INNER JOIN Reference sec ON sec.id = tb.sec_id
WHERE tb.publish = 1 AND deb.DTYPE = 'Distribution' AND EXISTS (
SELECT *
FROM DescriptionElementBase deb2 INNER JOIN DescriptionBase db2 ON db2.id = deb2.inDescription_id
INNER JOIN DefinedTermBase a2 ON a2.id = deb2.area_id
LEFT JOIN DefinedTermBase st2 ON st2.id = deb2.status_id
WHERE a.id <> 2269 AND a.partOf_id = a2.id AND tb.id = db2.taxon_id AND st.id = st2.id)

#8 Updated by Andreas Müller 10 months ago

  • % Done changed from 0 to 30

#9 Updated by Andreas Müller 10 months ago

#10 Updated by Andreas Müller 8 months ago

  • Target version changed from Release 5.12 to Release 5.13

#11 Updated by Andreas Müller 7 months ago

  • Target version changed from Release 5.13 to Release 5.14

#12 Updated by Andreas Müller 6 months ago

  • Target version changed from Release 5.14 to Release 5.15

#13 Updated by Andreas Müller 3 months ago

  • Target version changed from Release 5.15 to Release 5.18

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)