[FOSSGIS-Talk] QGIS 3.18.1: Nächster Nachbar

Di Apr 13 17:44:07 CEST 2021

Aufgrund eines aktuellen Projektes „durfte“ ich mich nun auch mit 
nächsten Nachbarn beschäftigen. Somit kam die Anfrage von Michael 
ganz gelegen, um sich der Sache einmal intensiver zu widmen. 

Der Vermutung von Thomas, dass es sich um Punktlayer bei Michaels 
Problem handelt, kann ich mich nur anschließen, da schließlich auch 
die Punkt basierte Distanzmatrix zum Einsatz kam. Jedoch kann ich 
beim Einsatz von Punktlayern keine Unterschiede in den Ergebnissen 
zwischen der Funktion 'Abstand zum nächsten Knoten (Linie zu 
Knoten)' und der Hub Analyse vom MMQGIS Plugin feststellen.

Bei mir dienten jedoch sowohl Polygone wie auch Linien als 
Datengrundlage und da sah die Sache schon gleich ganz anders aus. 
Bei Verwendung von zwei Polygonlayern kam es tlws. zu erheblichen 
Abweichungen.

Wie der Name von 'Abstand zum nächsten Knoten (Linie zu Knoten)' 
schon sagt, wird eine Linie zwischen Knoten gebildet. Doch während 
sich die Hub-Tools von MMQGIS auf den Zentroiden stützen, berechnet 
'Abstand zum nächsten Knoten (Linie zu Knoten)' einen anderen Punkt 
innerhalb der Ausdehnung der Eingangspolygone (bbox). Ein Grund, 
warum es zu Abweichungen kommen kann.

In der Abbildung im Anhang (siehe Link unten) wird die Lage der 
Verbindungsknoten inkl. "Hub-Verhalten" veranschaulicht. Weiße 
Kreise zeigen die Zentroide der Polygone an. Die roten Flächen 
stellen die Naben dar (mit Zahlenangabe), blau die Speichen (mit 
Buchstabenkennzeichnung), um im Hub-Jargon zu bleiben. Rot-
gestrichelte Linien mit Distanzangabe unterhalb entsprechen dem 
'Abstand zum nächsten Knoten (Linie zu Knoten)' und die orange-
gestrichelten mit Distanzangabe oberhalb der Hub-Berechung mit 
MMQGIS. Als Zusatz kommen noch die grünen Linien mit Distanzangabe 
auf der Linie ins Spiel: diese resultieren aus einer Berechnung mit 
der räuml. SQL-Funktion 'ST_Shortest_Line()'.

Spätestens bei der abgegriffenen Flächenkombination 4e lassen 
Zweifel an der Zuverlässigkeit der Funktion 'Abstand zum nächsten 
Knoten (Linie zu Knoten)' beim Einsatz mit Polygonen aufkommen. 
Während die berechnete Verbindungslinie von 4 auf e eine Distanz von 
knapp 3274m aufweist, misst das Messen-Werkzeug zwischen 2 und e 
eine kürzere Entfernung von 2997m zwischen den berechneten Knoten 
der Funktion.

Die von Thomas ins Feld geführte Funktion 'Attribute nach nächstem 
verknüpfen' liefert die gleichen Flächenpaarungen mit gleicher 
Entfernung wie 'ST_Shortest_Line()'. Allerdings werden keine Linien, 
sondern die Eingangspolygone mit neuen Attributen erstellt. Geht man 
den vorgeschlagenen Weg mit 'Durch Linien verbinden' weiter, so 
erhält man Verbindungslinien, die den jeweiligen 'Punkt auf 
Oberfläche' als Start- bzw. Endpunkte haben, also nicht die kürzeste 
Linie zwischen den Polygongrenzen. 

Wer allerdings die Verbindungslinie zwischen den Polygonen benötigt, 
kann sich diese über die neuen Attribute 'feature_x/y' und 
'nearest_x/y' selbst mit dem Geometrie-Generator zusammenbauen. Was 
für ein Umstand.

Zuverlässig und einfacher und auch in ein Modell-„Workflow“ 
integrierbar geht‘s mit 'SQL-Anweisung ausführen' (QGIS Version, 
nicht gdal). Die beiden Eingangslayer auswählen (Geometrietyp spielt 
keine Rolle) und folgenden Code in den Editor eintragen:
--Code-Start>

select a.pk, b.pk, 
min(st_distance(a.geometry, b.geometry)) as laenge, 
st_shortestLine(a.geometry, b.geometry) as geom 
from input1 as a, input2 as b 
group by a.pk

--Code-ende<

Erklärung: es werden die ID-Spalten („pk“ ) beider Eingangslayer, 
die minimal kürzeste Distanz zwischen zwei Geometrien und die 
kürzesten Linien zwischen den Eingangslayern selektiert und nach der 
Objektkennung des als Speichen fungierenden Layers gruppiert, so 
dass nur eine Linie von jedem Objekt des Speichenlayers 
zurückgegeben wird. 

Hierbei ist auf die Reihenfolge der Eingangslayer zu achten, da 
diese im Editor über „inputX“ angesprochen werden. Liegt der 
Nabenlayer in der Mehrfach-Layerauswahl über dem Speichenlayer, so 
ist der Alias (durch 'as' deklariert) zu vertauschen, ergo: 
from input1 as b, input2 as a.

Der Name der ID und der Geometriename müssen entsprechend angepasst 
werden. Für ID wird meist fid (gpkg), ogc-fid, pk (beide Spatialite) 
verwendet. Viele Shape-Dateien kommen ohne ID daher, also nach gpkg 
oder Spatialite umwandelt.

Weitere benötigte Attribute können direkt im Code eingebunden 
werden. Wer sich mit SQL jedoch nicht auskennt, kann im Nachgang 
über die Objektkennungen weitere Attribute verknüpfen.
Ein gewichtiger Vorteil bei diesem SQL basierten Ansatz besteht in 
der Unabhängkeit gegenüber dem Geometrietypen. Linien und Flächen 
werden genauso zuverlässig abgegriffen wie Punktgeometrien. Zudem 
lassen sich benötigte Attribute direkt einbinden (SQL-Kenntnisse 
vorausgesetzt).

Grüße

Bernd

Am Freitag, 9. April 2021, 12:00:02 CEST schrieb fossgis-talk-liste-
request at fossgis.de:

> Meldungen des Tages:
> 
>    1. Re:  QGIS 3.18.1: Nächster Nachbar (Thomas B)

> Hallo auch,
> um mal kurz meinen "Senf" dazuzugeben:
> 
> Warum die Algorithmen unterschiedliche Ergebnisse liefern ist 
> "aus der Ferne" schwer zu sagen.
> 
> Ist denn der räumliche Index der Layer aktuell?
> Je nachdem ob der jeweilige Algorithmus selbst einen erzeugt oder
> den bestehenden nutzt könnte ein nicht korrekter räumlicher Index
> eventuell Probleme machen.
> 
> ( Da ich vermute, dass beides Punktlayer sind dürfte auch die Art
> der Entfernungsmessung nicht ins Gewicht fallen. Der Algorithmus
> "Abstand zum nächsten Knoten" misst ja die kürzeste Entfernung
> explizit zum Zentrum eines Objektes, was z.B. bei einem
> Ziel-Polygon einen Unterschied macht zur kürzesten Distanz zum
> nächsten Punkt auf dem äußeren Ring. )
> 
> Aber genug der Kaffeesatz-Leserei.
> 
> Es gibt in QGIS 3.18 ja noch die Algorithmen "Attribute nach
> nächstem verknüpfen" und analog zum MMQGIS-Plugin einen
> Algorithmus "Durch Linien verbinden".
> Vielleicht klappt es mit einem der beiden Algorithmen besser?
> 
> Grundsätzlich könnte man das MMQGIS-Plugin schon auch abseits der
> GUI ansprechen aber das fände ich relativ kompliziert, da man
> dann ja manuell alle möglichen Parameter mit übergeben muss.
> 
> Von der Syntax her wäre das grob:
> 
> 
> from mmqgis.mmqgis_library import mmqgis_hub_lines
> 
> mmqgis_hub_lines( notwendige Argumente hier... )
> 
> # 8 benötigte Parameter der Funktion:: 'hub_layer',
> 'hub_name_field', 'spoke_layer', 'spoke_hub_name_field',
> 'allocation_criteria', 'distance_unit', 'output_geometry' und
> 'output_file_name'
> 
> 
> Viele Grüße,
> Thomas
> 
> 
> 
> Am Do., 1. Apr. 2021 um 20:00 Uhr schrieb Dr. Michael Hälsig <
> 
> michael.haelsig at online.de>:
> > Hallo,
> > ich habe Oberzentren und Mittelzentren, und möchte die
> > Mittelzentren an das
> > nächstliegende Oberzentrum anbinden.
> > 
> > Der Algorithmus 'Abstand zum nächsten Knoten (Linie zu Knoten)'
> > aus der Werkzeugkiste liefert auch *weitgehend* passende
> > Ergebnisse, der Algorithmus 'Distanzmatrix' mit k=1 das gleiche
> > - weitgehend passende- Ergebnis. Allerdings sind einige
> > Mittelzentren an weiter entfernte Oberzentren
> > angebunden, was ich nicht verstehe. Es geht um Distanzen von
> > 1.400 und 1.900
> > m, kann also nicht an Rundungsfehlern oder unterschiedlicher
> > Distanzberechnung
> > liegen.
> > 
> > Der Algorithmus 'Create Hublines / Distance' aus dem Plugin
> > MMQGIS liefert mir
> > *genau* das richtige Ergebnis. Er hat allerdings den Nachteil
> > für mich, dass
> > ich ihn nicht in einen Workflow, wie die anderen Algorithmen,
> > einbinden kann.
> > 
> > ==> Wieso liefern die Algorithmen unterschiedliche Ergebnisse?
> > Was übersehe
> > ich - oder wo schaue ich nicht genau hin?
> > 
> > ==>  Gibt es (alternativ) eine einfache Möglichkeit, den 'Create
> > Hublines' Algorithmus aus MMQGIS in einen Workflow einzubinden?
> > 
> > Vielen Dank für Tipps!
> > Michael Hälsig
> > 
> > --
> > Dr. Michael Hälsig
> > Diefenbachstr. 9
> > 81479 München
> > 
> > Tel: +49 89 79 199 563
> > Mobil: +49 171 333 7558
> > 
> > 
> > --
> > ................................................................
> > .... FOSSGIS Veranstaltungen
> > https://www.fossgis.de/news/fossgis-events/
> > 
> > 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
> 
> ------------------------------
> 
> Subject: Fusszeile der Nachrichtensammlung

-- 
Ihnen eine gute Zeit

Bernd Marcus
__________________________________

GISwana - Datentektonik

Am Steneberg 10 | D-37133 Friedland

T: +49 (0)5504 949 844 7
M: +49 (0)176 816 991 64
@: bmarcus at giswana.de
U: https://www.giswana.de/
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : vergleich_QGISknotenabstand_MMnearestHub_SQLshortestLine.png
Dateityp    : image/png
Dateigröße  : 79798 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.fossgis.de/pipermail/fossgis-talk-liste/attachments/20210413/39da61f1/attachment.png>