On Sun, 25 Feb 2018 12:00:41 +0100, Andrea Peri wrote:
Forse sarebbe stato meglio introdurre una codifica differente dal
NULLO per gestire l'eccezione ? Boh.
forse tutto considerato la soluzione piu' corretta sarebbe
quella di supportare il geom-type EMPTY, che e' previsto
dalle specifiche OGC
Hai fatot bene a correggermi.
In effetti mi ero sbagliato. Per qualche strana ragione mi e' rimasto in
testa che la tua CastToSimple ritornasse sempre il primo. Forse faceva
cosi' nelle prime versioni ?
Ad ogni modo la prudenza e' sempre d'obbligo perche' se ritorna NUL uno le
perde tutte anziche'
On Sun, 25 Feb 2018 06:48:04 +0100, Andrea Peri wrote:
Sempre esatto e preciso
ma questa volta sento di dover aggiungere un dettaglio ulteriore.
:D
L operatore casttomulti te dici che si può sempre applicare.
Occorre però stare attenti quando si applica per passare da multi a
simple ovvero usand
Sempre esatto e preciso
ma questa volta sento di dover aggiungere un dettaglio ulteriore.
:D
L operatore casttomulti te dici che si può sempre applicare.
Occorre però stare attenti quando si applica per passare da multi a simple
ovvero usando l operatore casttosimple.
Infatti occorre controllare
Ciao Alessandro, grazie mille per la risposta dettagliata :)
Avevo già eseguito nel frattempo dei test in SpatiaLite per vedere se
dovevo applicare le tue indicazioni lì o altrove risolvendo la
problematica. So già che la problematica mi si ripresenterà al prossimo
export ma ora so come affrontarl
On Sat, 24 Feb 2018 19:01:46 +0100, Massimiliano Moraca wrote:
Buonasera a tutti, vi scrivo dopo un po' per aggiornarvi.
Senza fare alcuna modifica al db esportato da PostGIS ed usando un
semplice
drag&drop in QGIS tutti i layer vengono correttamente letti. Il
problema
nasce però dopo un po', i
Mi rispondo da solo dicendo che devo applicare il tutto nel post
esportazione in SpatiaLite.
A questa però non sono arrivato...
Un'altra cosa che non mi è chiara, e l'ho verificata anche in PostGIS: come
> è possibile che da una intersezione di due vettori MultiPolygon ne venga
> fuori uno che è
Buonasera a tutti, vi scrivo dopo un po' per aggiornarvi.
Senza fare alcuna modifica al db esportato da PostGIS ed usando un semplice
drag&drop in QGIS tutti i layer vengono correttamente letti. Il problema
nasce però dopo un po', infatti per non so quale motivo saltano tematismi
ad esempio. Ho qui
Infatti.
Il drag-drop usa il driver gdal ma lo usa in modo semplificato.
La piu' grande differenza che io ho riscontrato e' quando ho una tabella
con piu' campi geometrici.
Il driver spatialite le intercetta tutte e le distingue. Ovvero ti mostra
la lista con tutti i campi geometrici tra cui scegl
Ho capito a che fai riferimento! In quella tabella c'erano 23 righe in
origine poi ho tolto quella con pkca 14 e non ho aggiornato il field. Me ne
ritrovo 22 anche in da PgAdmin :)
Comunque appena ho un po' più di tempo e lucidità mentale eseguo le
procedure che mi avete indicato e vedo che ne vie
controlla bene, la tabella comuni_ambito che aveva inizialmente 23 righe,
dopo dragAndDrop risultano 22.
meglio seguire la procedura descritta e non usare il dragAndDrop che,
credo, non passi per ogr.
notte
Il giorno 7 febbraio 2018 21:45, Massimiliano Moraca <
massimilianomor...@gmail.com> ha s
Salvatore ho fatto come hai indicato ed effettivamente vengono caricati
tutti i layer in maniera corretta(perchè dici che spariscono le geometrie,
a me sono comparse tutte). Quindi potrei bypassare il problema facendo
così? O devo per forza seguire le procedure che sono state indicate nei
vari inte
aggiungo, solo ai fini di aver un quadro più completo, che aggiungendo il
database spatialite (creato con la procedura esposta in questo thread) non
con il provider spatialite ma con il dragAndDrop tutte le tabelle vengono
lette da QGIS; alcune stranezze riscontrate: scomparsa di poligoni;
geometri
Grazie a tutti per le risposte.
Ancora non ho avuto modo di applicare le indicazioni che mi avete dato,
spero di farlo questo fine settimana. Vi tengo aggiornati.
Il giorno 7 febbraio 2018 18:48, Andrea Peri ha
scritto:
> Grazie a te che scrivendo articoli crei una base di letture da cui un nuov
Grazie a te che scrivendo articoli crei una base di letture da cui un nuovo
utente può partire per navigare in questo complicato universo.
Il 07 Feb 2018 18:25, "Totò Fiandaca" ha
scritto:
> Vorrei esprimere la mia gratitudine a Andrea Peri e Alessandro Furieri per
> le spiegazioni, chiare ed ef
Vorrei esprimere la mia gratitudine a Andrea Peri e Alessandro Furieri per
le spiegazioni, chiare ed efficaci.
Ho fatto delle prove sul db messo a disposizione da Massimiliano, seguendo
i consigli di Furieri, tutto funziona alla perfezione.
grazie
forse scriverò un articolo su questo thread.
sa
Su mapserver quando accedo spatialite uso un trucco mitico che mi insegnò
even rouault.
Anziché chiamare il.dataset direttamente in loco una query. Se il dataset e
ha due campi geometrici uno di nome centroide e l altro dimtipo altro e
con nome geometry e il dataset si chiama pippo , uso questa q
On Wed, 7 Feb 2018 12:06:06 +0100, Totò Fiandaca wrote:
correggetemi se dico fesserie:
una soluzione sarebbe quella di aggiungere un altro campo geometry
(es:
geom, definirlo per bene) alle tabelle e popolarle con la geometria
con un
UPDATE.
credo funzioni.
si, dovrebbe funzionare, ma il
A gdal , se ci sono più campi geometrici si può dire quale utilizzare con
un opportuno parametro.
Il problema è che qgis usa gdal con le opzioni di default è a quello che so
io non consente l impostazione di parametri extra. Anche se esistenti nel
driver di gdal usato.
Il 07 Feb 2018 12:06, "Totò
correggetemi se dico fesserie:
una soluzione sarebbe quella di aggiungere un altro campo geometry (es:
geom, definirlo per bene) alle tabelle e popolarle con la geometria con un
UPDATE.
credo funzioni.
poi, il provider spatialite di QGIS vedrebbe due colonne geometriche dello
stesso strato.
I
Questo succedeva anche nelle precedenti versioni dinpostgis.
Io Vecchi postgis richiedevano che l'utente dopo aver inserito una
geometria su una tabella la definisse in una speciale tabella chiamata
geometry_columns.
Qui nascevano un sacco di casini. Perché spesso l'utente non valorizzava
questo
On Wed, 7 Feb 2018 10:35:39 +0100, Totò Fiandaca wrote:
Ciao,
ho notato che i layer non riconosciuti da QGIS hanno, nella
tabella "geometry_columns" di spaltialite, codice 0 nella colonna
geometry_type;
conformemente alle specifiche OGC-SFS geometry-type=0 identifica
la super-classe astratta G
Riporto come esempio la query che ho scritto per definire comuni_ambito:
*CREATE TABLE comuni_ambito AS*
*SELECT*
*ST_Intersection (a1.geometry, a2.geometry) AS geometry,*
*a2.comune AS comune*
*FROM ambito AS a1, comuni_limitrofi_orig AS a2*
*WHERE ST_Intersects(a1.geometry, a2.geometry);*
Su
Ciao,
ho notato che i layer non riconosciuti da QGIS hanno, nella
tabella "geometry_columns" di spaltialite, codice 0 nella colonna
geometry_type;
credo che dipenda, come hai scritto, dal modo con cui li hai generati.
un parere da persone più esperte sarebbe gradito.
ciao
Il giorno 6 febbraio 2
Funziona Totò :)
Avevo notato l'assenza di apici prima e li ho aggiunti credendo fosse una
tua svista. Ho dovuto inserire il path di destinazione perchè mi è uscito
questo messaggio:
*ERROR 4: sqlite3_open(parete_puc.sqlite) failed: unable to open database
file*
*ERROR 1: SQLite driver failed to
massimiliano, è importante seguire bene la sintassi; hai aggiunto apici
dove non ci vogliono è public senza apici:
*ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
"SQLite" parete_puc.sqlite -progress PG:"dbname='parete_puc'
active_schema=public schemas=public host='localhost'
Nulla da fare...ti copio pari pari quello che scrivo:
*ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO -f
"SQLite" parete_puc.sqlite -progress PG:"dbname='parete_puc'
active_schema='public' schemas='public' host='localhost' port='5432'
user='postgres' password='1983' " -lco LAUND
Incolla sempre l'intero script cosi possiamo controllare.
nello script del blog, il db pg ha due schemi: active_schema=public,data_2015
schemas=public,data_2015
tu, se hai un solo schema, devi scrivere: active_schema=public
schemas=public
usa questo:
ogr2ogr --config PG_LIST_ALL_TABLES YES --con
Ho fatto come mi hai detto Totò(password a parte che era chiaro :D) ed ora
ho questo messaggio:
*ERROR 1: PQconnectdb failed.*
*FATALE: il database "puc_parete" non esiste*
*FAILURE:*
*Unable to open datasource `PG:dbname='puc_parete' active_schema='public'
schemas='public' host='localhost' por
Luca sono su Windows 10
Il giorno 6 febbraio 2018 19:46, Massimiliano Moraca <
massimilianomor...@gmail.com> ha scritto:
> Totò mi sono "permesso" di apportare due piccole modifiche allo script e
> cioè yes al post di no per l'index ed ho inserito il percorso in cui mi
> deve creare il db sqlite:
Totò mi sono "permesso" di apportare due piccole modifiche allo script e
cioè yes al post di no per l'index ed ho inserito il percorso in cui mi
deve creare il db sqlite:
*ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS NO-f
"SQLite" D:\Postgresql\export\puc_parete.sqlite -progress
Ciao massimiliano,
io seguo questo articolo, funziona bene:
https://pigrecoinfinito.wordpress.com/2017/11/28/da-postgis-a-spatialite/
Il giorno 6 febbraio 2018 11:40, Luca Delucchi ha
scritto:
> 2018-02-06 10:51 GMT+01:00 Massimiliano Moraca <
> massimilianomor...@gmail.com>:
> >
> >
> > parete
2018-02-06 10:51 GMT+01:00 Massimiliano Moraca :
>
>
> parete_puc
>
scusa mi ero dimenticato che volevi esportare l'intero db... io ho
fatto una prova con un mio di db e ha funzionato correttamente.
Su che sistema operativo sei? (io uso linux)
Sembrerebbe che non legga correttamente "--config P
2018-02-06 10:44 GMT+01:00 Luca Delucchi :
> 2018-02-06 10:40 GMT+01:00 Massimiliano Moraca <
> massimilianomor...@gmail.com>:
> > Tolto ed ora mi compare questo:
> >
> > ERROR 1: Couldn't fetch requested layer '\'!
> >
>
> il layer come si chiama?
>
>
parete_puc
__
2018-02-06 10:40 GMT+01:00 Massimiliano Moraca :
> Tolto ed ora mi compare questo:
>
> ERROR 1: Couldn't fetch requested layer '\'!
>
il layer come si chiama?
--
ciao
Luca
www.lucadelu.org
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman
Tolto ed ora mi compare questo:
*ERROR 1: Couldn't fetch requested layer '\'!*
Il giorno 6 febbraio 2018 10:38, Luca Delucchi ha
scritto:
> 2018-02-06 10:29 GMT+01:00 Massimiliano Moraca <
> massimilianomor...@gmail.com>:
> > Buongiorno,
>
> ciao
>
>
> > ___
> > Ho ricontrollato la stringa ma m
2018-02-06 10:29 GMT+01:00 Massimiliano Moraca :
> Buongiorno,
ciao
> ___
> Ho ricontrollato la stringa ma mi sembra apposto e coincide con quella al
> link[0]. La incollo di seguito:
> ___
> /ogr2ogr --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEW YES -f
> "SQLite" D:\Postgresql\export\mi
Buongiorno,
prendendo spunto da questa pagina[0] sto cercando di esportare un intero db
PostGIS in SpatiaLITE. Il db in questione non ha nessun trigger attivo,
nessuna view, ma solo semplici tabelle con geometrie e senza.
Quando cerco di esportare una singola tabella ci riesco senza problemi; il
d
38 matches
Mail list logo
