oggi, per caso, ho riscontrato un comportamento strato del geoprocessing
'differenza', sia di qgis che di saga, stesso comportamento che spiego di
seguito.
vi invito a fare questa prova:
1. disegnare un poligono, es. un bel quadrato (primo shapefile poligonale);
2. disegnare un secondo poligono, es. un rettangolo, stretto e alto, che si
sovrapponga al primo ( secondo shapefile);
3. fate la differenza tra i due poligoni (quadrato - rettangolo);
4. ora, uniteli nuovamente: union di qgis, unite la differenza con il
secondo shape;
5. teoricamente dobbiamo unire due poligoni ma l'union da vita a tre
poligoni (il terzo ha superficie nulla)
da varie prove ho dedotto che il problema sta nella differenza e non
nell'unione, perchè?
perchè se invece di unire il vettore differenza con il secondo shapefile,
unisco il vettore differenza con un altro shape (ottenuto ridigitalizzando
il secondo shapefile che ho usato per fare la differenza) l'union da due
soli poligoni, cioè corretto.
la notizia cattiva è che ho provato con 2.14,2.18 e master.... hanno tutti
il problema; ripeto anche con difference di saga.
ti confermo che anche a me succede la stessa cosa.
Credo che come dici tu, l'anomalia è che il vettore differenza è costituito
da un unica feature composta da due poligoni disgiunti, invece forse
sarebbe topologicamente più logico che desse origine a due features
distinte.
Ma onestamente non sono sicuro, e forse è giusto che sia così !?
.... ci ragiono un pò sopra e appena posso mi vado a rileggere un pò di
teoria sulle operazioni di overlay
Ma onestamente non sono sicuro, e forse è giusto che sia così !?
.... ci ragiono un pò sopra e appena posso mi vado a rileggere un pò di
teoria sulle operazioni di overlay
Ciao Nino, grazie per la conferma.
Aggiungo che NON può e non deve essere cosi perchè sarebbe, IMHO, grave!!!!
aggiungo un video dimostrativo [0]:
nel video dimostro che si crea una feature di sovrapposizione che non ha
senso (perchè l'una è la differenza dell'altra) ed inoltre genera un nuovo
vertice dovuta alla sovrapposizione.
Ma onestamente non sono sicuro, e forse è giusto che sia così !?
… ci ragiono un pò sopra e appena posso mi vado a rileggere un pò di
teoria sulle operazioni di overlay
Ciao Nino, grazie per la conferma.
Aggiungo che NON può e non deve essere cosi perchè sarebbe, IMHO, grave!!!
aggiungo un video dimostrativo [0]:
nel video dimostro che si crea una feature di sovrapposizione che non ha
senso (perchè l’una è la differenza dell’altra) ed inoltre genera un nuovo
vertice dovuta alla sovrapposizione.
Ma onestamente non sono sicuro, e forse è giusto che sia così !?
… ci ragiono un pò sopra e appena posso mi vado a rileggere un pò di
teoria sulle operazioni di overlay
Ciao Nino, grazie per la conferma.
Aggiungo che NON può e non deve essere cosi perchè sarebbe, IMHO, grave!!!
aggiungo un video dimostrativo [0]:
nel video dimostro che si crea una feature di sovrapposizione che non ha
senso (perchè l’una è la differenza dell’altra) ed inoltre genera un nuovo
vertice dovuta alla sovrapposizione.
Ma onestamente non sono sicuro, e forse è giusto che sia così !?
… ci ragiono un pò sopra e appena posso mi vado a rileggere un pò di
teoria sulle operazioni di overlay
Ciao Nino, grazie per la conferma.
Aggiungo che NON può e non deve essere cosi perchè sarebbe, IMHO, grave!!!
aggiungo un video dimostrativo [0]:
nel video dimostro che si crea una feature di sovrapposizione che non ha
senso (perchè l’una è la differenza dell’altra) ed inoltre genera un nuovo
vertice dovuta alla sovrapposizione.
Avevo completamente dimenticato questo thread: Stefano, hai una memoria di
ferro!!!
La cosa rimane comunque parecchio imbarazzante, difficile da far capire ai
neofiti che subito trarranno una conclusione negativa sull'uso di sw OS; si
dovrebbe adottare la stessa tecnica dei SW proprietari, cioè adottare delle
tolleranze su queste operazioni.
Avevo completamente dimenticato questo thread: Stefano, hai una memoria di
ferro!!!
La cosa rimane comunque parecchio imbarazzante, difficile da far capire ai
neofiti che subito trarranno una conclusione negativa sull’uso di sw OS; si
dovrebbe adottare la stessa tecnica dei SW proprietari, cioè adottare delle
tolleranze su queste operazioni.
Si ok, ma continuo a non capire (... sono un po' duro) cosa c'entra la
tolleranza col fatto che l'unione genera una terza geometria con area
nulla
!?
le operazioni di overlay richiedono tonnellate di calcoli, dove vengono
presi in considerazione le coord. dei vertici; queste coord. avranno decine
di cifre dopo la virgola ma un pc non potra mai prendere tutte le cifre, ad
un certo punto deve approssimare; questa approssimazione può provocare una
sovrapposizione (infinitesima); questa sovrapposizione crea la terza
geometria inattesa.
Si ok, ma continuo a non capire (... sono un po' duro) cosa c'entra la
tolleranza col fatto che l'unione genera una terza geometria con area
nulla
!?
le operazioni di overlay richiedono tonnellate di calcoli, dove vengono
presi in considerazione le coord. dei vertici; queste coord. avranno
decine
di cifre dopo la virgola ma un pc non potra mai prendere tutte le cifre,
ad
un certo punto deve approssimare; questa approssimazione può provocare una
sovrapposizione (infinitesima); questa sovrapposizione crea la terza
geometria inattesa.
spero di essere stato chiaro.
saluti
aggiungo un piccolo video [0] dimostrazione (che funziona SOLO nella
2.14.22):
nel video faccio unione tra il vettore differenza e un vettore che
digitalizzo usando lo snap, NON si crea nessuna sovrapposizione!!!
Ciao a tutti,
purtroppo e' una problematica riscontrata da tempo e confermo quanto esposto
in questa ML da parte di Salvatore e Stefano.
Ci si rende conto di questa particolare situazione quando si effettuano
operazioni multiple di geo-processing, per esempio durante la fase di
redazione di PRGC, ove si vanno a sottrarre e unire moltissimi poligoni,
ritrovandoti ad avere uno strato informativo risultante con tante di queste
situazioni.
Soluzione 1) (perdita di informazione nativa)
Modificare il numero annoso di decimali che si generano e che costituiscono
le coordinate dei vertici. Riprendendo l'esempio di Salvatore e' facilmente
verificabile, andando a modificare in Vertex Editor, il numero di decimali
che costituiscono le coordinate dei vertici stessi, portandoli a 4 decimali
come prova, salvando il tutto e ricaricando la Union eseguita il problema
del terzo incomodo nella Attribute Table sparisce.
Il problema sta nell'uso futuro di questo strato ottenuto, quando verra'
rapportato con le primitive di origine, in fase di intersezione (esempio,
restituzione di una destinazione urbanistica MULTISTRATO), in quanto andando
a privare lo strato risultante di parte dell'informazione originale si
verranno a generare degli scostamenti, che potranno essere insignificanti o
meno a seconda del lavoro che si sta svolgendo.
Soluzione 2) (fortemente consigliata rispetto alla prima)
a) Lavorare con PostgreSQL
b) Importare in PostgreSQL e fare una pulizia completa dello strato
informativo risultante.