[Gfoss] Segnalazione in merito a incompatibilita' sugli shapefiles di QGIS

Salve,
dopo l'ennesimo inciampo odierno causato da altri shapefiles con
contenuti non correttamente gestiti da QGIS.
Ritengo che sia ilaso di rimarcare il problema affinche' altri non
abbiano a inciamparci.
E' sempre la solita storia di shapefiles prodotti con qgis e che
contengono sempre records che sarebbero stati cancellati, ma che qgis
non ha realmente cancellato.
Il problema e' sempre il solito.
Quando questi shapefile escono da una filiera qgis e vengono veicolati
ad altri soggetti che usano un qualsiasi altro software GIS,
indipendentemente che esso sia un arcgis della esri, un autocad-map o
altro software gfoss.

Se chi ha prodotto lo shapefile ha usato un qgis ed e' passato dalle
grinfie di un qgis inferiore alla 2.14.x esso puo' contenere dei dati
che non dovrebbero esserci (perche' cancellati).
Il brutto e' che non ci se ne accorge e candidamente si impiegnao come
se fossero tutti buoni.

Le nuove versioni diqgis hanno risolto il problema in maniera parziale.
Infatti non marcano piu' una finta cancellazione sui dati che vengono editati.
Ma non correggono il problema sugli shapefile antecedenti.
Purtroppo pero' all'intenro del mondo QGIS e' assolutamente
IMPOSSIBILE ACCORGERSI CHE in uno shapefile contiene una tale
situazione di dati non cancellati.
Per cui si capisce bene che non potendo sapere se uno shapefile ha al
suo interno una tale situazione si e' in difficolta' quando si deve
spedire uno shapefile all'esterno sottoforma di una consegna.

Segnalo questa cosa perche' oggi per l'ennesima volta mi sono passati
tra le mani shapefile che contenevano records che non dovevano esserci
perche' cancellati.
O per meglio dire, in cui l'utente che li ha prodotti credeva di
averli cancellati.

Facile immaginare il caos che una cosa di questo genere puo'produrre
se prende piede.
Per risolvere non basta adottare l'ultima versione di GQIS; perche'
esso non consente di rilevare il problema negli shapefile e
correggerli.

Occorre adottare un software esterno che rilevi il problema e provveda
autonomamente a correggere tali shapefile.

A.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

Ciao Andrea,
non ho sotto mano una versione precedente di QGIS. Potresti mettere a
disposizione uno shapefile con struttura corrotta (record "zombie")?
Potrebbe essere un esercizio interessante realizzare un plugin per pulire
gli shapefile corrotti, prodotti con versioni < 2.14.x.

giovanni

Il giorno 20 ottobre 2016 12:56, Andrea Peri <aperi2007@gmail.com> ha
scritto:

Salve,
dopo l'ennesimo inciampo odierno causato da altri shapefiles con
contenuti non correttamente gestiti da QGIS.
Ritengo che sia ilaso di rimarcare il problema affinche' altri non
abbiano a inciamparci.
E' sempre la solita storia di shapefiles prodotti con qgis e che
contengono sempre records che sarebbero stati cancellati, ma che qgis
non ha realmente cancellato.
Il problema e' sempre il solito.
Quando questi shapefile escono da una filiera qgis e vengono veicolati
ad altri soggetti che usano un qualsiasi altro software GIS,
indipendentemente che esso sia un arcgis della esri, un autocad-map o
altro software gfoss.

Se chi ha prodotto lo shapefile ha usato un qgis ed e' passato dalle
grinfie di un qgis inferiore alla 2.14.x esso puo' contenere dei dati
che non dovrebbero esserci (perche' cancellati).
Il brutto e' che non ci se ne accorge e candidamente si impiegnao come
se fossero tutti buoni.

Le nuove versioni diqgis hanno risolto il problema in maniera parziale.
Infatti non marcano piu' una finta cancellazione sui dati che vengono
editati.
Ma non correggono il problema sugli shapefile antecedenti.
Purtroppo pero' all'intenro del mondo QGIS e' assolutamente
IMPOSSIBILE ACCORGERSI CHE in uno shapefile contiene una tale
situazione di dati non cancellati.
Per cui si capisce bene che non potendo sapere se uno shapefile ha al
suo interno una tale situazione si e' in difficolta' quando si deve
spedire uno shapefile all'esterno sottoforma di una consegna.

Segnalo questa cosa perche' oggi per l'ennesima volta mi sono passati
tra le mani shapefile che contenevano records che non dovevano esserci
perche' cancellati.
O per meglio dire, in cui l'utente che li ha prodotti credeva di
averli cancellati.

Facile immaginare il caos che una cosa di questo genere puo'produrre
se prende piede.
Per risolvere non basta adottare l'ultima versione di GQIS; perche'
esso non consente di rilevare il problema negli shapefile e
correggerli.

Occorre adottare un software esterno che rilevi il problema e provveda
autonomamente a correggere tali shapefile.

A.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
Gfoss@lists.gfoss.it
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.
807 iscritti al 31/03/2016

On Thu, Oct 20, 2016 at 12:56:20PM +0200, Andrea Peri wrote:

Se chi ha prodotto lo shapefile ha usato un qgis ed e' passato dalle
grinfie di un qgis inferiore alla 2.14.x esso puo' contenere dei dati
che non dovrebbero esserci (perche' cancellati).

[...]

Le nuove versioni diqgis hanno risolto il problema in maniera parziale.
Infatti non marcano piu' una finta cancellazione sui dati che vengono editati.
Ma non correggono il problema sugli shapefile antecedenti.

Non ho provato direttamente, ma mi e' stato detto che salvando
lo shapefile incriminato, attraverso l'ultima versione di QGIS
(2.17.x o 2.14.x), i record cancellati "logicamente" vengono
definitivamente rimossi. Non confermi ?

Per risolvere non basta adottare l'ultima versione di GQIS; perche'
esso non consente di rilevare il problema negli shapefile e
correggerli.

Credi debba solo avvertire, in fase di caricamento, della presenza di
record cancellati ?

Esiste un ticket sul bug tracker di QGIS attraverso cui seguire
l'evoluzione di questo problema che mi pare ti affligga da tempo ?

Io ho appena terminato di lavorare alla chiusura di bug marchiati
come "severi" sul tracker, ma non ne ho visto nessuno a proposito
di questo problema (forse non sono marchiati come "severi"?)

--strk;

SI, confermo.
Ma appunto il problema e' sapere quando siamo in una tale situazione.

Gia' sarebbe utile che qgis segnalasse la presenza di records cancellati.
Ma la risoluzione tramite l'esportazione poi introduce altri problemi.
(il mondo e' proprio difficile)

L'ideale sarebbe stato che QGIS, quando si apre lo shapefile in
editing e poi si richiude la sessione di editing, il QGIS anziche'
lasciare tutto intonso provvedesse lui a a rimuovere i records
cancellati logicamente.

Questo sarebbe preferibile piuttosto che costringere a esportarli.
Perche' la procedura di esportazione introduce altri tipi di problemi.

Un per tutti.
Nella versione 2.8 di qgis, ricordo bene che quando si esportava in
formato shapefile.
Ci si ritrovva con tutti i campi testuali a 255 caratteri.

Lo ricordobene perche' shapefiles con milioni di records divenivano giganteschi.
Te pensa infatti un dbf con 30 campi testuali da 10-15 caratteri
ciascuno = 450 bytes per record.
Se passi a 255 caratteri per campo testuale ti ritrovi che il singolo
record occuperebbe 7.650 bytes.
Se applichi questa cosa a uno shapefile che contiene chesso' 200.000
records vedi subito che ci sta la sua bella differenza.

Lo ricordo bene questo fatto su qgis 2.8
Da allora non esporto piu' gli shapefile da qgis, ma bensi' da spatialite.
Il quale a differenza di qgis esegue il conteggio dello spazio
occupato e mi ridimensiona i campi al mnimo necessario.

Per cui se vede che in un campo al massimo servoo 4 caratteri, crea un
campo da 4 caratteri.

QUESTO E' MEGLIO PERCHE' OCCUPA MENO SPAZIO DISCO E MENO BANDA A SCARICARE,
ma anche questo secondo me non va bene.

Perche' se io ho uno shapefile che da specifica , su un campo deve
avere 32 caratteri, ritrovarmi con uno shapefile che su tale campo ha
255 caratteri oppure ne ha 4 (perche' al momentolo shapefile al
massimo ha dati che occupano 4 caratteri) non e' corretto.

Perche' potrebbe succedere che poi devi aggiungervi un ulteriore
record che sfora i 4 caratteri, ma sempre dentro la specifica
originaledi 32 e scopri che lo shapefile non lo accetta.

Questo e' per dettagliare che l'esportzione porta dietro i suoi bei
problemini anche quella.
E quindi alla fine tra records cancellati logicamente ma sempre
prsenti, esportazioni che fannocrescere mmolto le dimensioni dei files
oppure che restringono i domini previsti per i campi,
ci si trova sempre in grossi dilemmi.

La migliore soluzione sarebbe che preso atto che la specifica
shapefile non ammette la presenza dei records cancellati logicamente,
i nuovi qgis dovrebbero segnalare la presenza di questi records e nel
caso correggerli di loro iniziativa quando si apre e si richiude una
sessione di editing.

Senza costringere a esportazioni che fanno poi nascere altri problemi.

Chiedo scusa se sono andato OT, ma immagino che queste cose siano
sostanzilament eutili per chi lavora in questo settore.
Considerato che non sono affatto cose banali nemmeno per chi ha riesce
a orizzontarcisi.

A.

Cosa che puo' provocare la crescita abnorme della compoenente dbf
nello shapefile.

A onor del vero questa cosa della conversione dei campi testo a 255
caratteri la scoprii su qgis 2.8.
Da allora non uso piu' qgis per generare gli shapefiles, ma passo
sistematicamente da spatialite che invece eseguendo ilconteggio dei
caratteri mi ottimizza lo spazio disco.

A onor del vero nessuno dei due andrebbe bene, perche' se io ho uno
shapefile con 52 caratteri su un campo testuale, vorrei che restassero
52 perche' sicuramente ci sar'a una specifica che dice cio'. E
ritrovarmi con campi di 255 caratteri mi porta a file abnormi, e
invece con campi minimizzati , rischio di divenire incompatibile con
la specifica.

Il 20 ottobre 2016 13:11, Sandro Santilli <strk@kbt.io> ha scritto:

On Thu, Oct 20, 2016 at 12:56:20PM +0200, Andrea Peri wrote:

Se chi ha prodotto lo shapefile ha usato un qgis ed e' passato dalle
grinfie di un qgis inferiore alla 2.14.x esso puo' contenere dei dati
che non dovrebbero esserci (perche' cancellati).

[...]

Le nuove versioni diqgis hanno risolto il problema in maniera parziale.
Infatti non marcano piu' una finta cancellazione sui dati che vengono editati.
Ma non correggono il problema sugli shapefile antecedenti.

Non ho provato direttamente, ma mi e' stato detto che salvando
lo shapefile incriminato, attraverso l'ultima versione di QGIS
(2.17.x o 2.14.x), i record cancellati "logicamente" vengono
definitivamente rimossi. Non confermi ?

Per risolvere non basta adottare l'ultima versione di GQIS; perche'
esso non consente di rilevare il problema negli shapefile e
correggerli.

Credi debba solo avvertire, in fase di caricamento, della presenza di
record cancellati ?

Esiste un ticket sul bug tracker di QGIS attraverso cui seguire
l'evoluzione di questo problema che mi pare ti affligga da tempo ?

Io ho appena terminato di lavorare alla chiusura di bug marchiati
come "severi" sul tracker, ma non ne ho visto nessuno a proposito
di questo problema (forse non sono marchiati come "severi"?)

--strk;

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

Esisterebbe gia' un tool che fa questo.
Usabile da procedura batch. E quindi utile per ripulire con una
semplice shell dos intere cartellate di shapefiles.
Ottimo e efficace.

Non e' roba nostra, e quindi non posso farne cenno piu' esplicito, ma
le ultime prove eseguite hanno dato ottimi risultati.

Mi sentirei di consigliarlo.
Purtroppo non e' stato ancora rilasciato, ma penso che lo sara' presto.

Resta comunque il problema che occorre ricordarsi di lanciarlo sempre
su tuttocio' che si riceve.
E' questo il passaggio difficile.
Per cui secondo me se si vuole veramente aiutare a far scomparrire
questa piaga endemica degli shapefile con i ghost-records occore che
lo stesso qgis prenda atto che dovrebbe lui stessoautomatizzare al suo
intenro dei comportamenti che ripuliscano sempre in automatico e senza
che sia l'operatore a doverloinvocare.
Altrimenti, come i virus dei computers continueranno a circolare
perche' sempre ciara' a giro qualcuno che da qualche parte o per
qualche ragione , continuera' ad usare una vecchia versione di qgis .

A.

Il 20 ottobre 2016 13:09, G. Allegri <giohappy@gmail.com> ha scritto:

Ciao Andrea,
non ho sotto mano una versione precedente di QGIS. Potresti mettere a
disposizione uno shapefile con struttura corrotta (record "zombie")?
Potrebbe essere un esercizio interessante realizzare un plugin per pulire
gli shapefile corrotti, prodotti con versioni < 2.14.x.

giovanni

Il giorno 20 ottobre 2016 12:56, Andrea Peri <aperi2007@gmail.com> ha
scritto:

Salve,
dopo l'ennesimo inciampo odierno causato da altri shapefiles con
contenuti non correttamente gestiti da QGIS.
Ritengo che sia ilaso di rimarcare il problema affinche' altri non
abbiano a inciamparci.
E' sempre la solita storia di shapefiles prodotti con qgis e che
contengono sempre records che sarebbero stati cancellati, ma che qgis
non ha realmente cancellato.
Il problema e' sempre il solito.
Quando questi shapefile escono da una filiera qgis e vengono veicolati
ad altri soggetti che usano un qualsiasi altro software GIS,
indipendentemente che esso sia un arcgis della esri, un autocad-map o
altro software gfoss.

Se chi ha prodotto lo shapefile ha usato un qgis ed e' passato dalle
grinfie di un qgis inferiore alla 2.14.x esso puo' contenere dei dati
che non dovrebbero esserci (perche' cancellati).
Il brutto e' che non ci se ne accorge e candidamente si impiegnao come
se fossero tutti buoni.

Le nuove versioni diqgis hanno risolto il problema in maniera parziale.
Infatti non marcano piu' una finta cancellazione sui dati che vengono
editati.
Ma non correggono il problema sugli shapefile antecedenti.
Purtroppo pero' all'intenro del mondo QGIS e' assolutamente
IMPOSSIBILE ACCORGERSI CHE in uno shapefile contiene una tale
situazione di dati non cancellati.
Per cui si capisce bene che non potendo sapere se uno shapefile ha al
suo interno una tale situazione si e' in difficolta' quando si deve
spedire uno shapefile all'esterno sottoforma di una consegna.

Segnalo questa cosa perche' oggi per l'ennesima volta mi sono passati
tra le mani shapefile che contenevano records che non dovevano esserci
perche' cancellati.
O per meglio dire, in cui l'utente che li ha prodotti credeva di
averli cancellati.

Facile immaginare il caos che una cosa di questo genere puo'produrre
se prende piede.
Per risolvere non basta adottare l'ultima versione di GQIS; perche'
esso non consente di rilevare il problema negli shapefile e
correggerli.

Occorre adottare un software esterno che rilevi il problema e provveda
autonomamente a correggere tali shapefile.

A.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
Gfoss@lists.gfoss.it
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.
807 iscritti al 31/03/2016

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

On Thu, Oct 20, 2016 at 02:01:23PM +0200, Andrea Peri wrote:

La migliore soluzione sarebbe che preso atto che la specifica
shapefile non ammette la presenza dei records cancellati logicamente,
i nuovi qgis dovrebbero segnalare la presenza di questi records e nel
caso correggerli di loro iniziativa quando si apre e si richiude una
sessione di editing.

Mi sembra di capire (senza averlo provato) che se applichi una
modifica, al salvataggio dovresti trovare i record fantasmi rimossi.
Mi confermi anche questo ? (non so costa intendi per "esportare").

Ad ogni modo: apri un ticket per una feature-request ?

--strk;

(non so costa intendi per "esportare").

esportare => save as

Mi sembra di capire (senza averlo provato) che se applichi una
modifica, al salvataggio dovresti trovare i record fantasmi rimossi.
Mi confermi anche questo

A me risulta di no.

Quando mi e' capitato l'ultima volta ho messo in editing e pi richiuso
confermando il salvataggio.
Ma il records fantasma e' rimasto.

Io usavo la 2.14 , non credo che la 2.16 su questo abbia fatto cambiamenti.

Il punto e' che se non si usa un sogtware gis differente da qgis,
questa cosa che con l'editing resta presente il record fantasma non si
riesce a rilevarla perche' qgis non fornisce elementi che informino
della presenza del record fantasma.

Noi abbiamo arcview3 della esri e con esso rileviamo che il record e'
ancora presente, ma capisco che chi lavora esclusivamente con qgis e'
in difficolta' in questo frangente.

Come risposto a Allegri stasera vedo di mettere a disposizione uno
shapefile siffatto, ma ribadiscoche e' praticamente impossibile per
chi opera con qgis rilevare questo dettaglio.

A.

Il 20 ottobre 2016 14:13, strk <strk@keybit.net> ha scritto:

On Thu, Oct 20, 2016 at 02:01:23PM +0200, Andrea Peri wrote:

La migliore soluzione sarebbe che preso atto che la specifica
shapefile non ammette la presenza dei records cancellati logicamente,
i nuovi qgis dovrebbero segnalare la presenza di questi records e nel
caso correggerli di loro iniziativa quando si apre e si richiude una
sessione di editing.

Mi sembra di capire (senza averlo provato) che se applichi una
modifica, al salvataggio dovresti trovare i record fantasmi rimossi.
Mi confermi anche questo ? (non so costa intendi per "esportare").

Ad ogni modo: apri un ticket per una feature-request ?

--strk;

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

On Thu, 20 Oct 2016 14:11:20 +0200, Andrea Peri wrote:

Esisterebbe gia' un tool che fa questo.
Usabile da procedura batch. E quindi utile per ripulire con una
semplice shell dos intere cartellate di shapefiles.
Ottimo e efficace.

Non e' roba nostra, e quindi non posso farne cenno piu' esplicito, ma
le ultime prove eseguite hanno dato ottimi risultati.

Mi sentirei di consigliarlo.
Purtroppo non e' stato ancora rilasciato, ma penso che lo sara' presto.

giusto per uscire dai misteri; si tratta del tool a riga di comando
"shp_sanitize" che fa parte degli spatialite-tools 4.4.0 che nel
loro complesso sono ancora in fase "release candidate", ma questo
speficico tool ha gia' raggiunto la piena maturita'

$ shp_sanitize --help

usage: shp_sanitize ARGLIST

-h or --help print this help message
-idir or --in-dir dir-path directory expected to contain
                                   all SHP to be checked
-odir or --out-dir dir-path <optional> directory where to
                                   store all repaired SHPs

======================= optional args ===========================
-geom or --invalid-geoms checks for invalid Geometries
-esri or --esri-flag tolerates ESRI-like inner holes
-force or --force-repair unconditionally repair
$

se non viene specificato -odir si limita a generare un report
diagnositico; se invece viene specificato -odir allora ripara
automaticamente tutti gli shp che presentano qualche problema
critico, ivi compresa la presenza dei micidiali records
"cancellati logicamente"

ciao Sandro

On Thu, Oct 20, 2016 at 02:24:19PM +0200, Andrea Peri wrote:

>(non so costa intendi per "esportare").

esportare => save as

>Mi sembra di capire (senza averlo provato) che se applichi una
>modifica, al salvataggio dovresti trovare i record fantasmi rimossi.
>Mi confermi anche questo

A me risulta di no.

Quando mi e' capitato l'ultima volta ho messo in editing e pi richiuso
confermando il salvataggio.
Ma il records fantasma e' rimasto.

Ecco.

Io usavo la 2.14 , non credo che la 2.16 su questo abbia fatto cambiamenti.

Serve anche l'ultimo numero della versione, per capirci meglio.
Ma potrebbe essere stato sistemato due settimane fa nel branch release-2_14:
https://github.com/qgis/QGIS/commit/872d86eb04e8ea2a2fe77a8c198d3636a698b6f8

Come risposto a Allegri stasera vedo di mettere a disposizione uno
shapefile siffatto, ma ribadiscoche e' praticamente impossibile per
chi opera con qgis rilevare questo dettaglio.

La segnalazione all'utente e' ancora una feature utile, se vuoi aprire
un ticket sulla questione.

--strk;

Ho fatto alcune prove.
Intanto cconfermo che la versione 2.12 genera ancora i records fantasma.
Molto probabilmente li genera anche le prime versioni della 2.14.
L'ultima (la 2.14.5 invece non li genera piu').
Idem la 2.16 non li genera piu'.

Ha invece ragione strk che se si edita uno shapefile con la 2.16 ,
quando si salva i records fantasma vengono rimossi.

Piccolo dettaglio: occorre editarli realmente. Ovvero non basta aprire
in editing e richiuderli. Ma occorre apportare una vera modifica.
Oppure cancellare un record oppure aggiungerne uno, e poi magari
rimuoverlo nuovamente.
Tutte operazioni un po' delicate e da fare con attenzione su shapefiles buoni.
Comunque meglio cosi' che doverli risalvare ex-novo per i problemi gia' esposti.
:slight_smile:

Proseguendo:
A questo link dropbox
https://www.dropbox.com/s/igbt5k9r9dfob93/logical_delete.7z?dl=0

E' possibile scaricare uno shapefile che ho preparato con qgis 2.12.
In esso se si apre con qgis si vede 1 record solo.
Se invece si apre con MapWidows si vedono 3 records.
:slight_smile:

Idem ritengoche si vedrebbero 3 records se si carica su postgis . Non
ho provato ma ne sono abbastanza sicuro, non mi risulta che postgis
abbia risolto questo problema. Ma strk potra' essere piu' preciso.

Immagino che sarebbe lo stesso se si usa OpenJump, Arcgis, o altro
software gfoss diverso da spatialite ultima versione o da qgis.

Riporto anche i messaggio che ritorna il tool di Furieri quando si
ispeziona in modalit'a diagnostica:

----------------------------------------------------------
Input dir: ./
Only a diagnostic report will be reported

Verifying .//logical_delete.shp
                row #1: logical deletion found
                row #2: logical deletion found
                HEADERS: found invalid BBOX
        found 3 invalidities: cleaning required.

===========================================
1 Shapefile has been inspected.
1 malformed Shapefile has been identified.
0 Shapefile has been repaired.
----------------------------------------------------------

Saluti,

A.

Il 20 ottobre 2016 14:24, Andrea Peri <aperi2007@gmail.com> ha scritto:

(non so costa intendi per "esportare").

esportare => save as

Mi sembra di capire (senza averlo provato) che se applichi una
modifica, al salvataggio dovresti trovare i record fantasmi rimossi.
Mi confermi anche questo

A me risulta di no.

Quando mi e' capitato l'ultima volta ho messo in editing e pi richiuso
confermando il salvataggio.
Ma il records fantasma e' rimasto.

Io usavo la 2.14 , non credo che la 2.16 su questo abbia fatto cambiamenti.

Il punto e' che se non si usa un sogtware gis differente da qgis,
questa cosa che con l'editing resta presente il record fantasma non si
riesce a rilevarla perche' qgis non fornisce elementi che informino
della presenza del record fantasma.

Noi abbiamo arcview3 della esri e con esso rileviamo che il record e'
ancora presente, ma capisco che chi lavora esclusivamente con qgis e'
in difficolta' in questo frangente.

Come risposto a Allegri stasera vedo di mettere a disposizione uno
shapefile siffatto, ma ribadiscoche e' praticamente impossibile per
chi opera con qgis rilevare questo dettaglio.

A.

Il 20 ottobre 2016 14:13, strk <strk@keybit.net> ha scritto:

On Thu, Oct 20, 2016 at 02:01:23PM +0200, Andrea Peri wrote:

La migliore soluzione sarebbe che preso atto che la specifica
shapefile non ammette la presenza dei records cancellati logicamente,
i nuovi qgis dovrebbero segnalare la presenza di questi records e nel
caso correggerli di loro iniziativa quando si apre e si richiude una
sessione di editing.

Mi sembra di capire (senza averlo provato) che se applichi una
modifica, al salvataggio dovresti trovare i record fantasmi rimossi.
Mi confermi anche questo ? (non so costa intendi per "esportare").

Ad ogni modo: apri un ticket per una feature-request ?

--strk;

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

Aggiungo che preparando lo shapefile, ho toccato con mano la rilevanza
del problema.
Spesso capita che vengono messi in circolazione dei dati, dopo averli
ripuliti di eventuali records che per ragioni varie non possono essere
divulgati.

Il irschio che tali dati rsiano rimasti contenuti negli shapefiel e' concreto.

:frowning:

A.

Il 21 ottobre 2016 00:51, Andrea Peri <aperi2007@gmail.com> ha scritto:

Ho fatto alcune prove.
Intanto cconfermo che la versione 2.12 genera ancora i records fantasma.
Molto probabilmente li genera anche le prime versioni della 2.14.
L'ultima (la 2.14.5 invece non li genera piu').
Idem la 2.16 non li genera piu'.

Ha invece ragione strk che se si edita uno shapefile con la 2.16 ,
quando si salva i records fantasma vengono rimossi.

Piccolo dettaglio: occorre editarli realmente. Ovvero non basta aprire
in editing e richiuderli. Ma occorre apportare una vera modifica.
Oppure cancellare un record oppure aggiungerne uno, e poi magari
rimuoverlo nuovamente.
Tutte operazioni un po' delicate e da fare con attenzione su shapefiles buoni.
Comunque meglio cosi' che doverli risalvare ex-novo per i problemi gia' esposti.
:slight_smile:

Proseguendo:
A questo link dropbox
https://www.dropbox.com/s/igbt5k9r9dfob93/logical_delete.7z?dl=0

E' possibile scaricare uno shapefile che ho preparato con qgis 2.12.
In esso se si apre con qgis si vede 1 record solo.
Se invece si apre con MapWidows si vedono 3 records.
:slight_smile:

Idem ritengoche si vedrebbero 3 records se si carica su postgis . Non
ho provato ma ne sono abbastanza sicuro, non mi risulta che postgis
abbia risolto questo problema. Ma strk potra' essere piu' preciso.

Immagino che sarebbe lo stesso se si usa OpenJump, Arcgis, o altro
software gfoss diverso da spatialite ultima versione o da qgis.

Riporto anche i messaggio che ritorna il tool di Furieri quando si
ispeziona in modalit'a diagnostica:

----------------------------------------------------------
Input dir: ./
Only a diagnostic report will be reported

Verifying .//logical_delete.shp
                row #1: logical deletion found
                row #2: logical deletion found
                HEADERS: found invalid BBOX
        found 3 invalidities: cleaning required.

===========================================
1 Shapefile has been inspected.
1 malformed Shapefile has been identified.
0 Shapefile has been repaired.
----------------------------------------------------------

Saluti,

A.

Il 20 ottobre 2016 14:24, Andrea Peri <aperi2007@gmail.com> ha scritto:

(non so costa intendi per "esportare").

esportare => save as

Mi sembra di capire (senza averlo provato) che se applichi una
modifica, al salvataggio dovresti trovare i record fantasmi rimossi.
Mi confermi anche questo

A me risulta di no.

Quando mi e' capitato l'ultima volta ho messo in editing e pi richiuso
confermando il salvataggio.
Ma il records fantasma e' rimasto.

Io usavo la 2.14 , non credo che la 2.16 su questo abbia fatto cambiamenti.

Il punto e' che se non si usa un sogtware gis differente da qgis,
questa cosa che con l'editing resta presente il record fantasma non si
riesce a rilevarla perche' qgis non fornisce elementi che informino
della presenza del record fantasma.

Noi abbiamo arcview3 della esri e con esso rileviamo che il record e'
ancora presente, ma capisco che chi lavora esclusivamente con qgis e'
in difficolta' in questo frangente.

Come risposto a Allegri stasera vedo di mettere a disposizione uno
shapefile siffatto, ma ribadiscoche e' praticamente impossibile per
chi opera con qgis rilevare questo dettaglio.

A.

Il 20 ottobre 2016 14:13, strk <strk@keybit.net> ha scritto:

On Thu, Oct 20, 2016 at 02:01:23PM +0200, Andrea Peri wrote:

La migliore soluzione sarebbe che preso atto che la specifica
shapefile non ammette la presenza dei records cancellati logicamente,
i nuovi qgis dovrebbero segnalare la presenza di questi records e nel
caso correggerli di loro iniziativa quando si apre e si richiude una
sessione di editing.

Mi sembra di capire (senza averlo provato) che se applichi una
modifica, al salvataggio dovresti trovare i record fantasmi rimossi.
Mi confermi anche questo ? (non so costa intendi per "esportare").

Ad ogni modo: apri un ticket per una feature-request ?

--strk;

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

Ho scaricato il file fornito da Andrea,

On 21/10/2016 00:51, Andrea Peri wrote:

E' possibile scaricare uno shapefile che ho preparato con qgis 2.12.
In esso se si apre con qgis si vede 1 record solo.
Se invece si apre con MapWidows si vedono 3 records.
:slight_smile:

In realtà aprendo il file in QGIS 2.16.2 (in Ubuntu 16.04), le feature non si vedono, ma si vede che ci sono :slight_smile:
Nel senso che se si fa "Zoom to layer" l'estensione riconosciuta è quella di tutte e 3 le features; inoltre, cliccando sul nome del layer in legenda e poi "Show feature count", appare in effetti "3".

Sull'issue tracker di QGIS ho trovato questo issue http://hub.qgis.org/issues/11007 che include link a tanti altri simili, chiuso a occhio perché troppo lungo, poi riaperto su http://hub.qgis.org/issues/15407, che è stato chiuso due settimane fa.

Strk, non sarebbe possibile attivare (magari in modo opzionale) un check sugli shapefile presenti in un progetto QGIS in modo che vengano segnalate queste anomalie, così un utente almeno sa esplicitamente quali layers hanno questo specifico problema?
E' da aprire un altro issue in proposito? Non vorrei fare casino, cosa suggerisci di riportare in modo che sia utile?

Ale

--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com <http://ilsarrett.wordpress.com>

Research information:

  * Google scholar profile
    <http://scholar.google.it/citations?user=IsyXargAAAAJ&hl=it&gt;
  * ORCID <http://orcid.org/0000-0002-1475-8686&gt;
  * Research Gate <https://www.researchgate.net/profile/Alessandro_Sarretta&gt;
  * Impactstory <https://impactstory.org/AlessandroSarretta&gt;

Grazie per le preziose informazioni.
Ammetto che ad attivare la opzione feature-count non ci avevo pensato,
e se anche ci avessi pensato non avrei creduto che potesse rilevare il
numero esatto di feature.

Mi domando "feature count" che numero riporterebbe se impostassi un
qualche tipo di filtraggio.
Ma questa e' una altra storia.
:slight_smile:

Una considerazione che rivolgo alla platea di chi legge:
Questo aspetto dei records fantasma non va' sottovalutato. E'
veramente importante che si riesca a superare questo scoglio e per
questo occorre sensibilizzare qando si incontraqualcuno che opera con
vecchie versioni di QGIS a cambiare versione e a passare a una
versione molto recente. Almeno la 2.14.5 (la 2.14.4 potrebbe essere
bugged anche lei) o la 2.16.

E' di giorni fa' uno scambio di email che ho avuto con un tecnico di
un piccolo ente locale che per altre ragioni utilizzava ancora qgis
2.0.1 (o 2.1) insomma un qgis stravecchio.
Spesso i tecnici che operano con i gis tendono a non cambiare la loro
piattaforma su cui operano da anni. Vuoi perche' temono di perdere i
progetti pre-impostati. A maggior ragione nei piccoli enti ove non
hann tempo da perdere e temono i problemi che un passaggio di
versione potrebbe presentare.
E qui ci sta' il solito rammarico che QGIS in passato non si e'
preoccupato abbastanza di conservare la compatibilita' con versioni
precedenti. Problema che indirettamente condiziona anche questo
problema perche' invoglia i tecnici degli enti locali a congelarsi su
una versione di qgis troppo vecchia e con il bug dei records-fantasma.

Non avete idea di quante persone stanno ancora usando vecchie versioni
di QGIS solamente perche' ormai hanno troppi progetti e nessuna voglia
o tempo di rimettere mano a tutto quanto per rimettere le cose a
posto.

Per questo il mio suggerimento e' familiarizzare con il tool da linea
di comando che ha scritto furieri. Che si sta rilevando abbastanza
valido.
Rileva i records fantasma, e rigenera gli shapefiles (in copia senza
sovrascrivere gli originali) in versione corretta.
Come surplus che non fa' mai male, corregge anche le invalidita'
geometriche . Argomento anche esso che per varie vicissitudini e'
sempre stato difficile da trattare su QGIS.

Unico neo, non scava ricorsivamente nelle sottocartelle.
Per cui occorre inbastire una procedurina batch che provveda lei a
spazzolare tutte le cartelle per ripulire.

L'importante e' ricordarsi di usarlo.
Il problema sta tutto li' e non e' poco, visto le sempre piu'
affollate ed agitate giornate lavorative che si hanno spingono sempre
piu' correre e si finisce per dimenticarsi di queste cose.

A.

Il 21 ottobre 2016 04:34, Alessandro Sarretta
<alessandro.sarretta@gmail.com> ha scritto:

Ho scaricato il file fornito da Andrea,

On 21/10/2016 00:51, Andrea Peri wrote:

E' possibile scaricare uno shapefile che ho preparato con qgis 2.12.
In esso se si apre con qgis si vede 1 record solo.
Se invece si apre con MapWidows si vedono 3 records.
:slight_smile:

In realtà aprendo il file in QGIS 2.16.2 (in Ubuntu 16.04), le feature non
si vedono, ma si vede che ci sono :slight_smile:
Nel senso che se si fa "Zoom to layer" l'estensione riconosciuta è quella di
tutte e 3 le features; inoltre, cliccando sul nome del layer in legenda e
poi "Show feature count", appare in effetti "3".

Sull'issue tracker di QGIS ho trovato questo issue
http://hub.qgis.org/issues/11007 che include link a tanti altri simili,
chiuso a occhio perché troppo lungo, poi riaperto su
http://hub.qgis.org/issues/15407, che è stato chiuso due settimane fa.

Strk, non sarebbe possibile attivare (magari in modo opzionale) un check
sugli shapefile presenti in un progetto QGIS in modo che vengano segnalate
queste anomalie, così un utente almeno sa esplicitamente quali layers hanno
questo specifico problema?
E' da aprire un altro issue in proposito? Non vorrei fare casino, cosa
suggerisci di riportare in modo che sia utile?

Ale

--
--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com <http://ilsarrett.wordpress.com>

Research information:

* Google scholar profile
   <http://scholar.google.it/citations?user=IsyXargAAAAJ&hl=it&gt;
* ORCID <http://orcid.org/0000-0002-1475-8686&gt;
* Research Gate <https://www.researchgate.net/profile/Alessandro_Sarretta&gt;
* Impactstory <https://impactstory.org/AlessandroSarretta&gt;

_______________________________________________
Gfoss@lists.gfoss.it
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.
807 iscritti al 31/03/2016

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

On Fri, Oct 21, 2016 at 12:51:25AM +0200, Andrea Peri wrote:

Idem ritengoche si vedrebbero 3 records se si carica su postgis . Non
ho provato ma ne sono abbastanza sicuro, non mi risulta che postgis
abbia risolto questo problema. Ma strk potra' essere piu' preciso.

PostGIS importa i record "logicamente cancellati", come verificato
tre settimane fa.

Se qualcuno vuole aiutare a rendere il loader di PostGIS piu' verboso
a riguardo, e magari dare la scelta all'utente riguardo il da farsi,
puo' seguire il ticket aperto contestualmente e fornire una patch:

  https://trac.osgeo.org/postgis/ticket/3645

--strk;

  () Free GIS & Flash consultant/developer
  /\ https://strk.kbt.io/services.html

On Fri, Oct 21, 2016 at 04:34:59AM +0200, Alessandro Sarretta wrote:

Strk, non sarebbe possibile attivare (magari in modo opzionale) un check
sugli shapefile presenti in un progetto QGIS in modo che vengano segnalate
queste anomalie, così un utente almeno sa esplicitamente quali layers hanno
questo specifico problema?

Mi sembra una buona idea.

E' da aprire un altro issue in proposito? Non vorrei fare casino, cosa
suggerisci di riportare in modo che sia utile?

Una "feature-request": che venga segnalata all'utente la presenza di
"record fantasmi" negli shapefile che si aprono, e venga data la
possibilita' di rimuoverli.

--strk;

On Fri, Oct 21, 2016 at 04:34:59AM +0200, Alessandro Sarretta wrote:

Nel senso che se si fa "Zoom to layer" l'estensione riconosciuta è quella di
tutte e 3 le features; inoltre, cliccando sul nome del layer in legenda e
poi "Show feature count", appare in effetti "3".

Ho aperto un ticket per il "Show feature count":
http://hub.qgis.org/issues/15735

Puoi aprirne un'altro per lo "Zoom to layer" ?

Con quell'altro (feature request) fanno 3 ticket, ma questi due sono
da considerare bug.

--strk;

Ecco qui i due ulteriori issue:

  * Wrong "Zoom to layer" extent on a shapefile layer with logically
    deleted records: http://hub.qgis.org/issues/15739
  * Inform user of logically deleted records in shapefiles and allow
    removal: http://hub.qgis.org/issues/15740

Ale

On 21/10/2016 10:14, Sandro Santilli wrote:

On Fri, Oct 21, 2016 at 04:34:59AM +0200, Alessandro Sarretta wrote:

Nel senso che se si fa "Zoom to layer" l'estensione riconosciuta è quella di
tutte e 3 le features; inoltre, cliccando sul nome del layer in legenda e
poi "Show feature count", appare in effetti "3".

Ho aperto un ticket per il "Show feature count":
http://hub.qgis.org/issues/15735

Puoi aprirne un'altro per lo "Zoom to layer" ?

Con quell'altro (feature request) fanno 3 ticket, ma questi due sono
da considerare bug.

--strk;

--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com <http://ilsarrett.wordpress.com>

Research information:

  * Google scholar profile
    <http://scholar.google.it/citations?user=IsyXargAAAAJ&hl=it&gt;
  * ORCID <http://orcid.org/0000-0002-1475-8686&gt;
  * Research Gate <https://www.researchgate.net/profile/Alessandro_Sarretta&gt;
  * Impactstory <https://impactstory.org/AlessandroSarretta&gt;

On Sat, Oct 22, 2016 at 08:01:42AM +0200, Alessandro Sarretta wrote:

Ecco qui i due ulteriori issue:

* Wrong "Zoom to layer" extent on a shapefile layer with logically
   deleted records: http://hub.qgis.org/issues/15739
* Inform user of logically deleted records in shapefiles and allow
   removal: http://hub.qgis.org/issues/15740

Grazie mille.
Ora si tratta di trovare risorse per risolverli.

--strk;

Ho fatto una prova con QGis 1.8.0 Lisboa (che uso in ufficio). Creato uno
shapefile con sei punti, poi cancellati tre; risultato: 3 punti in QGis e 3
punti con ArcMap.

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Segnalazione-in-merito-a-incompatibilita-sugli-shapefiles-di-QGIS-tp7596284p7596327.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.

Se guardi lo shapefile inserito nel ticket da Santilli.
Vedi 1 record o tre ?

Il 26 ott 2016 09:56, "Marco Curreli" <marcocurreli@tiscali.it> ha scritto:

Ho fatto una prova con QGis 1.8.0 Lisboa (che uso in ufficio). Creato uno
shapefile con sei punti, poi cancellati tre; risultato: 3 punti in QGis e 3
punti con ArcMap.

--
View this message in context: http://gfoss-geographic-free-
and-open-source-software-italian-mailing.3056002.n2.
nabble.com/Segnalazione-in-merito-a-incompatibilita-
sugli-shapefiles-di-QGIS-tp7596284p7596327.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian
mailing list mailing list archive at Nabble.com.
_______________________________________________
Gfoss@lists.gfoss.it
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.
807 iscritti al 31/03/2016