378 Bilddatensätze, acht Prüfabfragen

Schritte 1 bis 4 sind das Originalprogramm, Stand des Laufs: 30. August 2026. Schritt 5 ist die Ergänzung für dieses Portfolio. Beide Teile sind getrennt gehalten – der Originalcode wurde nicht angefasst.

Die Auswahl ist ausdrücklich nicht „die ersten zwei Treffer". Jedes Foto bekommt Punkte, und jeder Punkt trägt seine Begründung mit in den Bericht. Die Reihenfolge der Kriterien ist die eigentliche Entscheidung – sie legt fest, was was überstimmt.

Danach kommt die Regel, die im Bericht am häufigsten sichtbar wird: Erst wird je Beobachtung das beste Foto genommen, und nur wenn keine zweite Beobachtung übrig bleibt, ein zweites Foto derselben. Deshalb stammen bei allen 189 Arten die beiden Bilder aus verschiedenen Beobachtungen – Prüfabfrage 7 rechnet das nach.

Gegenüber der API verhält sich das Programm zurückhaltend: eine Sekunde Pause zwischen zwei Anfragen, höchstens 50 pro Minute bei erlaubten 60, vier Versuche mit wachsender Wartezeit. Im dokumentierten Lauf kam über 396 Anfragen keine einzige Abweisung wegen Überlastung zurück.

Vier Tabellen. Was in den Quelldaten nicht vorkommt, steht auch nicht im Modell: Ein Anki-Deck mit botanischen Namen kennt keinen deutschen Trivialnamen, und welche Suchvariante am Ende gegriffen hat, hält kein Metadatensatz fest. Zwei leere Spalten mitzuführen wäre die unehrlichere Lösung gewesen.

Der Import ist wiederholbar und nicht additiv: Ein zweiter Lauf legt die Datei neu an, statt Zeilen zu verdoppeln. Fehlende Werte bleiben NULL – nichts wird stillschweigend ersetzt, denn genau diese Lücken sollen die Abfragen ja finden.

Dass die Tabelle observations genauso viele Zeilen hat wie images, ist kein Modellierungsfehler, sondern das Ergebnis der Auswahlregel: Weil je Bild eine eigene Beobachtung gewählt wurde, steht hinter jedem Bild genau eine. Ein Modell, das das nicht abbilden könnte, könnte Prüfabfrage 7 nicht stellen.

Jede Abfrage hat einen Sollwert. Bestanden heißt: Die Abfrage findet nichts. Befund heißt: Sie findet etwas – und das ist dann das Ergebnis, kein Fehler des Programms.

Die acht Abfragen ausführen Prüfbericht (CSV)

Der Download-Bericht des Programms meldet 378 Bilder vorhanden, Ziel 378. Im Bildordner liegen aber 372 Dateien. Die Abfrage, die Metadaten gegen Dateibestand hält, benennt die Differenz:

SELECT i.filename, p.scientific_name, i.license_code
FROM images i
JOIN plants p ON p.plant_id = i.plant_id
WHERE i.file_present = 0
ORDER BY p.scientific_name, i.selected_rank

Es sind nicht sechs beliebige Dateien. Es sind genau die Bilder der drei Arten, die das Programm im Problembericht selbst als REVIEW markiert hat. Spiraea × arguta und Spiraea × vanhouttei fallen bei iNaturalist auf dasselbe Taxon zusammen – ohne Gegenmaßnahme hätten beide Arten identische Fotos bekommen. Das Programm hat das nach dem Durchlauf erkannt, für die zweite Art auf Ersatzfotos ausgewichen und beide Fälle zur Prüfung vorgelegt. Lonicera pileata* wurde auf das breitere Taxon Lonicera ligustrina aufgelöst.

Bei 36 der 189 Arten weicht der Name bei iNaturalist vom Namen im Deck ab. Als Zahl ist das wertlos: Bei 15 davon ist es nur die Schreibweise – das Deck führt Prunus avium* mit einer Merkhilfe, iNaturalist schreibt Prunus avium. Solche Zusätze werden vor dem Vergleich gestrichen, in SQL wie in der Browserfassung nach derselben Regel.

Übrig bleiben 21 Fälle, in denen der Name selbst ein anderer ist. Auch diese sind nicht gleichartig, und genau deshalb bewertet die Abfrage sie nicht:

Die ersten drei Zeilen sind unbedenklich, die letzten beiden nicht – und diesen Unterschied kann keine SQL-Abfrage entscheiden. Sie kann nur die Liste erzeugen, die jemand ansehen muss. Deshalb hat Abfrage 8 als einzige keinen Sollwert und den Status gezählt statt bestanden. Eine Prüfung, die hier ein Urteil fällte, wäre genau die Sorte Automatisierung, die hinterher niemand mehr auffängt.