[Gfoss] Errore nel backUp di postgres

Local Chapters GFOSS.it
,
1

Che versione di postgis usi ?

In ogni caso

puoi fare un

select * from public.pyuscaratterizzazioni where st_isvalid(geom)=false

per vedere se e quante geometrie non-valide ci sono.

Poi, se come immagino, hai postgis 1.5.0 ci puoi fare poco.

e secondo me l'unica cosa che potresti fare e' editare a mano le geometrie errate con qgis e correggerle tanto da renderle valide.

E' molto probabile che il comando pg_dump quando tenta di convertire la geometria in una codifica 'hex',
trovandola non valida non riesca a convertirla.

questo per te' e' un problema.
Infatti la versione 1.5 di postgis non permette di "portar via" dal DB le geometrie non valide, e quindi se anche
tu decidessi di spostarti su una versione successiva di postgis ove sarebbe possibile qualche altro tipo di intervento,
non riusciresti a spostare le geometrie non valide dalla tua versione a quella di destinazione.

Per cui, secondo me l'unica cosa che puoi fare per non perdere le geometrie non editabili e' correggerle con qgis direttamente su postgres.
Comunque anche editarle non e' banale, anche perche' non hai modo di sapere che tipo di errore e' presente.
Nella versione 1.5 di pg questo tipo di problematiche sono un po' sottovalutate.

Andrea.

2

Ciao Andrea e grazie per la risposta.

Sono su un server Ubuntu 4.4.1 , Postgres8.4 e Postgis 1.4. Le geometrie che mi da non valide sono allegramente 995!!!

A questo punto…mmmm…olio di gomito a quanto ho capito.

ciao e grazue

2010/9/8 Andrea Peri 2007 <aperi2007@gmail.com>

Che versione di postgis usi ?

In ogni caso

puoi fare un

select * from public.pyuscaratterizzazioni where st_isvalid(geom)=false

per vedere se e quante geometrie non-valide ci sono.

Poi, se come immagino, hai postgis 1.5.0 ci puoi fare poco.

e secondo me l’unica cosa che potresti fare e’ editare a mano le geometrie errate con qgis e correggerle tanto da renderle valide.

E’ molto probabile che il comando pg_dump quando tenta di convertire la geometria in una codifica ‘hex’,
trovandola non valida non riesca a convertirla.

questo per te’ e’ un problema.
Infatti la versione 1.5 di postgis non permette di “portar via” dal DB le geometrie non valide, e quindi se anche
tu decidessi di spostarti su una versione successiva di postgis ove sarebbe possibile qualche altro tipo di intervento,
non riusciresti a spostare le geometrie non valide dalla tua versione a quella di destinazione.

Per cui, secondo me l’unica cosa che puoi fare per non perdere le geometrie non editabili e’ correggerle con qgis direttamente su postgres.
Comunque anche editarle non e’ banale, anche perche’ non hai modo di sapere che tipo di errore e’ presente.
Nella versione 1.5 di pg questo tipo di problematiche sono un po’ sottovalutate.

Andrea.

3

On Thu, 9 Sep 2010 09:43:55 +0200, Luca Mandolesi wrote

Ciao Andrea e grazie per la risposta.

Sono su un server Ubuntu 4.4.1 , Postgres8.4 e Postgis 1.4. Le geometrie che mi da non valide sono allegramente 995!!!

A questo punto…mmmm…olio di gomito a quanto ho capito.

per inciso: questo è un problema assolutamente generalizzato.

anche io personalmente, quando ho deciso di rafforzare
i controlli di validità su SpatiaLite ho scoperto che in pratica
la stragrande maggioranza degli SHP attualmente in circolazione
contiene un numero mostruoso di “geometrie pazze”.

giusto per fare un piccolo “catalogo degli orrori”:

  • linestring con un solo vertice (i.e., un point)
  • vertici ripetuti enne volte
  • ring con due soli vertici (i.e., un linestring)
  • ring non chiusi (l’ultimo vertice non coincide con il primo)
  • ring con autointersezioni, spikes etc
  • multipolygon con sovrapposizioni tra i polygon elementari etc

N.B. tutte queste sono vere e proprie “mostruosità matematiche”,
e possono anche mandare in crash i sistemi :frowning:

Le versioni più recenti di PostGis (ma sarebbe più corretto
dire di GEOS) fortunatamente iniziano a ‘sputare via’ tutte
queste mostruosità.

se ti interessa, nelle ultime versione di SpatiaLite-GUI
è implementato un tool che consente di “medicare”
le ‘farfalle’ più grossolane.

conclusione: grazie ESRI, che per lunghi anni hai consentito
con i tuoi strumenti “professionali” di produrre queste schifezze
senza sottoporle a nessun tipo di controllo :slight_smile:

ciao Sandro

4

se ti interessa, nelle ultime versione di SpatiaLite-GUI
è implementato un tool che consente di “medicare”
le ‘farfalle’ più grossolane.

Interessante! Spero nell’inverno di potermi dedicare a Spatialite per integrarlo appieno e in maniera efficiente nel mio plugin per Qgis. Ma da archeologo la strada è sempre lunga e ardua.

conclusione: grazie ESRI, che per lunghi anni hai consentito
con i tuoi strumenti “professionali” di produrre queste schifezze
senza sottoporle a nessun tipo di controllo :slight_smile:

ciao Sandro

Ho controllato le geometrie che mi danno errore e per ora ho riscontrato sempre il medesimo problema: sono disegnate “a fiocchetto”, la linea del contorno si inviluppa su se stessa e purtroppo (ma anche per fortuna), essendo dei simboli convenzionali disegnati come geometrie, è stato fatto un copia incolla replicando il medesimo errore ovunque. Quindi credo proprio che proverò Spatialite e vediamo se si risolve in fretta.

Una domanda: io tali errori li ho generati con Qgis disegnando su postgres, come mai ti riferisci a ESRI? Vorresti dire che Qgis non dovrebbe ammettere simili errori e quindi ho un problema con Qgis che non conosco e me lo sto portando dietro???

5

On Thu, 9 Sep 2010 11:20:45 +0200, Luca Mandolesi wrote

Una domanda: io tali errori li ho generati con Qgis disegnando su postgres, come mai ti riferisci a ESRI?
Vorresti dire che Qgis non dovrebbe ammettere simili errori e quindi ho un problema con Qgis che non
conosco e me lo sto portando dietro???

No, evidentamente nel tuo caso il problema sono i “fiocchetti” e come sono disegnati,
ESRI non c’entra per nulla …

ma in linea di massima un sacco di cartografia è stata prodotta con strumenti ESRI,
evidente confidando nel fatto che:
“uso il meglio del meglio, e mi costa pure un sacco, quindi tutto sarà perfetto”

ma con solare evidenza questo non basta affatto per essere sicuri di non produrre
“cacca digitale”: evidentemente il problema è più generale: utilizzare un desktop-gis
non è sufficiente, solo gli Spatial-DBMS sembrano implementare un “controllo serio”
su svarioni e castronerie assortite (anche gravi) presenti nelle geometrie.

immagino che il principale “colpevole” (se proprio abbiamo bisogno di identifcare
un colpevole) sia il formato SHP, che di fatto consente di codificare qualsiasi
corbelleria, senza nessun controllo.

ciao Sandro

6

Capisco la tentazione di molti di dare addosso ai prodotti
proprietari, ma in questo caso il dualismo proprietario/libero non
c'entra proprio niente!
Anche le simple feature di OGC, come struttura dati, permettono di
scrivere castronerie. Lo standard poi offre le definizioni per
considerare corretto o meno una geometria, ma non ti evita di crearla.
Ne è un esempio lo stesso Qgis, ma qualsiasi altro prodotto open (ad
eccezione di Grass, che è rigoroso per sua natura): se vuoi evitare il
rischio di editare geometrie non valide, devi abilitare l'editing
"topologico", il quale impone delle regole che non permettono di
salvare le suddette castronerie. Lo stesso vale per i prodotti ESRI.
ArcGis Editor, ad es., permette d'impostare un gran numero di regole
topologiche per controllare la bontà dell'editing.
Quindi, se uno sa usare gli strumenti offerti dal prodotto che usa,
può abbassare il rischio di generare dati sporchi, altrimenti se li
tiene fintanto che una qualche procedura spaziale si pianterà con i
vari "TopologyException" che tormentani i dati su cui dobbiamo
lavorare quotidianamente!

giovanni

Il 09 settembre 2010 11:40, <a.furieri@lqt.it> ha scritto:

On Thu, 9 Sep 2010 11:20:45 +0200, Luca Mandolesi wrote

Una domanda: io tali errori li ho generati con Qgis disegnando su
postgres, come mai ti riferisci a ESRI?
Vorresti dire che Qgis non dovrebbe ammettere simili errori e quindi ho un
problema con Qgis che non
conosco e me lo sto portando dietro???

No, evidentamente nel tuo caso il problema sono i "fiocchetti" e come sono
disegnati,
ESRI non c'entra per nulla ...

ma in linea di massima un sacco di cartografia è stata prodotta con
strumenti ESRI,
evidente confidando nel fatto che:
"uso il meglio del meglio, e mi costa pure un sacco, quindi tutto sarà
perfetto"

ma con solare evidenza questo non basta affatto per essere sicuri di non
produrre
"cacca digitale": evidentemente il problema è più generale: utilizzare un
desktop-gis
non è sufficiente, solo gli Spatial-DBMS sembrano implementare un "controllo
serio"
su svarioni e castronerie assortite (anche gravi) presenti nelle geometrie.

immagino che il principale "colpevole" (se proprio abbiamo bisogno di
identifcare
un colpevole) sia il formato SHP, che di fatto consente di codificare
qualsiasi
corbelleria, senza nessun controllo.

ciao Sandro

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.it
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
460 iscritti al 15.7.2010

7

On 09/set/2010, at 11:56, "G. Allegri" <giohappy@gmail.com> wrote:

se vuoi evitare il
rischio di editare geometrie non valide, devi abilitare l'editing
"topologico", il quale impone delle regole che non permettono di
salvare le suddette castronerie. Lo stesso vale per i prodotti ESRI.
ArcGis Editor, ad es., permette d'impostare un gran numero di regole
topologiche per controllare la bontà dell'editing.
Quindi, se uno sa usare gli strumenti offerti dal prodotto che usa,
può abbassare il rischio di generare dati sporchi, altrimenti se li
tiene fintanto che una qualche procedura spaziale si pianterà con i
vari "TopologyException" che tormentani i dati su cui dobbiamo
lavorare quotidianamente!

giovanni

Totalmente d'accordo
Del resto anche Sandro da giustamente la responsabilità al formato
shape che come molti altri formati vettoriali delega i controlli
topologici all'applicazione che si usa e di conseguenza all'abilita
dell'utente nell'usare l'applicazione.
E' per questo sono preferibili quei formati che abilitano il controllo
con delle regole presenti intrinsecamente nel dato, ad es i formati
basati su RDBMS come Postgis e Spatialite
P

8

E' per questo sono preferibili quei formati che abilitano il controllo
con delle regole presenti intrinsecamente nel dato, ad es i formati
basati su RDBMS come Postgis e Spatialite

E' questo passaggio che continua a non essermi chiaro. In che senso le
regole sono presenti nel dato? Io in Postgis posso tranquillamente
avere geometrie non valide, dal momento che il formato implementa le
SFS OGC. La validazione è un passaggio ulteriore, e non necessario,
per gestire i dati nell'RDMS.

9

E' per questo sono preferibili quei formati che abilitano il controllo
con delle regole presenti intrinsecamente nel dato, ad es i formati
basati su RDBMS come Postgis e Spatialite

forse mi sono perso qualcosa, ma Luca dice di avere editato i dati
tramite QGIS direttamente in PostGIS quindi neanche gli RDBMS sono una
garanzia assoluta.

Ciao,

Stefano

10

E' questo passaggio che continua a non essermi chiaro. In che senso le
regole sono presenti nel dato? Io in Postgis posso tranquillamente
avere geometrie non valide, dal momento che il formato implementa le
SFS OGC. La validazione è un passaggio ulteriore, e non necessario,
per gestire i dati nell'RDMS.

Nel senso che ad es con dei trigger abiliti i controlli topologici sul
dato e a quel punto, qualsiasi applicazione tu stia usando, se violi
una delleregole che hai definito il sistema ti restituisce l'errore e
la feature non viene storata.
P

11

Il problema secondo me e’ un po’ piu’ sottile, e non basta dire colpa dello shapefile che non doveva accettare il dato non valido.

Infatti il problema di Luca e’ che ha una geometria in un ambiente (postgis 1.4) che, come molti prodotti di un certo tipo parte dal principio che il mondo sia sempre perfetto e preciso.

Infatti postgis 1.4 non immagina proprio che una geometria possa diventare non valida a fronte di una qualche operazione di taglio o unione. Cosa invece possibilissima.
Addirittura credo che anche dentro postgis una geometria possa diventare non valida a fronte di determinate operazioni. Non mi e’ mai capitato , ma almeno in linea teorica non lo escluderei a priori.

Questo in postgis 2.0.0 e’ stato risolto, infatti in tale versione hanno implementato una simpatica funzione ST_MakeValid che rende valida una geometria errata, o quanto meno fa in maniera che postgis non dia piu’ errori di eccezione rendendo possibile quindi esportarla o rimaneggiarla o correggerla.

Quello che vorrei sottolineare e’ l’importanza che l’ambiente consenta di lavorare con dati non validi , perche’ altrimenti non si ha modo di poter trasformare un dato non valido in un dato valido.

Se proprio si vuole fare dei distinguo, allora si deve distinguere tra
tra strumenti per “gestire dati gis” dagli strumenti per “creare dati gis”.

I primi devono colloquiare anche con dati non validi perche’ altrimenti non si comincia neanche a pensare come fare per correggerli quando ci capitano davanti.

I secondi invece dovendo pensare a creare dati GIS da zero, e’ ammissibile che non colloquiono con dati non validi perche’ il loro compito e’ crearne di ex-novo.

Pero’ in linea di massima e’ sempre preferibile che gli strumenti colloquino con dati non validi. L’importante e’ avere una strada per poter rilevare e correggere questi dati, o quanto meno avere degli strumenti che fanno la maggior parte del lavoro.
E per poter colloquiare con dati non validi il primo punto e’ avere un formato che consenta di scambiare dati non validi. Non si puo’ certo immagine di passarsi dei dump di postgres, che per giunta sono sensibili alla versione del dbms.

Per cui secondo me e’ bene che lo shapefile consenta di far passare dati non validi.
E’ altrettanto bene che postgis consenta di caricare sul suo db dati non validi, e’ poi importante che fornisca strumenti per identificare e correggere (quando si ritiene di doverlo fare) i dati non validi.

12

Va bene i trigger, ma l’azione non puo’ essere il non caricare il record.

Prova a immaginare cosa vuol dire che una feature non viene “storata” perche’
la sua componente geometrica non e’ valida.

se quella feature aveva una FK verso altre tabelle e cosi’ via a cascata, altri records non verranno storati.
Poi ti ritrovi con dei buchi nella tua copertura, che magari deve essere a totale copertura del suolo e i buchi non sono ammissibili.
E questo solo perche’ vi era un fiocchettino con una area di 10 cm ?

Cavolo !

Per un problema che dal punto di vista della geometria e’ molto probabilmente sotto il limite di validita’ dei dati presenti nella copertura mi si introduce una grana grossa come una montagna record mancanti, vincoli violati, etc…

La soluzione non puo’ essere questa, ma bensi’ storare nel DB comunque, poi si effettua una select che controlla se vi e’ qualcosa di non valido e se presente ci si passa sopra qualcosa che risolve il problema o al limite si corregge a mano, ma non si puo’ cancellare il record.
Cosi’ vi e’ il rischio concreto che spariscano case, solo perche’ avevano un fiocchetto microscopico nella loro geometria.

Il giorno 09 settembre 2010 12:32, Paolo Corti <pcorti@gmail.com> ha scritto:

E’ questo passaggio che continua a non essermi chiaro. In che senso le
regole sono presenti nel dato? Io in Postgis posso tranquillamente
avere geometrie non valide, dal momento che il formato implementa le
SFS OGC. La validazione è un passaggio ulteriore, e non necessario,
per gestire i dati nell’RDMS.

Nel senso che ad es con dei trigger abiliti i controlli topologici sul
dato e a quel punto, qualsiasi applicazione tu stia usando, se violi
una delleregole che hai definito il sistema ti restituisce l’errore e
la feature non viene storata.
P

–

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

13

Nel senso che ad es con dei trigger abiliti i controlli topologici sul
dato e a quel punto, qualsiasi applicazione tu stia usando, se violi
una delleregole che hai definito il sistema ti restituisce l'errore e
la feature non viene storata.

Ah, vabbè, questo equivale a impostare le regole di editing negli
altri software, ma non che il formato dati è di per sé esente da
errori.
Comunque ci siamo capiti :wink:

14

Sent from mobile

On 09/set/2010, at 13:18, "G. Allegri" <giohappy@gmail.com> wrote:

Nel senso che ad es con dei trigger abiliti i controlli topologici sul
dato e a quel punto, qualsiasi applicazione tu stia usando, se violi
una delleregole che hai definito il sistema ti restituisce l'errore e
la feature non viene storata.

Ah, vabbè, questo equivale a impostare le regole di editing negli
altri software, ma non che il formato dati è di per sé esente da
errori.
Comunque ci siamo capiti :wink:

Ma se le definisci nel db le regole lo fai una tantum e il db ti
rimane topologicamente integro a prescindere dall'app usata (qgis,
gvsig, wfst etc...)
P

15

Sent from mobile

On 09/set/2010, at 13:10, Andrea Peri <aperi2007@gmail.com> wrote:

Va bene i trigger, ma l’azione non puo’ essere il non caricare il record.

Prova a immaginare cosa vuol dire che una feature non viene “storata” perche’
la sua componente geometrica non e’ valida.

se quella feature aveva una FK verso altre tabelle e cosi’ via a cascata, altri records non verranno storati.
Poi ti ritrovi con dei buchi nella tua copertura, che magari deve essere a totale copertura del suolo e i buchi non sono ammissibili.
E questo solo perche’ vi era un fiocchettino con una area di 10 cm ?

Cavolo !

Per un problema che dal punto di vista della geometria e’ molto probabilmente sotto il limite di validita’ dei dati presenti nella copertura mi si introduce una grana grossa come una montagna record mancanti, vincoli violati, etc…

La soluzione non puo’ essere questa, ma bensi’ storare nel DB comunque, poi si effettua una select che controlla se vi e’ qualcosa di non valido e se presente ci si passa sopra qualcosa che risolve il problema o al limite si corregge a mano, ma non si puo’ cancellare il record.
Cosi’ vi e’ il rischio concreto che spariscano case, solo perche’ avevano un fiocchetto microscopico nella loro geometria.

Non sono affatto d’accordo.
Uno dei grossi vantaggi di un db relazionale e’ quello di poter gestire l’integrità referenziale dei dati a differenza di formati dati flat.
Eliminare fk, costanti, vincoli ecc ecc al fine di poter comunque caricare i dati per poi correggerli e renderli validi e’ una cosa che a mio avviso nella maggior parte delle situazioni, con db in produzione, non ci si può permettere.
Tali operazioni vanno fatte nelle procedure di caricamento, manuali o automatiche che siano
Poi ognuno la può pensare diversamente eh :wink:
Ciao
P

16

Non credo si possa dire a priori qual'è la strada 'corretta'. Dipende,
ovviamente, dalle specifiche del prodotto.
Io in genere propongo ai clienti il seguente approccio:

- carico tutti i dati in uno stato "raw"
- facio una serie di controlli sulla bontà del dato
- quelli buoni li committo, gli altri li tengo in stato "pending", e
poi valuto col cliente (o chi dovrà comunque usufruire del dato) il da
farsi. Talvolta il pending viene scartato, talvolta viene accettato ma
annotando eventuali problemi nei metadati.

giovanni

Il 09 settembre 2010 14:57, Paolo Corti <pcorti@gmail.com> ha scritto:

Sent from mobile
On 09/set/2010, at 13:10, Andrea Peri <aperi2007@gmail.com> wrote:

Va bene i trigger, ma l'azione non puo' essere il non caricare il record.

Prova a immaginare cosa vuol dire che una feature non viene "storata"
perche'
la sua componente geometrica non e' valida.

se quella feature aveva una FK verso altre tabelle e cosi' via a cascata,
altri records non verranno storati.
Poi ti ritrovi con dei buchi nella tua copertura, che magari deve essere a
totale copertura del suolo e i buchi non sono ammissibili.
E questo solo perche' vi era un fiocchettino con una area di 10 cm ?

Cavolo !

Per un problema che dal punto di vista della geometria e' molto
probabilmente sotto il limite di validita' dei dati presenti nella copertura
mi si introduce una grana grossa come una montagna record mancanti, vincoli
violati, etc...

La soluzione non puo' essere questa, ma bensi' storare nel DB comunque, poi
si effettua una select che controlla se vi e' qualcosa di non valido e se
presente ci si passa sopra qualcosa che risolve il problema o al limite si
corregge a mano, ma non si puo' cancellare il record.
Cosi' vi e' il rischio concreto che spariscano case, solo perche' avevano un
fiocchetto microscopico nella loro geometria.

Non sono affatto d'accordo.
Uno dei grossi vantaggi di un db relazionale e' quello di poter gestire
l'integrità referenziale dei dati a differenza di formati dati flat.
Eliminare fk, costanti, vincoli ecc ecc al fine di poter comunque caricare i
dati per poi correggerli e renderli validi e' una cosa che a mio avviso
nella maggior parte delle situazioni, con db in produzione, non ci si può
permettere.
Tali operazioni vanno fatte nelle procedure di caricamento, manuali o
automatiche che siano
Poi ognuno la può pensare diversamente eh :wink:
Ciao
P

17

On Thu, Sep 09, 2010 at 09:43:55AM +0200, Luca Mandolesi wrote:

Ciao Andrea e grazie per la risposta.

Sono su un server Ubuntu 4.4.1 , Postgres8.4 e Postgis 1.4. Le geometrie che
mi da non valide sono allegramente 995!!!

A questo punto....mmmm....olio di gomito a quanto ho capito.

Da papi Paul Ramsey:

http://s3.opengeo.org/postgis-power.pdf

qualche trucco si puo' usare, vedere la sezione apposita delle slide.
Comunque se il tutto deriva da rappresentazioni topologicamente
inconsistenti (aka shapefile) o che hanno vincoli semplicemente
*diversi* sulla topologia, c'e' poco da fare tranne uno script
che si smazza il DB e con apposita euristica individua e propone
una variazione. Scriverlo in Lisp, Prolog o Occaml sarebbe probabilmente
la cosa piu' adatta :wink:

--
Francesco P. Lovergine