|
|
### Idee:
|
|
|
Bei Klick auf ein Kartensymbol, das den Fundort einer Probe repräsentiert, muss der passende Steckbrief und das
|
|
|
passende 3D-Modell geladen werden.
|
|
|
Schaffe also eine Verbindung zwischen der Kartenposition/Symbol, dem Steckbrief und dem 3D-Modell einer Probe.
|
|
|
### Verknüpfung zwischen Punktobjekten, 3D-Scans und Steckbriefen
|
|
|
|
|
|
### Umsetzung:
|
|
|
Die Kartenposition wird durch die <Proben-ID> repräsentiert, welche in dem Shape-File enthalten ist, das die
|
|
|
Kartenposition enthält; der Steckbrief und das 3D-Modell jeweils durch ihre Dateinamen. Die Verbindung dieser
|
|
|
Informationen wird in dem JSON-Dokument CrossReferencer.json gespeichert, welches folgende Struktur aufweist:
|
|
|
Innerhalb der Anwendung ist eine Verknüpfung zwischen den Punkt-Features aus
|
|
|
der Bohrdatenbank des HLNUG (siehe dazu 1.1.6) und den Steckbriefen sowie den Modelldateien der 3D-Scans herzustellen. Klickt der/die Anwender:in z. B. in der Kartendarstellung auf ein Punktsymbol, das den Fundort einer Probe repräsentiert,
|
|
|
so ist das zugehörige Steckbrief-Objekt zu ermitteln, um diesen gemeinsam mit dem passenden 3D-Modell anzuzeigen. Die Verknüpfung ist nicht nur unidirektional
|
|
|
(Punkt -> Steckbrief) vorzunehmen, denn die in der Anforderungsanalyse benannten
|
|
|
User-Storys beinhalten auch den Fall, dass z. B. nach Objekten (d. h. letztlich
|
|
|
Steckbriefen) gesucht wird und der zugehörige Punkt in der Karte grafisch
|
|
|
hervorgehoben werden soll.
|
|
|
|
|
|
An dieser Stelle ergaben sich die beiden folgenden Umsetzungsmöglichkeiten:
|
|
|
1. In der Shapedatei mit der Information aus der Bohrdatenbank wird für jede Punktgeometrie ein Attribut ergänzt, das den Namen der systeminternen Steckbrief-Datei enthält.
|
|
|
2. Es wird eine Tabelle vorgehalten, die tupelweise die Information zu den Punkt-IDs der Shapedatei, Steckbrief-ID und 3D-Scandatei enthält.
|
|
|
|
|
|
Ansatz 1 wurde verworfen, da er den erheblichen Nachteil hat, dass im Falle einer Aktualisierung der Shapedatei durch das HLNUG die Ergänzungen nachzuführen sind.
|
|
|
Auch würde diese - nur auf den ersten Blick naheliegende - Lösung nur eine
|
|
|
unidirektionale Verknüpfung realisieren. Ansatz 2 bietet also den Vorteil, dass die
|
|
|
Shapedatei im laufenden Daten ausgetauscht werden kann, ohne dass die benötigte Information verloren geht (insofern die Punkt-IDs sich nicht ändern). Für große
|
|
|
Objektanzahlen ist für Ansatz 2 allerdings die sich ergebende Rechenlaufzeit zu
|
|
|
beachten! Hier wird eine geeignete Datenstruktur auszubauen sein (z. B. Sortieren
|
|
|
der Tabelle und Suche in Array o. ä., unter Umständen ist aber auch die Ablage in
|
|
|
einer Datenbank zu erwägen).
|
|
|
|
|
|
### Umsetzung
|
|
|
|
|
|
Der im Rahmen des Projektes implementierte *Cross-Referencer* setzt den oben beschriebenen Ansatz 2 um. Er wurde zunächst in Form einer einfachen
|
|
|
Dateistruktur implementiert, was bei der derzeitigen Objektmenge zu keinen
|
|
|
Laufzeitproblemen führte.
|
|
|
|
|
|
Die Kartenposition wird im Weiteren durch die <Proben-ID> repräsentiert, welche in dem Shape-File enthalten ist, das die Kartenposition enthält; der Steckbrief und die Datei des 3D-Scans jeweils durch ihre Dateinamen. Die Verbindung dieser
|
|
|
Informationen wird innerhalb der Anwendung in einem JSON-Dokument namens *CrossReferencer.json* gespeichert, welches folgende Struktur aufweist:
|
|
|
|
|
|
Struktur:
|
|
|
|
|
|
{
|
|
|
"items": [
|
|
|
{
|
|
|
"probe": "Proben-ID",
|
|
|
"steckbrief": "Name der Steckbrief-Datei",
|
|
|
"scan3d": "Name der Handstück-Datei"
|
|
|
"probe": <Proben-ID>,
|
|
|
"steckbrief": <Name der Steckbrief-Datei>,
|
|
|
"scan3d": <Name der Handstück-Datei>
|
|
|
},
|
|
|
...
|
|
|
]
|
|
|
}
|
|
|
|
|
|
Dabei müssen alle Werte - also <Proben-ID>, <Name der Steckbrief-Datei>, <Name der Handstück-Datei> - als
|
|
|
Strings, ohne File-Extension, in doppelten Hochkommata eingetragen werden. Bemerkung: die "Proben-ID" in dem Shape-File kann auch Buchstaben enthalten (!)
|
|
|
Dabei müssen alle Werte - also <Proben-ID>, <Name der Steckbrief-Datei>, <Name der Handstück-Datei> - als Zeichenketten, *ohne* Angabe der Datei-Extension, in doppelten Hochkommata eingetragen werden. Bemerkung: die "Proben-ID" in der Shapedatei kann auch Buchstaben enthalten, ist also nicht numerisch (!).
|
|
|
|
|
|
Beispiel:
|
|
|
|
... | ... | @@ -30,24 +51,24 @@ Beispiel: |
|
|
"items": [
|
|
|
{
|
|
|
"probe": "921",
|
|
|
"steckbrief": "steckbrief",
|
|
|
"scan3d": "Handstueck_CS3_3D"
|
|
|
"steckbrief": "steckbrief_921",
|
|
|
"scan3d": "Handstueck_CS3_3D_921"
|
|
|
},
|
|
|
{
|
|
|
"probe": "5761",
|
|
|
"steckbrief": "steckbrief2",
|
|
|
"scan3d": "Astronaut"
|
|
|
"steckbrief": "steckbrief_5761",
|
|
|
"scan3d": "Handstueck_CS3_3D_5761"
|
|
|
},
|
|
|
{
|
|
|
"probe": "38094",
|
|
|
"steckbrief": "steckbrief",
|
|
|
"scan3d": "Handstueck_CS3_3D_old"
|
|
|
"steckbrief": "steckbrief_38094",
|
|
|
"scan3d": "Handstueck_CS3_3D_38094"
|
|
|
}
|
|
|
]
|
|
|
}
|
|
|
|
|
|
In dem JavaScript-File CrossReferencer.js sind die benötigten Funktionalitäten wie folgt abgelegt, die alle Teil der
|
|
|
dort definierten Klasse CrossReferencer sind:
|
|
|
In der JavaScript-Datei *CrossReferencer.js* sind die benötigten Funktionalitäten,
|
|
|
die sämtlichst Teil der dort definierten Klasse <code>CrossReferencer</code> sind, wie folgt abgelegt:
|
|
|
|
|
|
| Name der Funktion | Wirkung der Funktion |
|
|
|
| ------ | ------ |
|
... | ... | |