Das ist eine für den Ausdruck optimierte Ansicht des gesamten Kapitels inkl. Unterseiten. Druckvorgang starten.
TODO: Warum sollte man die FieldMApp nutzen? Welche Datenaufnahme-Arten werden jetzt schon unterstützt?
| Modulartikel | Kurzbeschreibung |
|---|---|
| Profiling | Evaluieren der Nutzerkompetenz durch mehrere Fragen und anschließender Selbsteinschätzung |
| Projekte | Importieren und Ausfüllen von ODK Formularen |
| Fahrtansicht | Nutzergesteuerte Kartierung von besonderen Gebieten auf landwirtschaftlich genutzten Feldern |
TODO: Was kann das Modul leisten? Welche Daten werden gewonnen? Was ist dazu notwendig?
Die Fragen sind in den txt Dateien unter MobileDataCollection.Survey.Android Assets gespeichert. (TODO: Korrigieren sobald “modularize” abgeschlossen ist)
Es gibt einige Attribute, die für alle Fragen gleich sind. Zudem gibt es Konventionen für die Nutzung von Strings.
Jeder Fragentyp hat das Attribut InternId. Dieses dient als Primärschlüssel mit dem man die Frage eindeutig identifizieren kann. Dieses sollte also immer eineindeutig für eine gespeicherte Frage vergeben werden. Zudem enthält jeder Typ (bis auf Introspection) das Attribut Difficulty. Dies ist eine Zahl von 1, für leicht, bis 3, für schwer, welche den Schwierigkeitsgrad der Frage angibt. Der Fragetext ist im Attribut QuestionText gespeichert und auch in jedem Fragetyp vorhanden.
Die Fragen sind im JSON-Format in der Datei “questions” abgelegt. Zeilenumbrüche und Leerzeichen können also zur Formatierung (außerhalb von Strings) beliebig eingesetzt werden. Zudem unterstützt die von uns genutzte JSON-Bibliothek (Newtonsoft JSON) sowohl einzeilige als auch mehrzeilige Kommentare im C#-Stil.
Damit Bilder richtig geladen werden können, müssen diese mit Visual Studio in die Ordner Resources/drawable-mdpi für “niedrig” auflösende Bilder und in Resources/drawable-xhdpi für “hoch” auflösende Bilder abgelegt werden. Der Name der beiden Bilder muss gleich sein, damit das System erkennt, dass es sich um den gleichen Inhalt unterschiedlicher Auflösung handelt. Es wird dann automatisch in Abhängigkeit der Display-Größe das passende Bild angezeigt. Der Namen der Bilder muss immer mit dem jeweiligen Format enden z.B. “Bild.png”. Nach dem Hinzufügen neuer Bilder muss die App neu erstellt (kompiliert) werden, damit die neuen Bilder übertragen werden. Dasselbe gilt für neu hinzugefügte Fragen.
Der DoubleSlider Typ beinhaltet ein Bild und zwei Slider auf denen man jeweils einen Wert von 0 bis 100 angeben kann. Die Frage lautet immer: “Schätzen Sie den Grad der Bedeckung des Bodens durch Pflanzen (A) und den Anteil grüner Pflanzenbestandteile (B) ein.”
Ein QuestionDoubleSlider Objekt benötigt die Attribute int InternId, string QuestionText, int Difficulty, string PictureAddress, int AnswerA, int AnswerB, um erstellt zu werden. Das Attribut QuestionText enthält die anzuzeigende Frage. Diese kann beliebig gewählt werden. AnswerA und AnswerB stehen jeweils für die korrekten Antworten; für die Frage der Bodenbedeckung durch Pflanzen (A) und den Anteil grüner Pflanzenbestandteile (B) wird ein Wert von 0 bis 100 gesetzt. Der String PictureAdress enthält den Namen des Bildes, das für diese Frage angezeigt werden soll.
Um eine neue Frage einzufügen, öffnet man “questions”, geht zum Eintrag “DoubleSlider”, kopiert einen bestehenden Eintrag und fügt die neuen Werte ein.
Der ImageChecker Typ beinhaltet 4 Bilder, die einzeln ausgewählt werden können. Die Fragen dazu lauten z.B.: “Wo sehen sie die Feldfruchtsorte Weizen abgebildet?”
Ein QuestionImageChecker Objekt benötigt die Attribute int Internid, string QuestionText, int Difficulty, int Image1Correct, int Image2Correct, int Image3Correct, int Image4Correct, string Image1Source, string Image2Source, string Image3Source, string Image4Source, um erstellt zu werden. Das Attribut QuestionText enthält die anzuzeigende Frage. Diese kann beliebig gewählt werden. Die Attribute Image1Correct, Image2Correct, Image3Correct und Image4Correct geben an, welches Bild korrekt ist. Es können auch mehrere korrekt sein. Diese haben dann den Wert 1. Die falschen Bilder haben den Wert 0. Die Attribute Image1Source, Image2Source, Image3Source und Image4Source geben den Namen der einzelnen Bilder an.
Um eine neue Frage einzufügen, öffnet man “questions”, geht zum Eintrag “ImageChecker”, kopiert einen bestehenden Eintrag und fügt die neuen Werte ein.
Der Stadium Typ beinhaltet ein Bild und 2 Listen, in denen man zum einem das Wuchsstadium der Pflanze und zum anderem die Art der Pflanze anklicken kann. Die Fragen dazu lauten z.B.: “Ordnen Sie dem Bild eine Feldfruchtsorte und das/die Entwicklungstadium/-stadien zu.”
Ein QuestionStadium Objekt benötigt die Attribute int InternId, string QuestionText, int Difficulty, string Image, List<StadiumSubItem> Stadiums, List<Plant> Plants, int CorrectAnswerStadium, string CorrectAnswerFruitType. Die Liste Stadiums enthält mehrere StadiumSubItem Elemente. Die Elemente werden als JSON-Liste abgebildet. Das Gleiche gilt für die Liste Plants.
Das Attribut CorrectAnswerStadium ist eine Zahl von 1 bis 9 und gibt damit an, welches Element aus der List Stadiums das richtige Element ist. Die Elemente haben ihren Index (beginnend mit 0) als Zahl. Das Attribut CorrectAnswerFruitType ist ein String der Länge 1 und gibt an welches Element aus der Liste Plants das richtige Element ist.
Um eine neue Frage einzufügen, öffnet man “questions”, geht zum Eintrag “Stadium”, kopiert einen bestehenden Eintrag und fügt die neuen Werte ein.
Diese Fragen stellen eine Besonderheit dar, da es sich hier um die Selbsteinschätzung handelt. Daher haben die Fragen keine Bilder oder Schwierigkeiten, sondern nur einen Text und eine Auswahlmöglichkeit von 1 bis 5.
Ein QuestionIntrospection Objekt benötigt die Attribute int InternId, string QuestionText. Der QuestionText gibt dabei die Behauptung zur Selbsteinschätzung an z.B.: “Ich kann die Sorte von Feldfrüchten zuverlässig erkennen”.
Um eine neue Frage einzufügen, öffnet man “questions”, geht zum Eintrag “Introspection”, kopiert einen bestehenden Eintrag und fügt die neuen Werte ein.
TODO: Was kann das Modul leisten? Welche Daten werden gewonnen? Was ist dazu notwendig?
Projekt-Dateien sind ein ZIP-Archiv und enthalten eine Project.json-Datei und mehrere .odkbuild-Dateien.
Jede .odkbuild-Datei wird in der App in eine Fragebogenseite übersetzt. Dort werden diese alphabetisch angeordnet. Z.B. erscheinen Seiten die mit a beginnen vor Seiten die mit b beginnen. Deswegen wird empfohlen die Dateinamen mit einer Zahl zu beginnen: 01ErsteSeite.odbuild, 02ZweiteSeite.odkbuild …
Die Project.json folgt dem folgenden Muster:
{
"Project": {
"0": "Projektname auf Deutsch",
"1": "Project in English"
},
"Author": {
"0": "Autor-Bezeichnung auf Deutsch",
"1": "Author in English"
},
"Description": {
"0": "Beschreibung auf Deutsch",
"1": "Description in English"
},
"Secret": null,
"Languages": {
"0": "German",
"1": "English"
},
"ProfilingId": "uniqueProfilingId"
}
"Project", "Author", "Description" und "Languages" sind Listen, bei denen der jeweils der gleiche Index für die selbe Sprache steht. Diese wird in "Languages" festgelegt. "ProfilingId" identifiziert das für dieses Projekt notwendige Profiling (siehe Profiling).
Sprachen werden unterstützt, jedoch muss die "Languages"-Liste in jeder .odkbuild-Datei genau der in der Projects.json-Datei entsprechen.
| Feldname | Unterstützung |
|---|---|
| Data Name | ✔ |
| Label | ✔ |
| Hints | ✔ (komplett) In der App abrufbar über “Hinweis”-Knopf |
| Default Value | ❌ |
| Read Only | ❌ |
| Required | ✔ |
| Invalid Text | ❌ |
| Show question if | ✔ (Einschränkungen siehe “Formeln” weiter unten) |
| Constraint | ❓ (Darf keine Referenzen auf andere Elemente, sondern nur auf sich selbst via der “."-Notation haben. Weitere einschränkungen siehe “Formeln” weiter unten) |
| Constraint Invalid Text | ❌ |
| Calculate | ❌ |
| Feldname | Unterstützung |
|---|---|
| Length | ✔ (komplett) |
| Feldname | Unterstützung |
|---|---|
| Valid Range | ✔ (komplett) |
| Style | ❌ |
| Kind | ❌ |
| Feldname | Unterstützung |
|---|---|
| Range | ✔ (komplett) |
| Kind | ❓ Nur “Full Date” und “Full Date and Time” |
❌ (Time-Element wird nicht unterstützt)
| Feldname | Unterstützung |
|---|---|
| Kind | ❌ |
| Style | ❌ |
Hierzu wird in der App die Kamera geöffnet, damit man ein neues Foto machen kann.
| Feldname | Unterstützung |
|---|---|
| Kind | ❌ |
❌ (Barcode-Element wird nicht unterstützt)
| Feldname | Unterstützung |
|---|---|
| Options | ❓ (“Underlying Value” muss dem 0-basierten Listen-Index entsprechen. Muss also bei 0 starten und immer um 1 erhöht werden) |
| Cascading | ❌ |
| Follow-up Question | ❌ |
| Style | ❌ |
❌ (Select Multiple-Element wird nicht unterstützt)
❌ (Metadata-Element wird nicht unterstützt)
❌ (Metadata-Element wird nicht unterstützt)
❌ (Group-Element wird nicht unterstützt)
Siehe ODK Dokumentation zu Formeln. Wir nutzen NCalc um Formeln auszuwerten. Nach jeder Änderung werden alle unterstützten Formelfelder (“Constraint” und “Show question if”) neu berechnet.
Unterstützte Formelelemente (siehe “OdkBooleanExpresion” Klasse):
Über die von ODK definierten Elemente unterstützen wir weitere Elemente an. Um diese zu nutzen muss man ein Text-Element zum Formular hinzufügen und in den ODK-Namen ("Label") jeder Sprache den Elemententyp schreiben. Beispiel siehe “Kompass”.
Elementyp: compass
Beispiel-Label-Eintrag: "Ausrichtung der Pflanzenreihen{compass}". Der angezeigte Elementenname enthält {compass} dann nicht.
Wert wird als Zahl zwischen 0 und 360 angezeigt und gespeichert.
| Projekt | Projektdatei-Download |
|---|---|
| FieldCampagne | FieldCampagneProject.zip (Stand: 09.03.2021) |
TODO