Interessante questione in merito a shapefile vs spatialite su QGIS

[Andrea Peri]

salve,

intervengo per segnalera una scoperta che abbiamo fatto in questi
gorni e che aggiunge una informazione preziosa nella disputa tra
shapefile e spatialite.

Tutto e' partito dal fatto che giorni fa' al lavoro ci eravamo accorti
che (su qgis 2.6.1) se si caricava uno shapefile e si filtrava su
qualche valore, la tabella non era piu' editabile.

Questa cosa sulel prime sembrava corretta. In realt'a ci siamo resi
coto che non era corretta per niente.
Oltretutto sapevamo che in altri prodotti commerciali non accadeva questo.

Quindi abbiamo fato quleh prova extra e sono venute fuori interessanti
conclusioni che ritengo utile condividere.

Infatti se anziche' uno shapefile, usavamo uno spatialite "con il
provider spatialite" (e' importante precisare questo dettaglio).
La tabella restava editabile anche quando si filtrava e per di piu',
una modifica applicata a tappeto tramite il calcolatore dei campi
veniva effettuata sui soli campi presenti (dal filtraggio) non su
tutti indistintamente.

A questo punto , come controprova abbiamo fatto qualche prova
accedendo a spatialite trmaite il provider GDAL/OGR. E ci siamo
accorti che in questo caso, esattamente come nel caso degli shapefile
quando si filtrava il dataset , la tabella non era piu' editabile.

Quindi, la logica conclusione e' che e' gdal/ogr che mette in readonly
se il dataset e' filtrato, oppure e' un bug di qgis che mette readonly
quando filtrato su gdal.

Questa cosa e' importante da tenere presente, perche' qualche tempo
fa' si discuteva in lista qgis di abbandonare il provider spatialite
in favore del provider gdal/ogr.
In realt'a questa cosa sarebbe una iattura.
Perche' verrebbe meno una feature iportantissia per chi lvora
usualmente con i dati GIS.
Ovvero l possibilit'a di poter filtrare e operare in editing sui soli
dati filtrati .

Quindi sempre restando nel tema di perche' preferire shapefile o spatialite.
Io aggiugerei anche questo fatto:
con gli shapefile (che obbligatoriamente usano ogr) non si puo'
operare in editing su dati filtrati.
Mentre con spatialite (usando il provider spatialite ) si.
Immagino che lo stesso avviene per il provider postgis.

Ma questo getta dei dubbi sulla opportunta' di usare il formato
shapefile per l'editing dei dati.

A.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[Sieradz]

Boh, personalmente non mi sembra un bug, ma un comportamento perfettamente normale, e mi spiego.

Lo scopo del Filtro non e' quello di permettere l'editazione della tabella attributi, ma di generare un sottoinsieme da salvare con altro nome.

Se tu vuoi modificare gli attributi soltanto del sottoinsieme, il comando corretto non e' FILTRA bensi' SELEZIONA PER ESPRESSIONE dopodiche' (nel Calcolatore di Campi) occorre flaggare AGGIORNA SOLO LE GEOMETRIE SELEZIONATE.

Questa tecnica, che consente anche di salvare il sottoinsieme, rende di fatto ridondante (leggi inutile) il comando FILTRA.

Il blocco dell'editabilita' dopo il filtro, peraltro, accadde anche in formati diversi tipo il GMT, quindi non darei la croce addosso al povero shapefile...

[Andrea Peri]

La tua e' una opinione perfettamente legittima.
D'altronde qgis deve servire a tanti utenti differenti.
Ognuno con le proprie esigenze specifiche.

Resta il fatto che a chi lavora intensamente con molte geometrie e
deve lavorare su set limitati di dati
non gli basta la selezione.
Infatti se essa risolve la parte attributi, grazie al comando "msotra
solo i rcord selezionati",
non esiste analogo comando per le geometrie che continuano a essere
mostrate tutte, generando confusione e dando fastidio.

E' vero che uno potrebbe esportarsi i dati e lavorare su di essi . Ma
poi dovrebbe rimetterli insieme.
Con il rischio di imbattersi in altri problemi (magari il plugin che
fa il merge non funziona cosi bene come uno spera...)
Mentre invece bastava che qulcun gli dicesse.
Invece che uno shapefile uso uno spatialite e la tua vita sara' piu' facile ....

Quindi il messaggio e questo.
Poi se uno vuole usare lo shapefile e usare la selezione faccia pure.
L?importante e' poter scegliere.

Il brutto e' quando qualcuno forza la mano impoenendo una soluzione
tecnica unica solo perche' a lui va bene tale soluzione e vorrebbe che
tutti usino quella e solo quella.
Ma qui siamo tutti daccordo.
La flessibilita' richiede ampia scelta.

E secondo me se il formatoshapefile con filtro permettesse l'editing e
si comportasse come lo spatialite sarebbe meglio per tutti.
Chi vuole usare la selezione usa ancora quella e sta contento.
Chi vuole usare iil filtro usa quello e sta contento pure lui.

Non vedo perche' ci si debba tutti uniformare a una medesima soluzione
che poi scontenta qualcuno.

:)

A.




Il 11 dicembre 2014 21:23, Sieradz <[hidden email]> ha scritto:

> Boh, personalmente non mi sembra un bug, ma un comportamento perfettamente
> normale, e mi spiego.
>
> Lo scopo del Filtro non e' quello di permettere l'editazione della tabella
> attributi, ma di generare un sottoinsieme da salvare con altro nome.
>
> Se tu vuoi modificare gli attributi soltanto del sottoinsieme, il comando
> corretto non e' FILTRA bensi' SELEZIONA PER ESPRESSIONE dopodiche' (nel
> Calcolatore di Campi) occorre flaggare AGGIORNA SOLO LE GEOMETRIE
> SELEZIONATE.
>
> Questa tecnica, che consente anche di salvare il sottoinsieme, rende di
> fatto ridondante (leggi inutile) il comando FILTRA.
>
> Il blocco dell'editabilita' dopo il filtro, peraltro, accadde anche in
> formati diversi tipo il GMT, quindi non darei la croce addosso al povero
> shapefile...
>
>
>
> --
> View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Interessante-questione-in-merito-a-shapefile-vs-spatialite-su-QGIS-tp7590831p7590832.html
> Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
> 666+40 iscritti al 5.6.2014

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[Marco]

Sono d'accordo con Sieradz su (quasi) tutto, tranne che sulla totale ridondanza di FILTRA rispetto al potente SELEZIONA PER ESPRESSIONE.
Infatti, se è vero come è vero che con SELEZIONA PER ESPRESSIONE si può fare tutto, di più e meglio di quello che si fa con FILTRA è pur vero che, con FILTRA, è possibile isolare graficamente, "al volo", sulla Vista della mappa, i soli elementi filtrati, nascondendo gli altri. Tutto ciò è molto comodo, ad esempio, quando, con Gestore di stampe, si vuole poi stampare, "al volo", solo una parte, una selezione debitamente filtrata, degli elementi di un layer, (certo, volendolo, tutto ciò lo si può fare anche con SELEZIONA PER ESPRESSIONE, ma richiede qualche passaggio in più ...e quindi è meno "al volo").