[Gfoss] R: Re: problema sistema coordinate - passaggio from *csv to *shp

nel *csv di partenza i dati sono in utm wgs84 fuso 32 N
quando carico i
dati in qgis setto come CRS utm wgs84 fuso 32 N
(ed effettivamente
cadono dove devono cadere)

----Messaggio originale----
Da:
giohappy@gmail.com
Data: 06/04/2011 10.56
A: "marco.donnini@tiscali.it"
<marco.donnini@tiscali.it>
Cc: "Mailing List Gfoss (ita)"<gfoss@lists.
gfoss.it>
Ogg: Re: [Gfoss] problema sistema coordinate - passaggio from
*csv to *shp

Ciao Marco,
una domanda: tu hai lat/lon in gradi nel cvs
di partenza? In tal caso il CRS
è WGS84 geografico, non è proiettato
(UTM 32N).

giovanni

Il giorno 06 aprile 2011 10:50, marco.
donnini@tiscali.it <
marco.donnini@tiscali.it> ha scritto:

ciao a

tutti/e

ho un *csv creato partendo con un *xls costituito da
tre

colonne:

nome, Lat_utm, Long_utm

sono una serie di punti

georeferenziati in utm wgs84 fuso 32 N

non tutti i punti ricadono

però

nel fuso 32: ce ne sono alcuni che cadono nel fuso 33, ma ho

considerato la distorzione accettabile (ho necessità di lavorare in

coordinate metriche per poter meglio lavorare con distanze, aree.

perimetri ecc...).

quando vado a caricare con qgis il *cvs, me lo

carica senza problemi (i punti cadono dove devono cadere).

quando

vado

a salvare da *csv a *shp lasciando "CRS originale" vedo che i

punti

coincidono perfettamente con i punti del *csv georeferenziati

in utm

wgs84 fuso 32 N ma come *prj mi salva il *prj del sistema

wgs84 (lat

long).
il problema poi si pone quando voglio georiferire

il *shp

risultante in ws84... mi dice che non è possibile perchè il

CRS in

input è uguale a quello in output.
cancellando il *prj non

risolvo

nulla...

allora vado a salvare da *csv a *shp settando

come CRS di

uscita -> utm wgs84 fuso 32 N
e mi compare una

schermata che mi dice:

Esportazione nel file vettoriale fallita.

Errore: Failed to transform a
point while drawing a feature of type

". Writing stopped. (Exception:

trasformazione diretta di (102461.1,

92766.1)

fallito con errore:
latitudine or longitudine exceeded

limits)

..potrei risolvere
cambiando il sistema di coordinate

punto per punto del *csv, ma mi

sembra di "barare"

qualcuno ha

iqualche idea??

grazie mille!!
marco

Non temiamo alcun

confronto: Tiscali ha l'Adsl più veloce d'Italia!

Risparmia con

Tutto Incluso Light: Voce + Adsl 20 mega a soli 17,95 € al

mese per

12 mesi.

http://abbonati.tiscali.it/telefono-

adsl/prodotti/tc/tuttoincluso_light/?WT.mc_id=01fw

_______________________________________________

Iscriviti

all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione

Gfoss@lists.gfoss.it

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.

502 iscritti all'11.2.2011

Non temiamo alcun confronto: Tiscali ha l'Adsl più veloce d'Italia!

Risparmia con Tutto Incluso Light: Voce + Adsl 20 mega a soli 17,95 € al mese per 12 mesi.

http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso_light/?WT.mc_id=01fw

Ciao Marco
In vari casi ho dovuto seguire delle procedure simili alla tua, ho avuto lo stesso genere di problema

io ho risolto, in maniera un po’ macchinosa, così:
una volta creato lo *shp oppure direttamente con il *csv io l’ho importato dentro GRASS e ho fatto fare a GRASS la riproiezione (usando v.proj)
a quel punto da grass posso esportarlo in shp o in qualunque altro formato

buon lavoro
Gianluca Gasperini

AGRONOMO
via Lupinaio, 6
56040 Lorenzana - Pisa - Italia
e-mail: gianluca.gasperini@gmail.com
PEC: g.gasperini@epap.conafpec.it
mobile: +39 346 51 04 525
Tel.: +39 050 662 969
Fax.: +39 050 80 70 192
skype: gianluca.gasperini

Il giorno 06 aprile 2011 11:00, marco.donnini@tiscali.it <marco.donnini@tiscali.it> ha scritto:

nel *csv di partenza i dati sono in utm wgs84 fuso 32 N
quando carico i
dati in qgis setto come CRS utm wgs84 fuso 32 N
(ed effettivamente
cadono dove devono cadere)

----Messaggio originale----
Da:
giohappy@gmail.com
Data: 06/04/2011 10.56
A: “marco.donnini@tiscali.it
<marco.donnini@tiscali.it>
Cc: “Mailing List Gfoss (ita)”<gfoss@lists.
gfoss.it>
Ogg: Re: [Gfoss] problema sistema coordinate - passaggio from
*csv to *shp

Ciao Marco,
una domanda: tu hai lat/lon in gradi nel cvs
di partenza? In tal caso il CRS
è WGS84 geografico, non è proiettato
(UTM 32N).

giovanni

Il giorno 06 aprile 2011 10:50, marco.
donnini@tiscali.it <
marco.donnini@tiscali.it> ha scritto:

ciao a
tutti/e

ho un *csv creato partendo con un *xls costituito da
tre
colonne:
nome, Lat_utm, Long_utm

sono una serie di punti

georeferenziati in utm wgs84 fuso 32 N

non tutti i punti ricadono
però
nel fuso 32: ce ne sono alcuni che cadono nel fuso 33, ma ho

considerato la distorzione accettabile (ho necessità di lavorare in

coordinate metriche per poter meglio lavorare con distanze, aree.

perimetri ecc…).

quando vado a caricare con qgis il *cvs, me lo

carica senza problemi (i punti cadono dove devono cadere).

quando
vado
a salvare da *csv a *shp lasciando “CRS originale” vedo che i
punti
coincidono perfettamente con i punti del *csv georeferenziati
in utm
wgs84 fuso 32 N ma come *prj mi salva il *prj del sistema
wgs84 (lat
long).
il problema poi si pone quando voglio georiferire
il *shp
risultante in ws84… mi dice che non è possibile perchè il
CRS in
input è uguale a quello in output.
cancellando il *prj non
risolvo
nulla…

allora vado a salvare da *csv a *shp settando
come CRS di
uscita → utm wgs84 fuso 32 N
e mi compare una
schermata che mi dice:

Esportazione nel file vettoriale fallita.

Errore: Failed to transform a
point while drawing a feature of type
". Writing stopped. (Exception:
trasformazione diretta di (102461.1,
92766.1)

fallito con errore:
latitudine or longitudine exceeded
limits)

…potrei risolvere
cambiando il sistema di coordinate
punto per punto del *csv, ma mi
sembra di “barare”

qualcuno ha
iqualche idea??

grazie mille!!
marco

Non temiamo alcun
confronto: Tiscali ha l’Adsl più veloce d’Italia!

Risparmia con
Tutto Incluso Light: Voce + Adsl 20 mega a soli 17,95 € al
mese per
12 mesi.

http://abbonati.tiscali.it/telefono-
adsl/prodotti/tc/tuttoincluso_light/?WT.mc_id=01fw


Iscriviti
all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione

Gfoss@lists.gfoss.it

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.
502 iscritti all’11.2.2011

Non temiamo alcun confronto: Tiscali ha l’Adsl più veloce d’Italia!

Risparmia con Tutto Incluso Light: Voce + Adsl 20 mega a soli 17,95 € al mese per 12 mesi.

http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso_light/?WT.mc_id=01fw


Iscriviti all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@lists.gfoss.it
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.
502 iscritti all’11.2.2011

On Wed, 6 Apr 2011 13:21:06 +0200, Gianluca Gasperini wrote

io ho risolto, in maniera un po’ macchinosa, così:
una volta creato lo *shp oppure direttamente con il *csv io l’ho importato dentro GRASS e ho fatto fare a GRASS la riproiezione (usando v.proj)
a quel punto da grass posso esportarlo in shp o in qualunque altro formato

oppure, ancora più semplice: importi il *csv su SpatiaLite-GUI:
http://www.gaia-gis.it/spatialite-2.4.0-4/binaries.html
http://www.gaia-gis.it/spatialite-2.4.0-5/binaries.html

fai tutte le riproiezioni che ti servono (e qualsiasi altra pazza
operazione che ti viene in mente, perchè hai a disposizione tutta
l’illimitata potenza di fuoco supportata da SQL e SpatialSQL),
e poi alla fine esporti gli Shapefiles che ti servono

… sempre ammesso che ti servano ancora gli shp, visto che p.es.
puoi attaccare immediatamente un DB SpatiaLite a QGIS
e lavorarci sopra a velocità supersoniche che con gli shp
te le sogni con il canocchiale :slight_smile:

ciao Sandro

Marco,
il progetto Qgis in cui importi i tuoi dati è WGS84? In questo caso suppongo avvenga questo:

1 - importi i dati utm, e lui te li posiziona ma probabilmente le coordinate che vedi in basso a sx sono in gradi (milioni di gradi)
2 - quando esporti, lo shp assume il CRS del progetto, quindi WGS84 MA le tue coordinate sono ancora metriche
3 - se reimporti, stai importando già in WGS84, quindi non puoi riproiettare in WGS84…

opzione più semplice:

1 - setta il progetto come UTM
2 - importa il csv e nelle proprietà del layer setta il CRS (UTM)
3 - esporta in shp indicando come CRS di esportazione WGS84

giovanni

Il giorno 06 aprile 2011 13:35, <a.furieri@lqt.it> ha scritto:

On Wed, 6 Apr 2011 13:21:06 +0200, Gianluca Gasperini wrote

io ho risolto, in maniera un po’ macchinosa, così:
una volta creato lo *shp oppure direttamente con il *csv io l’ho importato dentro GRASS e ho fatto fare a GRASS la riproiezione (usando v.proj)
a quel punto da grass posso esportarlo in shp o in qualunque altro formato

oppure, ancora più semplice: importi il *csv su SpatiaLite-GUI:
http://www.gaia-gis.it/spatialite-2.4.0-4/binaries.html
http://www.gaia-gis.it/spatialite-2.4.0-5/binaries.html

fai tutte le riproiezioni che ti servono (e qualsiasi altra pazza
operazione che ti viene in mente, perchè hai a disposizione tutta
l’illimitata potenza di fuoco supportata da SQL e SpatialSQL),
e poi alla fine esporti gli Shapefiles che ti servono

… sempre ammesso che ti servano ancora gli shp, visto che p.es.
puoi attaccare immediatamente un DB SpatiaLite a QGIS
e lavorarci sopra a velocità supersoniche che con gli shp
te le sogni con il canocchiale :slight_smile:

ciao Sandro


Iscriviti all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@lists.gfoss.it
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.
502 iscritti all’11.2.2011