[Gfoss] riproiettare con GRASS

[Antonio Falciano]

Markus Neteler ha scritto:
> On Thu, Sep 20, 2007 at 11:43:46AM +0200, Antonio Falciano wrote:
>> Luca Mandolesi ha scritto:
>>>> Sempre che i tuoi dati siano nel fuso Est
>>> Si, si! Sono in Romagna in quel di Rimini!!!
>>>> dovresti provare con:
>>>> # Monte Mario / Italy zone 2
>>>> <3004> +proj=tmerc +lat_0=0 +lon_0=15 +k=0.999600 +x_0=2520000 +y_0=0
>>>> +ellps=intl +units=m +no_defs <>
>>> Bingo! Giusto! Ora il tutto si sovrappone correttamente.
>> Perfetto.
>>
>>> Due curiosità a questo punto:
>>> 1. come datum ho scelto la prima opzione, la peninsular part e non
>>> rome40 region. E' corretto?
>> Se hai definito una nuova location (ad es. GB_Est) con EPSG code: 3004 e
>> poi hai scelto la trasformazione 1 (Italy - Peninsular Part) è corretto.
>>
>>> 2. C'è un criterio con cui scegliere o l'una o l'altra tra Monte Mario
>>> / Italy zone 2
>>> e Monte Mario (Rome) / Italy zone 2 ?
>> E' essenzialmente un criterio dettato dall'esperienza. Personalmente
>> preferisco usare la 3004 + la trasformazione 1 (7 parametri) perchè mi
>> fornisce un'accuratezza maggiore (4 m), mentre la 26592 dovrebbe essere
>> accoppiata con la trasformazione 4 (rome40 region) che, essendo una
>> trasformazione a 3 parametri, risulta essere meno precisa.
> 
> Scusa, perchè questo ?Io preferisco la 26592 siccome contiene
> la definizione del "prime meridian" (pm=) che manca in 3004.
> 
> Uso da anni 26592 con datum di 7 parametri (sbagliato?):
> 

Se per datum intendi la trasformazione, temo proprio di si. Applicare la 
stessa trasformazione a due CRS che differiscono tra loro per un 
longitude offset
http://ocean.csl.co.uk/experimental/service/search.php?term=1262&submit=&searchType=coordinate_operation&format=html&view=collected&server=1
non credo sia proprio la stessa cosa.

> GRASS 6.3.cvs (pat):~ > g.proj -w
> PROJCS["Transverse Mercator",
>     GEOGCS["international",
>         DATUM["Monte_Mario",
>             SPHEROID["International_1924",6378388,297],
>             TOWGS84[-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68]],
>         PRIMEM["Greenwich",0],
>         UNIT["degree",0.0174532925199433]],
>     PROJECTION["Transverse_Mercator"],
>     PARAMETER["latitude_of_origin",0],
>     PARAMETER["central_meridian",9],
>     PARAMETER["scale_factor",0.9996],
>     PARAMETER["false_easting",1500000],
>     PARAMETER["false_northing",0],
>     UNIT["meter",1]]
> 
> Magari hai ragione, ma sono curioso perchè nondovrei usare
> EPSG 26592 con 7 parametri. GRASS mi offre sia il dato a
> 3 sia quello a 7 parametri tramite dialogo.
> 

In effetti, GRASS presenta tutte le trasformazioni possibili per i CRS 
italiani...
IMHO, queste trasformazioni andrebbero divise in due... mi spiego meglio:

- trasformazioni possibili per 26592:
http://ocean.csl.co.uk/experimental/service/search.php?term=26592&submit=&searchType=crs&format=html&view=collected&server=1
di cui:
http://ocean.csl.co.uk/experimental/service/search.php?term=8175&submit=&searchType=coordinate_operation&format=html&view=collected&server=1
è a 3 parametri

- trasformazioni possibili per 3004:
http://ocean.csl.co.uk/experimental/service/search.php?term=3004&submit=&searchType=crs&format=html&view=collected&server=1
ce ne sono un pacco, tra cui
http://ocean.csl.co.uk/experimental/service/search.php?term=1660&submit=&searchType=coordinate_operation&format=html&view=collected&server=1

sbaglio, o si tratta proprio dell'EPSG Geodetic Parameter Dataset?

> NB: una precisione di 4m non serve tanto se i dati GIS
> hanno una risoluzione di 10m per pixel (raster) 
> o peggiore.. :-)
> 

d'accordissimo, ma se permetti ...meglio 4 m che 30!

> Non so qunto aiuta:
> 
> EPSG SQL DB:
> # 3004:
> http://ocean.csl.co.uk/experimental/service/search.php?term=3004&submit=&searchType=crs&format=html&view=record&server=1
> 
> # 26592:
> http://ocean.csl.co.uk/experimental/service/search.php?term=26592&submit=&searchType=crs&format=html&view=record&server=1
> 
> Curioso,
> Markus

ciao
ant