Ciao a tutti, in questi giorni sto aggiornando il database server prostgresql. Postgresql gira su debian squeeze ed è alla versione 8.2.6. Ho installato in parallelo su porta differente la versione 9.1.4. I due database stanno girando regolarmente. Il mio problema è legato a reimportare i dati. Come suggerito nel manuale ho effettuato il dump con pg_dump della versione 9.1.4, dei dati del 8.2.6, purtroppo con psql, al momento di reimportare i dati, sorgono problemi. Da principio avevo il problema della codifica, il cluster 8.2.6 era LATIN1, mentre 9.1.6 è in UTF8, ho ovviato con pg_dump -E UTF8, ma il problema ad ora non risolto è dato dal fatto che le tabelle dello schema public non vengono reimportate. Reimporto con psql da utente postgres, quindi non mi pare un problema di permessi. L'errore che esce è del tipo: -- PostgreSQL database dump complete -- ERROR: syntax error at or near "public" LINE 1: public iso_2000 the_geom 2 -1 LINESTRING Qualcuno sa darmi qualche dritta? Saluti Eugenio _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 605 iscritti al 10.7.2012 |
Mi sono dimenticato di specificare che sul nuovo db 9.1.6, ho installato
postgis 2.0.1.... Sto vedendo che non esiste più la tabella geometry_columns, o meglio è una vista, quindi forse questo è il mio problema? Nel caso idee per importare i dati?? E. From: [hidden email] To: [hidden email] Subject: postgresql upgrade Date: Wed, 25 Jul 2012 08:14:22 +0000 Ciao a tutti, in questi giorni sto aggiornando il database server prostgresql. Postgresql gira su debian squeeze ed è alla versione 8.2.6. Ho installato in parallelo su porta differente la versione 9.1.4. I due database stanno girando regolarmente. Il mio problema è legato a reimportare i dati. Come suggerito nel manuale ho effettuato il dump con pg_dump della versione 9.1.4, dei dati del 8.2.6, purtroppo con psql, al momento di reimportare i dati, sorgono problemi. Da principio avevo il problema della codifica, il cluster 8.2.6 era LATIN1, mentre 9.1.6 è in UTF8, ho ovviato con pg_dump -E UTF8, ma il problema ad ora non risolto è dato dal fatto che le tabelle dello schema public non vengono reimportate. Reimporto con psql da utente postgres, quindi non mi pare un problema di permessi. L'errore che esce è del tipo: -- PostgreSQL database dump complete -- ERROR: syntax error at or near "public" LINE 1: public iso_2000 the_geom 2 -1 LINESTRING Qualcuno sa darmi qualche dritta? Saluti Eugenio _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 605 iscritti al 10.7.2012 |
Il 25 luglio 2012 10:27, Eugenio Trumpy <[hidden email]> ha scritto:
> Mi sono dimenticato di specificare che sul nuovo db 9.1.6, ho installato > postgis 2.0.1.... > Sto vedendo che non esiste più la tabella geometry_columns, o meglio è una > vista, > quindi forse questo è il mio problema? > > Nel caso idee per importare i dati?? Ciao Eugenio, mai mettere i dati nello schema public ;) Qui trovi un po' di suggerimenti per l'esecuzione di backup e restore, comunque credo che lavorando dato per dato dovresti risolvere: http://blog.cleverelephant.ca/2010/09/postgis-back-up-restore.html A presto L. -- Luca Casagrande http://www.lucacasagrande.net _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 605 iscritti al 10.7.2012 |
> Ciao Eugenio,
> mai mettere i dati nello schema public ;) OT: Perchè? Oddio..non mi fare preoccupare! _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 605 iscritti al 10.7.2012 |
Il 25 luglio 2012 11:49, Luca Mandolesi <[hidden email]> ha scritto:
>> Ciao Eugenio, >> mai mettere i dati nello schema public ;) > > OT: Perchè? Oddio..non mi fare preoccupare! E' solo un vantaggio nell'eseguire aggiornamenti/backup/ripristini..niente di preoccupante :) In questo modo ti fai un dump del tuo schema senza alcuna tabella di sistema o altro legato all'installazione di PostGIS. Nell'articolo postato (e nei commenti presenti) ci sono utili informazioni sulla questione. -- Luca Casagrande http://www.lucacasagrande.net _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 605 iscritti al 10.7.2012 |
Il 25/07/2012 11:58, [hidden email] ha scritto:
> E' solo un vantaggio nell'eseguire > aggiornamenti/backup/ripristini..niente di preoccupante :) In questo > modo ti fai un dump del tuo schema senza alcuna tabella di sistema o > altro legato all'installazione di PostGIS. Nell'articolo postato (e > nei commenti presenti) ci sono utili informazioni sulla questione. comunque dal 2.0 (con pg9.1) in avanti, e' tutto piu' semplice (live, dal corso PGIS2.0 ;) ) -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 605 iscritti al 10.7.2012 |
In reply to this post by frippe12573
Ciao Luca e tutti, il link che mi hai mandato è chiaro, ma forse non del tutto, nel senso che oltre a consigliare di tenere i dati in uno schema diverso dal public per i motivi esposti, non afferro bene se esiste una via diversa che non modificare la posizione dei dati di partenza nel db (altro schema), ne tanto meno se ci sia una via per trasferire tutti i database in con un pg_dumpall o uno per volta. Esperienze a riguardo e altri suggerimenti? Mi è balenata in testa anche l'idea di installare su postgresql 9.1.4 un postgis vecchio, tipo 1.5.x e quindi reimportare i dati in questa configurazione, per poi a restore effettuato fare un postgis_upgrade... malsano? Eugenio > >> Ciao Eugenio, > >> mai mettere i dati nello schema public ;) > > > > OT: Perchè? Oddio..non mi fare preoccupare! > > E' solo un vantaggio nell'eseguire > aggiornamenti/backup/ripristini..niente di preoccupante :) > In questo modo ti fai un dump del tuo schema senza alcuna tabella di > sistema o altro legato all'installazione di PostGIS. > > Nell'articolo postato (e nei commenti presenti) ci sono utili > informazioni sulla questione. > > -- > Luca Casagrande _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 605 iscritti al 10.7.2012 |
In reply to this post by mando
Esiste uno strumento open source per riparare gli shapefile con
geometrie corrotte? Su QGIS c'è lo strumento di controllo, ma come riparare le geometrie corrotte? So solo che su PostGIS 2 c'è la funzione st_makevalid. _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 605 iscritti al 10.7.2012 |
Il 25 luglio 2012 16:02, Pietro d'Orio <[hidden email]> ha scritto:
> Esiste uno strumento open source per riparare gli shapefile con geometrie > corrotte? > grass dovrebbe essere in grado di farlo utilizzando v.clean -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 605 iscritti al 10.7.2012 |
Il problema è che importando uno shape file su grass si perdono le eventuali sovrapposizioni, o sbaglio ?
Il giorno 25 luglio 2012 16:11, Luca Delucchi <[hidden email]> ha scritto: Il 25 luglio 2012 16:02, Pietro d'Orio <[hidden email]> ha scritto: _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 605 iscritti al 10.7.2012 |
Si, diciamo che l'importazione e
l'esportazione degli shapefile da GRASS non è consigliata perchè
GRASS altera le geometrie in base alle sue regole topologiche...
Facendo una domanda più pratica, come risolvete di solito i problemi con geometrie corrotte? Pietro Il 25/07/2012 19:22, Luca Lanteri ha scritto: Il problema è che importando uno shape file su grass si perdono le eventuali sovrapposizioni, o sbaglio ? _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 605 iscritti al 10.7.2012 |
On Mon, 30 Jul 2012 15:23:11 +0200, Pietro d'Orio wrote:
> > Facendo una domanda più pratica, come risolvete di solito i problemi > con geometrie corrotte? > Ciao Pietro, uno dei migliori strumenti in circolazione e' la ST_MakeValid() di PostGIS presto anche su spatialite (e magari anche su altri sw) l'ottimo Strk si e' saggiamente dato da fare per esporre diversi metodi geometrici di utilita' comune dentro a liblwgeom ;-) in pillole: a partire da PostGIS 2.x liblwgeom viene installata come libreria self-standing. dipende solo da GEOS, non ha nessuna dipendenza con PostGIS; casomai e' vero il rovercio, cioe' e' PostGIS che si appoggia su liblwgeom quindi ora qualsiasi altra applicazione open source ora puo' accedere nel modo piu' facile e diretto a diversi metodi geometrici interessanti che prima erano appannaggio esclusivo di PostGIS ciao Sandro -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 605 iscritti al 10.7.2012 |
Free forum by Nabble | Edit this page |