Marcel C. Hagner

Verfasste Forenbeiträge

Ansicht von 2 Beiträgen - 1 bis 2 (von insgesamt 2)
  • Autor
    Beiträge
  • Marcel C. HagnerMarcel C. Hagner
    Teilnehmer

    Lieber Florian,

    Danke für deine weiteren Rückfragen und das Interesse. Ich gebe mir Mühe, alles bestmöglich zu beantworten. Wie schon gesagt, wir sind noch in der Entwicklung und auf der Suche nach Optimierungsvorschlägen.

    1. Die Alpha kommt nächste oder übernächste Woche bei uns an. Diese wird zunächst nicht frei zugänglich sein. Später wird sie dann über einen Store beschränkt verfügbar sein. Die App ist ja auch sehr speziell auf unsere Bedürfnisse in BaWü zugeschnitten, wir wären aber bereit, eine erweiterte Version auf unsere Kosten entwickeln zu lassen, wenn klar ist, ob Bedarf an der App herrscht und bekannt ist, welche Einträge/Daten benötigt werden. Das Grundprogramm ist ja vorhanden.

    2. Der Abstand ist natürlich abhängig von der Größe des Displays, optischen Variablen (Auflösung, Sensor etc.) und der Winkel, mit dem das Display fotografiert wird. Wir planen, mittels einer im normalen Einsatz befindlichen ca. 20 MP Spiegelreflex mit 18-55mm Objektiv, das Display in ca. 25-35 cm abzufotografieren. Eine Hand löst die Kamera aus, eine Hand hält das Tablet. Oder das Tablet liegt auf einem Tisch/Boden/Koffer.
    Wie das in der Praxis klappt, testen wir ab übernächster Woche.

    3. Zu Beginn arbeiten wir mit unseren Standard-Samsung Doku-Tablets (Samsung Tab Active II oder III), der Plan war aber von Anfang an, mit wasserfesten Touch-E-Ink-Readern/Displays zu arbeiten. Die Samsung-Geräte sind super für die Feldarbeit, nur das Display ist natürlich eine Schwachstelle bei starker Sonneneinstrahlung.

    Unsere Tablets haben eine wenig-spiegelnde Displayschutzfolien. Aber es stimmt: der Aufnahmewinkel ist entscheidend, da eine Spiegelung im QC-Code Bereich den Leseerfolg drastisch senkt. Das hatten wir durch erste Tests bereits schnell feststellen müssen. Wir haben aber noch zwei weitere Absicherungen eingeplant: zusätzlich zum QR-Code wird ein 128-Bit Barcode erzeugt und die Daten werden noch als Reintext dargestellt. Sollte also der QR-Code nicht lesbar sein, wird der Barcode zu Rate gezogen und im aller letzten Fall kann die Informationen händisch abetippt werden.
    Eine andere Idee ist, den QR-Code nicht Einzel und möglichst groß, sondern mehrere Male exakt gleich “dupliziert” darzustellen, damit Spiegelungen in Teilbereichen des Displays ignoriert werden können. Da kommt aber wieder das Thema Displayauflösung und Schärfe der Aufnahme auf. Wenn die Codes zu klein sind, reicht vermutlich die Auflösung bei unseren Tabelts nicht aus.

    Das Konzept ist, mit den DSRL-Kameras die QR-Codes händisch abzufotografieren und direkt danach die gewünschte Bilderreihe aufzunehmen, zu dem die Informationen des QR-Codes gehören. Es gibt auch noch an anderen Stellen Schwierigkeiten, vor allem was die weitere Verarbeitung der Bilder mittels eines Pythonskripes angeht, die meisten hat mein Kollege aber bereits gemeistert.

    Ich hoffe, das war alles verständlich.

    Viele Grüße,
    mARCel

    Marcel C. HagnerMarcel C. Hagner
    Teilnehmer

    Hallo Florian,
    Hallo Agnes,

    vielen Dank für die rasche Rückmeldung. Es freut mich, dass das Thema passt, auch wenn es weniger um analytische Aspekte und deren Automatisierung geht.

    Ist der QR-Code-Generator einfach per Eingabe zu bedienen?

    Wir haben wie bereits erwähnt, über eine Firma, die Android-Apps entwickelt, eine Eingabemaske designen und programmieren lassen, die alle wichtigen Grabungs-Daten wie z.B. Befundnummer, Profilnummer, Planumsnummer, Blickrichtung, Fotograf, Datum sowie ein Bemerkungsfeld als Formular erhält. Bis auf den Inhalt des Bemerkungsfeldes (um die Komplexität des QR-Codes zu verringern), werden alle Informationen dann in einen QR-Code umgewandelt. Und gleichzeitig in einer Liste im Hintergrund gespeichert.
    Der QR-Code wird, glaube ich, über eine Open-Source-Lösung für Android-Apps erzeugt, dass müsste ich nochmals nachfragen.

    Welches Export-Format werden die Fotolisten bei dir bekommen?
    Wir arbeiten ausschließlich mit *.csv im UTF8 bwz. 16-Format. *.csv-Dateien sind auch für Grabungsfirmen in BaWü vorgeschrieben.

    Mit der Automatisierung von Prozessen kann man auch gewährleisten, dass das Ergebniss standardisiert wird und dann hat man nicht das Problem dass die vorhandenen Daten uneinheitlich sind.

    Stimmt! Daher haben wir z. B. die Eingaben auch so beschränkt, dass das Format stimmt mit z.B. führenden Nullen (Befund 0011 nicht 11) und kein wichtiges Feld ausgelassen werden kann.

    Das Ganze ist natürlich auf die Vorgaben unserer Landesdenkmalpflege zugeschnitten. Eine flexiblere Variante wäre aber sicherlich möglich.

    Danke nochmals. Ich freue mich über eine rege Diskussion!

    Viele Grüße,
    mARCel

Ansicht von 2 Beiträgen - 1 bis 2 (von insgesamt 2)