[FOSSGIS-Talk] Anfrage professionelle Programmierung einer Erweiterung für QGis 2.18.

Fr Jan 5 15:10:03 CET 2018

Hallo Bernd,

Da gehe ich mit Dir einig. Die Daten sollten in den Bildern selber 
gespeichert werden und nirgendwo sonst. So ist garantiert, dass alle 
wesentlichen Infos beim Bild bleiben. ExifTools ist ein wunderbares Tool 
dafür.

Was mir vorschwebt, ist, dass man in OGR einen Provider dafür schreiben 
würde - zum Lesen und Schreiben der EXIF-Daten (vermutlich am Besten 
über das exiftool). Das hätte den grossen Vorteil, dass nicht nur QGIS 
diese Daten lesen und schreiben könnte sondern irgendein GIS. Und in 
QGIS würde es wie ein Shapefile daherkommen - das aber nirgends 
existiert sonder die Daten direkt aus den JPEG Bildern eines Folders 
bezieht und auch wieder dorthin schreibt. Es bräuchte eine Option um 
festzulegen welche Exif-Daten in der Attributtabelle zugänglich sein 
sollen - denn da gibt es hunderte - das wären viel zu viele - und 
vermutlich hat jeder eine andere Vorstellung davon welche EXIF-Daten er 
sehen möchte. Jeder Ordner mit JPEG wäre dann also ein OGR-Layer. Pro 
Ordner hätte man eine Text-Config-Datei in der drinsteht welche 
EXIF-Tags in der Attributtabelle kommen würden.

Es ist nur die Frage wie performant das wäre (ohne Zwischencache). 
Vielleicht braucht es aus Performance-Gründen einen temporären 
Zwischencache (v.a. zum performanten Lesen) der aber beim Schliessen des 
OGR-Layers wieder gelöscht würde.

Das ist nur mal laut gedacht. Man müsste mit einem OGR-Entwickler (am 
Besten Even Rouault) und einem QGIS Entwickler schauen ob das machbar ist.

Wenn die Fotos als OGR Layer ladbar sind, kann es in irgendeinem GIS 
dargestellt und editiert werden. Es braucht auch kein Plugin und würde 
sowohl für QGIS 2 als auch für QGIS 3 funktionieren.

Was meinst Du dazu?

Grüsse,
Andreas

On 05.01.2018 14:28, Bernd Vogelgesang wrote:
> Hi Andreas,
>
> aus der Erinnerung zum Gespräch mit Sylvia und eigenen älteren 
> Überlegungen:
>
> Im Prinzip wäre mit einer Umsetzung der Funktionen des Programmes 
> Geosetter auf QGIS per Plugin ein erster großer Teil der Anforderungen 
> erschlagen. Die bisher verfügbaren Plugins kommen dem bei Weitem nicht 
> nahe.
>
> Für mich liegt der Charme beim Geosetter, dass er mit den ExifTools 
> arbeitet, und die editierten Daten auch per Exif wieder in die Bilder 
> selber rein schreibt. Anders als in QGIS kann man damit leicht und 
> schnell graphisch wesentliche Fotodaten ändern.
> Leider läuft das aber auch nur auf Windows und wird auch nur noch 
> sporadisch weiterentwickelt. Was fehlt ist aber eben auch eine 
> tabellarische Ansicht der relevanten Daten für alle geladenen Bilder.
>
> Ich habe mit vor einigen Jahren mal mit VBA und ExifTools eine Art 
> Bilddatenbank gebastelt, in der die Bilder im Prinzip die 
> Datenbankeinträge selber darstellten.
> Es war mir nämlich unmöglich aus zugesandten Bildern dritter zu 
> ersehen, was darauf überhaupt dargestellt worden war.
> Im Falle des Forstes sieht man da dann halt einen Baum. Aber auf den 
> ersten Blick weiß ja nur der Fotografierende, was da jetzt der 
> eigentliche Informationsgehalt ist.
> Seine richtige Macht spielt das georeferenzierte Bild m.M.n aber erst 
> aus, wenn zu der editierbaren Lage (wegen GPS-Ungenauigkeiten im Wald) 
> auch die Bildinhaltsbeschreibung, bzw. Verschlagwortungen direkt im 
> Bild mit weitergereicht werden können.
>
> Idealer Weise sollte man dann auch noch z.B. Blickrichtung und 
> Entfernung zum Objekt etc. leicht editieren können und zur 
> Wiederverwendung im Bild speichern, so dass daraus resultierende 
> Punktlayer dann auch die tatsächlich gemeinte Lage und nicht den 
> Standort des Fotografen darstellen.
>
> Auf Seiten von Exiftool kann man ja sogar über eigene Profildateien 
> jede nur denkbare eigene Datenstruktur in die Bilder einbauen.
>
> Auf Seiten von QGIS wäre es eben nett, diese Daten von Bildern aus 
> einem Verzeichnis z.B. tabellarisch mit Bildvorschau darzustellen, um 
> aufwandsarm diese Daten zu korrigieren, oder fehlende zu ergänzen (Bei 
> Geosetter nur jedes Bild einzeln nacheinander möglich) und 
> andererseits lagebezogene Daten wie die Position, Blickrichtung, 
> Abstand zum Objekt graphisch mit wenigen Klicks anzupassen und ins 
> Bild zurückzuspeichern.
>
> In dem Fall meines Projektes sollte ich damals eine Fotodokumentation 
> mit über 250 Fotos mit Lagekarten der Fotopunkte von einem 
> Truppenübungsplatz erstellen, auf dem ich selber noch nie gewesen war.
> Ich habe dann eine Exceldatei gebastelt, die auf Knopfdruck die 
> Exifdaten der Bilder eingelesen, und tabellarisch dargestellt hat. Per 
> Mouse-Over über die Tabellenzeile wurde eine Bildvorschau des Fotos 
> eingeblendet.
> Die Kartierer konnten damit selber die Range eintragen auf der das 
> Bild geschossen wurde, den Bildinhalt beschreiben, Datum und Uhrzeiten 
> korrigieren (wegen verstellter Kameradaten damals recht häufig), 
> Blickrichtung angeben usw. etc.
>
> Per Knopfdruck wurden die Änderungen ins Bild zurückgespeicher und aus 
> den Dateinamen wie DSC12437859.jpg les- und sortierbare Dateinamen wie 
> z.B.  RangeNr_Datum_Bildnummer.jpg erzeugt.
>
> Mit einem zweiten Knopfdruck wurde das ganze aus der Exceldatei in 
> eine Worddatei mit Überschriften für die Ranges, den dort geschossen, 
> für den Druck runterskalierten Bildern samt Bildunterschriften, sowie 
> den vorher separat hergestellten Fotostandortkarten geschrieben.
>
> Damals habe ich mir damit zwar keine Zeit gespart, dafür aber 
> unbezahlbare Nerven, da jeder der Beteiligten mit wenigen Knopfdrücken 
> das Endergebnis begutachten, und eventuell entdeckte Fehler selber an 
> der Quelle (also im Bild) ausmerzen konnte.
>
> Das ganze ist jetzt natürlich ein extremes Beispiel der Verwendung 
> einer "Bilddatenbank", aber aus meiner bisherigen Erfahrung ist eine 
> ausschließlich getrennte Datenhaltung von Bild und seinen impliziten 
> Informationen ein ungemein fehleranfälliges Unterfangen. Ein einfaches 
> Verschieben, Umbenennen oder Aufteilen eines Bildordners oder Bildes 
> selbst reicht ja schon, um Bilder und Daten voneinander zu trennen. 
> Und Jahre später hat ein unbeteiligter Dritter dann seine liebe Mühe, 
> sich das Ganze wieder neu zu erarbeiten.
>
> Die Parallelen von meinen Nutzungsszenarien zu Sylvias Wünschen sehe 
> ich darin, dass z.B. nach Jahren Baumstandorte nachkontrolliert werden 
> sollen, die zuvor per Telefonkamera aufgenommen wurden.
> Um die ganzen Daten wie Baumart, Pflanzjahr, Schutzmaßnahmen, 
> Brusthöhendurchmesser etc. etc. nicht nur wieder auf dem 
> Mäusebildschirm des Telefons im Wald bei Regen nachforschen zu müssen, 
> sondern auch schnell einen "fail-save"-Papierausdruck dabei zu haben, 
> wäre eine Fotostandortreportfunktion wie in meinem geschilderten 
> Projekt ein ungemein nützliches Hilfsmittel als Teil einer künftigen 
> "Forst-Fachschale" in QGIS, aber auch darüber hinaus für eine Vielzahl 
> weiterer Anwendungsmöglichkeiten.
>
> Wie der Weg dahin aussehen könnte, vermag ich mangels technischer 
> Kompetenz leider nicht zu sagen, ich wollte aber auf alle Fälle mal 
> das Potential einer schnellen und bequemen Fotodatenverarbeiung im GIS 
> skizzieren.
>
>
> Wer bis hier gelesen hat, kann sich bei mir ein Bier abholen.
>
> Grüße,
> Bernd
>
>
> Am 04.01.2018, 17:12 Uhr, schrieb Andreas Neumann <a.neumann at carto.net>:
>
>> Hallo Sylvia,
>>
>> Diese Anforderung wurde auch schon öfter diskutiert - ob QGIS das auch
>> ohne Plugin unterstützen könnte. Es wurde auch schon diskutiert, ob man
>> dafür einen OGR-Provider (folder-basiert) machen könnte.
>>
>> Was schwebt Dir genau vor?
>>
>>      * QGIS sollte einen Ordner mit geotagged JPEG-Bildern öffnen können
>> und die Bilder lagerichtig darstellen?
>>      * Soll der Ordner überwacht werden, sodass neue Fotos sobald sie in
>> den Ordner kopiert werden gleich dargestellt werden, ohne dass der Layer
>> neu geladen werden muss?
>>      * Soll in der Karte nur ein Punkt dargestellt werden oder das
>> Thumbnail des Fotos selber?
>>      * Wenn nur ein Punkt - soll das Bild per Action zu öffnen sein oder
>> "on mouseover"?
>>      * Sollen die Bilder, falls sie sich überlappen würden wenn die
>> Positionen zu knapp aneinander liegen mit dem Punktverdrängungsrenderer
>> leicht verschoben werden, sodass man alle Thumbnails von Bildern
>> komplett sehen kann?
>>      * Sollen weitere benutzerdefinierte EXIF-Daten (wie Titel, 
>> Filename,
>> Aufnahmedatum, Kameraname, GPSTimeStamp, etc) in der Attributtabelle
>> angezeigt werden?
>>      * Soll - falls in den Bildern vorhanden - auch die Aufnahmerichtung
>> dargestellt werden? (EXIF GPSDestLatitude/GPSDestLongitude resp.
>> GPSImgDirection)?
>>      * Sonst noch was?
>>
>> Mich interessiert das Thema auch einigermassen (privat) - daher kann ich
>> gerne helfen die Spezifikation zu erstellen und einen geeigneten
>> Entwickler zu finden. Ev. kann ich sogar helfen mitzufinanzieren
>> (kleineren Anteil).
>>
>> Zum zeitlichen Aspekt und zur Zielplattform: wenn das ein QGIS
>> Kernfeature (ohne Plugin) werden soll bekommst Du es sicher nicht mehr
>> in QGIS 2.18 (da kommen keine neuen Features mehr) sondern nur in 3.X.
>> QGIS 3.2 kommt frühestens im Juni/Juli 2018. Der Feature Freeze von QGIS
>> 3 war schon.
>>
>> Grüsse,
>> Andreas
>>
>> On 2018-01-04 16:47, Sylvia wrote:
>>
>>> Liebe Liste,
>>>
>>> mit Bernd Vogelgesangs Hilfe bin ich wieder ein Stück weiter, habe 
>>> jetzt
>>> exifread an der richtigen Stelle auf meinem Rechner und konnte in den
>>> letzten Tagen die Erweiterung Photo2Shape ausprobieren  nochmals 
>>> herzlichen
>>> Dank an Bernd.
>>>
>>> Aus der Arbeit mit dieser Erweiterung und dem Telefonat mit Bernd 
>>> resultiert
>>> nun meine Anfrage an die Liste.
>>>
>>> Zuerst das Ziel__
>>>
>>> Wenn mehrere Beteiligten am selben Projekt arbeiten, dann ist es 
>>> immer eine
>>> Überlegung wert, wie die Informationen hin- und hergeschickt werden. 
>>> Der
>>> Aufbau eines WebGis o. ä. ist mit Aufwand und laufenden Kosten 
>>> verbunden und
>>> daher für Kleinwaldbesitzer, für Forstbetriebsgemeinschaften usw. keine
>>> Lösung. Außerdem, und das wiegt fast schwerer, muß jeder QGis bedienen
>>> können, was in der Realität nicht funktionieren wird.
>>>
>>> Eine sinnvolle und effektive Zusammenarbeit wäre über 
>>> georeferenzierte Fotos
>>> möglich. Fast jeder hat ein GPS-taugliches Handy. Jeder kann ohne 
>>> weitere
>>> Schulung ein Foto machen und  verschicken. Ob das das Foto eines 
>>> Polters,
>>> einer Käferfichte, eines Hiebs oder eines zu pflegenden 
>>> Jungbestandes ist,
>>> das spielt keine Rolle. Das Einlesen und Weiterverarbeiten des 
>>> Fotos, die
>>> Übernahme der Information an die richtige Stelle usw. erfolgt an 
>>> zentraler
>>> Stelle von einer geschulten und befugten Person. Einfach, sinnvoll,
>>> effizient  wenn man die Fotos einlesen könnte 
>>>
>>> Daher meine konkrete Anfrage__
>>>
>>> Ich suche jemanden, der professionell eine Erweiterung programmieren 
>>> kann
>>> für QGis 2.18., die bequem und unkompliziert georeferenzierte Fotos 
>>> einlesen
>>> und anzeigen kann UND diese Erweiterung muss unter der 
>>> Standardinstallation
>>> von QGis lauffähig sein.
>>>
>>> Ist so etwas programmiertechnisch überhaupt machbar? Wer würde so etwas
>>> professionell machen?
>>>
>>> Ich habe für mich ein Pflichtenheft zusammengestellt, das wir ggf.
>>> besprechen könnten. Und dann könnte man abschätzen, wieviel so eine
>>> Programmierung kosten würde und wie schnell so etwas fertig sein 
>>> könnte.
>>>
>>> Ich freue mich auf eine Antwort,
>>>
>>> viele Grüße
>>>
>>> Sylvia Welschof
>>>
>>> -- 
>>> ....................................................................
>>> FOSDEM'18  3. und 4. Februar 2018 in Brüssel
>>> https://fosdem.org/2018/
>>>
>>> FOSSGIS 2018, die Konferenz für Open Source GIS mit OpenData und
>>> OpenStreetMap in Bonn!
>>> 21.-24. März 2018 an der Universität Bonn
>>> https://fossgis-konferenz.de/2018/
>>> 18.-25. März OSGeo Code Sprint im BaseCamp Bonn
>>> https://wiki.osgeo.org/wiki/OSGeo_Code_Sprint_2018
>>>
>>> FOSSGIS Veranstaltungen 2018
>>> https://www.fossgis.de/node/306
>>>
>>> FOSSGIS e.V, der Verein zur Förderung von Freier Software aus dem
>>> GIS-Bereich und Freier Geodaten!
>>> https://www.fossgis.de/ https://twitter.com/fossgis_eV
>>>
>>> ____________________________________________________________________
>>> FOSSGIS-Talk-Liste mailing list
>>> FOSSGIS-Talk-Liste at fossgis.de
>>> https://lists.fossgis.de/mailman/listinfo/fossgis-talk-liste
>
>