Perfetto. Quindi la Z non viene persa nella importazione su postgis da qgis. Questo mi tranquillizza molto.
Probabilmente QGIS 2.10 perde la Z quando va a esportare da postgis a shapefile, ma almeno il dato originale sul postgis e' intatto. Grazie per la prova. A. Il 30 settembre 2015 09:15, Totò Fiandaca <pigrecoinfin...@gmail.com> ha scritto: > Buongiorno, > ho appena fatto la query (nel mio db) > select distinct ST_GeometryType(geom) from reg_toscana.sample > importando lo shp in pg (da qgis) ottengo 'geometry(MultiPolygonZ 3003)' > con la query 'ST Multipolygon' > allego due immagini http://1drv.ms/1M0XDSt > > Il giorno 30 settembre 2015 08:39, Andrea Peri <aperi2...@gmail.com> ha > scritto: >> >> Infatti e' la strada maestra. >> Il nostro esempio che dava errore e' con poligoni 3D. >> >> Si, ma a me interessa sapere in che forma e' il dato dentro il postgis. >> >> E' una questione infrastrutturale. >> Noi non usiamo postgis, ma piuttosot spatialite, ma il problema e' >> similare. >> >> Te pensa a un professionista che lavora su dati della Regione. >> Svolge il lavoro tenendo i dati in postgis. >> Perche' epiu' efficiente dello shapefile e questo e' perfettamente >> logico e sensato. >> >> Poi alla fine esporta il lavoro per effettuare la consegna al cliente >> e i dati diventano 2D. >> >> I dati diventano sempre piu' pesanti e quindi sempre piu' spesso vanno >> tenuti su un dbms (postgis o spatialite), ma se in questo passaggio >> diventano 2D, abbiamo un problema. >> Perche' le ultime specifiche ad esempio quelle del DBTopografico vanno >> sempre piu' verso dati dove le geometrie sono dotate di Z (2,5D). >> >> Quindi sarebbe utile capire se il caricamento di postgis effettuato >> con qgis perde la Z oppure no. >> >> Poi, puo' essere usato anche ogrinfo puntando nella query il db >> postgis, ma la sintassi e' un pochino piu' arzigogolata e con la query >> che gli ho passato fa' sicuramente prima. >> >> A. >> >> >> Il 30 settembre 2015 08:23, Sieradz <anto...@amicocad.it> ha scritto: >> > / >> > Andrea Peri wrote >> >> Quindi PolygonZ, PointZ e LinestringZ >> >> per verificarla basta che esegui questo codice: >> >> select distinct ST_GeoemtryType(the_geom) from schema.nome_tabella; >> > >> > / >> > >> > ...oppure ancora, al prompt di comando: >> > >> > *OGRINFO pippo.shp* ;) >> > >> > >> > >> > -- >> > View this message in context: >> > http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Brutto-errore-su-esportazione-dati-con-qgis-tp7594219p7594253.html >> > Sent from the Gfoss -- Geographic Free and Open Source Software - >> > Italian mailing list mailing list archive at Nabble.com. >> > _______________________________________________ >> > Gfoss@lists.gfoss.it >> > 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. >> > 750 iscritti al 18.3.2015 >> >> >> >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty àèìòù >> ----------------- >> _______________________________________________ >> Gfoss@lists.gfoss.it >> 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. >> 750 iscritti al 18.3.2015 > > > > > -- > Salvatore Fiandaca > mobile.:+39 327.493.8955 > m: pigrecoinfin...@gmail.com > 43°51'0.54"N 10°34'27.62"E - EPSG:4326 > > -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ Gfoss@lists.gfoss.it 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. 750 iscritti al 18.3.2015
