[QGIS-DE] Bugfixing für Überlagerungswerkzeuge und Join Attributes fördern?

[Bernhard Ströbl]

Hallo Thomas,

danke für die gute Zusammenfassung. Ich möchte einzelne Punkte aus 
meiner eigenen Erfahrung als Anwender und Programmierer von zwei 
Processing-Algorithmen einbringen:

ad a) Die Frage, ob die Algorithmen per se funktionieren, kann man - 
Matthias Kuhn hat darauf schon hingewiesen - am besten mit Tests 
rauskriegen. Die benutzen aber nur ganz wenige korrekte Geometrien. 
Diverse gemeldete Defekte waren nämlich auch auf Fehler in den 
Eingabelayern zurückzuführen (z.B. 2.5D Shapefiles, Geometriefehler in 
den Eingabeshapes), d.h. eine Übersicht muß diese Fehlermeldungen 
aussortieren, weiterhin gab es auch Probleme mit sehr großen 
Eingabelayern (Speicherüberlauf, bzw. sehr lange Laufzeiten), was auf 
eine nicht-ideale Implementierung hinweist. IMHO ist ein Hauptproblem, 
dass insbesondere Shapedateien sich anzeigen lassen, obwohl sie Fehler 
enthalten, das ist vielen Benutzern nicht bewusst und ich wüsste nicht, 
wie man das ändern sollte: GIS-Daten und GIS-Datenverarbeitung sind 
komplexe Aufgaben, die, zum sie korrekt auszuführen, einiges an 
Verständnis voraussetzen.

ad c) ich dachte, es geht ums Processing-Framework und um die 
QGIS-Algorithmen darin

ad e) gute Frage! Vielleicht kann das jemand beantworten, der QGIS 
Enterprise hat?

ad f) -1, Verarbeitungswerkzeuge müssen funktionieren, Punkt.

IMHO kann Deine Fragen niemand zusammenfassend beantworten, man müsste 
sich also auf die Suche machen.

Ich selbst mache Geoverarbeitung entweder nativ in GRASS (Hauptvorteil 
ist das topologische Datenmodell => keine fehlerhaften Geometrien, keine 
Topologiefehler) oder in PostGIS (meist als Views mit dem Ziel der 
Redundanzfreiheit) oder ich nutze natürlich meine eigenen beiden 
Algorithmen :-)

Bernhard

Am 25.05.2016 um 16:12 schrieb Thomas Schüttenberg:
> Hallo Zusammen,
> für die Behebung der hier seit einiger Zeit diskutierten Probleme rund um Bearbeitungswerkzeuge und Tabellenverknüpfungen benötigen wir eine Startegie, die eine Reihe von notwendigen Fragen klärt:
>
> a) welche Funktionen sind genau deffekt?
> b) sind diese Fehler bereits ausreichend dokumentiert und/oder gemeldet?
> c) welche Beziehungen, Abhängigkeiten oder bestehen zum Processing-Framework?
> d) gibt es diesbezüglich Resonanz von Seiten des QGIS-Projektes bzw. der Entwickler?
> e) stellen die von Sourcepole für QGIS Enterprise überarbeiteten Vektoranalyse-Tools eine Lösung für die Probleme dar?
> [ggf. f) gibt es zusätzliche Möglichkeiten der Anwenderschaft zu helfen: Aufzeigen (Webseite) alternativer, paralleler Arbeitsweisen/Werkzeuge ohne Fehler?]
>
> Erst wenn diese Punkte geklärt sind, kann der Verein IMHO als Auftraggeber, (Co-)Finanzierer oder Crowdfunding-Initiator tätig werden, denn dafür ist in jedem Fall die konkrete Beschreibung unseres Vorhabens Voraussetzung. Ich würde mich freuen, wenn jemand diese wichtige Vorarbeit übernehmen würde. [Zu d): mein Schreiben an qgis-developer-ML ergab nur den Rat eine Testinfrastuktur für die Geoverarbeitungswerkzeuge zu etablieren.]
>
> Aufbauend auf diese Analyse können wir entweder eine Liste von Bugfixes beauftragen bzw. Angebote dazu einholen (ähnlich meinem Vorschlag zur Doku-Übersetzung, der anscheinend auf schweigende Zustimmung stößt) oder die Sourcepole-Lösung freikaufen oder etwas anderes....
>
> Beste Grüße
> Thomas
>
>
>> Otto Dassau <dassau at gbd-consult.de> hat am 9. Mai 2016 um 16:45 geschrieben:
>>
>>
>> Hallo Thomas,
>>
>> hat sich hierzu etwas Neues ergeben?
>>
>> Grüße Otto
>>
>> Am Tue, 12 Apr 2016 16:31:18 +0200 (CEST)
>> schrieb Thomas Schüttenberg <thomas at qgis.de>:
>>
>>> Hallo Leute,
>>>
>>> ich teile Eure Ansicht, dass diese Fehler dringend behoben werden sollten
>>> und dass eine langfristige / benutzerfreundliche Lösung erstrebenswert ist.
>>>
>>> Da mittlerweile verschiedene mögliche Lösungsansätze im Raum stehen (grob
>>> gesagt punktuelles Bugfixing vs. Generalüberholung) habe ich mir erlaubt,
>>> unsere Diskussion auf die QGIS-dev Liste zu lenken, um dort mal nach evt.
>>> Plänen bezüglich weiterer Konsolidierung der Geoverarbeitungswerkzeuge
>>> etc. zu fragen, auch weil zum kursierenden Sourcepole Angebot keine
>>> abschließende Entscheidung/Meinung von QGIS.ORG bekannt zu sein scheint
>>> (also ob man es überhaupt wollte, oder ob es nur an Geld liegt, etc.).
>>>
>>> Gruß
>>> Thomas
>>>
>

-- 
Bernhard Ströbl
Anwendungsbetreuer GIS

Kommunale Immobilien Jena
Am Anger 26
07743 Jena

Tel.: 03641 49- 5190
E-Mail: bernhard.stroebl at jena.de
Internet: www.kij.de


Kommunale Immobilien Jena
Eigenbetrieb der Stadt Jena
Werkleiter: Karl-Hermann Kliewe


__________ Information from ESET Mail Security, version of virus signature database 13547 (20160526) __________

The message was checked by ESET Mail Security.
http://www.eset.com