[Gfoss] ancora: QGIS UTM ED50 Emilia Romagna

Salve a tutti
Prometto solennemente che se da questa discussione ne cavo i piedi faccio anche un video tutorial da mettere sul wiki :slight_smile:

Premesso che il 90% dei problemi deriva dalla mia mancanza di preparazione sull’argomento…

Avrei da eseguire delle elaborazioni usando come base la ctr dell’Emilia Romagna che, come proiezione dovrebbe essere UTM ED 50 32nord con un falso nord di -4000000

apro qgis
vado in impostazioni, proiezione personalizzata, e inserisco la stringa +proj=utm +zone=32 +ellps=intl +units=m +no_defs +toWGS84 +y0=-4000000, salvo e do OK
vado in impostazioni, proprietà del progetto, metto metri, proiezione: abilita proiezione al volo e scelgo quella creata da me…
Applica, OK
carico il raster
vado in proprietĂ , Generale, cambia e scelgo quella creata da me, applica OK

primo problema: se mi sposto su dei punti noti della carta le coordinate che visualizzo in basso a destra sono ancora quelle “originali” senza la traslazione di 4000000

secondo problema: carico delle coordinate prese dal GPS e imposto come proiezione WGS84 (verificate su google earth la precisione è ottima) ho lo scarto di 4000000, poco male… modifico tutti i punti del file txt togliendo 4000000 alle y e torno a importare, a questo punto ho uno sfalsamento di circa 300mt in direzione y e 100 in direzione x

ipotesi??
ho provato a fare una traslazione dei punti gps originali secondo gauss-boaga (fuso ovest) y=-3999820.00 e l’errore in y è entro un range tollerabile, ma permane quello in X

al che i miei quesiti sono 3:

  1. perchè qgis non riproietta correttamente i layer secondo le proiezioni?
  2. ipotizzando che le ctr siano in gauss-boaga quali sono i parametri di traslazione con wgs84?
  3. esiste per grass un comando per traslare i raster equivalente a v.transform?

scusate la lunghezza del messaggio, ma ho letto tanto e ho cercato di riassumere tutti i dubbi che sono rimasti in sospeso, in modo poi da poter essere d’aiuto a d’altri nel caso se ne venga a capo…

grazie a tutti

enrico

ciao enrico,
1) accertati della proiezione dei dati (se sicuro che non sia in gauss
boaga?)
2) in ogni caso, usa le proiezioni predefinite da qgis
3) non attivare la proiezione al volo ma apri i dati su un progetto pulito e
vedi se le coordinate che
visualizzi sono quelle che ti aspetti

ciao ciao
emanuele

enrico lambertini wrote:

Salve a tutti
Prometto solennemente che se da questa discussione ne cavo i piedi faccio
anche un video tutorial da mettere sul wiki :slight_smile:

Premesso che il 90% dei problemi deriva dalla mia mancanza di preparazione
sull'argomento...

Avrei da eseguire delle elaborazioni usando come base la ctr dell'Emilia
Romagna che, come proiezione dovrebbe essere UTM ED 50 32nord con un falso
nord di -4000000

apro qgis
vado in impostazioni, proiezione personalizzata, e inserisco la stringa
+proj=utm +zone=32 +ellps=intl +units=m +no_defs +toWGS84 +y0=-4000000,
salvo e do OK
vado in impostazioni, proprietĂ  del progetto, metto metri, proiezione:
abilita proiezione al volo e scelgo quella creata da me..
Applica, OK
carico il raster
vado in proprietĂ , Generale, cambia e scelgo quella creata da me, applica
OK

primo problema: se mi sposto su dei punti noti della carta le coordinate
che
visualizzo in basso a destra sono ancora quelle "originali" senza la
traslazione di 4000000

secondo problema: carico delle coordinate prese dal GPS e imposto come
proiezione WGS84 (verificate su google earth la precisione è ottima) ho lo
scarto di 4000000, poco male.... modifico tutti i punti del file txt
togliendo 4000000 alle y e torno a importare, a questo punto ho uno
sfalsamento di circa 300mt in direzione y e 100 in direzione x

ipotesi??
ho provato a fare una traslazione dei punti gps originali secondo
gauss-boaga (fuso ovest) *y=-3999820.00 e *l'errore in y è entro un range
tollerabile, ma permane quello in X

al che i miei quesiti sono 3:
1. perchè qgis non riproietta correttamente i layer secondo le proiezioni?
2. ipotizzando che le ctr siano in gauss-boaga quali sono i parametri di
traslazione con wgs84?
3. esiste per grass un comando per traslare i raster equivalente a
v.transform?

scusate la lunghezza del messaggio, ma ho letto tanto e ho cercato di
riassumere tutti i dubbi che sono rimasti in sospeso, in modo poi da poter
essere d'aiuto a d'altri nel caso se ne venga a capo...

grazie a tutti

enrico

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

--
View this message in context: http://www.nabble.com/ancora%3A-QGIS-UTM-ED50-Emilia-Romagna-tp19589110p19593186.html
Sent from the Gfoss mailing list archive at Nabble.com.

ciao

se ti può essere utile trovi una location di esempio in utm32 rer a
questo indirizzo (italian Grass locations):

http://wwwamb.bologna.enea.it/forgrass/download/

prova a visualizzare il file PROJ_INFO in
/it-utm32eur50rer/PERMANENT/ e trovi alcune risposte alle tue domande.

puoi anche guardare qui:

http://listserv.unipr.it/pipermail/grass-italia/2005-December/001366.html
http://www.nabble.com/UTM32*-e-UTM33*-che-codice-epsg-hanno--to14155612.html#a14166727
http://www.nabble.com/confusione-coordinate-e-sistemi-di-riferimento-to18667670.html#a18668734

Per riproiettare i raster guarda l'help del comando r.proj (o
gdalwarp se preferisci).

ciao

2008/9/21 Emanuele Masiero <emanuele.masiero@gmail.com>:

ciao enrico,
1) accertati della proiezione dei dati (se sicuro che non sia in gauss
boaga?)
2) in ogni caso, usa le proiezioni predefinite da qgis
3) non attivare la proiezione al volo ma apri i dati su un progetto pulito e
vedi se le coordinate che
visualizzi sono quelle che ti aspetti

ciao ciao
emanuele

enrico lambertini wrote:

Salve a tutti
Prometto solennemente che se da questa discussione ne cavo i piedi faccio
anche un video tutorial da mettere sul wiki :slight_smile:

Premesso che il 90% dei problemi deriva dalla mia mancanza di preparazione
sull'argomento...

Avrei da eseguire delle elaborazioni usando come base la ctr dell'Emilia
Romagna che, come proiezione dovrebbe essere UTM ED 50 32nord con un falso
nord di -4000000

apro qgis
vado in impostazioni, proiezione personalizzata, e inserisco la stringa
+proj=utm +zone=32 +ellps=intl +units=m +no_defs +toWGS84 +y0=-4000000,
salvo e do OK
vado in impostazioni, proprietĂ  del progetto, metto metri, proiezione:
abilita proiezione al volo e scelgo quella creata da me..
Applica, OK
carico il raster
vado in proprietĂ , Generale, cambia e scelgo quella creata da me, applica
OK

primo problema: se mi sposto su dei punti noti della carta le coordinate
che
visualizzo in basso a destra sono ancora quelle "originali" senza la
traslazione di 4000000

secondo problema: carico delle coordinate prese dal GPS e imposto come
proiezione WGS84 (verificate su google earth la precisione è ottima) ho lo
scarto di 4000000, poco male.... modifico tutti i punti del file txt
togliendo 4000000 alle y e torno a importare, a questo punto ho uno
sfalsamento di circa 300mt in direzione y e 100 in direzione x

ipotesi??
ho provato a fare una traslazione dei punti gps originali secondo
gauss-boaga (fuso ovest) *y=-3999820.00 e *l'errore in y è entro un range
tollerabile, ma permane quello in X

al che i miei quesiti sono 3:
1. perchè qgis non riproietta correttamente i layer secondo le proiezioni?
2. ipotizzando che le ctr siano in gauss-boaga quali sono i parametri di
traslazione con wgs84?
3. esiste per grass un comando per traslare i raster equivalente a
v.transform?

scusate la lunghezza del messaggio, ma ho letto tanto e ho cercato di
riassumere tutti i dubbi che sono rimasti in sospeso, in modo poi da poter
essere d'aiuto a d'altri nel caso se ne venga a capo...

grazie a tutti

enrico

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

--
View this message in context: http://www.nabble.com/ancora%3A-QGIS-UTM-ED50-Emilia-Romagna-tp19589110p19593186.html
Sent from the Gfoss mailing list archive at Nabble.com.

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.

--
--
Craveri Paolo Livio

Lat. 44° 39' 11.08'' N Long. 7° 23' 25.26'' E
-------------------------------------------------------------
Preferisco ricevere allegati in formato OpenDocument
http://it.wikipedia.org/wiki/OpenDocument
I prefer to receive attachments in OpenDocument format
http://en.wikipedia.org/wiki/OpenDocument

http://www.gnu.org/philosophy/no-word-attachments.it.html

Enrico Lambertini ha scritto:

Salve a tutti
Prometto solennemente che se da questa discussione ne cavo i piedi
faccio anche un video tutorial da mettere sul wiki :slight_smile:

Premesso che il 90% dei problemi deriva dalla mia mancanza di
preparazione sull'argomento...

Avrei da eseguire delle elaborazioni usando come base la ctr dell'Emilia
Romagna che, come proiezione dovrebbe essere UTM ED 50 32nord con un
falso nord di -4000000

apro qgis
vado in impostazioni, proiezione personalizzata, e inserisco la stringa
+proj=utm +zone=32 +ellps=intl +units=m +no_defs +toWGS84 +y0=-4000000,
salvo e do OK
vado in impostazioni, proprietĂ  del progetto, metto metri, proiezione:
abilita proiezione al volo e scelgo quella creata da me..
Applica, OK
carico il raster
vado in proprietĂ , Generale, cambia e scelgo quella creata da me, applica OK

primo problema: se mi sposto su dei punti noti della carta le coordinate
che visualizzo in basso a destra sono ancora quelle "originali" senza la
traslazione di 4000000

Ti visualizza le cordinate "originali" poichè riconosce solo questa stringa:
+proj=utm +zone=32 +ellps=intl +units=m
che di fatto è l'UTM ED50 32N (EPSG:23032).
La sottostringa "+toWGS84 +y0=-4000000" non è corretta, perchè +towgs84
è seguito da 3 o da 7 parametri e il falso nord si definisce con +y0 ma
con +y_0.
Inoltre, anche se il falso nord fosse stato definito correttamente, le
coordinate rimarrebbero ugualmente inalterate poichè in proj.4 alcuni
sistemi di coordinate, tra i quali quelli che usano "+proj=utm" e quindi
anche UTM ED50 32N, contengono implicitamente i valori delle false
origini (+x_0 e +y_0).
Per bypassare il problema, si tratta di utilizzare un trick, in modo da
"convincere" proj.4 a fare quello che vogliamo. Basta sapere cos'è UTM.
E' una proiezione universale trasversa di Mercatore e quindi occorre
semplicemente sostituire "+proj=tmerc" a "+proj=utm" per ovviare al
problema delle false origini. Così facendo "+y_0=-4000000" dovrebbe
avere effetto.
Ora però, avendo sostituito la proiezione (anche se, di fatto, è la
stessa!), dobbiamo specificare tutti gli altri parametri (ellissoide,
centro della proiezione, false origini e fattore di contrazione), poichè
proj.4 non sa piĂą che stiamo parlando di una proiezione UTM. E quindi,
la stringa per 23032* dovrebbe essere:

+proj=tmerc +ellps=intl +lat_0=0 +lon_0=9 +x_0=500000 +y_0=-4000000
+k=0.9996 +units=m

In definitiva, per visualizzare correttamente le coordinate (senza falso
nord) dovresti definire 23032 per la vista, abilitare la proiezione al
volo ed assegnare 23032* (UTM-RER) ai dati.

secondo problema: carico delle coordinate prese dal GPS e imposto come
proiezione WGS84 (verificate su google earth la precisione è ottima) ho
lo scarto di 4000000, poco male.... modifico tutti i punti del file txt
togliendo 4000000 alle y e torno a importare, a questo punto ho uno
sfalsamento di circa 300mt in direzione y e 100 in direzione x

perchè sottrarre 4000000 alle y? sono coordinate in WGS84, lasciale così
come sono... se la vista è in 23032, dovresti aggiungere

ipotesi??
ho provato a fare una traslazione dei punti gps originali secondo
gauss-boaga (fuso ovest) //y=-3999820.00 e //l'errore in y è entro un
range tollerabile, ma permane quello in X

Su queste traslazioni posso solo dirti che possono essere considerate
costanti solo per brevi distanze e non a livello regionale. Anche per
questa ragione ti conviene mantenerli inalterati.

al che i miei quesiti sono 3:
1. perchè qgis non riproietta correttamente i layer secondo le proiezioni?

vedi sopra

2. ipotizzando che le ctr siano in gauss-boaga quali sono i parametri di
traslazione con wgs84?

+towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68
parametri validi per l'Italia peninsulare

3. esiste per grass un comando per traslare i raster equivalente a
v.transform?

credo i.warp, si tratta di un add-on (mai usato personalmente) che
utilizza gdalwarp, presente nelle GDAL e nelle FWtools.

scusate la lunghezza del messaggio, ma ho letto tanto e ho cercato di
riassumere tutti i dubbi che sono rimasti in sospeso, in modo poi da
poter essere d'aiuto a d'altri nel caso se ne venga a capo...

grazie a tutti

di nulla! Hai fatto benissimo.

ciao
Antonio

Enrico Lambertini ha scritto:

Salve a tutti
Prometto solennemente che se da questa discussione ne cavo i piedi
faccio anche un video tutorial da mettere sul wiki :slight_smile:

Bravo, attendiamo! :slight_smile:
Saluti.
pc
--
Paolo Cavallini, see: * http://www.faunalia.it/pc *

grazie a tutti per l’aiuto, soprattutto ad Antonio per la descrizione attenta per dettagliata

Il giorno 21 settembre 2008 19.48, Antonio Falciano ha scritto:

Ti visualizza le cordinate “originali” poichè riconosce solo questa stringa:

+proj=utm +zone=32 +ellps=intl +units=m

che di fatto è l’UTM ED50 32N (EPSG:23032).
La sottostringa “+toWGS84 +y0=-4000000” non è corretta, perchè +towgs84
è seguito da 3 o da 7 parametri e il falso nord si definisce con +y0 ma
con +y_0.
Inoltre, anche se il falso nord fosse stato definito correttamente, le
coordinate rimarrebbero ugualmente inalterate poichè in proj.4 alcuni
sistemi di coordinate, tra i quali quelli che usano “+proj=utm” e quindi
anche UTM ED50 32N, contengono implicitamente i valori delle false
origini (+x_0 e +y_0).
Per bypassare il problema, si tratta di utilizzare un trick, in modo da
“convincere” proj.4 a fare quello che vogliamo. Basta sapere cos’è UTM.
E’ una proiezione universale trasversa di Mercatore e quindi occorre
semplicemente sostituire “+proj=tmerc” a “+proj=utm” per ovviare al
problema delle false origini. Così facendo “+y_0=-4000000” dovrebbe
avere effetto.
Ora però, avendo sostituito la proiezione (anche se, di fatto, è la
stessa!), dobbiamo specificare tutti gli altri parametri (ellissoide,
centro della proiezione, false origini e fattore di contrazione), poichè
proj.4 non sa piĂą che stiamo parlando di una proiezione UTM. E quindi,
la stringa per 23032* dovrebbe essere:

+proj=tmerc +ellps=intl +lat_0=0 +lon_0=9 +x_0=500000 +y_0=-4000000
+k=0.9996 +units=m

In definitiva, per visualizzare correttamente le coordinate (senza falso
nord) dovresti definire 23032 per la vista, abilitare la proiezione al
volo ed assegnare 23032* (UTM-RER) ai dati.

provato, FUNZIONA… ma solo coi vettoriali, se assegno questa proiezione a un layer raster me la colloca correttamente, ma non la visualizza (bug di qgis??)

perchè sottrarre 4000000 alle y? sono coordinate in WGS84, lasciale così
come sono… se la vista è in 23032, dovresti aggiungere

a questo punto penso che mi convenga tenermi come sistema di riferimento della vista UTM-RER e crearmi una proiezione personalizzata con cui traslare solo il layer dei punti WGS84 (UTM 32N), che se ho capito il concetto dovrebbe essere qualcosa del tipo
+proj=tmerc +ellps=intl +lat_0=0 +lon_0=9 +x_0=-500000 +y_0=4000000
+k=0.9996 +units=m

giusto?

grazie

e.l.

Enrico Lambertini ha scritto:

grazie a tutti per l'aiuto, soprattutto ad Antonio per la descrizione
attenta per dettagliata

di nulla!

Il giorno 21 settembre 2008 19.48, Antonio Falciano ha scritto:

    Ti visualizza le cordinate "originali" poichè riconosce solo questa
    stringa:
    +proj=utm +zone=32 +ellps=intl +units=m
    che di fatto è l'UTM ED50 32N (EPSG:23032).
    La sottostringa "+toWGS84 +y0=-4000000" non è corretta, perchè +towgs84
    Ă¨ seguito da 3 o da 7 parametri e il falso nord non si definisce con +y0 ma
    con +y_0.
    Inoltre, anche se il falso nord fosse stato definito correttamente, le
    coordinate rimarrebbero ugualmente inalterate poichè in proj.4 alcuni
    sistemi di coordinate, tra i quali quelli che usano "+proj=utm" e quindi
    anche UTM ED50 32N, contengono implicitamente i valori delle false
    origini (+x_0 e +y_0).
    Per bypassare il problema, si tratta di utilizzare un trick, in modo da
    "convincere" proj.4 a fare quello che vogliamo. Basta sapere cos'è UTM.
    E' una proiezione universale trasversa di Mercatore e quindi occorre
    semplicemente sostituire "+proj=tmerc" a "+proj=utm" per ovviare al
    problema delle false origini. Così facendo "+y_0=-4000000" dovrebbe
    avere effetto.
    Ora però, avendo sostituito la proiezione (anche se, di fatto, è la
    stessa!), dobbiamo specificare tutti gli altri parametri (ellissoide,
    centro della proiezione, false origini e fattore di contrazione), poichè
    proj.4 non sa piĂą che stiamo parlando di una proiezione UTM. E quindi,
    la stringa per 23032* dovrebbe essere:

    +proj=tmerc +ellps=intl +lat_0=0 +lon_0=9 +x_0=500000 +y_0=-4000000
    +k=0.9996 +units=m

    In definitiva, per visualizzare correttamente le coordinate (senza falso
    nord) dovresti definire 23032 per la vista, abilitare la proiezione al
    volo ed assegnare 23032* (UTM-RER) ai dati.

provato, FUNZIONA... ma solo coi vettoriali, se assegno questa
proiezione a un layer raster me la colloca correttamente, ma non la
visualizza (bug di qgis??)

E' vero... sia sotto Hardy che sotto win, con la Metis i raster sono
visualizzati solo se sono definiti nello stesso SRS della vista. Se si
tenta di riproiettarli da un SRS differente rispetto a quello della
vista, sono georeferenziati correttamente, ma non sono visualizzati.
Non ti saprei dare una spiegazione in merito.

    perchè sottrarre 4000000 alle y? sono coordinate in WGS84, lasciale così
    come sono... se la vista è in 23032, dovresti aggiungere

... alla stringa +towgs84=-87,-98,-121
(qui mi ero dimenticato di scrivere i parametri)

a questo punto penso che mi convenga tenermi come sistema di riferimento
della vista UTM-RER e crearmi una proiezione personalizzata con cui
traslare solo il layer dei punti WGS84 (UTM 32N), che se ho capito il
concetto dovrebbe essere qualcosa del tipo
+proj=tmerc +ellps=intl +lat_0=0 +lon_0=9 +x_0=-500000 +y_0=4000000
+k=0.9996 +units=m

giusto?

No, UTM WGS84 32N (EPSG:32632) rimane inalterata, ossia:

+proj=longlat +ellps=WGS84 +datum=WGS84

Tieni presente che WGS84 è il datum di riferimento assoluto delle proj.4
e che tutti gli altri SRS possono essere ricondotti ad esso mediante dei
parametri di trasformazione (+towgs84=...) e non viceversa. Tieni conto
anche che le trasformazioni verso WGS84 hanno effetto in entrambi i versi.
Dovresti quindi aggiungere alle stringhe di UTM ED50 32N e di UTM-RER
i parametri di trasformazione verso WGS84, ossia:

[...] +towgs84=-87,-98,-121

Spero di aver chiarito un pò le idee.

ciao
Antonio

Paolo Craveri ha scritto:

Per riproiettare i raster guarda l'help del comando r.proj (o
gdalwarp se preferisci).

enrico lambertini wrote:

3. esiste per grass un comando per traslare i raster equivalente a
v.transform?

In effetti, definite due location, una in 23032 e l'altra in UTM-RER,
è possibile usare r.proj, anche se si tratta di una semplice traslazione.
In alternativa, noti i due CRS, si può usare anche gdal_translate.

ciao
Antonio

.................................................................................................

   In definitiva, per visualizzare correttamente le coordinate (senza
falso
    nord) dovresti definire 23032 per la vista, abilitare la proiezione
al
    volo ed assegnare 23032* (UTM-RER) ai dati.

provato, FUNZIONA... ma solo coi vettoriali, se assegno questa
proiezione a un layer raster me la colloca correttamente, ma non la
visualizza (bug di qgis??)

E' vero... sia sotto Hardy che sotto win, con la Metis i raster sono
visualizzati solo se sono definiti nello stesso SRS della vista. Se si
tenta di riproiettarli da un SRS differente rispetto a quello della
vista, sono georeferenziati correttamente, ma non sono visualizzati.
Non ti saprei dare una spiegazione in merito.

Vorrei aggiungere che con QGIS 0.11 compilato con cmake ho problemi con i
raster di GRASS.
Se gli SRS della vista e del raster che tento di visualizzare non
corrispondono, QGIS va in crash.
Questo non accadeva con QIS 0.11 installato dai pacchetti.

Definendo l' SRS corretto alla vista va tutto bene.

Saluti
Gabriele

--
View this message in context: http://www.nabble.com/ancora%3A-QGIS-UTM-ED50-Emilia-Romagna-tp19589110p19627257.html
Sent from the Gfoss mailing list archive at Nabble.com.

Gabriele N. ha scritto:

Vorrei aggiungere che con QGIS 0.11 compilato con cmake ho problemi con i
raster di GRASS.
Se gli SRS della vista e del raster che tento di visualizzare non
corrispondono, QGIS va in crash.

In effetti, ci sono un pò di ticket aperti e non sulla questione:
http://trac.osgeo.org/qgis/ticket/1079
http://trac.osgeo.org/qgis/ticket/474
http://trac.osgeo.org/qgis/ticket/204
Per il momento, dobbiamo limitarci ad usare raster (di GRASS e non)
definiti nello stesso SRS della vista.

ciao
Antonio

Antonio Falciano ha scritto:

Gabriele N. ha scritto:
  
Vorrei aggiungere che con QGIS 0.11 compilato con cmake ho problemi con i
raster di GRASS.
 Se gli SRS della vista e del raster che tento di visualizzare non
corrispondono, QGIS va in crash.
    

In effetti, ci sono un pò di ticket aperti e non sulla questione:
[http://trac.osgeo.org/qgis/ticket/1079](http://trac.osgeo.org/qgis/ticket/1079)
[http://trac.osgeo.org/qgis/ticket/474](http://trac.osgeo.org/qgis/ticket/474)
[http://trac.osgeo.org/qgis/ticket/204](http://trac.osgeo.org/qgis/ticket/204)
Per il momento, dobbiamo limitarci ad usare raster (di GRASS e non)
definiti nello stesso SRS della vista.

ciao
Antonio
  

ma anche i vettori, non semprevengono riproiettatti correttamente, per es. riproiettare da wgs84 a UTM-RER mi da lo stesso problema, è collocato correttamente, ma non si vede…

a proposito di raster… è capitato a qualcuno di non riuscire a stampare dei raster? in alcuni casi non li stampa e fa pagina bianca come sfondo…

ciao

e.l.

enrico lambertini ha scritto:

ma anche i vettori, non semprevengono riproiettatti correttamente, per
es. riproiettare da wgs84 a UTM-RER mi da lo stesso problema, è
collocato correttamente, ma non si vede...

Poichè non uso correntemente Qgis, per vederci chiaro, ho fatto qualche
test: ho estratto tre province della regione Emilia Romagna (Bologna,
Ravenna e Ferrara) da [1] che è in 23032, di cui:
- Bologna l'ho lasciata in 23032;
- Ravenna l'ho trasformata in 32632 e
- Ferrara in 23032*,
ottendo in definitiva 3 shapefile nei 3 SRS che ci interessano.
Definisco quindi un progetto in 23032, carico le tre province nei tre
differenti SRS ... et voilĂ  ... il mosaico, a meno dell'accuratezza delle
trasformazioni, è ricomposto. In particolare, 23032 e 23032* combaciano
alla perfezione, trattandosi solo di una traslazione!
Non contento di ciò, ho provato a cambiare l'SRS del progetto,
impostandolo una prima volta come 23032* ed una seconda come 32632, ed
in entrambi i casi va tutto perfettamente!
Prova a caricare i tuoi layer vettoriali in un nuovo progetto.
Verificata la corretta riproiezione di questi, carica solo raster
definiti nel'SRS del progetto. Paolo Craveri ti ha giĂ  detto come fare
per trasformare i raster in GRASS oppure con le GDAL. A questo punto non
dovresti avere piĂą problemi, bug e pazienza permettendo.

ciao
Antonio

[1] http://www.istat.it/ambiente/cartografia/province.zip

Alla fine sono giunto a una conclusione:

pur essendo dichiarati come sistema di riferimento ed50 utm32n RER in realtà i ctr a disposizione in Emilia-Romagna usano come sistema di riferimento i Gauss-Boaga, infatti mi sono procurato delle mappe vettoriali in utm di una porzione di territorio e ho effettuato una semplice traslazione lineare di X=+999947 per le Y=+3999820 [1] ed ho ottenuto una sovrapposizione pressochè perfetta (errori inferiori al metro), quindi come suggerito da diversi di voi ho mantenuto i ctr nella loro proiezione originaria (senza riproiettarli in qgis per evitare che "sparissero") ed ho semplicemente traslato il layer vettoriale dei punti... PERFETTO :slight_smile:

appena ho tempo provvedo a scrivere un riassunto di questa discussione e postare tutto sul wiki con anche l'aggiunta di qualche bella immagine

ciao e grazie a tutti

enrico lambertini

p.s. ho notato che il problema della ri-proiezione dei raster non è stato risolto ancora nemmeno nella beta di qgis 1.0 speriamo che per la stable sia sistemato.. in tanto la gestione della prestampa è veramente MOLTO MOLTO migliorata

[1] http://listserv.unipr.it/pipermail/grass-italia/2005-December/001366.html

Paolo Cavallini ha scritto:

enrico lambertini ha scritto:

  
appena ho tempo provvedo a scrivere un riassunto di questa discussione e
postare tutto sul wiki con anche l'aggiunta di qualche bella immagine
    

bene, attendiamo fiduciosi.
  
ciao e grazie a tutti

enrico lambertini

p.s. ho notato che il problema della ri-proiezione dei raster non è
stato risolto ancora nemmeno nella beta di qgis 1.0 speriamo che per la
stable sia sistemato.. 
    

Cosa intendi? La riproiezione dei raster, a che ne sappia io, non e' mai
stata supportata in qgis, e dubito che ne varrebbe la pena, con quel che
costa in termini computazionali.
Salutoni.
pc
  

in pratica se abilito come impostazione globale nel file la proiezione al volo e ad un layer vettoriale da un srs diverso da quello del file viene riproiettatto correttamente nel nuovo sistema di riferimento, se si cambia l’srs di un layer raster il layer viene riproiettato nella posizione corretta, ma non è più visibile, neanche se si stampa… al che le mie personali ipotesi sono 2: o è una mancanza di sviluppo/bug e allora si attende che qualche programmatore capace corregga/implementi oppure converrebbe impedire di cambiare SRS ai layer raster e spiegare chiaramente che srs dei file deve sempre coincidere con quello dei layer raster (tuttavia ciò mi sembrerebbe una grossa limitazione per un programma che si sta evolvendo così rapidamente)

ciao

e.l.

enrico lambertini ha scritto:

in pratica se abilito come impostazione globale nel file la proiezione
al volo e ad un layer vettoriale da un srs diverso da quello del file
viene riproiettatto correttamente nel nuovo sistema di riferimento, se
si cambia l'srs di un layer raster il layer viene riproiettato nella
posizione corretta, ma non è più visibile, neanche se si stampa.... al
che le mie personali ipotesi sono 2: o è una mancanza di sviluppo/bug e
allora si attende che qualche programmatore capace corregga/implementi
oppure converrebbe impedire di cambiare SRS ai layer raster e spiegare
chiaramente che srs dei file deve sempre coincidere con quello dei layer
raster (tuttavia ciò mi sembrerebbe una grossa limitazione per un
programma che si sta evolvendo così rapidamente)

Come scrivevo, credo che riproiettare al volo un raster (si dovrebbe
usare gdal per questo) sia un'operazione talmente lenta che avrebbe poco
senso. Cosa fanno altri sw per questo (a parte grass, che avendo una
struttura dati molto piu' complessa puo' lavorare piu' rapidamente con
le matrici)?
Concordo, che se le cose stanno cosi' l'utente dovrebbe essere
avvertito, e non dovrebbe poter provare a riproiettare.
Ti va di aprire una discussione sulla lista internazionale di qgis?
Saluti.
pc
--
Paolo Cavallini, see: * http://www.faunalia.it/pc *

Paolo Cavallini ha scritto:

enrico lambertini ha scritto:

  
in pratica se abilito come impostazione globale nel file la proiezione
al volo e ad un layer vettoriale da un srs diverso da quello del file
viene riproiettatto correttamente nel nuovo sistema di riferimento, se
si cambia l'srs di un layer raster il layer viene riproiettato nella
posizione corretta, ma non è più visibile, neanche se si stampa.... al
che le mie personali ipotesi sono 2: o è una mancanza di sviluppo/bug e
allora si attende che qualche programmatore capace corregga/implementi
oppure converrebbe impedire di cambiare SRS ai layer raster e spiegare
chiaramente che srs dei file deve sempre coincidere con quello dei layer
raster (tuttavia ciò mi sembrerebbe una grossa limitazione per un
programma che si sta evolvendo così rapidamente)
    

Come scrivevo, credo che riproiettare al volo un raster (si dovrebbe
usare gdal per questo) sia un'operazione talmente lenta che avrebbe poco
senso. Cosa fanno altri sw per questo (a parte grass, che avendo una
struttura dati molto piu' complessa puo' lavorare piu' rapidamente con
le matrici)?
Concordo, che se le cose stanno cosi' l'utente dovrebbe essere
avvertito, e non dovrebbe poter provare a riproiettare.
Ti va di aprire una discussione sulla lista internazionale di qgis?
Saluti.
pc
  

Ne so veramente poco, comunque sono sempre disponibile a discutere e approfondire il dibattito.

Nonostante la complessità dell’operazione secondo me è fondamentale per l’utente novizio e non, poter riproiettare i raster, quantomeno, dovrebbe essere possibile nel momento del caricamento selezionare la creazione di un nuovo raster riproiettato e importare quello, io parlo da utente inesperto che si è avvicinato da pochissimo ai software GIS in generale.
Anche perché, se ho 2 raster da sovrapporre in sistemi di riferimento differenti cosa faccio? carico in grass ri-proietto e re-importo? se sono 2 ok lo faccio, ma se sono 20-30? mi rompo presto… se sono un centinaio???

Mi potresti spiegare cosa intendi con usare gdal per riproiettare?