[Gvsig_italian] R: Re: Sovrapposizione layer .shp - Scarto di 500 km - Risolto

[Antonio Falciano]

Il 28/12/2010 17.29, Moro Emanuele ha scritto:
> Non dimentichiamo che i dati delle CTR e dei limiti confinari istat
> possono avere origini diverse (es catastale, igm 25000, ecc.) ed
> addirittura essere stati digitalizzati a precisioni diverse. Perciò non
> è irragionevole aspettarsi delta di varii metri anche dopo aver messo a
> punto conversioni di coordinate o trasformazioni di datum.
> ;-)

La procedura che va a buon fine utilizzata in ultima battuta da Paolo
sfrutta comunque solo le conversioni e quindi non introduce
assolutamente altre fonti di errore. Tuttavia, resta pur sempre il fatto
che gli shp dei comuni ISTAT liberamente disponibili in download
presentano le geometrie semplificate, ragion per cui non si avra' mai
una perfetta congruenza con i confini IGM o della CTR. D'altronde, non
stiamo parlando mica di topografia ad alta precisione! ;)

> Auguri a tutti!

grazie altrettanto

ciao
Antonio

> Emanuele
>
>
> ----- Messaggio originale -----
> Da: gvsig_italian-bounces a lists.gvsig.org<gvsig_italian-bounces a lists.gvsig.org>
> A: Lista di discussione in lingua italiana utenti e sviluppatori di gvSIG<gvsig_italian a lists.gvsig.org>
> Inviato: Tue Dec 28 14:26:56 2010
> Oggetto: Re: [Gvsig_italian] Sovrapposizione layer .shp - Scarto di 500 km - Risolto
>
>
> Il 28/12/2010 13.19, Antonio Falciano ha scritto:
>> Il 28/12/2010 11.30, e-paul ha scritto:
>>> 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.
>>
>> Da quello che affermi qui e dalla perplessita' di cui parli dopo, e'
>> evidente che c'e' ancora molta confusione... Cerchero' di essere ancora
>> piu' chiaro, sperando di venirne a capo una volta per tutte,
>> possibilmente entro la fine del 2010.
>>
>>> 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)
>>
>> NB: l'Italia e' interessata dalle zone 32, 33 e 34 e non solo dalla 33
>> http://upload.wikimedia.org/wikipedia/commons/e/ed/Utm-zones.jpg
>>
>>> - caricare il layer CTR (è in WGS84)
>>
>> al limite, UTM WGS84 33N (EPSG:32633) e non WGS84 (EPSG:4326)
>>
>>> - 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.
>>
>> NB: questa procedura vale nell'ipotesi di CTR (quadro di unione e raster)
>> in UTM WGS84 33N (EPSG:32633)
>>
>>> A questo punto i layer raster delle singole sezioni CTR si sovrappongono
>>> senza alcun problema al quadro di unione.
>>
>> Certo! Questo avviene perche' al quadro di unione e ai raster della CTR
>> hai assegnato lo stesso CRS (EPSG:32633), ma cio' non vuol dire che stai
>> operando correttamente...
>>
>>> 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?
>>
>> Infatti! Questo dovrebbe indurti a pensare che quadro di unione e raster
>> della
>> CTR della Regione Lazio possano essere rappresentati in UTM ED50 33N
>> (EPSG: 23033), come d'altronde avevo gia' anticipato qui:
>> https://gvsig.org/lists/pipermail/gvsig_italian/2010-December/001836.html
>> leggendo i sistemi di coordinate in questa pagina:
>> http://www.urbanisticaecasa.regione.lazio.it/cartanet/#
>> dopo aver cliccato su "6. Quadri di unione" nel menu' a sinistra.
>>
>> In tal caso (quadro di unione e raster CTR in EPSG:23033), procederei cosi':
>> - crea una nuova vista in EPSG:23033 (UTM ED50 33N) [1];
>> - carica il layer dei comuni ISTAT in EPSG:23032 (UTM ED50 32N) SENZA
>> definire alcuna trasformazione (utilizzando lo stesso datum della vista
>> - ED50 -, non e' necessaria, per cui gvSIG operera' semplicemente una
>> "conversione" che, in questo caso, consistera' nel cambio di fuso);
>> - carica il layer vettoriale quadro di unione e i layer raster della CTR
>> sempre in EPSG:23033 (UTM ED50 33N), SENZA definire alcuna
>> trasformazione (dato che utilizziamo lo stesso CRS della vista).
>> A questo punto dovresti ottenere la tanto agognata sovrapposizione.
>>
>> [1] Per comodita', utilizziamo EPSG:23033 (UTM ED50 33N) per la vista,
>> poiche', come abbiamo detto in precedenza, i raster non sono proiettati
>> al volo in gvSIG e quindi ci conviene utilizzare lo stesso CRS dei raster
>> (...e anche per non complicare ulteriormente il problema).
>>
>>> Grazie ancora a tutti per l'aiuto e per le tantissime informazioni fornite!
>>> Paolo
>>
>> Buon lavoro!
>>
>
> Grazie mille.
> La procedura indicata ha funzionato perfettamente.
> Mi scuso se la discussione si è prolungata fin troppo e ha fatto perdere
> tempo agli utenti più esperti!
> Grazie ancora per le informazioni e l'aiuto!
> 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
>


-- 
Antonio Falciano
http://www.linkedin.com/in/antoniofalciano