Espressione di QGIS - overlay_intersects

QGIS QGIS-it-user
1

La Funzione in oggetto è parecchio interessante e ci permette di fare acrobazie in QGIS.

La funzione attualmente è così definita:

overlay_intersects(layer[,expression][,filter][,limit][,cache:=false][,min_overlap][,min_inscribed_circle_radius][,return_details][,sort_by_intersection_size])

per maggiori dettagli vai qui

Ho notato che ha un funzionamento anomalo (forse bug) quando utilizzo l’espressione per determinare la sovrapposizione tra poligoni (topologicamente corretti).

La sovrapposizione tra poligoni può restituire:

  1. una linea (quando sono perfettamente adiacenti lungo un lato)
  2. un poligono.

Nel caso di sovrapposizione che restituisce una linea, ho notato un comportamento strano, ovvero, se la sovrapposizione è caratterizzata da un solo segmento, allora calcola correttamente la lunghezza; ma nel caso la sovrapposizione avesse più segmenti, per esempio una linea a forma di L, restituisce solo la lunghezza del segmento più lungo.

Sotto un esempio:

image
image1161×768 141 KB

Se la sovrapposizione tra i poligoni restituisse poligoni, allora noto altra anomalia, ovvero, i calcoli delle aree di sovrapposizione sono corretti solo se i poligoni sono definito Polygon, nel caso fossero MultiPolygon, restituiscevalori errati.
Sotto un esempio di sovrapposizione con MultiPolygon:

image
image1146×859 89.3 KB

La selezione(colore giallo) è un multipoligono con due parti) l’area calcolata è solo quella indicata dalla freccia

Allego un progetto di esempio (usare le viste per visualizzare correttamente i due casi)
progetto_overlap.zip (35.9 KB)

Se qualcuno avesse tempo e voglia di guardare, magari poi, apriamo una issue.

saluti

2

Ciao Salvatore,
non conoscevo l’opzione return_details della funzione overlay_intersects.

L’opzione è stata introdotta, insieme a sort_by_intersection_size, da Alessandro Pasotti con PR Overlay intersects sort by intersection size by elpaso · Pull Request #46683 · qgis/QGIS · GitHub a partire da QGIS 3.24.

Ho letto la descrizione dell’opzione, ma da essa non sarei riuscito a capire a cosa corrisponde il valore di overlap restituito dalla funzione se non avessi visto gli esempi fatti da te in questo post.

Quindi sono andato a leggere il codice sorgente della funzione e ho capito perché ottieni tali risultati: quando l’intersezione tra la geometria della feature corrente e una delle geometrie del layer indicato nella funzione è una geometria composta da più parti (ciò può avvenire anche quando i layer non sono multipart), allora il valore di overlap restituito dalla funzione per quella intersezione è il valore della lunghezza o dell’area solo della parte più lunga o più grande.

Questo comportamento mi pare abbastanza controintuitivo e non capisco perché Alessandro Pasotti abbia progettato tale opzione per restituire solo il valore della parte più lunga o più grande dell’intersezione e non dell’intera geometria risultate dall’intersezione.
Comunque sia, tale comportamento non è esplicitato nella descrizione della funzione.

Mi pare che la funzionalità abbia comunque almeno un bug: infatti, quando la geometria risultante dall’intersezione è composta da parti che non sono dello stesso tipo geometrico, per esempio un poligono e una linea, la funzione non restituisce alcun risultato se è impostata l’opzione return_details, mentre restituisce il risultato corretto se non è impostata tale opzione.

3

Ciao Andrea,
dopo la tua analisi, cosa consigli di fare, visto che anche tu hai notato almeno un bug?

saluti

4

Penso sia utile creare un bug report.

5

Ho aperto una Issue

saluti

1 Like
6

Sembra che Alessandro Pasotti abbia sistemato il problema che avevo segnalato, anche se avevo capito che NON lo considerava un bug e che non lo avrebbe risolto.

Ho scaricato e testato la builds [1] ed ora :slight_smile:

image
image1130×691 92.7 KB

grazie mille elpaso

[1] overlay_intersects: flatten collections and filter by type by elpaso · Pull Request #59477 · qgis/QGIS · GitHub

7

Ciao Salvatore,
Alessandro ha modificato solo parzialmente la funzionalità.

Se verifichi il tuo esempio per l’intersezione di due poligoni che genera un poligono composto da più di una parte, vedrai che il valore di ‘overlap’ restituito dalla funzione è sempre quello di prima, cioè quello della parte più grande.

Inoltre, benché nel tuo l’esempio, relativo all’intersezione che genera una linea composta da più segmenti consecutivi, adesso la funzione restituisce il valore di ‘overlap’ dell’intera linea, potrai notare che se la linea di intersezione non è continua ma è effettivamente formata da due parti separate, la funzione restituisce il valore di ‘overlap’ solo della parte più grande come nel caso precedente.

image
image639×463 49.8 KB

8

Ho appena testato, hai ragione.

Ma secondo te, è un comportamento intuitivo dell’espresione? per me no!

Poi, questa implementazione è molto personalizzata (risolve un caso d’uso dell’azienda che ha commissionato l’opzione) e questo non si dovrebbe fare nel core di QGIS, ma tramite plugin.

grazie

9

Ha successivamente deciso di modificare parzialmente la funzionalità dopo che ho mostrato alcune criticità e incongruenze dell’implementazione.

Sono d’accordo con te.

Evidentemente, le tre persone (compreso Nyall Dawson) che hanno revisionato il codice non si sono accorte dei problemi che avrebbe potuto creare quel tipo di implementazione non sufficientemente generale, ma troppo particolare. Non so se si siano rese conto del fatto che la funzione avrebbe restituito solo il valore di overlap della parte più grande.

Se la documentazione avesse esplicitamente indicato tale comportamento, molto probabilmente non l’avresti considerato un bug (tranne il problema con le linee con più segmenti consecutivi, il quale è dovuto ad un comportamento della libreria GEOS che io considero un bug e che ho segnalato Intersecting LINESTRINGs or POLYGONs wrongly creates MULTILINESTRING with multiple parts although not needed · Issue #1193 · libgeos/geos · GitHub, e per il quale Alessandro ha introdotto un workaround nella funzione in QGIS).

Considera anche che tale comportamento della funzione è presente a partire da QGIS 3.24, cioè da ormai quasi 3 anni.
È probabile che, fino ad ora, solo pochissimi utenti abbiano utilizzato tale funzionalità o forse nessuno, tranne, se non ho capito male, l’azienda per cui lavorava Andreas Neumann.
Tuttavia penso che ormai non sia più possibile modificarne il funzionamento.

La cosa che si potrebbe fare senza modificare il comportamento corrente, è richiedere che la funzione si comporti ANCHE come a noi sembra più corretto: per esempio aggiungendo un’ulteriore opzione per decidere se il valore di overlap restituito debba essere quello della parte più grande (di default, per mantenere la retro-compatibilità), oppure dell’intera geometria, oppure (per completezza) della parte più piccola.

1 Like
10

Sono d’accordo con te.

Secondo te ci vuole molto tempo per implementarlo?
è una cosa molto complessa aggiungere altra opzione?

saluti

11

Ciao Salvatore,
scusami… mi ero dimenticato di rispondere.
In realtà non ci vuole molto ad aggiungere una nuova opzione, come ipotizzata nei messaggi precedenti, se essa deve esclusivamente modificare il valore restituito nella chiave “overlap”.

Tuttavia guardando il codice sorgente e il comportamento di altre opzioni della funzione per come è stata progettata precedentemente, non sono sicuro del modo corretto di implementarla.

Per esempio, la funzione aveva già l’opzione “min_overlap” che opera sulle singole parti e non sull’intera geometria multipart (il che è già indicato nella documentazione).

Così come aveva già l’opzione “min_inscribed_circle_radius” che ugualmente opera sulle singole parti (come già indicato nella documentazione) e per la quale non si può operare sull’intera geometria multipart.

Poi, oltre al valore della chiave “overlap”, anche il valore della chiave “radius” è calcolato alla stessa maniera. Tuttavia per quest’ultimo non si può operare sull’intera geometria multipart.

Quindi, adesso ho l’impressione che aggiungere una nuova opzione che modifichi esclusivamente quale valore debba essere restituito nella chiave “overlap”, possa risultare in una incoerenza nel funzionamento delle varie opzioni già presenti…

12

Peccato, occasione persa per QGIS,
grazie per il tempo che ci hai dedicato.

saluti

13

Fammi sapere se ti viene in mente quale possa essere l’approccio più logico / intuitivo per fare in modo che la nuova opzione sia armonizzata con il comportamento attuale delle varie opzioni già esistenti o se pensi che la nuova opzione possa intervenire solo sul valore restituito dalla chiave “overlap” senza creare incoerenze.

Chiaramente una nuova opzione non potrebbe essere introdotta prima di QGIS 3.42.

Peraltro, per ora la PR di Alessandro Pasotti non è stata ancora revisionata.

A presto.

Andrea

14

Per me il caso d’uso spiegato da Pasotti [1] ha senso solo per chi lo ha commissionato, non credo abbia altro uso pratico.
Quindi per me andrebbe tutto smantellato per renderlo di uso generale e non particolare come è adesso.

Non ci perderei più tempo.

grazie di nuovo Andrea.

saluti

[1] QGIS Expression - overlay_intersects · Issue #59408 · qgis/QGIS · GitHub