Errore nel backUp di postgres
Locked
 
|
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. _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
|
|
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 <[hidden email]>
_______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
|
|
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 :-( 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 :-) ciao Sandro _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
|
|
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.
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???
_______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
|
|
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 [hidden email] 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 |
|
|
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, <[hidden email]> 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 > [hidden email] > 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 > Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
Re: Errore nel backUp di postgres
|
|
On 09/set/2010, at 11:56, "G. Allegri" <[hidden email]> 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 > > 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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
|
|
> 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. _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
Re: Errore nel backUp di postgres
|
|
In reply to this post by Paolo Corti
> 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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
Re: Errore nel backUp di postgres
|
|
In reply to this post by giohappy
> 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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
Re: Errore nel backUp di postgres
|
|
In reply to this post by a.furieri
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. _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
Re: Errore nel backUp di postgres
|
|
In reply to this post by Paolo Corti
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 <[hidden email]> ha scritto:
-- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
|
|
In reply to this post by Paolo Corti
> 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 ;) _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
Re: Errore nel backUp di postgres
|
|
In reply to this post by Andrea Peri
>> 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 Certo che e' possibile che una geometria diventi non valida dentro postgis. E' possibile in qualsiasi ambiente: oracle, sde, shapefile,postgis e anche spatialite. E' una problematica che attiene alla rappresentazione del dato che nei computer e' sempre in una aritmetica finita e non infinita. A parole di parla di numeri reali, ma nella realta' dei computers i numeri reali non sono , e quando effettui delle operazioni di taglio, ad esempio, introduci dei vertici che hanno dei leggerissimi (a livelli microscopici) spostamenti, che pero' si moltiplicano per ogni singolo taglio che fai sulla medesima geometria questo effetto a cascata introduce delle somme di spostamenti che come effetto ultimo possono causare lo scavalcamento di un vertice rispetto a un altro e di conseguenza la nascita dei mitici fiocchetti. Insomma questo succede in qualunque ambiente, postgis compreso. Cambia solo l'entita dei microspostamenti che determinano questo effetto. Nel geodatabase la griglia e' variabile ma generalmente piu' grossa rispetto a postgis, in postgis ha un certo grado di finezza (molto elevato), in oracle la grana e' variabile e credo possa raggiungere sotto certe condizioni quella di postgis. Ma ribadisco che anche postgis ha una griglia e quindi puo' accedere anche li'. Va aggiunto che alla nascita dei fiocchetti , oltre alla dimensione della griglia, concorre anche gli algoritmi impiegati nelle varie operazioni di taglio e cuci che i GIS compiono, e li' pero' mi fermo perche' non so' che algoritmi usano i vari strumenti. In realta' andrebbe poi chiarito che nel caso di postgis si dovrebbe in realta parlare di Geos , perche' postgis usa Geos per tutte queste operazioni. Come pure nel caso del geodatabase , in realta' si dovrebbe parlare di arcview/arceditor perche' e' lui lo strumento che effettua realmente l'operazione. -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
|
|
Dopo aver letto la vostra discussione ho fatto un po' di prove.
Ho creato un layer postgis vuoto e ci ho incollato dentro le geometrie non valide che ho nel layer che non mi backuppa, quelle col 'fiocchetto' per intenderci. Ho disegnato io stesso da qgis dei fiocchetti sia senza che con l'editing topologico attivo, oppure con l'impedisce intersezione, ma nulla, qgis mi fa chiudere la modifica e i dati sono salvati. A questo punto ho provato a fare il backup di questo layer di test e il back up viene eseguito correttamente, nonostante la query di validazione delle geometrie mi dica che tutte le geometrie presenti sono errate.
ergo: i cari "fiocchetti" son ben accetti mentre non ho individuato il problema sul back up dato dal: ERROR: geometry contains non-closed rings. Cercherò queste geometrie non chiuse e provo a capire come sono state generate.
ciao luca
_______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
Re: Errore nel backUp di postgres
|
|
>ergo: i cari "fiocchetti" son ben accetti mentre non ho individuato
il problema sul back up >dato dal: ERROR: geometry contains non-closed
rings. Una ipotesi potrebbe essere che si trattava in origine di "holes" in un poligono. A causa di operazioni varie, si sono contratti diventando delle linee in cui il vertice iniziale e quello finale non coincidono. a questo punto saresti passato da poligono con buco interno a poligono con linea non chiusa interna, classificata pero' come poligono. Chiaramente poiche' postgis si aspetta una geometria poligonale a delimitare il buco, il fatto che il vertice iniziale e quello finale non coincidano e' per lui un chiaro errore che ti segnala. Il giorno 09 settembre 2010 13:39, Luca Mandolesi <[hidden email]> ha scritto: Dopo aver letto la vostra discussione ho fatto un po' di prove. -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
Re: Errore nel backUp di postgres
|
|
In reply to this post by giohappy
Sent from mobile
On 09/set/2010, at 13:18, "G. Allegri" <[hidden email]> 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 ;) 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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
Re: Errore nel backUp di postgres
|
|
In reply to this post by Andrea Peri
Sent from mobile
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 ;) Ciao P
_______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
|
|
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 <[hidden email]> ha scritto: > > Sent from mobile > On 09/set/2010, at 13:10, Andrea Peri <[hidden email]> 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 ;) > Ciao > P Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
Re: Errore nel backUp di postgres
|
|
In reply to this post by mando
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 ;-) -- Francesco P. Lovergine _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] 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 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |