[Gvsig_italian] Sovrapposizione layer .shp - Scarto di 500 km

Mar 28 Dic 2010 02:30:01 PST

Salve a tutti,
finalmente credo di aver individuato il mio errore. Nel caricare il 
layer dei comuni ISTAT, prima di selezionare la trasformazione, non 
selezionavo il corretto CRS del layer, ovvero 23032. Ora mi sembra che 
si sovrappongano correttamente.
Facendo così, anche i layer raster delle sezioni CTR si sovrappongono 
correttamente.

Riepilogo il metodo (spero corretto) a beneficio di altri che 
eventualmente si trovano come me ad affrontare questo tipo di ostacolo.
- creare una nuova vista in CRS 32633 (per l'Italia, zona 33)
- caricare il layer CTR (è in WGS84)
- caricare il layer dei comuni ISTAT: bisogna prima selezionare il CRS 
del layer, che è 23032, poi la corretta trasformazione (codice 1133, da 
ED50 a WGS84) e i layer dovrebbero sovrapporsi correttamente.

A questo punto i layer raster delle singole sezioni CTR si sovrappongono 
senza alcun problema al quadro di unione.

Mi rimane una perplessità in quanto mi sembra che l'errore di 
sovrapposizione tra CTR e confini comunali ISTAT sia notevole 
(nell'ordine delle decine di metri), è possibile?

Grazie ancora a tutti per l'aiuto e per le tantissime informazioni fornite!
Paolo

Il 23/12/2010 23.17, e-paul ha scritto:
> Salve a tutti,
> scusate se continuo a "battere" su un argomento così vecchio, ma ormai
> questa per me è diventata una sfida (spero che qualcuno voglia
> condividerla con me)!
>
> Dunque ho provato a operare così:
> - creo una vista con CRS 4326
> - aggiungo il layer ISTAT dei Comunisenza alcuna trasformazione o
> riproiezione (i dati sono in ED 23032)
> - aggiungo il layer quadro di unione CTR specificando CRS 32633 (zona
> 33N) che dovrebbe essere quella cui si riferisce la CTR
>
> A questo punto ho una vista con CRS 4326 su cui i layer si sovrappongono
> correttamente! (salto sulla sedia dalla gioia).
>
> Quindi provo a caricare i raster delle singole sezioni della CTR (files
> .tiff) ma la vista rimane completamente bianca. Immagino che succeda
> perché questi ultimi vengono "sparati" a distanze enormi dagli altri
> layer! Infatti zoomando su ciascun layer esso viene visualizzato
> correttamente.
> Il file .tfw associato a ciascun raster delle sezioni CTR contiene i
> seguenti dati:
> (es. sezione 365100)
> 1.261906
> 0.00
> 0.00
> -1.261906
> 286204
> 4664190
> 293263.1000000001
> 4658433.19
>
> Credo che l'errore sia dovuto al fatto che sto caricando dei layer con
> coordinate chilometriche su una vista con coordinate geografiche?
>
> Grazie ancora a tutti per le tantissime informazioni date finora (e per
> quelle che ancora mi vorrete eventualmente dare).
>
> Non so se la lista possa essere utilizzata per questo ma approfitto per
> augurare a tutti giorni di felicità e serenità.
>
> Paolo Caporro
>
> Il 20/12/2010 14.11, Pietro d'Orio ha scritto:
>> Il tuo quadro di unione si trova in coordinate GEOGRAFICGE WGS84, non
>> sono PROIETTATE EPSG: 4326
>>
>> I dati istat sono in ED50 UTM32N, EPSG 23032
>>
>> Ora ne approfitto per fare un appunto perchè ho notato che sono in molti
>> a fanno fatica a distinguere i due tipi di coordinate: geografiche e
>> proiettate
>>
>> Le coordinate geografiche sono solitamente espresse in gradi LAT e LONG
>> costruite su di un elissoide di riferimento (per esempio WGS84), e in
>> quanto tali non hanno una zona!!
>>
>> Ora questo elissoide non è altro che la forma matematica che va ad
>> approssimare la "forma" del pianeta. E' ovvio che a seconda delle zone
>> l'errore che si va a creare può essere maggiore o minore.
>>
>> Dato che un elissoide non può essere rappresentato sul piano, bisogna
>> proiettarlo su di un cilindro o un cono.
>>
>> La proiezione dunque permette di trasferire le coordinate da lat-long a
>> piane metriche. Per esempio UTM32N WGS84 rappresenta coordinate
>> appartenenti all'elissoide di riferimento WGS84 riproiettate su di un
>> cilindro che utilizza il fuso 32 nord come centro, o "punto di contatto"
>> tra l'elissoide e il cilindro. Questo punto (che in questo caso è una
>> linea) ha distorsione 0 e mano mano che ci si allontana questa
>> distorsione aumenta.
>> Ecco perchè esistono molti tipi di proiezioni e diverse zone (32N, 33N,
>> 32S, 33S, ecc)
>>
>> Aggiungerei una nota:
>>
>> Proiettare e riproiettare dati utilizzando lo stesso elissoide di
>> riferimento (per es.: WGS84 ->  UTM32N WGS84 ->  WGS84) non crea errori, e
>> qualsiasi desktop gis è in grado di farlo.
>> Nel caso in cui la riproiezione venga effettuata tra diversi elissoidi
>> (per es. WGS84 UTM32N ->  ED50 UTM32N) questa può generare errori anche
>> di diversi metri. Per applicare una trasformazione corretta bisognerebbe
>> procurarsi l'elenco dei famosi 7 parametri, che vanno a sostituire il
>> processo di riproiezione. I sette parametri sono in ordine:
>>
>>      * X (spostamento di coordinate lungo l'asse X)
>>      * Y (spostamento di coordinate lungo l'asse Y)
>>      * Z (spostamento di coordinate lungo l'asse Z)
>>      * dX (rotazione intorno all'asse X)
>>      * dY (rotazione intorno all'asse Y)
>>      * dZ (rotazione intorno all'asse Z)
>>      * K fattore di scala
>>
>>
>> *Dr. Pietro d'Orio*
>> *R3 GIS* Srl - GmbH
>> Via Johann Kravogl-Str. 2
>> I-39012 Meran/Merano (BZ)
>> web: www.r3-gis.com<http://www.r3-gis.com/>
>> Email: pietro.dorio a r3-gis.com<mailto:pietro.dorio a r3-gis.com>
>> Tel. : +39 0473 494949
>> Fax : +39 0473 069902
>>
>> *ATTENZIONE!* Le informazioni contenute nella presente e-mail e nei
>> documenti eventualmente allegati sono confidenziali. La loro diffusione,
>> distribuzione e/o riproduzione da parte di terzi, senza autorizzazione
>> del mittente è vietata e può violare il D. Lgs. 196/2003. In caso di
>> ricezione per errore, Vogliate immediatamente informare il mittente del
>> messaggio e distruggere la e-mail.
>>
>> *ACHTUNG!* Die in dieser Nachricht oder in den beigelegten Dokumenten
>> beinhalteten Informationen sind streng vertraulich. Ihre Verbreitung
>> und/oder ihre Wiedergabe durch Dritte ist ohne Erlaubnis des Absenders
>> verboten und verstößt gegen das Legislativdekret 196/2003. Sollten Sie
>> diese Mitteilung irrtümlicherweise erhalten haben, bitten wir Sie uns
>> umgehend zu informieren und anschließend die Mitteilung zu vernichten.
>>
>> *WARNING!* This e-mail may contain confidential and/or privileged
>> information. If you are not the intended recipient (or have received
>> this e-mail in error) please notify the sender immediately and destroy
>> this e-mail. Any unauthorised copying, disclousure or distribution of
>> the material in this e-mail is strictly forbidden and could be against
>> the law (D. Lgs. 196/2003)
>>
>>
>>
>>
>>
>>
>>
>> e-paul ha scritto:
>>> A questo punto... non ci sto più  capendo nulla!
>>> Scusate ma, come ho premesso, sono autodidatta e alle prime armi.
>>>
>>> Dunque, ricapitolando;
>>> - come faccio a sapere qualeè  il CRS associato al mio quadro di unione
>>> della CTR? Il file qu_10u33.prj contiene quanto segue:
>>> GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]
>>> quindi siamo in WGS 1984, ma in  che zona?
>>> Il fatto che nel nome del file ci sia un "33" mi fa pensare che siamo
>>> nella zona 33, ma questa informazioneè  contenuta nel file?
>>>
>>> - Il file ISTAT dei Comuni effettivamente fa riferimento alla zona 32N.
>>> Il file "com2010_s.prj" contiene quanto segue:
>>> PROJCS["ED_1950_UTM_Zone_32N",GEOGCS["GCS_European_1950",DATUM["D_European_1950",SPHEROID["International_1924",6378388.0,297.0]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",9.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]
>>>
>>> - riproiezione al volo vuol dire che i layer vengono correttamente
>>> rappresentati indipendentemente dal CRS adottato per la vista che sto
>>> utilizzando? Devo essere io comunque a specificare la trasformazione
>>> necessaria o il software individua i CRS di ciascun layer autonomamente?
>>>
>>> Il 17/12/2010 10.22, Antonio Falciano ha scritto:
>>>
>>>> Il 17/12/2010 9.20, Pietro d'Orio ha scritto:
>>>>
>>>>> Io opererei in questo modo:
>>>>>
>>>>> 1. Apri una vista con codice EPSG 23030 e ci carichi i dati originali Istat
>>>>> 2. Apri il processo di riproiezioni a partire da 23030 al codice EPSG
>>>>> della tua CTR
>>>>> 3. Chiudi la vista, ne fai una nuova con il codice EPSG della tua CTR e
>>>>> carichi i nuovi confini riproiettati.
>>>>>
>>>
>>> Alla fine ho aeguito un po' una via di mezzo tra le varie proposte che
>>> ho letto qui nella lista:
>>> - ho creato una nuova vista con CRS 32633
>>> - ho caricato il quadro di unione CTR (non dovrebbero essere necessarie
>>> riproiezioni, se ho capito bene, quindi non ne applico alcuna)
>>> - ho caricato lo shapefile dei comuni ISTAT riproiettando al volo (cioè
>>> quando carico il file con trasformazione da WGS_84 a EPSG 32633
>>>
>>> I layer sono ancora distanti 500 km :-(
>>>
>>> Se invece riproietto (tirando a indovinare) il layer dei comuni ISTAT da
>>> WGS84 a EPSG 32634 si sovrappongono correttamente.
>>>
>>> Qualcuno di voi potrebbe essere disposto a fare la stessa operazione di
>>> sovrapposizione per verificare i risultati? in caso posso inviare i
>>> files necessari in email privata.
>>>
>>> Grazie ancora a tutti e scusate per il protrarsi di questa discussione!
>>> Paolo Caporro
>>> _______________________________________________
>>> Gvsig_italian mailing list
>>> Gvsig_italian a lists.gvsig.org
>>> https://gvsig.org/lists/mailman/listinfo/gvsig_italian
>>>
>>
>>
>> _______________________________________________
>> Gvsig_italian mailing list
>> Gvsig_italian a lists.gvsig.org
>> https://gvsig.org/lists/mailman/listinfo/gvsig_italian
> _______________________________________________
> Gvsig_italian mailing list
> Gvsig_italian a lists.gvsig.org
> https://gvsig.org/lists/mailman/listinfo/gvsig_italian