Salve, ho notato che la funzione “aggregate” con la variabile @parent non funziona se i due layer hanno SR differenti. Prova fatta sulla versione 3.4.5 (windows 10).
Francamente non ricordo se fosse così anche nelle precedenti, cioè, è normale?
Martina
marti_ wrote
Salve, ho notato che la funzione "aggregate" con la variabile @parent non
funziona se i due layer hanno SR differenti. Prova fatta sulla versione
3.4.5 (windows 10).
Francamente non ricordo se fosse così anche nelle precedenti, cioè, è
normale?
Ciao Martina,
che io sappia è stato sempre cosi, cioè i due layer devono avere stesso
EPSG.
Che sia normale non lo so, si dovrebbe chiedere a Nyall oppure a Matthias
[0]
[0]
http://changelog.qgis.org/en/qgis/version/3.0.0/#expose-parent-variable-aggregate-functions
-----
https://pigrecoinfinito.wordpress.com/
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Italian-User-f5250612.html
Ciao,
certo che è normale !
Stiamo parlando di operazioni geospaziali (come appunto aggregate) tra entità (i layer) che devono essere espressi nello stesso SR.
Saluti
Nino
Il lun 4 mar 2019, 18:58 Martina Savarese <martina.savarese@gmail.com> ha scritto:
Salve, ho notato che la funzione “aggregate” con la variabile @parent non funziona se i due layer hanno SR differenti. Prova fatta sulla versione 3.4.5 (windows 10).
Francamente non ricordo se fosse così anche nelle precedenti, cioè, è normale?
Martina
QGIS-it-user mailing list
QGIS-it-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-it-user
Grazie,
avevo un caso in cui dovevo verificare la corretta ubicazione di un layer punti (con un dato SR e con un campo striga contenente il nome del comune), rispetto a un layer poligonale di comuni con altro SR e stesso campo. Allo scopo di tale verifica ho pensato di poter utilizzare o l’algoritmo “Unisci attributi per posizione” o uno spatial join con “aggregate”, preferendo quest’ultimo per avere un campo virtuale, con i valori concatenati da virgola, e che successivamente potessi anche riutilizzare per altro semplicemente sostituendo il campo nell’espressione (invece di avere una serie di nomi di comuni separati da virgola, avere i nomi delle entità, la tipologia o altro).
Alla fine ho risolto con “Unisci attributi per posizione” (senza dover riproiettare uno dei due layer, dal momento che stavo lavorando con la 3), ma mi è andata bene perché i punti con ubicazione sbagliata erano pochi: se fossero stati molti di più avrei dovuto salvare il file di output per poter proseguire a spostare i punti anche nei giorni successivi e magari aggiungerci anche un campo di verifica da spuntare o segnarmi a che punto ero arrivata con le correzioni, perché non avrei avuto il vantaggio di un campo virtuale che si modifica man mano che correggevo i punti.
Tutta questa menata per dire che sarebbe stato utile se “aggregate” con @parent funzionasse anche con layer di SR differenti e con il prossimo file puntuale che dovrò correggere credo tutto sommato mi convenga riproiettare il layer dei comuni 
Martina
Il giorno lun 4 mar 2019 alle ore 22:15 nino formica <ninofor60@gmail.com> ha scritto:
Ciao,
certo che è normale !
Stiamo parlando di operazioni geospaziali (come appunto aggregate) tra entità (i layer) che devono essere espressi nello stesso SR.Saluti
NinoIl lun 4 mar 2019, 18:58 Martina Savarese <martina.savarese@gmail.com> ha scritto:
Salve, ho notato che la funzione “aggregate” con la variabile @parent non funziona se i due layer hanno SR differenti. Prova fatta sulla versione 3.4.5 (windows 10).
Francamente non ricordo se fosse così anche nelle precedenti, cioè, è normale?
Martina
QGIS-it-user mailing list
QGIS-it-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-it-user
marti_ wrote
Tutta questa menata per dire che sarebbe stato utile se "aggregate" con
@parent funzionasse anche con layer di SR differenti e con il prossimo
file
puntuale che dovrò correggere credo tutto sommato mi convenga riproiettare
il layer dei comuni
Ciao Martina,
secondo me con un po' di ingegno si potrebbe fare!!!!
prova a usare la funzione transform(geom, source_auth_id, dest_auth_id)
applicata ad una delle due geometrie, cosi facendo, forse (non ho testato),
riesci ad usare aggregate anche con SR differenti.
facci sapere
saluti
-----
https://pigrecoinfinito.wordpress.com/
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Italian-User-f5250612.html
prova a usare la funzione transform(geom, source_auth_id, dest_auth_id)
applicata ad una delle due geometrie, cosi facendo, forse (non ho testato),
riesci ad usare aggregate anche con SR differenti.
si, confermo che bisogna riproiettare con la funzione transform. questo
è un ottimo esempio della riproiezione al volo e dei problemi che può
portare
Matteo
Mmh, non mi ha funzionato 
cioè il calcolatore non mi dà errori, ma mi restituisce tutti valori nulli sul campo virtuale, proprio come faceva senza usare transform.
Sul layer poligonale dei comuni (EPSG 32632) ho usato l’espressione:
aggregate( layer:=‘id layer_punti’, aggregate:=‘concatenate’, expression:=“DENOMINAZIONE”, filter:=intersects ( transform( $geometry , ‘EPSG:32632’, ‘EPSG:4326’ ) , geometry( @parent)), concatenator:=', ')
dove ‘id layer_punti’ è l’id di tale layer (che ha EPSG 4326)
Alla fine ho riproittato il layer dei comuni in 4326 e ottenuto il campo virtuale che volevo (riproiettare l’altro sarebbe stato un casino per come avevo già impostatoil progetto) però mi avrebbe fatto più comodo mantenerlo in un sistema proiettato.
Comunque grazie per la dritta,
Martina
Il giorno mar 5 mar 2019 alle ore 15:56 matteo <matteo.ghetta@gmail.com> ha scritto:
prova a usare la funzione transform(geom, source_auth_id, dest_auth_id)
applicata ad una delle due geometrie, cosi facendo, forse (non ho testato),
riesci ad usare aggregate anche con SR differenti.si, confermo che bisogna riproiettare con la funzione transform. questo
è un ottimo esempio della riproiezione al volo e dei problemi che può
portareMatteo
QGIS-it-user mailing list
QGIS-it-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-it-user
marti_ wrote
Mmh, non mi ha funzionato
cioè il calcolatore non mi dà errori, ma mi restituisce tutti valori nulli
sul campo virtuale, proprio come faceva senza usare transform.
Sul layer poligonale dei comuni (EPSG 32632) ho usato l'espressione:
aggregate( layer:='id layer_punti', aggregate:='concatenate',
expression:="DENOMINAZIONE", filter:=intersects ( transform( $geometry ,
'EPSG:32632', 'EPSG:4326' ) , geometry( @parent)), concatenator:=', ')
dove 'id layer_punti' è l'id di tale layer (che ha EPSG 4326)
Ciao Martina,
secondo me dovresti fare al contrario, cioè:
aggregate( layer:='id layer_punti', aggregate:='concatenate',
expression:="DENOMINAZIONE", filter:=intersects ( transform( $geometry ,
'EPSG:4326', 'EPSG:32632' ) , geometry( @parent)), concatenator:=', ')
facci sapere
-----
https://pigrecoinfinito.wordpress.com/
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Italian-User-f5250612.html
Il giorno mar 5 mar 2019 alle ore 22:01 Totò ha scritto:
secondo me dovresti fare al contrario, cioè:
aggregate( layer:=‘id layer_punti’, aggregate:=‘concatenate’,
expression:=“DENOMINAZIONE”, filter:=intersects ( transform( $geometry ,
‘EPSG:4326’, ‘EPSG:32632’ ) , geometry( @parent)), concatenator:=', ')
Sì a occhio direi che dovrebbe funzionare così :)) anche se non l’ho testato.
Il fatto è che probabilmente era abbastanza assurdo usare questo metodo per quel che mi ero prefissa (fare tutto con un solo e semplice campo!!) se non altro perché, essendo un’operazione abbastanza “pesante” per il calcolatore, ogni volta che dovevo ricare la tabella mi toccava aspettare un bel po’. Riutilizzare un campo così impostato poi non aveva senso dato che avendo già impostato una relazione tra i due vettori per concatenare dei valori potevo usare semplicemente relation_aggregate che risulta molto più leggero per il calcolatore di campi.
Vabbè, come si dice, sbagliando s’impara
Martina
marti_ wrote
Il giorno mar 5 mar 2019 alle ore 22:01 Totò ha scritto:
secondo me dovresti fare al contrario, cioè:
aggregate( layer:='id layer_punti', aggregate:='concatenate',
expression:="DENOMINAZIONE", filter:=intersects ( transform( $geometry
,
'EPSG:4326', 'EPSG:32632' ) , geometry( @parent)), concatenator:=', ')Sì a occhio direi che dovrebbe funzionare così :)) anche se non l'ho
testato.
Ciao Martina,
Non capisco se scherzi o meno, hai un occhio cosi sensibile??
La cosa da sottolineare è che queste tipologie di espressioni, nel field
calc, sono molto lente purtroppo;
forse occorrerebbe segnalarlo.
saluti
-----
https://pigrecoinfinito.wordpress.com/
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Italian-User-f5250612.html
No che non scherzo, e nemmeno ho un occhio particolarmente sensibile, semplicemente rileggendo la funzione una volta staccata dal computer impallato (e impallata evidentemente anch’io) mi sembra del tutto logico che la la $geometry non è quella del layer sulla cui tabella sto operando, ma quella del layer “figlio” indicato in funzione, mentre il @parent è quello appunto genitore. Tant’è che la relazione di progetto 1:N l’ho impostata con il layer dei comuni come “parent” e quello dei punti come “child”.
Quindi a occhio mi sembrava evidente il mio errore.
Nel mio caso era abbastanza assurdo risolvere l’enorme quantità di errori del dataset che stavo usando pensando di usare un’unica scorciatoia: il mio errore era proprio di tipo metodologico, non di una funzione.
In questo caso mi è stato più utile staccare dal computer, prendere carta e penna e farmi qualche schemino per trovare una metodologia più sistematica per risolvere le varie cose. Così magari la prossima volta sono in grado di crearmi uno o più modelli che mi consentano di dare una ripulita preliminare al dataset per impazzire meno su ogni singolo punto di esso.
Martina
Il giorno gio 7 mar 2019 alle ore 08:40 Totò <pigrecoinfinito@gmail.com> ha scritto:
marti_ wrote
Il giorno mar 5 mar 2019 alle ore 22:01 Totò ha scritto:
secondo me dovresti fare al contrario, cioè:
aggregate( layer:=‘id layer_punti’, aggregate:=‘concatenate’,
expression:=“DENOMINAZIONE”, filter:=intersects ( transform( $geometry
,
‘EPSG:4326’, ‘EPSG:32632’ ) , geometry( @parent)), concatenator:=', ')Sì a occhio direi che dovrebbe funzionare così :)) anche se non l’ho
testato.Ciao Martina,
Non capisco se scherzi o meno, hai un occhio cosi sensibile??La cosa da sottolineare è che queste tipologie di espressioni, nel field
calc, sono molto lente purtroppo;
forse occorrerebbe segnalarlo.saluti
https://pigrecoinfinito.wordpress.com/
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Italian-User-f5250612.html
QGIS-it-user mailing list
QGIS-it-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/qgis-it-user
La cosa da sottolineare è che queste tipologie di espressioni, nel field
calc, sono molto lente purtroppo;
forse occorrerebbe segnalarlo.
il problema è noto e credo per ora non risolvibile facilmente. Ogni
volta che si lancia una di questa funzioni viene fatto un loop per ogni
riga e ne viene verificata (e in questo caso) riproiettata al volo la
geometria.
ANche l'ottimo plugin di Enrico (refFunctions), che lo segnala
correttamente è lento proprio per questo motivo