[Gfoss] riproiettare con GRASS

Local Chapters GFOSS.it
1

Salve a tutti,
sto provando con GRASS 6.3 su Mac Os X a riproiettare i confini
comunali italiani (fonte ISTAT) per allinearli ad alcuni layers da me
realizzati, ma ho qualche problema, che con la proiezione al volo di
QGIS non avevo.

I miei layer sono in Gauss-Boaga e per la location ho usato:

# Monte Mario (Rome) / Italy zone 2
<26592> +proj=tmerc +lat_0=0 +lon_0=2.54766666666666 +k=0.999600
+x_0=2520000 +y_0=0 +ellps=intl +pm=rome +units=m +no_defs <>

Il layer dell'ISTAT
(http://www.freegis-italia.org/index.php?option=com_content&task=view&id=347&Itemid=46)
è in ED 1950 UTM 32N e nella creazione della location ho usato:

# ED50 / UTM zone 32N
<23032> +proj=utm +zone=32 +ellps=intl +units=m +no_defs <>

Con il comando g.region -p lanciato sulle due location ottengo:

location gauss-boaga:

projection: 99 (Transverse Mercator)
zone: 0
datum: rome40
ellipsoid: international
north: 1
south: 0
west: 0
east: 1
nsres: 1
ewres: 1
rows: 1
cols: 1
cells: 1

location UTM32N:

projection: 1 (UTM)
zone: 32
datum: eur50
ellipsoid: international
north: 1
south: 0
west: 0
east: 1
nsres: 1
ewres: 1
rows: 1
cols: 1
cells: 1

A questo punto con v.proj ho importato dalla location in UTM32N ad
importare il vettoriale dei comuni, ma continuo a non riuscire a
sovrapporlo e rispetto ai miei layer l'italia appare spostata pi√π a
sinistra (almeno non è più in Libia come mi succedeva con QGIS che
assegnava ELD78... :slight_smile: ).

Mentre definivo la location in GRASS l'unico dubbio mi era sorto sulla
scelta del datum, ma il più ovvio mi sembrava il primo (messaggio di
allerta compreso!)

---
1
Used in whole eur50 region
towgs84=-87.000,-98.000,-121.000
Default 3-Parameter Transformation (May not be optimum for older
datums; use this only if no more appropriate options are available.)
---
2
Used in Denmark
---
3
Used in France
---
4
Used in Gibraltar
---
5
Used in Spain (except Northwest)
6
Used in Spain (Northwest only - 41d30'N to 43d50'N and 4d30'W to 9d25'W)
---
7
Used in Spain (Balearic Islands)
8
Used in Turkey

A questo punto sono fermo. Aiutino?

grazie

2

Così al volo, ritengo che la mancata sovrapposizione dei dati (se si tratta di alcune centinaia di metri e non di centinaia di km!!) sia la incompatibilità di base dei due CRS (Gauss-Boaga e UTMED50), vedi discussione [1] aperta proprio da te Luca, nella quale io vi sottoponevo proprio il problema relativo ai due CRS in questione.

PB

[1] http://www.nabble.com/Assegnare-proiezione-in-gvSIG-tf4409298.html

Il 18/09/07, Luca Mandolesi ha scritto:

Salve a tutti,
sto provando con GRASS 6.3 su Mac Os X a riproiettare i confini
comunali italiani (fonte ISTAT) per allinearli ad alcuni layers da me
realizzati, ma ho qualche problema, che con la proiezione al volo di
QGIS non avevo.

I miei layer sono in Gauss-Boaga e per la location ho usato:

Monte Mario (Rome) / Italy zone 2

<26592> +proj=tmerc +lat_0=0 +lon_0=2.54766666666666 +k=0.999600
+x_0=2520000 +y_0=0 +ellps=intl +pm=rome +units=m +no_defs <>

Il layer dell’ISTAT
(http://www.freegis-italia.org/index.php?option=com_content&task=view&id=347&Itemid=46 )
è in ED 1950 UTM 32N e nella creazione della location ho usato:

ED50 / UTM zone 32N

<23032> +proj=utm +zone=32 +ellps=intl +units=m +no_defs <>

Con il comando g.region -p lanciato sulle due location ottengo:

location gauss-boaga:

projection: 99 (Transverse Mercator)
zone: 0
datum: rome40
ellipsoid: international
north: 1
south: 0
west: 0
east: 1
nsres: 1
ewres: 1
rows: 1
cols: 1
cells: 1

location UTM32N:

projection: 1 (UTM)
zone: 32
datum: eur50
ellipsoid: international
north: 1
south: 0
west: 0
east: 1
nsres: 1
ewres: 1
rows: 1
cols: 1
cells: 1

A questo punto con v.proj ho importato dalla location in UTM32N ad
importare il vettoriale dei comuni, ma continuo a non riuscire a
sovrapporlo e rispetto ai miei layer l’italia appare spostata pi√π a
sinistra (almeno non è più in Libia come mi succedeva con QGIS che
assegnava ELD78… :slight_smile: ).

Mentre definivo la location in GRASS l’unico dubbio mi era sorto sulla
scelta del datum, ma il più ovvio mi sembrava il primo (messaggio di
allerta compreso!)

1
Used in whole eur50 region
towgs84=-87.000,-98.000,-121.000
Default 3-Parameter Transformation (May not be optimum for older
datums; use this only if no more appropriate options are available.)

2
Used in Denmark

3
Used in France

4
Used in Gibraltar

5
Used in Spain (except Northwest)
6
Used in Spain (Northwest only - 41d30’N to 43d50’N and 4d30’W to 9d25’W)

7
Used in Spain (Balearic Islands)
8
Used in Turkey

A questo punto sono fermo. Aiutino?

grazie

Iscriviti all’associazione GFOSS.it : http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss

3

Così al volo, ritengo che la mancata sovrapposizione dei dati (se si tratta
di alcune centinaia di metri e non di centinaia di km!!) sia la

opterei per le centinaia di Kilometri!!!

discussione [1] aperta proprio da te Luca, nella quale io vi sottoponevo
proprio il problema relativo ai due CRS in questione.

Ok. Effettivamente mi sono un po' perso lì. Rileggerò il tutto con
calma, vedendo se esiste qualche escamotage. Al massimo mi
"accontento" (si fa per dire :slight_smile: ) di QGIS+GRASS e visualizzare il
tutto.

Ciao e grazie

4

On Tue, Sep 18, 2007 at 04:35:09PM +0200, Luca Mandolesi wrote:
...

Con il comando g.region -p lanciato sulle due location ottengo:

...

A questo punto sono fermo. Aiutino?

Potresti spedirci invece

g.proj -w
?

A questo punto con v.proj ho importato dalla location in UTM32N ad
importare il vettoriale dei comuni, ma continuo a non riuscire a
sovrapporlo e rispetto ai miei layer l'italia appare spostata piu' a
sinistra

Postresti misuare quanto e' spostata la mappa?

ciao
Markus

------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------

5

Potresti spedirci invece

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["metre",1]]

ED50_32N

PROJCS["UTM Zone 32, Northern Hemisphere",
    GEOGCS["international",
        DATUM["European_Datum_1950",
            SPHEROID["International_1924",6378388,297],
            TOWGS84[-87.000,-98.000,-121.000]],
        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",500000],
    PARAMETER["false_northing",0],
    UNIT["metre",1]]

Postresti misuare quanto e' spostata la mappa?

All'incirca il vettoriale che proviene dalla location UTM32N è
spostato verso Ovest di 540179 metri (ho provato anche a importare da
GB a UTM e la distanza è la medesima).

(Measurement
--segment length = 540179 metres
cumulative length = 540179 metres)

Ciao

6

Luca Mandolesi ha scritto:

Salve a tutti,
sto provando con GRASS 6.3 su Mac Os X a riproiettare i confini
comunali italiani (fonte ISTAT) per allinearli ad alcuni layers da me
realizzati, ma ho qualche problema, che con la proiezione al volo di
QGIS non avevo.

I miei layer sono in Gauss-Boaga e per la location ho usato:

# Monte Mario (Rome) / Italy zone 2
<26592> +proj=tmerc +lat_0=0 +lon_0=2.54766666666666 +k=0.999600
+x_0=2520000 +y_0=0 +ellps=intl +pm=rome +units=m +no_defs <>

Il layer dell'ISTAT
(http://www.freegis-italia.org/index.php?option=com_content&task=view&id=347&Itemid=46)
è in ED 1950 UTM 32N e nella creazione della location ho usato:

# ED50 / UTM zone 32N
<23032> +proj=utm +zone=32 +ellps=intl +units=m +no_defs <>

Sempre che i tuoi dati siano nel fuso Est 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 <>

ciao
ant

7

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.
Due curiosità a questo punto:
1. come datum ho scelto la prima opzione, la peninsular part e non
rome40 region. E' 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 ?

Grazie :slight_smile:

ciao

8

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.
Tutto ciò è valido, anche se:
- la Monte Mario (Rome) / Italy è quella che formalmente corrisponde
all'esatta definizione del ns sistema cartografico nazionale,
utilizzando di fatto il datum Roma40; presenta però il problema che
rispetto al datum geocentrico di appoggio (WGS84) occorrono ben due
trasformazioni (cambio di datum e cambio di proiezione)
- la Monte Mario / Italy, invece, è stato il modo per condurre più
facilmente GB a WGS84, imponendo praticamente il passaggio del meridiano
fondamentale per Greewich (cosa che in realtà non è!), rendendo
necessaria così una sola trasformazione (cambio di proiezione).
Spero di essere stato abbastanza chiaro.

Grazie :slight_smile:

ciao

ciao
ant

9

Questo thread è molto interessante. Sono cose che non sono del tutto chiare per molti. Non so se esiste già una paginetta sul wiki con quanto ha detto Antonio, se non ci fosse potrebbe essere utile farla. Che ne dite?

Giovanni

Il 20/09/07, Antonio Falciano <afalciano@yahoo.it> ha scritto:

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.

  1. 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.
Tutto ciò è valido, anche se:

  • la Monte Mario (Rome) / Italy è quella che formalmente corrisponde
    all’esatta definizione del ns sistema cartografico nazionale,
    utilizzando di fatto il datum Roma40; presenta però il problema che
    rispetto al datum geocentrico di appoggio (WGS84) occorrono ben due
    trasformazioni (cambio di datum e cambio di proiezione)
  • la Monte Mario / Italy, invece, è stato il modo per condurre più
    facilmente GB a WGS84, imponendo praticamente il passaggio del meridiano
    fondamentale per Greewich (cosa che in realtà non è!), rendendo
    necessaria così una sola trasformazione (cambio di proiezione).
    Spero di essere stato abbastanza chiaro.

Grazie :slight_smile:

ciao

ciao
ant

Iscriviti all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss

10

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?):

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.

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

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

------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------

11

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.. :slight_smile:

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

12

Mi permetterò di raccogliere e riordinare questi appunti sul wiki...

Il 20/09/07, Antonio Falciano<afalciano@yahoo.it> ha scritto:

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.. :slight_smile:
>

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

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss

13

Aggiungo infine l'ulitmo (forse) dubbio.

Visti i felici esiti con il vettoriale, ho provato a riproiettare con
GRASS anche un raster con r.proj da:

# Monte Mario (Rome) / Italy zone 2
<26592> +proj=tmerc +lat_0=0 +lon_0=2.54766666666666 +k=0.999600
+x_0=2520000 +y_0=0 +ellps=intl +pm=rome +units=m +no_defs <>

a

# ED50 / UTM zone 32N
<23032> +proj=utm +zone=32 +ellps=intl +units=m +no_defs <>

Ricevendo l'errore:

Input raster map is outside current region

Nel tutorialino di riferimento che uso non me la dava come opzione! :slight_smile:
http://www.ing.unitn.it/~grass/docs/tutorial_62/htdocs/esercitazione/datum/node5.html

E' perchè non è possibile trasferire da GB a UTM un raster?

14

On 9/20/07, Luca Mandolesi <mandoluca@gmail.com> wrote:

Aggiungo infine l'ulitmo (forse) dubbio.

Visti i felici esiti con il vettoriale, ho provato a riproiettare con
GRASS anche un raster con r.proj da:

# Monte Mario (Rome) / Italy zone 2
<26592> +proj=tmerc +lat_0=0 +lon_0=2.54766666666666 +k=0.999600
+x_0=2520000 +y_0=0 +ellps=intl +pm=rome +units=m +no_defs <>

a

# ED50 / UTM zone 32N
<23032> +proj=utm +zone=32 +ellps=intl +units=m +no_defs <>

Ricevendo l'errore:

Input raster map is outside current region

Nel tutorialino di riferimento che uso non me la dava come opzione! :slight_smile:
http://www.ing.unitn.it/~grass/docs/tutorial_62/htdocs/esercitazione/datum/node5.html

E' perchè non è possibile trasferire da GB a UTM un raster?

Ritiro l'errore!!! La risposta c'è già nel tutti "Forse non tutti
sanno che", http://wiki.gfoss.it/index.php/Forse_non_tutti_sanno_che.

scusate e ciao a tutti!!!

mando