[Gfoss] Assegnare proiezione in gvSIG

Local Chapters GFOSS.it
,
1

Salve,
ho iniziato a dare un'occhiata a gvSIG, ma non riesco a capire come
assegnare ad un layer la proiezione corretta.
Ho una base con raster 1:25000 e 1:5000 della provincia di rimini e con QGIS
li carico correttamente con Monte Mario (Rome) Italy zone 2.

Ora in QGIS carico anche i confini ISTAT dei comuni italiani che sono in
ELD79/UTM zone 32 e tramite proiezione al volo vengono correttamente
sovrapposti ai dati sopra descritti.

In gvSIG non riesco a fare questo. Quale proiezione devo assegnare o meglio,
esistono delle tabelle di confronto dei vari nomi e codici (EPSG, postgis,
etc) in modo da poter sapere quale proiezione usare?

grazie a tutti

--
View this message in context: http://www.nabble.com/Assegnare-proiezione-in-gvSIG-tf4409298.html#a12578988
Sent from the Gfoss mailing list archive at Nabble.com.

2

Per gestire meglio i CRS in gvSIG è utile installare il plugin sviluppato appositamente.
Quello embedded nel software infatti è piuttosto limitato e, per quanto ne so io, non possiede i parametri della Gauss-Boaga nè tantomeno permette di impostare un CRS custom.
Una volta installato, il plugin mette a disposizione i CRS codificati secondo l’EPSG e dunque tutti gli esistenti (o quasi).
Per quanto riguarda layers con CRS diversi, per quel che ho capito usandolo, gvSIG non ha la funzione di riproiezione al volo dei dati cartografici, dunque non è possibile usarli nella stessa vista.
Non so se Antonio Falciano, che conosce il software molto meglio, sappia qualcosa in più sulla questione.

PB

Il 09/09/07, mando ha scritto:

Salve,
ho iniziato a dare un’occhiata a gvSIG, ma non riesco a capire come
assegnare ad un layer la proiezione corretta.
Ho una base con raster 1:25000 e 1:5000 della provincia di rimini e con QGIS
li carico correttamente con Monte Mario (Rome) Italy zone 2.

Ora in QGIS carico anche i confini ISTAT dei comuni italiani che sono in
ELD79/UTM zone 32 e tramite proiezione al volo vengono correttamente
sovrapposti ai dati sopra descritti.

In gvSIG non riesco a fare questo. Quale proiezione devo assegnare o meglio,
esistono delle tabelle di confronto dei vari nomi e codici (EPSG, postgis,
etc) in modo da poter sapere quale proiezione usare?

grazie a tutti

–
View this message in context: http://www.nabble.com/Assegnare-proiezione-in-gvSIG-tf4409298.html#a12578988
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

3

Pietro Blu Giandonato ha scritto:

Per gestire meglio i CRS in gvSIG è utile installare il plugin <http://www.gvsig.gva.es/index.php?id=1580&L=2&K=1&gt;sviluppato appositamente.
Quello embedded nel software infatti è piuttosto limitato e, per quanto ne so io, non possiede i parametri della Gauss-Boaga nè tantomeno permette di impostare un CRS custom.

Esatto. NB: il plugin è già integrato nell'installazione principale dalla
versione 1.1 rc1, mentre nella 1.02 (ultima versione stabile) no.
Anche con il plugin non è possibile ancora definire una proiezione
personalizzata, piuttosto possono semplicemente essere
definite delle trasformazioni personalizzate a partire da CRS con
codifica EPSG.

Una volta installato, il plugin mette a disposizione i CRS codificati secondo l'EPSG e dunque tutti gli esistenti (o quasi).

Nell'ultima versione non stabile (1.1 rc2) sono presenti i CRS con
codifica EPSG, ESRI e IUA2000, manca ancora quella PostGIS a differenza
di Qgis.

Per quanto riguarda layers con CRS diversi, per quel che ho capito usandolo, gvSIG non ha la funzione di riproiezione al volo dei dati cartografici, dunque non è possibile usarli nella stessa vista.

Anche in gvSIG è possibile ottenere le proiezioni al volo, a patto che
sia definita un'opportuna trasformazione tra il CRS del layer e quello
della vista. Per fare ciò, scegliendo il CRS del layer occorre definire
l'eventuale trasformazione da utilizzare (EPSG, Manual, ecc.).

Codifica EPSG:
La proiezione al volo funziona egregiamente quando si ha a che fare con
wgs84, utm wgs84 e utm ed50, mentre con gauss boaga roma40 no.
Ad esempio, la trasformazione da gb roma40 a utm wgs84 definita
manualmente (utilizzando i classici parametri +towgs84=-104.1, -49.1,
-9.9, 0.971, -2.917, 0.714, -11.68) non sortisce alcun effetto: è come
se una trasformazione di default (sicilia? sardegna?) avesse la priorità.

Codifica ESRI:
Qui la proiezione al volo va meglio con gauss boaga (per modo di dire...),
peccato che la trasformazione utilizzata dà un errore dell'ordine dei 200
m e che non è possibile personalizzare la trasformazione.

In definitiva, per gauss boaga è consigliabile al momento effettuare le
conversioni all'esterno di gvSIG oppure usare GRASS/Qgis.

Non so se Antonio Falciano, che conosce il software molto meglio, sappia qualcosa in più sulla questione.

Pietro, grazie per l'assist... rimetto la palla al centro :wink:

Ciao
Antonio

PB

Il 09/09/07, *mando* ha scritto:

    Salve,
    ho iniziato a dare un'occhiata a gvSIG, ma non riesco a capire come
    assegnare ad un layer la proiezione corretta.
    Ho una base con raster 1:25000 e 1:5000 della provincia di rimini e
    con QGIS
    li carico correttamente con Monte Mario (Rome) Italy zone 2.

    Ora in QGIS carico anche i confini ISTAT dei comuni italiani che sono in
    ELD79/UTM zone 32 e tramite proiezione al volo vengono correttamente
    sovrapposti ai dati sopra descritti.

    In gvSIG non riesco a fare questo. Quale proiezione devo assegnare o
    meglio,
    esistono delle tabelle di confronto dei vari nomi e codici (EPSG,
    postgis,
    etc) in modo da poter sapere quale proiezione usare?

    grazie a tutti

    --
    View this message in context:
    http://www.nabble.com/Assegnare-proiezione-in-gvSIG-tf4409298.html#a12578988
    Sent from the Gfoss mailing list archive at Nabble.com
    <http://Nabble.com>.

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

------------------------------------------------------------------------

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

------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG Free Edition. Version: 7.5.485 / Virus Database: 269.13.8/993 - Release Date: 06/09/2007 15.18

4

On Sun, Sep 09, 2007 at 06:44:57AM -0700, mando wrote:

Salve,
ho iniziato a dare un'occhiata a gvSIG, ma non riesco a capire come
assegnare ad un layer la proiezione corretta.
Ho una base con raster 1:25000 e 1:5000 della provincia di rimini e con QGIS
li carico correttamente con Monte Mario (Rome) Italy zone 2.

Ora in QGIS carico anche i confini ISTAT dei comuni italiani che sono in
ELD79/UTM zone 32 e tramite proiezione al volo vengono correttamente
sovrapposti ai dati sopra descritti.

In gvSIG non riesco a fare questo. Quale proiezione devo assegnare o meglio,
esistono delle tabelle di confronto dei vari nomi e codici (EPSG, postgis,
etc) in modo da poter sapere quale proiezione usare?

Credo che sia il solito problema che il software non contiene
i datum geodetici di GaussBoaga. Non ho verificato con gvSIG pero'.

Missa che GRASS e' l'unico GIS libero che contiene questi
parametri :slight_smile: Infatti, e' un po triste che tanti software hanno
ancora questo problema.

Se mancano i datum italiani in gvSIG, bisogna definire la proiezione
"a mano" includendo il parametro "towgs84...". Nell'archivio di questa
lista dovrebbono esserci questi parametri (si trovano anche GRASS o
sul sito http://crs.bkg.bund.de/crs-eu/ -> CRS Description -> national -> I).

ciao
Markus

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

5

Sito molto molto utile Markus, grazie della segnalazione.

Vorrei a questo punto sottoporvi un problema che ho riscontrato riguardo l’utilizzo di dati con differenti CRS.
In ufficio, in Regione, utilizziamo ArcXXX per lavorare abitualmente, con layer con i seguenti CRS:

  1. Gauss-Boaga est (ESRI “Monte_Mario_Italy_2”)
  2. ED50 UTM33N (ESRI “ED_1950_UTM_Zone_33N”)
  3. WGS84 UTM33N (ESRI “WGS_1984_UTM_Zone_33N”)
    …per non parlare dei 32N e anche 34N per la parte più a est della Puglia.

Il problema è l’amata-odiata Gauss-Boaga. Mi spiego…
Caricando in una mappa di ArcXXX tre layer ognuno con un CRS differente tra quelli citati sopra, accade quanto segue:
a) impostando il CRS della mappa come 1) si sovrappongono correttamente i layer 1) e 3) ma non 2)
b) impostando il CRS delle mappa come 2) si sovrappongono correttamente i layer 2) e 3) ma non 1)
c) impostando il CRS della mappa come 3) tutti i layer si sovrappongono correttamente.

Qui appresso i parametri delle trasformazioni tra:
i) CRS 2) e 3), tipo: Geocentric Translation, parametri: dx = -104.0; dy = -101.0; dz = -140.0
ii) CRS 1) e 3), tipo: Position Vector, parametri: dx = -104.0; dy = -49.1; dz = 9.9; rx = 0.971; ry = -2.917; rz = 0.714 ; s = -11.68
iii) CRS 1) e 2) non è possibile definire una trasformazione.

Appare chiaro dunque che la mancata sovrapposizione tra i layer 1) e 2) settando uno o l’altro dei CRS è dovuta al fatto che manca una trasformazione tra i due sistemi di riferimento. Il problema invece non sussiste se scegliamo il WGS84 UTM33N come sistema di rappresentazione dell’intera mappa, poichè 1) e 2) possono essere trasformati nel 3).

Se avrete pazienza, sono costretto a fare una digressione.
Quando ArcXXX era nella versione ArcView 3.0, il CRS Gauss-Boaga (GB) non era “cagato” nemmeno per sbaglio da questi, e ricordo che mi si pose il serio problema di dover riproiettare proprio in GB delle carte topografiche IGM che avevo georeferenziato in ED50 UTM33N grazie al reticolo sovrastampato, CRS che invece era supportato. Ovviamente non avendo ArcView i parametri GB nel proprio database non potevo procedere alla riproiezione.

Riuscii però a procurarmi una pubblicazione, che purtroppo ho smarrito e non ricordo nemmeno di chi fosse, una sorta di piccolo trattato di cartografia che parlava proprio della trasformazione tra GB e ED50 UTM33N. Il testo affermava che il problema della GB consisteva nel fatto che i parametri di trasformazione cambiavano per ogni foglio di taglio 1: 100.000, e riportava in appendice una serie di tabelle che elencavano i suddetti parametri foglio per foglio di tutta Italia. Grazie ad esse calcolai in maniera spartana i parametri per la Puglia, mediando quelli del foglio più a NO e quello più a SE. In tal modo sarei stato in grado di mitigare al meglio l’errore dovuto ai centri di proiezione differenti per ogni foglio, ottenendo un file di definizione della GB per la Puglia abbastanza preciso. I parametri di definizione erano identici al ED50 UTM33N, cambiavano solo il falso est e il falso nord, rispettivamente 2.519.941 metri e -186 metri.

Molto simile a quello che nelle versioni seguenti di ArcView 3.x sarebbe poi stato il GB, finalmente supportato, ma in cui falso il est è 2.520.000 metri e il falso nord 0 metri. Questa piccola differenza, usando il GB “ufficiale”, mi portava a riproiezioni di layer che generavano uno shift diagonale che andava da 50 a oltre 200 metri, mentre con il “mio” GB lo shift era quasi inesistente.

Oggi continuo a usare in alcuni casi gli stessi parametri che misi a punto allora, quando purtroppo costretto ad utilizzare dati GB e ED50 UTM33N contemporaneamente, che non si sovrappongono affatto tra loro, a meno di non impostare per la vista/mappa la WGS84 UTM33N. Usando il CRS “rivisto e corretto” invece, tutto si sovrappone, a prescindere dal CRS scelto per la visualizzazione.

Chi è arrivato fin qui a leggere si chiederà: e allora? E allora vi chiedo se avete mai riscontrato situazioni del genere anche dalle vostre parti. E magari qualche superesperto di CRS potrà chiarire la situazione.

A presto,
PB

Il 10/09/07, Markus Neteler ha scritto:

On Sun, Sep 09, 2007 at 06:44:57AM -0700, mando wrote:

Salve,
ho iniziato a dare un’occhiata a gvSIG, ma non riesco a capire come
assegnare ad un layer la proiezione corretta.
Ho una base con raster 1:25000 e 1:5000 della provincia di rimini e con QGIS
li carico correttamente con Monte Mario (Rome) Italy zone 2.

Ora in QGIS carico anche i confini ISTAT dei comuni italiani che sono in
ELD79/UTM zone 32 e tramite proiezione al volo vengono correttamente
sovrapposti ai dati sopra descritti.

In gvSIG non riesco a fare questo. Quale proiezione devo assegnare o meglio,
esistono delle tabelle di confronto dei vari nomi e codici (EPSG, postgis,
etc) in modo da poter sapere quale proiezione usare?

Credo che sia il solito problema che il software non contiene
i datum geodetici di GaussBoaga. Non ho verificato con gvSIG pero’.

Missa che GRASS e’ l’unico GIS libero che contiene questi
parametri :slight_smile: Infatti, e’ un po triste che tanti software hanno
ancora questo problema.

Se mancano i datum italiani in gvSIG, bisogna definire la proiezione
“a mano” includendo il parametro “towgs84…”. Nell’archivio di questa
lista dovrebbono esserci questi parametri (si trovano anche GRASS o
sul sito http://crs.bkg.bund.de/crs-eu/ → CRS Description → national → I).

ciao
Markus

ITC → dall’1 marzo 2007 Fondazione Bruno Kessler
ITC → since 1 March 2007 Fondazione Bruno Kessler

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

6

Pietro Blu Giandonato ha scritto:

Vorrei a questo punto sottoporvi un problema che ho riscontrato riguardo l'utilizzo di dati con differenti CRS.
In ufficio, in Regione, utilizziamo ArcXXX per lavorare abitualmente, con layer con i seguenti CRS:
1) Gauss-Boaga est (ESRI "Monte_Mario_Italy_2")
2) ED50 UTM33N (ESRI "ED_1950_UTM_Zone_33N")
3) WGS84 UTM33N (ESRI "WGS_1984_UTM_Zone_33N")
...per non parlare dei 32N e anche 34N per la parte più a est della Puglia.

In Puglia, devo darvi atto, si presenta la casistica più ampia...

Il problema è l'amata-odiata Gauss-Boaga. Mi spiego...
Caricando in una mappa di ArcXXX tre layer ognuno con un CRS differente tra quelli citati sopra, accade quanto segue:
a) impostando il CRS della mappa come 1) si sovrappongono correttamente i layer 1) e 3) ma non 2)
b) impostando il CRS delle mappa come 2) si sovrappongono correttamente i layer 2) e 3) ma non 1)
c) impostando il CRS della mappa come 3) tutti i layer si sovrappongono correttamente.

Qui appresso i parametri delle trasformazioni tra:
i) CRS 2) e 3), tipo: Geocentric Translation, parametri: dx = -104.0; dy = -101.0; dz = -140.0

ED_1950_To_WGS_1984_1 1133 Geocentric_Translation -87 -98 -121

ii) CRS 1) e 3), tipo: Position Vector, parametri: dx = -104.0; dy = -49.1; dz = 9.9; rx = 0.971; ry = -2.917; rz = 0.714 ; s = -11.68

Monte_Mario_To_WGS_1984_4 1660 Position_Vector -104.1 -49.1 -9.9 0.971
-2.917 0.714 -11.68

iii) CRS 1) e 2) non è possibile definire una trasformazione.

Dovresti utilizzare "in serie" le due citate in precedenza mediante
project tool.

Appare chiaro dunque che la mancata sovrapposizione tra i layer 1) e 2) settando uno o l'altro dei CRS è dovuta al fatto che manca una trasformazione tra i due sistemi di riferimento. Il problema invece non sussiste se scegliamo il WGS84 UTM33N come sistema di rappresentazione dell'intera mappa, poichè 1) e 2) possono essere trasformati nel 3).

Infatti, le trasformazioni "composte" di coordinate ricorrono ad datum
geocentrico di appoggio (WGS84).

Se avrete pazienza, sono costretto a fare una digressione.
Quando ArcXXX era nella versione ArcView 3.0, il CRS Gauss-Boaga (GB) non era "cagato" nemmeno per sbaglio da questi, e ricordo che mi si pose il serio problema di dover riproiettare proprio in GB delle carte topografiche IGM che avevo georeferenziato in ED50 UTM33N grazie al reticolo sovrastampato, CRS che invece era supportato. Ovviamente non avendo ArcView i parametri GB nel proprio database non potevo procedere alla riproiezione.

Riuscii però a procurarmi una pubblicazione, che purtroppo ho smarrito e non ricordo nemmeno di chi fosse, una sorta di piccolo trattato di cartografia che parlava proprio della trasformazione tra GB e ED50 UTM33N. Il testo affermava che il problema della GB consisteva nel fatto che i parametri di trasformazione cambiavano per ogni foglio di taglio 1: 100.000, e riportava in appendice una serie di tabelle che elencavano i suddetti parametri foglio per foglio di tutta Italia. Grazie ad esse calcolai in maniera spartana i parametri per la Puglia, mediando quelli del foglio più a NO e quello più a SE. In tal modo sarei stato in grado di mitigare al meglio l'errore dovuto ai centri di proiezione differenti per ogni foglio, ottenendo un file di definizione della GB per la Puglia abbastanza preciso. I parametri di definizione erano identici al ED50 UTM33N, cambiavano solo il falso est e il falso nord, rispettivamente 2.519.941 metri e -186 metri.

Molto simile a quello che nelle versioni seguenti di ArcView 3.x sarebbe poi stato il GB, finalmente supportato, ma in cui falso il est è 2.520.000 metri e il falso nord 0 metri. Questa piccola differenza, usando il GB "ufficiale", mi portava a riproiezioni di layer che generavano uno shift diagonale che andava da 50 a oltre 200 metri, mentre con il "mio" GB lo shift era quasi inesistente.

Questo perchè i tuoi parametri, con buona approssimazione, riproducono
lo scostamento esistente tra i due sistemi cartografici. ESRI, invece,
così come altri software (es.: gvSIG), utilizzano delle trasformazioni di
default che non necessariamente si prestano bene al caso dell'Italia
peninsulare, bensì a Sicilia e/o Sardegna. Affidarsi alla proiezione al
volo comporta l'utilizzo di queste trasformazioni di default e quindi
accuratezze inaccettabili, mentre definire il CRS ed la trasformazione
da adottare (un pò come hai fatto tu), quando ciò è possibile,
garantisce un corretto utilizzo del software. Al momento in ambito
GFOSS, GRASS e Qgis che utilizzano le librerie PROJ consentono di
applicare le trasformazioni aggiungendo al WKT di proj il parametro
+towgs84, ovvero le traslazioni, le rotazioni ed un fattore di scala
(questi ultimi sono presenti solo nelle trasformazioni a 7 parametri tipo
Position Vector e Coordinate Frame).
C'è anche da dire che le trasformazioni dell'EPSG presentano accuratezze
fino a 4 m e quindi per grandi scale a partire dal 25k lasciano il tempo
che trovano...

Oggi continuo a usare in alcuni casi gli stessi parametri che misi a punto allora, quando purtroppo costretto ad utilizzare dati GB e ED50 UTM33N contemporaneamente, che non si sovrappongono affatto tra loro, a meno di non impostare per la vista/mappa la WGS84 UTM33N. Usando il CRS "rivisto e corretto" invece, tutto si sovrappone, a prescindere dal CRS scelto per la visualizzazione.

Chi è arrivato fin qui a leggere si chiederà: e allora? E allora vi chiedo se avete mai riscontrato situazioni del genere anche dalle vostre parti. E magari qualche superesperto di CRS potrà chiarire la situazione.

E' normale. E' così ovunque in tutta Italia.

A presto,
PB

Ciao
Antonio

Il 10/09/07, *Markus Neteler* ha scritto:

    On Sun, Sep 09, 2007 at 06:44:57AM -0700, mando wrote:
     >
     > Salve,
     > ho iniziato a dare un'occhiata a gvSIG, ma non riesco a capire come
     > assegnare ad un layer la proiezione corretta.
     > Ho una base con raster 1:25000 e 1:5000 della provincia di rimini
    e con QGIS
     > li carico correttamente con Monte Mario (Rome) Italy zone 2.
     >
     > Ora in QGIS carico anche i confini ISTAT dei comuni italiani che
    sono in
     > ELD79/UTM zone 32 e tramite proiezione al volo vengono correttamente
     > sovrapposti ai dati sopra descritti.
     >
     > In gvSIG non riesco a fare questo. Quale proiezione devo
    assegnare o meglio,
     > esistono delle tabelle di confronto dei vari nomi e codici (EPSG,
    postgis,
     > etc) in modo da poter sapere quale proiezione usare?

    Credo che sia il solito problema che il software non contiene
    i datum geodetici di GaussBoaga. Non ho verificato con gvSIG pero'.

    Missa che GRASS e' l'unico GIS libero che contiene questi
    parametri :slight_smile: Infatti, e' un po triste che tanti software hanno
    ancora questo problema.

    Se mancano i datum italiani in gvSIG, bisogna definire la proiezione
    "a mano" includendo il parametro "towgs84...". Nell'archivio di questa
    lista dovrebbono esserci questi parametri (si trovano anche GRASS o
    sul sito http://crs.bkg.bund.de/crs-eu/
    <http://crs.bkg.bund.de/crs-eu/&gt; -> CRS Description -> national -> I).

    ciao
    Markus

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

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

------------------------------------------------------------------------

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

------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG Free Edition. Version: 7.5.485 / Virus Database: 269.13.13/998 - Release Date: 10/09/2007 8.48

7

Il 11/09/07, Antonio Falciano ha scritto:

Pietro Blu Giandonato ha scritto:

Qui appresso i parametri delle trasformazioni tra:
i) CRS 2) e 3), tipo: Geocentric Translation, parametri: dx = -104.0; dy
= -101.0; dz = -140.0

ED_1950_To_WGS_1984_1 1133 Geocentric_Translation -87 -98 -121

Evidentemente ho sbagliato a riportare i parametri, perchè è proprio la ED_1950_To_WGS_1984_1 che uso.

ii) CRS 1) e 3), tipo: Position Vector, parametri: dx = -104.0; dy =
-49.1; dz = 9.9; rx = 0.971; ry = -2.917; rz = 0.714 ; s = -11.68

Monte_Mario_To_WGS_1984_4 1660 Position_Vector -104.1 -49.1 -9.9 0.971
-2.917 0.714 -11.68

E’ lei. La utilizzo appunto per riproiettare GB in WGS84 e viceversa.

iii) CRS 1) e 2) non è possibile definire una trasformazione.

Dovresti utilizzare “in serie” le due citate in precedenza mediante
project tool.

Evito se posso di riproiettare i dati, preferisco usare la “on the fly” in modo da lasciarli intonsi il più possibile…

Appare chiaro dunque che la mancata sovrapposizione tra i layer 1) e 2)
settando uno o l’altro dei CRS è dovuta al fatto che manca una
trasformazione tra i due sistemi di riferimento. Il problema invece non
sussiste se scegliamo il WGS84 UTM33N come sistema di rappresentazione
dell’intera mappa, poichè 1) e 2) possono essere trasformati nel 3).

Infatti, le trasformazioni “composte” di coordinate ricorrono ad datum
geocentrico di appoggio (WGS84).

Buono a sapersi.

Molto simile a quello che nelle versioni seguenti di ArcView 3.x sarebbe
poi stato il GB, finalmente supportato, ma in cui falso il est è
2.520.000 metri e il falso nord 0 metri. Questa piccola differenza,
usando il GB “ufficiale”, mi portava a riproiezioni di layer che
generavano uno shift diagonale che andava da 50 a oltre 200 metri,
mentre con il “mio” GB lo shift era quasi inesistente.

Al momento in ambito
GFOSS, GRASS e Qgis che utilizzano le librerie PROJ consentono di
applicare le trasformazioni aggiungendo al WKT di proj il parametro
+towgs84, ovvero le traslazioni, le rotazioni ed un fattore di scala
(questi ultimi sono presenti solo nelle trasformazioni a 7 parametri tipo
Position Vector e Coordinate Frame).

Lasciamo perdere allora… di fatto GB e ED50 UTM33N sono “incompatibili” a meno di non effettuare riproiezioni in serie.

C’è anche da dire che le trasformazioni dell’EPSG presentano accuratezze
fino a 4 m e quindi per grandi scale a partire dal 25k lasciano il tempo
che trovano…

Sempre meglio che niente. Per il lavoro che faccio mi interessa avere il massimo possibile di accuratezza dal p. di vista spaziale, l’importante è essere sempre in grado di tenere traccia delle trasformazioni applicate ai dati.

Comunque, tirando le fila del discorso, di fronte al fatto che applicativi FOSS capaci di gestire riproiezioni al volo di più raster con CRS diversi pare non ve ne siano, l’unica strada possibile è la riproiezione materiale dei dati, con tutte le conseguenze del caso.

Con ArcGIS è invece possibile farlo, ma:

  1. impostando il CRS del progetto/vista unicamente in WGS84, poichè GB e ED50 convergono correttamente verso WGS84, con errore di posizionemento di circa 1-2 metri con dati come ortofoto con risoluzione pixel di 50cm;
  2. o usando un CRS per GB “corretto” (come quello ottenuto da me), qui l’errore è più alto, aggirandosi attorno ai 4-5 metri sempre con dette ortofoto. L’unico vantaggio è la possibilità di poter scegliere indifferentemente uno qualunque dei 3 CRS per il progetto/vista, i dati si sovrapporranno sempre tra loro, tenendo conto degli errori ovviamente.

Saluti e grazie per le info,
PB

Il 10/09/07, Markus Neteler ha scritto:

On Sun, Sep 09, 2007 at 06:44:57AM -0700, mando wrote:

Salve,
ho iniziato a dare un’occhiata a gvSIG, ma non riesco a capire come
assegnare ad un layer la proiezione corretta.
Ho una base con raster 1:25000 e 1:5000 della provincia di rimini
e con QGIS
li carico correttamente con Monte Mario (Rome) Italy zone 2.

Ora in QGIS carico anche i confini ISTAT dei comuni italiani che
sono in
ELD79/UTM zone 32 e tramite proiezione al volo vengono correttamente
sovrapposti ai dati sopra descritti.

In gvSIG non riesco a fare questo. Quale proiezione devo
assegnare o meglio,
esistono delle tabelle di confronto dei vari nomi e codici (EPSG,
postgis,
etc) in modo da poter sapere quale proiezione usare?

Credo che sia il solito problema che il software non contiene
i datum geodetici di GaussBoaga. Non ho verificato con gvSIG pero’.

Missa che GRASS e’ l’unico GIS libero che contiene questi
parametri :slight_smile: Infatti, e’ un po triste che tanti software hanno
ancora questo problema.

Se mancano i datum italiani in gvSIG, bisogna definire la proiezione
“a mano” includendo il parametro “towgs84…”. Nell’archivio di questa
lista dovrebbono esserci questi parametri (si trovano anche GRASS o
sul sito http://crs.bkg.bund.de/crs-eu/
<http://crs.bkg.bund.de/crs-eu/> → CRS Description → national → I).

ciao
Markus

ITC → dall’1 marzo 2007 Fondazione Bruno Kessler
ITC → since 1 March 2007 Fondazione Bruno Kessler

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

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

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.485 / Virus Database: 269.13.13/998 - Release Date: 10/09/2007 8.48

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

8

Pietro Blu Giandonato ha scritto:

Vorrei a questo punto sottoporvi un problema che ho riscontrato riguardo
l'utilizzo di dati con differenti CRS.
In ufficio, in Regione, utilizziamo ArcXXX per lavorare abitualmente, con
layer con i seguenti CRS:
1) Gauss-Boaga est (ESRI "Monte_Mario_Italy_2")
2) ED50 UTM33N (ESRI "ED_1950_UTM_Zone_33N")
3) WGS84 UTM33N (ESRI "WGS_1984_UTM_Zone_33N")
...per non parlare dei 32N e anche 34N per la parte più a est della
Puglia.

Si', l'argomento e' un po' complesso...
Un consiglio da leggere:

http://www.asprs.org/resources/grids/
-> Italy
   (http://www.asprs.org/resources/grids/08-2005-italy.pdf)

ciao
Markus

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

9

Si', l'argomento e' un po' complesso...
Un consiglio da leggere:

Terribilmente complesso...cmq ho provato a riproiettare con GRASS e
non ho ottenuto la tanto agognata sovrapposizione.
Dunque:

Lo shape è questo:
http://www.freegis-italia.org/index.php?option=com_content&task=view&id=347&Itemid=46
e il sistema di riferimento: ED 1950 UTM 32N.

Caricando questo layer con QGIS gli viene assegnato ELD79 / UTM32N (è
corretto?) e il progetto, con CRS settato su Monte Mario (Rome) -
Italy zone 2 e proiezione al volo i miei layer in GB si sovrappongo
perfettamente.

Ho creato quindi una location con GRASS con il sistema di riferimento
ELD79 / UTM32N e poi ho provato a importarlo con v.proj nella location
Monte Mario (Rome) - Italy zone 2, ma il vettoriale dei confini
comunali risulta essere più a sinistra rispetto ai vettoriali in GB.

Se avevo ben capito dalla vostra discussione con GRASS non dovrebbero
esserci problemi. Ho dimenticato qualcosa?

10

On Tue, Sep 11, 2007 at 05:22:55PM +0200, Luca Mandolesi wrote:

> Si', l'argomento e' un po' complesso...
> Un consiglio da leggere:

Terribilmente complesso...cmq ho provato a riproiettare con GRASS e
non ho ottenuto la tanto agognata sovrapposizione.
Dunque:

Lo shape è questo:
http://www.freegis-italia.org/index.php?option=com_content&task=view&id=347&Itemid=46
e il sistema di riferimento: ED 1950 UTM 32N.

Caricando questo layer con QGIS gli viene assegnato ELD79 / UTM32N (è
corretto?) e il progetto, con CRS settato su Monte Mario (Rome) -
Italy zone 2 e proiezione al volo i miei layer in GB si sovrappongo
perfettamente.

Ho creato quindi una location con GRASS con il sistema di riferimento
ELD79 / UTM32N e poi ho provato a importarlo con v.proj nella location
Monte Mario (Rome) - Italy zone 2, ma il vettoriale dei confini
comunali risulta essere più a sinistra rispetto ai vettoriali in GB.

Se avevo ben capito dalla vostra discussione con GRASS non dovrebbero
esserci problemi. Ho dimenticato qualcosa?

Non mi sembra giusto applicare
ELD79: "European Libyan Datum of 1979"

Per caso (!) le stringe in PROJ4 sono identice:
/usr/local/share/proj/epsg

# ELD79 / UTM zone 33N
<2078> +proj=utm +zone=33 +ellps=intl +units=m +no_defs <>

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

... ma non mi convince. Poi, come gia' detto, in PROJ4/EPSG mancano
tanti datum dovuto alla struttura del file (mentre GRASS fornisce almeno
alcuni).

Proposta: pubblici le tue GRASS location o almeno i PROJ_INFO file
per permettere un controllo.

ciao
Markus

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

11

Non mi sembra giusto applicare
ELD79: "European Libyan Datum of 1979"

Per caso (!) le stringe in PROJ4 sono identice:
/usr/local/share/proj/epsg

sotto questo path non ho epsg

# ELD79 / UTM zone 33N
<2078> +proj=utm +zone=33 +ellps=intl +units=m +no_defs <>

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

Effettivamente in QGIS le stringhe sono uguali

Proposta: pubblici le tue GRASS location o almeno i PROJ_INFO file
per permettere un controllo.

Volentieri, ma non l'ho mai fatto. Adesso guardo come fare e poi posto.

Grazie mille per ora

ciao ciao

12

Markus Neteler ha scritto:

Non mi sembra giusto applicare
ELD79: "European Libyan Datum of 1979"

Concordo, sia perchè è giusto chiamare le cose con il loro vero nome
e poi perchè ...

Per caso (!) le stringe in PROJ4 sono identice:
/usr/local/share/proj/epsg

# ELD79 / UTM zone 33N
<2078> +proj=utm +zone=33 +ellps=intl +units=m +no_defs <>

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

... ma non mi convince. Poi, come gia' detto, in PROJ4/EPSG mancano
tanti datum dovuto alla struttura del file (mentre GRASS fornisce almeno
alcuni).

... è vero che i WKT sono identici, ma la trasformazione utilizzata nella
proiezione al volo punterà ad un EPSG code errato (si riferirà all'area
libica) e ciò ovviamente non va bene.

Ciao
Antonio

13

On Tue, Sep 11, 2007 at 06:36:49PM +0200, Luca Mandolesi wrote:

> Non mi sembra giusto applicare
> ELD79: "European Libyan Datum of 1979"
>
> Per caso (!) le stringe in PROJ4 sono identice:
> /usr/local/share/proj/epsg

sotto questo path non ho epsg

- magari /usr/share/proj/epsg ?
- oppure: hai installato PROJ4?

> # ELD79 / UTM zone 33N
> <2078> +proj=utm +zone=33 +ellps=intl +units=m +no_defs <>
>
> # ED50 / UTM zone 33N
> <23033> +proj=utm +zone=33 +ellps=intl +units=m +no_defs <>

Effettivamente in QGIS le stringhe sono uguali

Certo. Ma Libia non e Italia... Cosi` potresti crearti
confusione dopo 2 anni quando ti chiedi "perche` avevo
messo ELD79? Cosa centra Libia..?" - per quello.

> Proposta: pubblici le tue GRASS location o almeno i PROJ_INFO file
> per permettere un controllo.

Volentieri, ma non l'ho mai fatto. Adesso guardo come fare e poi posto.

Grazie mille per ora

ciao ciao

good luck
markus

--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
FBK-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy
http://www.grassbook.org/ http://www.osgeo.org/

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

14

On 9/11/07, Markus Neteler <neteler@itc.it> wrote:

On Tue, Sep 11, 2007 at 06:36:49PM +0200, Luca Mandolesi wrote:
> > Non mi sembra giusto applicare
> > ELD79: "European Libyan Datum of 1979"
> >
> > Per caso (!) le stringe in PROJ4 sono identice:
> > /usr/local/share/proj/epsg
>
> sotto questo path non ho epsg

- magari /usr/share/proj/epsg ?
- oppure: hai installato PROJ4?

Ho installato PROJ4 da questo sito:
http://www.kyngchaos.com/software/unixport/frameworks

e il file epsg è installato sotto:
/Library/Frameworks/PROJ.framework/Resources/proj/

Ecco le definizioni (mi sembrano uguali a quelle che mi hai scritto):

# ELD79 / UTM zone 33N
<2078> +proj=utm +zone=33 +ellps=intl +units=m +no_defs <>

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

> > Proposta: pubblici le tue GRASS location o almeno i PROJ_INFO file
> > per permettere un controllo.

Le location le ho definite tramite qgis. Ecco qua le info; ho usato
g.region. E' corretto?

projection: 99 (Transverse Mercator)
zone: 0
datum: ** unknown (default: WGS84) **
ellipsoid: international
north: 5322670
south: 4009430
west: 1719280
east: 2909640
nsres: 1190.60743427
ewres: 1190.36
rows: 1103
cols: 1000
cells: 1103000

projection: 1 (UTM)
zone: 0
datum: ** unknown (default: WGS84) **
ellipsoid: international
north: 5336180
south: 4004610
west: 239983
east: 1430810
nsres: 1191.02862254
ewres: 1190.827
rows: 1118
cols: 1000
cells: 1118000

grazie

15

On Wed, Sep 12, 2007 at 12:23:34PM +0200, Luca Mandolesi wrote:

On 9/11/07, Markus Neteler <neteler@itc.it> wrote:
> On Tue, Sep 11, 2007 at 06:36:49PM +0200, Luca Mandolesi wrote:
> > > Non mi sembra giusto applicare
> > > ELD79: "European Libyan Datum of 1979"
> > >
> > > Per caso (!) le stringe in PROJ4 sono identice:
> > > /usr/local/share/proj/epsg
> >
> > sotto questo path non ho epsg
>
> - magari /usr/share/proj/epsg ?
> - oppure: hai installato PROJ4?

Ho installato PROJ4 da questo sito:
http://www.kyngchaos.com/software/unixport/frameworks

ah, allora MacOSX.

e il file epsg è installato sotto:
/Library/Frameworks/PROJ.framework/Resources/proj/

Ecco le definizioni (mi sembrano uguali a quelle che mi hai scritto):

# ELD79 / UTM zone 33N
<2078> +proj=utm +zone=33 +ellps=intl +units=m +no_defs <>

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

attenzione: magari sono uguali in PROJ4, ma la definizione
completa potrebbe essere diversa. Sarebbe da controllare
nel DB SQL di EPSG.

> > > Proposta: pubblici le tue GRASS location o almeno i PROJ_INFO file
> > > per permettere un controllo.

Le location le ho definite tramite qgis. Ecco qua le info; ho usato
g.region. E' corretto?

projection: 99 (Transverse Mercator)
zone: 0
datum: ** unknown (default: WGS84) **

no, spagliato. Manca il datum - cosi' GRASS fa default su WGS84
che e' sicuramente spagliato. Gauss-Boaga questo? Se si,
dovrebbe essere Roma40 (scusa, non mi ricordo tutta la
discussione).

ellipsoid: international
north: 5322670
south: 4009430
west: 1719280
east: 2909640
nsres: 1190.60743427
ewres: 1190.36
rows: 1103
cols: 1000
cells: 1103000

projection: 1 (UTM)
zone: 0
datum: ** unknown (default: WGS84) **
ellipsoid: international
north: 5336180
south: 4004610
west: 239983
east: 1430810
nsres: 1191.02862254
ewres: 1190.827
rows: 1118
cols: 1000
cells: 1118000

Cosi' ti fa UTM su WGS84 - e' quello che ti serve?
Le coordinate mi sembrano strano: non puo essere
che la region sia identica tra GaussBoaga e UTM.
Sono due proiezioni diversi.

ciao
Markus

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

16

On 9/12/07, Markus Neteler <neteler@itc.it> wrote:

On Wed, Sep 12, 2007 at 12:23:34PM +0200, Luca Mandolesi wrote:
> On 9/11/07, Markus Neteler <neteler@itc.it> wrote:
> > On Tue, Sep 11, 2007 at 06:36:49PM +0200, Luca Mandolesi wrote:
> > > > Non mi sembra giusto applicare
> > > > ELD79: "European Libyan Datum of 1979"
> > > >
> > > > Per caso (!) le stringe in PROJ4 sono identice:
> > > > /usr/local/share/proj/epsg
> > >
> > > sotto questo path non ho epsg
> >
> > - magari /usr/share/proj/epsg ?
> > - oppure: hai installato PROJ4?
>
> Ho installato PROJ4 da questo sito:
> http://www.kyngchaos.com/software/unixport/frameworks

ah, allora MacOSX.

Scusami, non l'avevo citato scritto

no, spagliato. Manca il datum - cosi' GRASS fa default su WGS84
che e' sicuramente spagliato. Gauss-Boaga questo? Se si,
dovrebbe essere Roma40 (scusa, non mi ricordo tutta la
discussione).

Ok. Adesso almeno so che è sbagliato in partenza. Provo a fare tutto
da GRASS. Grazie intanto.

17

Lo so, è un argomento lasciato in sospeso tempo fa… ma sempre attuale. Lo rinverdisco con un’ultima (spero utile per tutti) scoperta.

Riuscii però a procurarmi una pubblicazione, che purtroppo ho smarrito e non ricordo nemmeno di chi fosse, una sorta di piccolo trattato di cartografia che parlava proprio della trasformazione tra GB e ED50 UTM33N. Il testo affermava che il problema della GB consisteva nel fatto che i parametri di trasformazione cambiavano per ogni foglio di taglio 1: 100.000, e riportava in appendice una serie di tabelle che elencavano i suddetti parametri foglio per foglio di tutta Italia.

…e finalmente ho trovato degli ottimi appunti di topografia e geodesia [1] nei quali, a pag. 78, vengono riportati proprio i coefficienti di correzione dell’IGM per la conversione da Gauss-Boaga a UTM ED50 e viceversa, per ogni Foglio in scala 1: 100.000 della Carta Topografica d’Italia.

Negli stessi appunti si afferma che questi abbiano una precisione migliore delle equazioni di Molodensky… non ci resta che provare per credere.

Hope this helps,
PB

[1] http://www.mondovi.polito.it/ebook/doc/top05.pdf Per scaricare gli altri 4 basta sostituire 01, 02, 03 e 04 al nome del file :wink:

18

Pietro Blu Giandonato ha scritto:

Lo so, è un argomento lasciato in sospeso tempo fa... ma sempre attuale. Lo rinverdisco con un'ultima (spero utile per tutti) scoperta.

    Riuscii però a procurarmi una pubblicazione, che purtroppo ho
    smarrito e non ricordo nemmeno di chi fosse, una sorta di piccolo
    trattato di cartografia che parlava proprio della trasformazione tra
    GB e ED50 UTM33N. Il testo affermava che il problema della GB
    consisteva nel fatto che i parametri di trasformazione cambiavano
    per ogni foglio di taglio 1: 100.000, e riportava in appendice una
    serie di tabelle che elencavano i suddetti parametri foglio per
    foglio di tutta Italia.

...e finalmente ho trovato degli ottimi appunti di topografia e geodesia [1] nei quali, a pag. 78, vengono riportati proprio i coefficienti di correzione dell'IGM per la conversione da Gauss-Boaga a UTM ED50 e viceversa, per ogni Foglio in scala 1: 100.000 della Carta Topografica d'Italia.

Grazie della brillante segnalazione, Pietro.
Altra pubblicazione molto utile in tal senso è quella dell'ottimo Vito
Borneo:
http://www.carsismo.it/rivista/2006/ricerche_speleologiche_2006_01_borneo.pdf
che ha calcolato le correzioni per i fogli 50k per Puglia e Basilicata e,
al tempo stesso, ha realizzato un bel saggio di cartografia.
Visto che è un mio conterraneo, ne approfitto per segnalare anche
il suo sito web: http://www.borneo.name/ ed, in particolar modo,
la sezione Topografia.
Magari, visto che ieri si è affacciato in lista, sarebbe molto
interessante discutere con lui circa le trasformazioni nei software GIS.
L'ideale, come sostiene anche Markus Neteler, sarebbe realizzare un
grigliato GFOSS che consenta una maggiore accuratezza nelle
trasformazioni adatta a scale fino al 5k-2k, confrontabile con quella di
Traspunto, che però non è open.
Il grigliato sarebbe poi inserito ad esempio nelle librerie proj con
tutti i vantaggi che ne deriverebbero per tutti.

Buona giornata
Antonio

Negli stessi appunti si afferma che questi abbiano una precisione migliore delle equazioni di Molodensky... non ci resta che provare per credere.

Hope this helps,
PB

[1] http://www.mondovi.polito.it/ebook/doc/top05.pdf Per scaricare gli altri 4 basta sostituire 01, 02, 03 e 04 al nome del file :wink:

------------------------------------------------------------------------

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

19

Lancio una provocazione: per caso siete tutti iscritti al partito dell'area vasta? :slight_smile:

ciao
ant

Antonio Falciano ha scritto:

Pietro Blu Giandonato ha scritto:

Lo so, è un argomento lasciato in sospeso tempo fa... ma sempre attuale. Lo rinverdisco con un'ultima (spero utile per tutti) scoperta.

    Riuscii però a procurarmi una pubblicazione, che purtroppo ho
    smarrito e non ricordo nemmeno di chi fosse, una sorta di piccolo
    trattato di cartografia che parlava proprio della trasformazione tra
    GB e ED50 UTM33N. Il testo affermava che il problema della GB
    consisteva nel fatto che i parametri di trasformazione cambiavano
    per ogni foglio di taglio 1: 100.000, e riportava in appendice una
    serie di tabelle che elencavano i suddetti parametri foglio per
    foglio di tutta Italia.

...e finalmente ho trovato degli ottimi appunti di topografia e geodesia [1] nei quali, a pag. 78, vengono riportati proprio i coefficienti di correzione dell'IGM per la conversione da Gauss-Boaga a UTM ED50 e viceversa, per ogni Foglio in scala 1: 100.000 della Carta Topografica d'Italia.

Grazie della brillante segnalazione, Pietro.
Altra pubblicazione molto utile in tal senso è quella dell'ottimo Vito
Borneo:
http://www.carsismo.it/rivista/2006/ricerche_speleologiche_2006_01_borneo.pdf
che ha calcolato le correzioni per i fogli 50k per Puglia e Basilicata e,
al tempo stesso, ha realizzato un bel saggio di cartografia.
Visto che è un mio conterraneo, ne approfitto per segnalare anche
il suo sito web: http://www.borneo.name/ ed, in particolar modo,
la sezione Topografia.
Magari, visto che ieri si è affacciato in lista, sarebbe molto
interessante discutere con lui circa le trasformazioni nei software GIS.
L'ideale, come sostiene anche Markus Neteler, sarebbe realizzare un
grigliato GFOSS che consenta una maggiore accuratezza nelle
trasformazioni adatta a scale fino al 5k-2k, confrontabile con quella di
Traspunto, che però non è open.
Il grigliato sarebbe poi inserito ad esempio nelle librerie proj con
tutti i vantaggi che ne deriverebbero per tutti.

Buona giornata
Antonio

Negli stessi appunti si afferma che questi abbiano una precisione migliore delle equazioni di Molodensky... non ci resta che provare per credere.

Hope this helps,
PB

[1] http://www.mondovi.polito.it/ebook/doc/top05.pdf Per scaricare gli altri 4 basta sostituire 01, 02, 03 e 04 al nome del file :wink:

------------------------------------------------------------------------

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

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

20

Grazie per i complimenti...
ultimamente mi sono ben addendrato nella
problematica topografia del cambio di coordinate,
Traspunto fa qualcosa di simile del Verto, ovvero
utilizza i parametri dei punti IGM95 distributi nel
territorio per il passaggio fra differenti sistemi.
Credo sia la soluzione migliore, ovvero non
un'unica formula per tutto il territorio, ma sfruttare
i 7 parametri della trasformazione di Molodensky
in locale...

----- Original Message ----- From: "Antonio Falciano" <afalciano@yahoo.it>
To: "Geographic Free and Open Source Software - Italian mailing list" <gfoss@faunalia.com>
Sent: Tuesday, October 16, 2007 9:53 AM
Subject: Re: [Gfoss] Assegnare proiezione in gvSIG

Pietro Blu Giandonato ha scritto:

Lo so, è un argomento lasciato in sospeso tempo fa... ma sempre attuale.
Lo rinverdisco con un'ultima (spero utile per tutti) scoperta.

    Riuscii però a procurarmi una pubblicazione, che purtroppo ho
    smarrito e non ricordo nemmeno di chi fosse, una sorta di piccolo
    trattato di cartografia che parlava proprio della trasformazione tra
    GB e ED50 UTM33N. Il testo affermava che il problema della GB
    consisteva nel fatto che i parametri di trasformazione cambiavano
    per ogni foglio di taglio 1: 100.000, e riportava in appendice una
    serie di tabelle che elencavano i suddetti parametri foglio per
    foglio di tutta Italia.

...e finalmente ho trovato degli ottimi appunti di topografia e geodesia
[1] nei quali, a pag. 78, vengono riportati proprio i coefficienti di
correzione dell'IGM per la conversione da Gauss-Boaga a UTM ED50 e
viceversa, per ogni Foglio in scala 1: 100.000 della Carta Topografica
d'Italia.

Grazie della brillante segnalazione, Pietro.
Altra pubblicazione molto utile in tal senso è quella dell'ottimo Vito
Borneo:
http://www.carsismo.it/rivista/2006/ricerche_speleologiche_2006_01_borneo.pdf
che ha calcolato le correzioni per i fogli 50k per Puglia e Basilicata e,
al tempo stesso, ha realizzato un bel saggio di cartografia.
Visto che è un mio conterraneo, ne approfitto per segnalare anche
il suo sito web: http://www.borneo.name/ ed, in particolar modo,
la sezione Topografia.
Magari, visto che ieri si è affacciato in lista, sarebbe molto
interessante discutere con lui circa le trasformazioni nei software GIS.
L'ideale, come sostiene anche Markus Neteler, sarebbe realizzare un
grigliato GFOSS che consenta una maggiore accuratezza nelle
trasformazioni adatta a scale fino al 5k-2k, confrontabile con quella di
Traspunto, che però non è open.
Il grigliato sarebbe poi inserito ad esempio nelle librerie proj con
tutti i vantaggi che ne deriverebbero per tutti.

Buona giornata
Antonio

Negli stessi appunti si afferma che questi abbiano una precisione
migliore delle equazioni di Molodensky... non ci resta che provare per
credere.

Hope this helps,
PB

[1] http://www.mondovi.polito.it/ebook/doc/top05.pdf Per scaricare gli
altri 4 basta sostituire 01, 02, 03 e 04 al nome del file :wink:

------------------------------------------------------------------------

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

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