Gfoss -- Geographic Free and Open Source Software - Italian mailing list

Brutto errore su esportazione dati con qgis

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

25 messages Options

Andrea Peri

Re: Brutto errore su esportazione dati con qgis

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 <[hidden email]> 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.
> _______________________________________________
> [hidden email]
> 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 àèìòù
-----------------
_______________________________________________
[hidden email]
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

pigreco

Re: Brutto errore su esportazione dati con qgis

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 <[hidden email]> 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 <[hidden email]> 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.
> _______________________________________________
> [hidden email]
> 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 àèìòù
-----------------

_______________________________________________
[hidden email]
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: [hidden email]

43°51'0.54"N 10°34'27.62"E - EPSG:4326

_______________________________________________
[hidden email]
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

https://pigrecoinfinito.com/

Andrea Peri

Re: Brutto errore su esportazione dati con qgis

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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> 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.
>> > _______________________________________________
>> > [hidden email]
>> > 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 àèìòù
>> -----------------
>> _______________________________________________
>> [hidden email]
>> 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: [hidden email]
> 43°51'0.54"N 10°34'27.62"E - EPSG:4326
>
>

Andrea Peri

Re: Brutto errore su esportazione dati con qgis

Salve,
abbiamo completato anche noi un ultimo ciclo di prove.

Sia con QGIS 2.8.3 che con QGIS 2.10.1 .
Quando si esporta uno shapefile dotato di Z (nel caso del 2.10 solo
per poche geometrie a causa del bug), la Z viene mantenuta e
correttamente valorizzata.

Quindi nessun rischio di perdere la Z con QGIS quando si esporta.

Grazie quindi a Toto e a Sucameli per la disponibilita' dimostrata.

A.

Il 30 settembre 2015 09:19, Andrea Peri <[hidden email]> ha scritto:

> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]> 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.
>>> > _______________________________________________
>>> > [hidden email]
>>> > 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 àèìòù
>>> -----------------
>>> _______________________________________________
>>> [hidden email]
>>> 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: [hidden email]
>> 43°51'0.54"N 10°34'27.62"E - EPSG:4326
>>
>>
>
>
>
> --
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -----------------

pcav

Re: Brutto errore su esportazione dati con qgis

In reply to this post by Andrea Peri

Il 30/09/2015 08:13, Andrea Peri ha scritto:

> Poi, un secondo dilemma che mi rode in testa e':
> PERCHE SU QGIS 2.8.3 NON DAVA ERRORE ?

L'implementazione delle geometrie e' profondamente cambiata, proprio per
supportare curve e geometrie 3D, quindi qualche bachetto e' prevedibile.
grazie ad Andrea e Toto' per la segnalazione, e grazie mille a Giuseppe
per il fix.
Saluti.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
_______________________________________________
[hidden email]
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