Am unteren Rand soll es ein Panel geben, das Funde, Ablagen und Kontexte als Kacheln aufnehmen kann. Die Kacheln können auch wieder entfernt werden. Kacheln können in Formulartextboxen gezogen werden und die Textbox mit dem passenden Wert. Die Arbeit mit Kacheln soll das Arbeiten weiter beschleunigen und abwechslungsreich machen.

• [ ]

Siehe: https://www.w3schools.com/sqL/sql_injection.asp

Bis auf Weiteres abgelehnt, weil Parameter mit "?" gesetzt werden und nicht über einen Namen (z. B. "@id"): https://secure.php.net/manual/de/mysqli-stmt.bind-param.php

Analog zum Projekt "Haizahn" soll log4php in "Munins Archiv" eingebunden werden. Im Applikationswurzelverzeichnet "src" sollen im Ordner "log" fünf Logdateien von max. 1MB Größe in wechselnder Reihenfogle beschrieben werden. Der Logger soll ein Mal in der Anwendung initialisiert werden und als globale Variable den Webservice-Klassen zur Verfügung stehen, vgl. config.php.

• log4php zentral konfigurieren
• globalen Zugriff auf Logger implementieren
• Code mit Logaufrufen anreichern

Als Anwender möchte ich Ablagen, Orte und Fundattribute in einem Explorer (Baumstruktur mit Grid) durchklicken, anlegen, bearbeiten, verschieben und löschen. Das Arbeiten auf diese Weise entspricht dem Arbeiten mit dem Dateisystem mit dem Dateiexplorer.

• Ablagen
• Fundattribute
• Orte

Die Typen der Ablagen, Fundattribute und Orte sind gedacht, vom Anwender nach eigenem Ermessen angelegt zu werden. Aktuell müssen sie jedoch von einem Datenbankadministrator registriert werden.

Typen dürfen zukünftig umbenannt werden. Sie dürfen aber nicht gelöscht werden, wenn es Elemente gibt, die von dem zu löschenden Typ sind.

• Typen auflisten
• neuen Typ anlegen
• Typen bearbeiten
• Typen löschen, wenn keine Elemente von dem Typ existieren

Typen und Elemente sollen vom Anwender mit systemweiter Wirkung umsortiert werden können. Voraussetzung dafür ist ein neues Datenbankfeld, nachdem eine bedarfsabhängige Reihenfolge der Typen und Elemente erfolgen kann. Der Grund ist, dass eine alphabetische oder Reihenfolge nach Erstellung nicht immer sinnvoll ist, z. B. bei römischen Zahlen.

Bei Baumstrukturen zählt die Reihenfolge für Elemente einer Ebene und eines Elternknotes (alle direkten Kinder eines Knotens) neu.

• neue Spalte "Order" für alle Typen anlegen
• neue Spalte "Order" für alle Listen- und Baumstrukturelemente anlegen
• Standardwert ist Null (Zahl: 0)
• Reihenfolge in GUI bearbeiten

Eine ZIP-Datei wird zum Download zur Verfügung gestellt. Interessenten laden die Datei herunter und entpacken diese in einem leeren Web-Verzeichnis des Apache-WebServers. Der Interessent ruft den Ordnerpfad im Browser mit dem Protokoll HTTP auf, z. B. "http://localhost/Munins Archiv/". Der Browser zeigt die Installationsseite und führt den Installateur durch den Prozess, in dem u.a. die Datenbank konfiguriert wird.

• Prozess definieren
• Folgen auf Updates klären
• Aufräumen nach Abschluss des Prozesses
• Logprotokoll während der Installation zur Fehleranalyse
• Folgen auf das Einspielen alter Backups klären

Um unterschiedliche Arbeitsprozesse zu beschleunigen, soll es eine Zwischenablage in der Oberfläche geben, die auf allen Seiten verfügbar ist. Elemente, wie bspw. Ablagen oder Funde, können in die Zwischenablage mittel Maussteuerung (Anfassen und Ziehen) oder ggf. Kontextmenü gebracht werden. Die Elemente werden als Kachel dargestellt und können über Kontextmenü oder ein Löschen-X in der Kachel entfernt werden. Angewendet werden die Elemente per Maussteuerung wie folgt: Der Anwender zieht ein in der Zwischenablage ausgewähltes Element in ein entsprechendes HTML-Control, das daraufhin mit den Informationen des Elementes gefüllt wird.

Beispiel:
Der Anwender befindet sich im Formular für Funde und legt einen neuen Eintrag an. Aus der Zwischenablage wählt der Anwender eine Ablage, z. B. einen Karton, und zieht diesen mit der Maus in die Ablagetextbox im Fundformular. Daraufhin trägt das System den Datenpfad der gewählten Ablage in die Textbox ein.

Der Vorteil besteht darin, dass der Anwender beim Anlegen und Bearbeiten von Elementen sich wiederholende Informationen nicht von Hand erneut eingeben muss, sondern diese mit einer einfachen Geste hinzufügt oder überschreibt.

• Ablegen von Elementen in die Zwischenablage (Ablagen, Kontexte, Funde, Fundattribute und Orte)
• Entfernen von Elementen aus der Zwischenablage
• Öffnen des Elements in seinem Bearbeitungsformular über das Kontextmenü
• Einfügen der Elementinformation in dafür vorgesehenen HTML-Controls
• Maussteuerung
• Kentextmenüsteuerung
• ein Element kann nur ein Mal in der Zwischenablage sein
• Elemente in der Zwischenablage können vom Anwender beliebig angeordnet werden

Für die URL-Abfrage ist mit dem "PageName" auch nur der Seitenname nötig, um einen Sitemap-Eintrag zu finden und dessen URL zu ermitteln, auch wenn sich die Position des Eintrages in der Sitemap verändert hat, vgl. #14.

• jQuery-Erweiterung für die URL-Abfrage implementieren
• URL-Abfrage integrieren

Eine wesentliche Funktionalität der archäologischen Archivanwendung ist das Suchen und zwar das Suchen von Funden. Gründe hierfür können bspw. wissenschaftliche Untersuchungen oder Ausstellungen sein.

Die Einfachheit der Suche besteht darin, dass die Suchkriterien (Filter) nicht das volle Potenzial an Komplexität ausschöpfen. Die wäre z. B. dann der Fall, wenn Funde in einem Begehungs- oder Grabungszeitraum gesucht werden könnten.

Die einzelnen Suchkriterien werden logisch mit Und verknüpft, wodurch die Ergebnismenge immer eine Schnittmenge ist. Beispiel: Es werden Funde gesucht, die die Beschriftung "2-1" haben und in der Ablage "Regal B" liegen. Im Gegensatz dazu wird die Ergebnismenge vergrößert, indem gleichartige Kriterien hinzugefügt werden. Beispiel: Es werden Funde gesucht, die in der Ablage "Regal B" oder in der Ablage "Regal C" liegen. Lediglich die Fundattribute schneiden die Ergebnismenge, das heißt, dass ein Fund mindestens die angegebenen Fundattribute ausweisen muss, z. B. "Material: Ton" und "Gegenstand: Gefäß".

Suchkriterien
Beschriftung:
Der eingegebene Text wird nicht exakt gesucht, sondern es dürfen davor und danach weitere Zeichen stehen. Beispiel: Es wird "2" gesucht und es wird auch "21" gefunden. Wenn hingegen Anführungszeichen verwendet werden, muss exakt gesucht werden. Beispiel: Es wird ""23"" gesucht und es wird nur "23" gefunden.

Ablage:
Der Anwender klickt den Button "Hinzufügen" und das System öffnet einen Dialog. Der Anwender wählt eine beliebige Ablage aus der angebotenen Auswahl und beendet den Dialog. Das System sucht alle Funde, die mit dem ausgewählten Knoten und seinem vollständigen Unterbaum verknüpft sind. Beispiel: Der Anwender wählt das "Regal A" aus, dann sucht das System alle Funde die dem "Regal A", seinen Brettern und deren Kartons u.s.w. zugeordnet sind.

Kontext:
Der Anwender klickt den Button "Hinzufügen" und das System öffnet einen Dialog. Der Anwender wählt eine beliebigen Kontext aus der angebotenen Auswahl und beendet den Dialog. Das System sucht alle Funde, die mit dem ausgewählten Knoten und seinem vollständigen Unterbaum verknüpft sind. Beispiel: Der Anwender wählt die "Fundstelle 42" aus, dann sucht das System alle Funde die der "Fundstelle 42", seinen Begehungsflächen und deren Begehungen zugeordnet sind.

Fundattribut:
Der Anwender klickt den Button "Hinzufügen" und das System öffnet einen Dialog. Der Anwender wählt ein beliebiges Attribut aus der angebotenen Auswahl und beendet den Dialog. Das System sucht alle Funde, die mit dem ausgewählten Knoten und seinem vollständigen Unterbaum verknüpft sind. Beispiel: Der Anwender wählt das "Material: Metall" aus, dann sucht das System alle Funde die dem "Material: Metall", "Material: Edelmetall", "Material: Gold" etc. zugeordnet sind. Der Anwender kann weitere Attribute in die Filterliste hinzufügen. Das System sucht dann alle Funde, die mindestens die gewählten Attribute haben. Beispiel: Das Anwender aht "Material: Eisen" und "Gegenstand: Werkzeug" ausgewählt. Das System zeigt alle Funde an, die mit dem Knoten "Material: Eisen" und "Gegenstand: Werkzeug" (oder deren Unterknoten) verknüpft sind, aber auch weitere Attribute aufweisen, wie bspw. "Verzierung: Spiralmuster".

Benutzerprofile sollen die Arbeit mit Munins Archiv dahingehend vereinfachen, dass ein Anwender seinen aktuellen Arbeitsstand speichern kann, um später fortzufahren. Des Weiteren sollen die Benutzerkonten dazu verwendet werden, um bei Fundmeldungen den Finder auszuweisen. Folgende Daten sind vorgesehen:

• Name (Vor- und Nachname in einem Feld)
• Adresse
• Kontaktdaten (z. B. Telefonnummer, E-Mail-Adresse etc.)

Ausblick:
Zukünftig könnten Benutzerkonten auch zur Markierung oder gar Sperrung von Daten eingesetzt werden. Zum Beispiel sollen bestimmte Funde oder Fundplätze nicht jedem zugänglich sein. Ein anderes Beispiel ist, dass ein Anwender markieren möchte, dass er gerade einen Fund oder Fundkomplex bearbeitet. Auf diese Weise werden Daten nicht überschrieben.

• Konto anlegen
• Konto bearbeiten (nur eigenes Konto!)
• Konten auflisten
• Anzeige, unter welchem Konto der Anwender gerade arbeitet
• Anmeldung via GUID im gescannten QR Code (Smartphone)
• Anmeldung via Auswahl des Benutzernames aus einer Liste (Laptop)

Anmerkung:
Benutzer haben kein Passwort, weil noch nicht geklärt ist, wie ein Passwort zurückgesetzt werden können soll. Eine Lösung kann sein, dass es einen Administrator gibt oder eine Rechteverwaltung mit der Rolle Administrator. Unter der Annahme, dass die Gruppenmitglieder kooperativ arbeiten, ist eine Rechteverwaltung keine dringliche Problematik.

Fundattribute lieferten bisher alle Funde mit, die mit ihnen verknüpft sind. Dies verursacht Verzögerungen beim Laden. Es sind große Datenmengen bei bestimmten Fundattributen zu erwarten, z. B. bei Scherbenbeschreibungen.

Entsprechend dem Ticket #9 sollen Formulare und Datenobjekte mehrer Links enthalten können. Die Anwender müssen über eine Verwaltungsseite die gesetzen Links aufgelistet bekommen, filtern können und einzeln sowie in Gruppen beabreiten können. In der Verwaltungsübersicht muss zu jedem Link auch das Objekt aufgeführt sein, zu dem er gehört. Das heißt, wenn ein Link auf der Ablageübersicht gesetzt ist, dann muss in der Linkverwaltung zu diesem Link als Platz "Ablageübersicht" eingetragen sein und mittels Verlinkung geöffnet werden können.

Jeder Link hat einen Ort, wo er platziert ist. Das kann ein Datenobjekt sein, z. B. ein konkreter Fundeintrag, oder eine Formularseite. Der Link besteht aus einer URL und einem optionalen Anzeigetext. Is der Anzeigetext nicht gesetzt, wird die URL angezeigt.

Um einen Link für ein Formular zu setzen, zu ändern oder zu löschen, muss der Anwender die Seite in den Bearbeitungsmodus bringen, z. B. durch Klicken des zum Formular gehörenden Bearbeiten-Buttons.

Will der Anwender stattdessen einen Link für ein Datenobjekt setzen, findet er die Links als eigenes Feld vor.

Die Ortsangaben bilden einen anspruchsvollen Themenkomplex. Akuell werden drei Arten unterschieden: Kartasterdaten, Gebietskörperschaften und Flurnamen. Zu den Kartasterinformationen zählen die Gemarkung und die Flustücksnummer. Die Gebietskörpeschaften bestehen aus den Ebenen und Gliedern der politischen Verwaltungseinheiten, z. B. Bundesland, Bezirk, Landkreis, Gemeide, Ortsteil. Der Flurname wiederum ist lediglich der Name eines Hügels, Flusses, einer Wiese oder eines Tales etc.

Wünschenswert wäre alle drei Arten sowie Koordinatendaten miteinander in Beziehung zu setzen, sodass die Anwendung bei Kenntniss einer Information die anderen Daten für den Benutzer vorauswählt. Dies ist aktuell nicht möglich, aufgrund mangelnder Kenntnis über die Gesamtthematik, mangelnde Datenquellen, Komplexität der Datenverknüpfung und des enormen Zeitbedarfs für witere Recherchearbeiten.

Als Konsequenz werden für Ortskontexte drei Ortsangaben angegeben werden können: Kartasterdaten, Gietskörperschaft und Flurname. Diese werden vom System nicht geprüft. Der Anwender muss selbst für die korrekte Verküpfung dieser drei Arten sorgen.

Die Implementierung könnte sich an den Fundattributen orientieren. Dies ermöglicht das Ergänzen weiterer Ortdaten. Jedoch sollten die Geo-Daten (GPS, Gauß-Krüger etc.) nicht damit erfasst werden, weil Ortdaten als Text erfasst werden und Koordinaten in Form von mindestens zwei Zahlen verarbeitet werden.

• Kartasterdaten
• Gebietskörperschaften
• Flurnamen
• Netzstruktur der Ortsdaten löschen

Alle Web-Services sollen ein JSON-Objekt zurückschicken, das Aufschluss darüber gibt, ob es einen Fehler gab, wie die Fehlermeldung lautet und was das Ergebnis der Anfrage ist.

Beispiel:
{
"ResponseCode" : 0,
"ResponseMessage" : "Alles i.O.!",
"Response" :
{
"Id" : 111,
"Typ" : "Karton"
"Bezeichnung" : "1"
}
}

Diese Aufgabe ist veraltet, siehe #52.

• Anleitungsinhalt festlegen
• Demoumgebung einrichten
• Video drehen
• Youtube-Konto anlegen
• Video auf Youtube hochladen

Aktuell können Referenzdaten mit einem Element verknüft werden, wenn dieses bereits gespeichert wurde. Das bedeutete, dass ein neues Element zwei Speichervorgänge benötigt, um vollständig erfasst zu werden.

Elemente müssen in einem Arbeitsgang angelegt werden können. Das zweistufige Speichern muss das System eigenständig durchführen und darf nicht Teil des Benutzerprozesses sein!

Gegenwärtig gibt es eine Navigation im Kopfbereich jeder Seite. Hauptsächlich handelt es sich um die Einteilung der Datenstrukturen, z. B. Ablagen, Orte, Kontexte etc. Zusätzlich gibt es noch die Startseite mit statistischen Daten über die Datenstrukturen sowie die Druckseite für die Kartonschilder. In den Seiten für die Datenstrukturen unterteilt sich der Arbeitsbereich in eine Liste der Wurzelelemente und die Formularfelder für ein neues oder ausgewähltes Element. Der Nachteil hierbei ist, dass aufgrund kleiner Bildschirme und dem Bedarf größerer Schriften diese beiden Hauptblöcke nicht nebeneinander Platz finden.

Ein Ansatz wäre, dass die Übersicht zur Seite oder nach oben eingeklappt werden kann, bzw. vom Benutzer überhaupt erst aufgeklappt werden muss. Bei diesem Ansatz bleibt aber das Platzproblem bestehen.

Besser ist der Ansatz, Reiter (Tabs) zu verwenden. Diese könnten wie eine Unternaviagtion vertikal, auf der linken Seite angeordnet sein. Der erste Reiter beinhaltet die Wurzelelementliste und kann später ein Baum-Control sein und mit Suchfunktionen angereichert werden. Der zweite Reiter zeigt alle Datenfelder und wird automatisch geöffnet, wenn der Benutzer im ersten Reiter ein Element auswählt. Der dritte Reiter könnte bspw. die Typen (z. B. für Abalgen: Raum, Regal etc.) der Datenstruktur verwalten. Statistiken u.s.w. folgen in weiteren Reitern.

Aufgrund gemachter Erfahrungen, muss der "Kontext" verbessert werden.

Zu Begehungen:

• Ortsdaten können nur Begehungsflächen zugeorndet werden
• LfD-Nummern können nur der Maßnahme (Begehung) zugeordnet werden

Es soll eine neue Navigation entstehen, die einen Ausblick auf zukünftige Schwerpunkte der Anwendung bietet. Zentrale Bereiche sind eine Aktivitätenverwaltung, die Archivverwaltung und eine Organisationsverwaltung der archäologischen Organisation.

Die Aktivitätenverwaltung soll den neuen Schwerpunkt abbilden, der zu einer qualitativeren Zusammenarbeit mit dem Landesamt für Denkmalpflege beitragen wird.

Die Archivverwaltung bleibt weiterhin ein zentraler Bestandteil der Anwendung, in dem die Funde beschrieben udn archivalisch organisiert werden.

Die Organisationsverwaltung ist vorerst nur ein Hilfsmittel, um für die Erstellung von Druckformularen Name und Adresse der Organisation zu verwalten sowie die Mitglieder den archäologischen Aktivitäten und Fundbergungen zuzuordnen.

• Tagebuch
  • Fundstellen
    • neu anlegen
    • in Orten suchen
    • suchen
    • in Karte anzeigen
  • Aktivitäten
    • neu anlegen
    • in Fundstellen suchen
    • in Orten suchen
    • suchen
    • in Karte anzeigen
  • Orte
    • Gebietskörperschaften verwalten
    • Kartasterdaten verwalten
    • Flurnamen verwalten
• Archiv
  • Ablagen
    • neu anlegen
    • suchen
  • Funde
    • neu anlegen
    • in Ablagen suchen
    • in Fundstellen suchen
    • suchen
    • in Karte anzeigen
  • Fundattribute
    • neu anlegen
    • suchen
• Administration
  • Organisation
    • Organisationsprofil bearbeiten
    • Mitglied neu anlegen
    • Mitglieder suchen
  • Typen
    • Ablagetypen verwalten
    • Fundattributtypen verwalten
    • Ortstypen verwalten
  • Anwendung
    • Sicherung erstellen
    • Server herunterfahren
• Hilfe

Jede Seite hat einen eindeutigen Seitennamen (PageName), der dem zugehörigen Sitemap-Knoten zugeordnet ist. Somit kann die Breadcrumb-Navigation mit dem Seitennamen als Eingabeparameter den Navigationspfad der Seite ermitteln und anzeigen.

• Sitemap in JSON anlegen
• jQuery-Erweiterung für die Hauptnavigation implementieren
• Hauptnavigation integrieren
• PageName in Sitemap und JS-Dateien der HTML-Seiten einführen
• jQuery-Erweiterung für die Breadcrumb-Navigation implementieren
• Breadcrumb-Navigation integrieren

Die Methodensignatur von PHP beschränkt sich auf den Methodennamen, was eine Polymorphie mit unterschiedlicher Parameteranzahl ausschließt. Es müssten in solchen Fällen neue Methodennamen verwendet werden, die Parameter als Liste übergeben und ausgewertet werden oder nach einem anderen Konzept entwickelt werden.

Eine Möglichkeit, um den Programmmierstil beizubehalten wäre, der Einsatz einer anderen Programmiersprache auf der Serverseit, z. B. Java. Der Webserver würde Tomcat werden. Durch den kompilierten Code könnte die Ausführungszeit verkürzt werden. Darüber hinaus ist der Einsatz eines ORMs möglich.

Die Anforderungen beschränken sich auf die Interaktion mit der MySQL-Datenbank, Server-seitige Logik und die Web-Service-Dienstleistung.

Für Briefköpfe bei Datenexporten, z. B. bei Fundmeldungen an das Landesamt für Denkmalpflege, soll ein Organisationsprofil in Munins Archiv ausgefüllt werden. Folgende Daten sind vorgesehen:

• Name
• Adresse
• Kontaktdaten (z. B. Telefonnummer, E-Mail-Adresse oder Web Site)
• Logo

Aufgrund der Komplexität der Grabungsdaten, muss das Datenmodell für Grabungen neu entwickelt werden. Weil die AG Archäologie Fürth die einzige Nutzerin von Munnins Archiv v1.0 ist, soll das Upgrade-Skript für die Version 1.1 alle Daten, Datenbankstrukturen, Webservices und Formulare, die mit Grabungen zu tun haben, löschen. In der Folge gibt es bis auf Weiteres ab der Version 1.1 keinen Kontext Grabung. Funde können nur noch dem Kontext Begehung verknüpft werden.

• Alle Funde, die zu dem Grabungskontext oder dessen Unterkontexten zugeordnet sind, werden gelöscht.
• Alle LfD-Erfassungsnummern, die zu dem Grabungskontext oder dessen Unterkontexten zugeordnet sind, werden gelöscht.
• Alle Verknüpfungen zu Ablagen, die dem Grabungskontext oder dessen Unterkontexten zugeordnet sind, werden gelöscht. In der Folge sind die Ablagen leer.
• Alle Verknüpfungen zu Orten, die dem Grabungskontext oder dessen Unterkontexten zugeordnet sind, werden gelöscht. In der Folge können die Orte ggf. nicht verknüpft sein.
• Alle Grabungskontexte und deren Unterkontexte werden gelöscht.
• Die Kontexttypen Grabung, Fläche, Befund und Laufende Nummer werden gelöscht.
• Webservice-Code wird gelöscht.
• GUI-Code wird gelöscht.

Auf der linken Seite von Formularen und anderen Seiten muss ein Panel integriert werden, das die wesentlichen Informationen eines ausgewählten Elementes anzeigt.

Bei Formularen wird eine Übersicht des Elementes angezeigt, das aktuell im Formular geladen ist. Hierbei werden nur die in der Datenbank gespeicherten Werte angezeigt, nicht die im Formular geänderten!

Bei Suchseiten wird eine Übersicht des Elementes angezeigt, das aktiv ist und aktuell in Baumstruktur oder Tabellenstruktur etc. markiert ist.

Ein Übersichtspanel muss in den folgenden Seiten eingebunden werden:

• Ablageformular
• Kontextformular
• Fundattributformular
• Ortsformular
• Ablagesuche in Kontexten
• Fundsuche in Ablagen
• Fundsuche in Kontexten
• Fundsuche in Fundattributen
• Kontextsuche in Orten

Eine wichtige Voraussetzung für Kurzschreibweisen von Elementpfaden (Pfad eines Elementes innerhalb einer Baumstruktur) ist hier beschrieben #46

Wie können Grabungen abgebildet werden?
Wie detailliert müssen Grabungen abgebildet werden?
Welche Daten von Grabungen werden für welche Anwendungsfälle benötigt?

Der Anwender benutzt die Feldbegehungen und Grabungen (Fundkontexte), um jedem Fund seinen Bergungsort und Bergungszeitpunkt/-zeitraum zuzuordnen. Das im Folgenden beschriebene Szenario stellt den minimalsten Nutzen für den Anwender dar. Erweiterungen sollen möglich sein, werden jedoch hierbei nicht berücksichtigt.

Der Fundkontext, zu dem Feldbegehungen und Grabungen zählen, dient dazu, den Ort und Zeitpunkt/-raum der Fundbergung über die Anwendung direkt erfassbar und durchsuchbar zu machen.

Mit der Installation von WLAN in den Räumen der AG Archäologie Fürth ist es nun auch möglich, Munins Archiv auf Mobilgeräten zu benutzen. Munins Archiv bleibt als Webseite erhalten und wird nicht als App neuentwickelt.

• Entwicklung eines Nutzungskonzepts für Smartphones

Die Smartphone-Fähigjeit wurde in v1.1 bereits umgesetzt und bleibt Bestandteil weiterer Entwicklungen.

Eine Tablet-Optimierung wird erst angestrebt, wenn es den Bedarf gibt.

Es wird in dieser Version mehrere Seiten mit einer Karte zum Anzeigen geben. Es gibt eine Karte für alle Fundstellen und eine Karte für die Flächen. Die Karte basiert auf Kacheln von Openstreetmap. Die Anzeige übernimmt Leaflet.

Es gibt unterschiedliche Ebenen, die ein- und ausgeblendet werden können: Messtischblatt, Flurkarte.

In der linken Seitenleiste werden alle auf der ganzen Karte (nicht nur die im sichtbaren Bereich) befindlichen Elemente aufgelistet. Beim Klicken auf einen Eintrag springt die Karte zu dem Element.

Navigation:

• Tagebuch > Fundstellen > Karte
• Tagebuch > Begehungen > Karte
• Tagebuch > Grabungen > Karte

Anmerkung:
In dieser Version wird keine Suchfunktion unterstützt.

• Eine Übersichtskarte jeweils für Fundstellen, Begehungen und Grabungen implementieren
• Linke Spalte listet alle vorhandenen Daten auf
• Linke Spalte ermöglicht das Ein- und Ausblenden der Kartenränder für Messtischblätter (TK25) und Flurkarten (TK5)
• Rechte Spalte zeigt die Karte mit den Markierungen (Marker oder Flächen)
• Sind die Kartenränder (TK25 bzw. TK5) eingeblendet, zeigt das System die Kartennummer an.
• Die aufgelisteten Daten in der linken Spalte geben nur eine Übersicht. Über einen Link kann die Formularseite des Datensatzes geöffnet werden.

Ab v2.0 ist es möglich, dass der Anwender in eine Textbox hierarchische Daten wie einen Dateipfad einträgt, z. B. das Fundattribut Material: "Metall/Eisen". Bei einigen Datentypen ist es nicht nötig, dass der Typ mit angegeben werden muss, weil die Elemente eindeutig sind. Dies gilt für Fundattribute, Orte und Kontexte. Dagegen kann es bei Ablagen dazu kommen, dass die Unterablagen einer Ablage sich nicht allein in der Bezeichnung unterscheiden, sondern der Typ angegeben werden muss. Beispielsweise sind in einem Raum Stellplätze (A bis ...) und Regale (A bis ...). Das Problem könnte umgeangen werden, indem für jeden Typ dieser Menge ein anderes Nummerierungssystem gewählt wird, z. B. Stellplätze (a bis ...) und Regale (A bis ...). Jedoch ist diese Lösung nicht befriedigend.

Es stellt sich die Frage:
Wie kann der Datenpfad kurz gehalten werden bei gleichzeitiger Freiheit der Bezeichnungswahl?

Dabei bleibt unberühert, dass keine zwei Unterelemente des selben Typs die gleiche Bezeichnung tragen dürfen, weil die Elemente sonst nicht eindeutig sind. Z. B. In einem Raum dürfen keine zwei Regale die Bezeichnung "A" tragen.

Aktuell muss sich ein Interessent die benötigten Installationsteile aus dem Repository selbst zusammenstellen. Es muss ein Paket erdacht und erzeugt werden, dass folgende Bestandteile umfasst:

• Applikationsdateien (z. B. HTML-, CSS-, JS- und PHP-Dateien)
• Datenbankerzeugungsskripte, ggf. Datenbankaktualisierungsskripte
• Benutzerhandbuch
• ...

Daten, wie bspw. Ablagen, werden zwar nach ihrem Typ sortiert, aber innerhalb dieser Gruppen ist die Sortierung nach der Ablagenbezeichnung nicht immer sinnvoll. Ein einfaches Beispiel ist das der arabischen Zahlen. Alphabetisch sortiert lautet deren Zahlenreihe: 1, 10, 11, 12, ..., 19, 2, 20, 21, 22, ..., statt 1, 2, ..., 10, 11, 12, ..., 19, 20, 21, 22... . Das gleiche Problem entsteht auch bei römischen Zahlen. Eine Lösung könnte sein, dass die Zahlen als Zahlen und nicht als Text behandelt werden. Dagegen spricht, dass der Anwender damit die Freiheit verliert, Zahlenbezeichnungen und Textbezeichnungen in einem Reihenfolgensystem zu mischen.

Als Lösung wird empfohlen, die Listen unabhängig von den Bezeichnungen und Typen zu sortieren. Hierzu soll die jeweilige Liste vom Benutzer in einen Bearbeitungmodus gebracht werden. Zur technischen Umsetzung siehe: http://jqueryui.com/sortable/.

Die Datenbankaktualisierung ist hier beschrieben: #47

Beispielsweise beim Anlegen von Kindablagen muss bisher auch die Verknüpfung zur Elternablage vom Anwender neu hergestellt werden. Dies gilt auch für das Anlegen von Funden, die in der selben Ablage liegen oder aus dem selben Kontext stammen.

Zur Beschleunigung dieser Anlegeprozesse, soll es Hinzufügen-Buttons geben, die nicht nur das Anlegeformular aufrufen, sonden den oder die bekannten Feldwerte übergeben.

Weitereichende Lösungskonzepte sollten mehr als nur einen Feldwert vorbelegen. Das Anlegen von Kopien, die nur an den entsprechenden Stellen überschrieben werden birgt das Risiko, dass der Anwender zu Fehlern verleitet wird, weil alle Felder bereits ausgefüllt sind.

• Das Elternelement ist gesetzt, wenn aus einem geöffneten heraus ein neues Kindelement angelegt werden soll. siehe #29
• Bei Fundattribut und Kontext ist der Typ von anzulegenden Kindelementen bekannt. Das System wählt den entsprechenden Typ aus.

• Apache log4php
• Font Awesome Icons
• jQuery min
• jQuery UI
• jsGrid
• jsTree

Die neue Architektur trennt die Logik von den Datenobjekten. In der Folge wird es Klassen geben, die nur Daten halten und mit anderen Datenobjekten verbunden sind. Sie werden von Fabriken (Factories) mit den Daten der Datenbank befüllt. Die Fabriken übernehmen auchweitere Operationen im Zusammenhang mit der Datenbank, z. B. Speichern Aktualisieren und Löschen.

Bisher haben die Webdienste nur die Kerndaten eines Objekts ausgeliefert und der Client musste verknüpfte Objekte eigenständig nachladen. In der neuen Version liefern die Webdienste auch die verknüpften Objekte mit, aber nur deren Kerndaten!
Zu den Kerndaten zählt die ID, um die Verknüfung der Elemente zu ermöglichen. Des Weiteren gehört die Bezeichnung und der Typ zu den Kerndaten eines jeden Objekts.
Aufgrund der Bedeutung der Pfadinformation eines Elementes innerhalb der gesamten Baumstruktur, muss der Pfad ebenso zu den Kerndaten gezählt werden.

Zu den verknüpften Daten müssen alle Vorfahren auf dem Pfad sowie die direkten Nachkommen (Kinder) gezählt werden.

Das neue sehr vollständige Objekt, das vom Webdienst ausgeliefert werden wird, soll ohne weitere Anfragen in dem jeweiligen Formular geladen werden können, um bearbeitet werden zu können. Umgekehrt nimmt der Webdienst ein vollständiges Objekt entgegen, speichert die Kerndaten und verwertet von den verknüpften Daten lediglich die ID.

Zur Vereinfachung von:
#37, #11 etc.

Achtung:
Die Pfadverarbeitung nimmt an Bedeutung zu. Die Pfadinformation wird der Erfahrung nach vorwiegend gelesen und nach der Erzeugung nur selten durch Umhängen, Löschen oder Hinzufügen verändert. Aus diesem Grund ist eine entsprechende Technik für die Pfadverarbeitung zu wählen, z. B. Caching oder das Speichern des Pfades als berechenbare Information, die bei Änderung neu berechnet wird.

Die Kartonbezeichnung wird aktuell aus dem verknüpften Kontext berechnet. Dieses Verhalten wird umgestellt. Die Bezeichnung wird nicht mehr berechnet.

• SQL-Statement oder ein updatesicheres PHP-Skript zum Eintragen der Kartonbezeichnung (berechnet aus dem verknüpften Kontext)
• Altcode aufräumen

Unter dem Ordner "Dienste" soll es folgende neue Unterordner geben "Ablage", "AblageTyp", "Fund", "Fundattribut", "Kontext", "KontextTyp", "Ort", "OrtsTyp" und "LfD". In die Order werden die zugehörigen PHP-Dateien der Dienste verschoben und umbenannt, z. B.: "DeleteAblage.php" zu "Delete.php" und "GetOrtWithParents.php" zu "GetWithParents.php".

Der Ordner "Klassen" soll in das Applikationsverzeichnis "src" verschoben werden.

Es ist hierbei zu beachten, dass sowohl in allen PHP-Dateien die include- und require-Anweisung als auch die Aufrufadressen in den Javascriptdateien korrigiert werden!

Im Formular für Fundstellen wird eine Karte angezeigt. Der Anwender kann mit der Maus in der Karte navigieren und eine Markierung setzen, wo sich die Fundstelle befindet.

optional: Die Längen- und Breitengrade werden dem Anwender angezeigt und erfolgt einmal im Format Grad-Minute-Sekunde und einmal im Format Grad (dezimal).

Zum Korrigieren einer Positionierung verwendet der Anwender den Lösch-Button an der Karte.

Der Anwender kann alternativ die Längen- und Breitengradwerte direkt in einer Anzeigebox ändern.

Anmerkung:
Die Maßstabsungenauigkeit und die Größe von kleinen Flächen können dazu führen, dass die Flächen nicht (genau genug) abgebildet werden können. Dies muss getestet werden.

• WebService sendet im Fehlerfall HTTP-Statuscode 500 und eine Nachrichtenliste im Body (http_response_code())

• WebService unterscheidet die Anfrage anhand der HTTP-Anfragemethode ($_SERVER["REQUEST_METHOD"])

• WebService Client verwendet AJAX mit einer Zieladresse (z. B. http://localhost/Munins-Archiv/src/services/user/1) und unterschiedlicher HTTP-Methode (POST, GET, DELETE, PUT), siehe Statuscode in jqXHR

• Ablage

• AblageTyp

• Ort

• OrtTyp

• FundAttribut

• FundAttributTyp

• Fund

Fund können vermessen werden. Dafür stehen drei Dimensionen (Höhe, Breite und Tiefe) zur Verfügung. Zudem kann die Masse bestimmt werden. Weil es vom Fundobjekt und vom Erfasser abhängig ist, welche Dimension Höhe, Breite und Tiefe ist, werden die Dimensionen neutral benannt.

• drei jeweils optionale Längenangaben in Millimeter (mm) als ganze Zahl
• Bezeichnung: Dimension 1, Diemension 2 und Dimension 3
• optionale Gewichtsangaben in Gramm (g) als ganze Zahl

Alle Baumstrukturen in Munins Archiv sollen sich wie ein Dateiverzeichnis verhalten. Das bedeutet, dass alle Elemente eine Bezeichnung haben müssen und dass die Bezeichnung aller Kindelemente eines Elementes eindeutig sein muss. Diese neue Eigenschaft trifft auf Fundattribute, Kontexte, Ablagen und Orte zu.

Die Anpassung kann im Rahmen des Upgrade-Prozesses von v1.0 auf v1.1 erfolgen.

• Gesetzte Bezeichnung und eindeutige Kindelementbezeichnung für Fundattribute
• Gesetzte Bezeichnung und eindeutige Kindelementbezeichnung für Kontexte
• Gesetzte Bezeichnung und eindeutige Kindelementbezeichnung für Ablagen
• Gesetzte Bezeichnung und eindeutige Kindelementbezeichnung für Orte
• Keine Bezeichnung darf das Trennzeichen "/" enthalten
• Die Anwendung muss prüfen, dass das vorgesehene Trennzeichen "/" nicht eingegeben wird

Die Beschreibung eines Fudes ist abhängig vom Erfasser, der seine eigene Erfahrung und seinen eigenen Wortschatz vewendet. Um Mehrfacheinträge durch Synonyme zu verhindern und trotzdem Individualität zu emöglichen, soll es zu Fundattributwerten Sysnonyme geben.

Die Synonymfunktion kann auch dazu verwendet werden, um Abkürzungen oder Symbole zu hinterlegen.

• Es können mehrere Synonyme für einen Fundattributwert erstellt werden.
• Wie sollen Synonyme vewendet werden?

Aktuell hat die Anwendung den Schwerpunkt in der Archivverwaltung. Nach dem Treffen am 29.03.2017 mit Frau Dr. Hannig-Wanninger und Herrn Wanninger vom Bayerischen Landesamt für Denkmalpflege (BLfD) hat sich gezeigt, dass für eine Zusammenarbeit mit dem BLfD ein neuer Schwerpunkt in der Anwendung gesetzt werden muss. Hierbei handelt es sich um eine Art Akitivitätentagebuch, das alle Maßnahmen eines archäologieschen Akteurs (z. B. einer Arbeitsgruppe) umfasst, die zur Bestätigung, Berichtigung und Erschließung oder Ausschließung von Denkmalflächen führen.

Solche Maßnahmen sind nicht nur Grabungen und Feldbegehungen, die bereits in der Anwendung unter dem Stichwort "Kontext" behandelt werden, sondern umfassen ebenso Bodenuntersuchungen mit bspw. Geo-Radar, aber auch Recherchearbeiten bspw. in Bibliotheken und Archiven. Es müssen sowohl die positiven Ergebnisse als auch die negativen Ergebnisse für eine Berichterstattung erfassbar sein. Ein Beispiel ist, dass Luftbilder Bodenstrukturen zeigen, die bei einer geologischen Untersuchung als biologisches Phänomen identifiziert werden.

Vorarbeit:

• #27

Daten, die in einer Baumstruktur verknüpft sind, z. B. Ablagen, können gegenwärtig miteinander so verknüpft werden, dass über die Unter- oder Oberelemente das Ausgangselement wieder angetroffen wird. Ein solcher Ring darf nicht gebildet werden können! Eine solche Verknüpfung ist thematisch unzulässig und bewirkt technisch einen ewig laufenden Ladezyklus.

Lösung
Ein Element darf nicht in seine eigene Baumstruktur hinein verschoben werden.

Aktuell gibt es in Munins Archiv zwei Nummern des (Bayerischen) Landesamtes für Denkmalpflege (LfD): die Denkmalnummer und die Eingangsnummer.

Die Denkmalnummer besteht aus der Messtischblattnummer und einer vierstelligen Laufnummer, z. B. "6528/0123".

Die Eingangsnummer setzt sich aus dem Jahr der Registrierung und einer laufenden Nummer zusammen, z. B. "1994/123".

Mittlerweile hat das BLfD ein neues Nummernsystem, das den Anlass gibt, das Thema LfD-Nummer neu zu diskutieren. Es ist zu erwarten, dass andere Landesämter eigene Nummensysteme haben und historische Daten existieren.

Die einfachste Lösung ist von daher, dass zu den Maßnahmen frei wählbare Texte als LfD-Nummern eingebbar sind. Eine Erweiterung kann darin bestehen, dass in einem Adminbereich erlaubte Formate eingetragen werden können.

• Datenbankstruktur anpassen
• Felder LfD-Erfassungsjahr und LfD-Erfassungsnummer zu "LfD-Nummer" zusammenfassen
• Felder BLfD-Nr und TK25 zu "LfD-Nummer" zusammenfassen
• LfD-Nummer kann jedem Kontext hinzugefügt werden
• Daten transformieren (PHP-/SQL-Skript)
• WebServices anpassen (Server und Client)
• GUI anpassen

Funde sind mit Ablagen und Kontexten verknüpft, die als Baumstruktur vorliegen. Ebenso sind Kontexte mit der Ortsbaumstruktur verknüpft. Diese Strukturen bieten die Möglichkeit einer systematischen und anschaulichen Suche nach einem Kriterium.

• Kontextsuchbaum für Funde implementieren (Fund/SearchInKontexten.html)
• Ablagesuchbaum für Funde implementieren (Fund/SearchInAblagen.html)
• Kontextsuchbaum für Ablagen implementieren (Ablage/SearchInKotexten.html)
• Fundattributsuchbaum für Funde implementieren (Fund/SearchInFundattributen.html)
• Ortssuchbaum für Kontexte implementieren (Kontext/SearchInOrten.html)

Eingescannte Dokumente, erstellte Berichte sowie Datentabellen reichern die Datenmenge einer Maßnahme an und ermöglichen die Digitalisierung weiter voranzutreiben. In dieser Anforderung geht es aktuell darum, Dateien mit einer Begehung oder einer Grabung zu verknüpfen. Ein Dokument kann nur einer Maßnahme zugeordnet werden.

• Dokument hat einen Namen (eindeutig zur Menge aller Dokumente überhaupt)
• Dokument hat einen Titel (eindeutig zur Menge aller Dokumente der Maßnahme)
• Dokument hat mehrere Autoren
• Dokument hat eine Quelle (Freitext)
• Dokument hat mehrere Schlagworte

Offene Fragen:

• max. Dateigröße
• Speicherort (Dateisystem, Datenbank oder Dateiservice)
• Sicherung erstellen und wieder einspielen
• Suchfunktion

Die Oberfläche muss den neuen Funktionen und der neuen Architektur entsprechend angepasst werden.

• #50 Oberflächen zu Grabungen entfernen
• #49 Formulare an neue Architektur anbinden
• #24 LfD-Nummer (Freitext) für alle Kontexte zulassen
• #23 Baumstruktur der Ortsangaben (drei Arten) umsetzen
• #53 Elemente anlegen, bearbeiten, verschieben, löschen im Explorer

Problemstellung
Anlass zu den folgenden Überlegungen ist das Bedürfnis der Anwender, sich eigene Dokumentationen zu erstellen, die ihrer persönlichen Struktur und Formulierung entsprechen. Gleichzeitig soll das gegenwärtige Handbuchformat, eine Open-Document-Textdatei, kritisch hinterfragt werden.

Handbuch als Datei
Der Vorteil des Handbuches als ODT-Datei ist, dass seine Bearbeitung den Anwendern keine Schwierigkeiten machen sollte. Es ist anzunehmen, dass die meisten Benutzer ausreichend Erfahrung in einem Textbearbeitungsprogramm, namentlich Microsoft Word, haben. Auch das Drucken oder Weitergeben des Handbuches sollte den Anwenderkreis vor keine neuen Herausforderungen stellen.

Gleichwohl gibt es schwerwiegende Nachteile, wie zum Beispiel, dass die Datei zu einem Zeitpunkt nur von einer Person bearbeitet werden kann. Zwar können in das Dokument Links eingefügt werden, aber die Datei selbst kann im besten Fall nur als Ganzes verlinkt werden, nicht aber einzelne Kapitel oder gar Abschnitte. Zudem wird das Benutzerhandbuch trotz eines Inhaltsverzeichnisses eine gewisse Unübersichtlichkeit haben wie sie allen Papier orientierten Textdokumenten inne ist. Mit immer mehr neuen Funktionalitäten der Anwendung und detaillierteren Beschreibungen mit Abbildungen etc. wächst die Datei an und verzögert das Laden und Navigieren in der Datei. Wenn die Anwender die Dokumentation erweitern, müssen sie einen entsprechend hohen Aufwand betreiben, um aktuellere Handbuchversionen mit ihrer Version zu vereinen. Oder die Anwender pflegen eigene Anmerkungen in separaten Dateien. In Dem Zusammenhang kommt das nächste Problem, die Ablage der Datei(en). Anwender finden selbst eigene Dateien nicht wieder oder kommen nicht an die Dateien anderer heran, z. B. aufgrund dezentraler Speicherung.

Handbuch als Wiki
Ein Lösungsansatz besteht darin, ein Wiki (z. B. MediaWiki) zu installieren und in Munins Archiv Links zu hinterlegen. So könnten Formularseiten mit Wiki-Seiten verlinkt werden, die eine detaillierte Hilfe mit Screenshots etc. bieten. Auch könnten Datenobjekte, z. B. Funde, mit Wiki-Seiten verlinkt werden, die nicht nur die Untersuchung des Fundes ausführlich dokumentieren und mit Fotos anreichern, sondern auch weitere Dokumente, bspw. Forschungsarbeiten, die im Wiki verwaltet werden, verlinken. Das Handbuch würde als Exportdatei für den Import ins eigene Wiki bereitgestellt werden. Neue Versionen des Handbuches könnten einfach importiert werden. Aufgrund der Versionsverwaltung des Wikis wären die aktuelle Version und eine ältere Version vergleichbar und notfalls wieder herstellbar. Für die Anwender ergäbe sich außerdem die Möglichkeit, dass mehrere Redakteure gleichzeitig am Handbuch arbeiten können. Den Anwendern steht der Wiki-Editor mit einer Vielzahl vonTextbearbeitungsfunktionen zur Verfügung. Drucken ist eine Standardfunktion eines jeden Browsers.

Linkfunktion in Munins Archiv
Munins Archiv könnte sich mit dieser Lösung stärker auf die Verwaltung der Funde konzentrieren. Dokumentenverwaltung sowie ausführliche Beschreibungen der Funde und Fundumstände wäre ausgelagert und über Links verknüpft. Textformatierung, Textsuche sowie Dokumentenformate müssen in der Weiterentwicklung von Munins Archiv gar nicht erst thematisiert werden. Die Links bieten auch die Möglichkeit, ein ganz anderes Dokumentensystem zu verwenden. Zum Beispiel könnte der Verwalter einen Dokumentenserver bereitstellen. Die Anwender bearbeiten die Dokumente, entsprechend den Möglichkeiten des Systems und verlinken die Dokumente in Formularseiten sowie Datenobjekten in Munins Archiv.

Es muss zwischen den zwei Funktionen des Anlegens und des Hinzufügens unterschieden werden. Aktuell ist das Anlegen implementiert. Hierbei setzt das System das Elternelement für das neue Element.

Die beiden Funktionen sind im Formularfeld "Kinder" und äquivalenten Feldern anzubieten.

• neues Kindelement anlegen ("Anlegen"-Button)
• vorhandenes Kindelement verknüpfen ("Auswählen"-Button)

Für alle Baumnavigatioen gilt, dass nur die Wurzelebene vorgeladen wird. Alle weiteren Ebenen wrden erst geladen, wenn der Anwender den jeweiligen Elternkoten öffnet. Dabei kann es vorkommen, dass keine Kinderknoten zum Anzeigen vorhanden sind. Diese Irritation wird akzeptiert.

• Baumnavigation für Ablagen
• Baumnavigation für Fundattribute
• Baumnavigation für Kontexte
• Baumnavigation für Orte

Die Baumnavigation wird in die jeweilige Übersichtsseite (Overview.html) eingebaut, statt der bisherigen Liste. Die Seite wird anschließend zur Suchseite (Search.html).

• Seiten umgenennen (Overview.html -> Search.html)
• umbenannte Seiten in der Sitemap anpassen

In hierarchischen Datenstrukturen, z. B. in den Ablagen (Kartons in Regalen und Regale in Räumen) wird der Elternknoten bisher über ein Folge von Auswahl-Controls ausgewählt. Für jede Tiefe in der Hierarchie gibt es ein Auswahl-Control. In jedem Auswahl-Control befinden sich alle Kindknoten des im vorangegangenen Control ausgewählten Knotens. Je tiefer also ein Elternknoten liegt, desto mehr Elemente müssen geladen werden. Diese Control-Ansammlung wird gegenwärtig auch bei der Formularanzeige verwendet, um Änderungen, ohne einen zusätzlichen Klich zu ermöglichen.

Abgesehen vom Anlegen eines Datensatzes, sind Änderungen in Bezug auf den Elternknoten sehr selten zu erwarten. Die Anwendung findet in einem Archiv statt, nicht in einem Lagerhaus mit stündlichen Änderungen.

Die Auswahl-Controls, sollen nur noch über ein Popup erscheinen. Im Anzeigemodus soll eine einfache Liste der Elternknoten bis zum Wurzelknoten angezeigt werden. Der erste Listeneintrag ist der Wurzelknoten und der unterste Listeneintrag ist dabei der direkte Elternknoten.