Segnalazione in merito a incompatibilita' sugli shapefiles di QGIS

[Andrea Peri]

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 àèìòù
-----------------
_______________________________________________
[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.
807 iscritti al 31/03/2016

[giohappy]

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 <[hidden email]> 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 àèìòù
> -----------------
> _______________________________________________
> [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.
> 807 iscritti al 31/03/2016

_______________________________________________
[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.
807 iscritti al 31/03/2016

[Sandro Santilli-2]

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;
_______________________________________________
[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.
807 iscritti al 31/03/2016

[Andrea Peri]

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 <[hidden email]> 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 àèìòù
-----------------
_______________________________________________
[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.
807 iscritti al 31/03/2016

[Andrea Peri]

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 <[hidden email]> 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 <[hidden email]> 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 àèìòù
>> -----------------
>> _______________________________________________
>> [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.
>> 807 iscritti al 31/03/2016
>
>

--
-----------------
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.
807 iscritti al 31/03/2016

[Sandro Santilli]

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;

_______________________________________________
[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.
807 iscritti al 31/03/2016

[Andrea Peri]

>(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 <[hidden email]> 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 àèìòù
-----------------
_______________________________________________
[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.
807 iscritti al 31/03/2016

[a.furieri]

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
_______________________________________________
[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.
807 iscritti al 31/03/2016

[Sandro Santilli]

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;
_______________________________________________
[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.
807 iscritti al 31/03/2016

[Andrea Peri]

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.
:)

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.
:)

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 <[hidden email]> 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 <[hidden email]> 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 àèìòù
-----------------
_______________________________________________
[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.
807 iscritti al 31/03/2016

[Andrea Peri]

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.

:(

A.


Il 21 ottobre 2016 00:51, Andrea Peri <[hidden email]> 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.
> :)
>
> 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.
> :)
>
> 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 <[hidden email]> 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 <[hidden email]> 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 àèìòù
-----------------
_______________________________________________
[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.
807 iscritti al 31/03/2016

[Alessandro Sarretta]

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.
> :)
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 :-)
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>
  * ORCID <http://orcid.org/0000-0002-1475-8686>
  * Research Gate <https://www.researchgate.net/profile/Alessandro_Sarretta>
  * Impactstory <https://impactstory.org/AlessandroSarretta>


_______________________________________________
[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.
807 iscritti al 31/03/2016

[Andrea Peri]

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.
:)

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
<[hidden email]> 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.
>> :)
>
> 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 :-)
> 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>
>  * ORCID <http://orcid.org/0000-0002-1475-8686>
>  * Research Gate <https://www.researchgate.net/profile/Alessandro_Sarretta>
>  * Impactstory <https://impactstory.org/AlessandroSarretta>
>
>
> _______________________________________________
> [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.
> 807 iscritti al 31/03/2016

--
-----------------
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.
807 iscritti al 31/03/2016

[Sandro Santilli]

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
_______________________________________________
[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.
807 iscritti al 31/03/2016

[Sandro Santilli-2]

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;
_______________________________________________
[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.
807 iscritti al 31/03/2016

[Sandro Santilli-2]

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;
_______________________________________________
[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.
807 iscritti al 31/03/2016

[Lorenzo Luisi]

Salve,
non entro nel merito delle modalità per eliminare definitivamente i record
cancellati solo virtualmente.
Vorrei solo far notare che la richiesta all'utente di decidere cosa farne
dei record zombie, mi sembra inutile, soprattutto se si parla di file
vecchi.
Per quanto mi riguarda se decido di cancellare un oggetto (o molti oggetti)
è perché voglio proprio farlo e voglio eliminare dalla mente il pensiero di
ricordarmi di averlo/i cancellato/i e andare a rivedere se QGis (o altri)
l'ha proprio fatto con gli oggetti che io ho ritenuto di cancellare!
Scusate per l'intromissione e buona giornata a tutti,
Lorenzo Luisi


--
*Lorenzo Luisi* [Cartografia - Stereoscopia - Fotointerpretazione - SIT/GIS]
[phone] www.spaziocartograficopugliese.it
https://it.linkedin.com/in/lorenzolusispazcartpugliese

_______________________________________________
[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.
807 iscritti al 31/03/2016

[Sandro Santilli-2]

On Fri, Oct 21, 2016 at 12:53:33PM +0200, Lorenzo Luisi wrote:

> Salve,
> non entro nel merito delle modalità per eliminare definitivamente i record
> cancellati solo virtualmente.
> Vorrei solo far notare che la richiesta all'utente di decidere cosa farne
> dei record zombie, mi sembra inutile, soprattutto se si parla di file
> vecchi.
> Per quanto mi riguarda se decido di cancellare un oggetto (o molti oggetti)
> è perché voglio proprio farlo e voglio eliminare dalla mente il pensiero di
> ricordarmi di averlo/i cancellato/i e andare a rivedere se QGis (o altri)
> l'ha proprio fatto con gli oggetti che io ho ritenuto di cancellare!
> Scusate per l'intromissione e buona giornata a tutti,

Probabilmente sono un maniaco del controllo, ma se uno strumento
software MODIFICA un file senza il mio consenso, lo considero
PERICOLOSO e non raccomandabile.

Magari chi mi ha passato il file voleva cancellare dei dati,
ma puo' anche darsi che io invece voglia leggerli.

E' ora di "svuotare il cestino" ?

--strk;
_______________________________________________
[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.
807 iscritti al 31/03/2016

[Lorenzo Luisi]

Strk,
effettivamente ognuno si regola come meglio può organizzare il proprio
lavoro.
Personalmente consegno file che contengono esattamente quello che devono
contenere e ritengo che chi legge i miei file possa essere solo infastidito
(come mi è capitato di esserlo) dal trovare oggetti che in realtà non ci
dovrebbero essere perché magari erano errati in quanto eccedevano le
tolleranze prescritte.
Al limite, più che cancellare, inserisco oggetti "civetta" per targare
inconfondibilmente quel particolare file :-)

Ad ogni modo non volevo dispensare consigli non richiesti sulle modalità
più opportune per procedere alla soluzione dell'inconveniente tecnico.
Buona serata a tutti,
Lorenzo Luisi


Il giorno 21 ottobre 2016 16:00, Sandro Santilli <[hidden email]> ha scritto:

> On Fri, Oct 21, 2016 at 12:53:33PM +0200, Lorenzo Luisi wrote:
> > Salve,
> > non entro nel merito delle modalità per eliminare definitivamente i
> record
> > cancellati solo virtualmente.
> > Vorrei solo far notare che la richiesta all'utente di decidere cosa farne
> > dei record zombie, mi sembra inutile, soprattutto se si parla di file
> > vecchi.
> > Per quanto mi riguarda se decido di cancellare un oggetto (o molti
> oggetti)
> > è perché voglio proprio farlo e voglio eliminare dalla mente il pensiero
> di
> > ricordarmi di averlo/i cancellato/i e andare a rivedere se QGis (o altri)
> > l'ha proprio fatto con gli oggetti che io ho ritenuto di cancellare!
> > Scusate per l'intromissione e buona giornata a tutti,
>
> Probabilmente sono un maniaco del controllo, ma se uno strumento
> software MODIFICA un file senza il mio consenso, lo considero
> PERICOLOSO e non raccomandabile.
>
> Magari chi mi ha passato il file voleva cancellare dei dati,
> ma puo' anche darsi che io invece voglia leggerli.
>
> E' ora di "svuotare il cestino" ?
>
> --strk;
>

--
*Lorenzo Luisi* [Cartografia - Stereoscopia - Fotointerpretazione - SIT/GIS]
[phone] www.spaziocartograficopugliese.it
https://it.linkedin.com/in/lorenzolusispazcartpugliese

_______________________________________________
[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.
807 iscritti al 31/03/2016

[Sandro Santilli-2]

On Fri, Oct 21, 2016 at 06:35:51PM +0200, Lorenzo Luisi wrote:

> Ad ogni modo non volevo dispensare consigli non richiesti sulle modalità
> più opportune per procedere alla soluzione dell'inconveniente tecnico.

Lorenzo, i consigli sono ben accetti.
I contributi in codice ancora meglio ! :)

--strk;
_______________________________________________
[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.
807 iscritti al 31/03/2016