Save a tutti,
vedo stamani che l’ottimo Sucameli ha gia’ provveduto a committare una patch.
Ho datouna occhiata alla patch per curiosita’, e avveto la ESTREMA necessita di chiedere un ulteriore contributo a Toto’.
Prima spiego il mio “dilemma cosmico”:
Quello che e’ emerso dalla patch di Sucameli e’ che il problema era dovuto al fatto che lo shapeifle che io usavo e’ uno shapefile di tipo 3D.
Cioe’ un PolygonZ.
A questo punto la spiegazione del perche’ a Toto’ non dava errore con i suoi e’ che non erano di tipo 3D, ma 2D.
Questo pero’ mi apre la prova a un altro BRUTTISSIMO sospetto.
Infatti Toto’ aveva riportato che se lui importava lo shapefile su postgis usando qgis, e da li lo esportava sempre con qgisl’errore non compariva.
Questo mi fa’ ritenere che l’importazione da QGIS a POSTGIS PERDE LA Z !
Si sa’ da sempre che non la gestisce, ma un conto e’ non gestirla, un altro e’ perderla.
Questa e’ una cosa che andrebbe un attimo ponderata per le sue conseguenze.
Infatti molti dati che usa la pubblica amministrazione da ora in avanti, non solo noi, sono e saranno sempre piu’ 3D.
Quindi PolygonZ, PointZ e LinestringZ.
Per questo chiederei a Toto’ se puo’ verificare se lo shapeifle nostr del pacchetto di esempio che ha imortato sul suo postgis ha ancora la Z oppure no.
per verificarla basta che esegui questo codice:
select distinct ST_GeoemtryType(the_geom) from schema.nome_tabella;
dove schema e’ il nome dello schema dove hai la tabella
nome_tabella e’ la tabella e
“the_geom” e’ il nome del campo geometria.
Grazie.
L’impiego su postgis di qgis e’ prassi molto diffusa (e anche opportuna per molti versi), ma occorrerebbe che la Z non venisse persa.
Poi, un secondo dilemma che mi rode in testa e’:
PERCHE SU QGIS 2.8.3 NON DAVA ERRORE ?
Che forse su QGIS 2.8.3 riusciva a espotare in shapefileZ mentre su QGIS 2.10 no ?
A.
···
Il giorno 30 settembre 2015 00:17, Andrea Peri <aperi2007@gmail.com> ha scritto:
Fatto.
Toto’ grazie infinite per i tuoi contributi.
A.
–
Il giorno 29 settembre 2015 23:50, Totò Fiandaca <pigrecoinfinito@gmail.com> ha scritto:
Partendo dall’insieme degli elementi del video precedente (circa 40), non è un particolare elemento che causa errore ma l’esportazione di un particolare sottoinsieme di 7 elementi ; se presi singolarmente non da errore.
Allego video
http://1drv.ms/1JAOLkw
Andrea, mettilo tu il video per favore.
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
Il giorno 29 settembre 2015 23:37, Totò Fiandaca <pigrecoinfinito@gmail.com> ha scritto:
Partendo dall’insieme degli elementi del video circa 40, non è un particolare elemento che causa errore ma ma l’essportazione di un sottoinsieme di 7 elementi. se presi singolarmente non da errore.
Andrea, mettilo tu il video per favore.
–
Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51’0.54"N 10°34’27.62"E - EPSG:4326
Il giorno 29 settembre 2015 23:31, Totò Fiandaca <pigrecoinfinito@gmail.com> ha scritto:
un attimo è trovo l’elemento che provoca l’errore!!!
–
Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51’0.54"N 10°34’27.62"E - EPSG:4326
Il giorno 29 settembre 2015 23:30, Andrea Peri <aperi2007@gmail.com> ha scritto:
Toto’ lo vuoi inserire te nel ticket questo video ?
E’ un ottimo contributo.
A.
Il 29 settembre 2015 23:15, Totò Fiandaca <pigrecoinfinito@gmail.com>
ha scritto:
ecco il video
http://1drv.ms/1JAL7Hq
Il giorno 29 settembre 2015 23:09, Totò Fiandaca <pigrecoinfinito@gmail.com>
ha scritto:
Andrea, sto facendo un video per dimostrare che l’errore non dipende dal
numero di elementi.
ho provato a selezionare circa 40 elementi in alto centrale e da lo stesso
errore.
Il giorno 29 settembre 2015 23:04, Andrea Peri <aperi2007@gmail.com> ha
scritto:
Il bug e’ piu’ complicato di quanto pensassi.
A quanto pare sembra avere a che fare anche con qualcosa inerente il
particolare shapefile.
Pero’ il fatto che con qgis 2.8.3 non avviene indubbiamente dimostra
che il bug e’ di qgis.
Forse ci puo’ entrare la codifica del charset o vai a sappi te che cosa
altro.
Forse la presenza di qualche carattere spurio, o magari il sistema di
riferimento dello shapefile
Boh.
A.
Il 29 settembre 2015 22:53, Totò Fiandaca <pigrecoinfinito@gmail.com>
ha scritto:
confermo errore con il file messo a disposizione.
non so se serva, ma ho fatto la seguente prova:
caricato shp sample in qgis, poi importato in pg e poi ricarico in qgis
,
esporto il file e non da più errore.
ciao
Il giorno 29 settembre 2015 22:36, Totò Fiandaca
<pigrecoinfinito@gmail.com>
ha scritto:
per completezza prova fatta con shp multipoint circa 16.000 elementi e
altro shp multipoligon con circa 28.000 elementi, tutto ok!!!
Il giorno 29 settembre 2015 22:29, Totò Fiandaca
<pigrecoinfinito@gmail.com> ha scritto:
Ciao Andrea,
ho appena fatto una prova con un shapefile (Multilinestring) con
circa
60.000 elementi e va tutto liscio come l’olio!!!
Il giorno 29 settembre 2015 22:14, Andrea Peri <aperi2007@gmail.com>
ha
scritto:
Salve,
proprio oggi un collega (Marco) mi ha segnalato un bruttissimo bug
di
qgis.
Un bug che e’ comparso nella versione 2.10 di qgis.
La versione 2.8.3 funzionava bene.
Il bug e’ presente anche nella attuale DEV di qgis.
Dalle indagini svolte questo e’ il risultato:
Se si tenta di esportare uno shapefile che ha piu’ di 9000 elementi
circa qgis da’ errore .
Se si seleziona un numero inferiore di elementi , l’esportazione
avviene senza problemi.
Ho aperto un ticket, speriamo che sia risolto visto che
l’esportazione
dei dati da verso uno shapefile e’ una cosa importante per un
professionista che lavora nei gis.
Qui il ticket.
Ho messo anche un sample shapefile che permette di verificare il
problema.
http://hub.qgis.org/issues/13451
Saluti,
A.
–
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: pigrecoinfinito@gmail.com
43°51’0.54"N 10°34’27.62"E - EPSG:4326
–
Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51’0.54"N 10°34’27.62"E - EPSG:4326
–
Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51’0.54"N 10°34’27.62"E - EPSG:4326
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
–
Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51’0.54"N 10°34’27.62"E - EPSG:4326
–
Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51’0.54"N 10°34’27.62"E - EPSG:4326
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
–
Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51’0.54"N 10°34’27.62"E - EPSG:4326
Andrea Peri
. . . . . . . . .
qwerty àèìòù
