[Gfoss] Come 'dimostrare' che uno shapefile è in Gauss Boaga Est?

Local Chapters GFOSS.it
1

Ho un dilemma: mi è stato contestato dal mio comune che gli shapefiles da me realizzati con Qgis su CTR dal WMS regionale caricato come Montemario Italy Zona 2 - EPSG ID3004 non sono in GAUSS BOAGA EST perchè ArcGis non li carica (di conseguenza non mi pagano…).

Questo è un file proj di partenza passatomi dal comune che usa ArcGis:

PROJCS[“Transverse_Mercator”,GEOGCS[“GCS_International 1909 (Hayford)”,DATUM[“D_unknown”,SPHEROID[“intl”,6378388,297]],PRIMEM[“Greenwich”,0],UNIT[“Degree”,0.017453292519943295]],PROJECTION[“Transverse_Mercator”],PARAMETER[“latitude_of_origin”,0],PARAMETER[“central_meridian”,15],PARAMETER[“scale_factor”,0.9996],PARAMETER[“false_easting”,2520000],PARAMETER[“false_northing”,0],UNIT[“Meter”,1]]

Questo è un file proj generato da me con Qgis:

PROJCS[“Transverse_Mercator”,GEOGCS[“GCS_International 1909 (Hayford)”,DATUM[“D_unknown”,SPHEROID[“intl”,6378388,297]],PRIMEM[“Greenwich”,0],UNIT[“Degree”,0.017453292519943295]],PROJECTION[“Transverse_Mercator”],PARAMETER[“latitude_of_origin”,0],PARAMETER[“central_meridian”,15],PARAMETER[“scale_factor”,0.9996],PARAMETER[“false_easting”,2520000],PARAMETER[“false_northing”,0],UNIT[“Meter”,1]]

Se qualcuno avesse arcGis gli potrei passare un mio shape e potrebbe dirmi se è vero che non li carica.

Grazie

Luca

2

Per chi volesse provare a caricare due file ecco i link:

http://dl.dropbox.com/u/4627790/shape_test_aree.zip

http://dl.dropbox.com/u/4627790/shape_test_punti.zip

Ciao e grazie…

ps: mi sento così depresso…

3

On Fri, Apr 15, 2011 at 10:06:10AM +0200, Luca Mandolesi wrote:

Ho un dilemma: mi è stato contestato dal mio comune che gli shapefiles
da me realizzati con Qgis su CTR dal WMS regionale caricato come
Montemario Italy Zona 2 - EPSG ID3004 non sono in GAUSS BOAGA EST
perchè ArcGis non li carica (di conseguenza non mi pagano...).

Dovresti farti spiegare come deducono:

  "non sono in GAUSS BOAGA EST"

dall'osservazione:

  "ArcGis non li carica"

Non conoscendo ArcGis credo comunque che uno shapefile dovrebbe
essere caricato se non corrotto. Poi magari puo' essere mostrato
in un posto assurdo, ma "non li carica" sembra aver a che fare
con l'incapacita' di leggere il formato.

Insomma: fatti dire di piu'. All'accusa l'onere della prova ...

--strk;

  () Free GIS & Flash consultant/developer
  /\ http://strk.keybit.net/services.html

4

2011/4/15 Davide <riverlab@gmail.com>

Ciao
Sono GB EST corretti … il qpj eprò da una definizione diversa di
quella del prj di ARCGIS
Ti mando il prj corretto per arcgis, associalo ad ogni shape
chiamandolo con lo stesso nome .prj
Ciao
D.

Ecco questo mi interessa…spiega un po’ a me che son ignorante.

Io ho già un .prj … quindi dovrei cancellare da tutti i miei shape il file qpj e di contro, sostituire il contenuto dei file prj con la stringa che mi hai mandato?

Mi sembra macchinoso…dovrei saperlo a priori? Dove sta l’inghippo???

Grazie

5

2011/4/15 Salvatore Virdis <virdis@uniss.it>

il datum non è specificato!

Ma dovrei specificarlo io? Non è Qgis stesso a creare lo shape con tutte le occorrenze del caso?

6

Il 15/04/2011 10.06, Luca Mandolesi ha scritto:

Ho un dilemma: mi è stato contestato dal mio comune che gli shapefiles da me realizzati con Qgis su CTR dal WMS regionale caricato come Montemario Italy Zona 2 - EPSG ID3004 non sono in GAUSS BOAGA EST perchè ArcGis non li carica (di conseguenza non mi pagano...).

Questo è un file proj di partenza passatomi dal comune che usa ArcGis:

PROJCS["Transverse_Mercator",GEOGCS["GCS_International 1909 (Hayford)",DATUM["D_unknown",SPHEROID["intl",6378388,297]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",15],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",2520000],PARAMETER["false_northing",0],UNIT["Meter",1]]

Questo è un file proj generato da me con Qgis:

PROJCS["Transverse_Mercator",GEOGCS["GCS_International 1909 (Hayford)",DATUM["D_unknown",SPHEROID["intl",6378388,297]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",15],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",2520000],PARAMETER["false_northing",0],UNIT["Meter",1]]

Se qualcuno avesse arcGis gli potrei passare un mio shape e potrebbe dirmi se è vero che non li carica.

Strano, dovrebbe caricarli eccome... a meno che gli shapefile non siano corrotti! L'unica anomalia riscontrabile in entrambi i file prj sta nel fatto che mancano le esatte denominazioni dei sistemi di coordinate... il che potrebbe inficiare le eventuali trasformazioni. L'ESRI WKT corretto e' il seguente:

PROJCS["Monte Mario / Italy zone 2",GEOGCS["Monte Mario",DATUM["D_Monte_Mario",SPHEROID["International_1924",6378388,297]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",15],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",2520000],PARAMETER["false_northing",0],UNIT["Meter",1]]

Fonte: http://spatialreference.org/ref/epsg/3004/esriwkt/

Puoi associarlo anche manualmente a tutto il tuo dataset con la stringa riportata sopra.
In bocca al lupo!

ciao
Antonio

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

7

A me lo carica.
Mi sembra però che il Datum (Roma 1940) non sia specificato: quindi sicuramente qualche arrosto c'è.
andrebbe quindi specificato il Datum.

ciao

Salvatore

--
Salvatore Virdis, PhD

Università degli Studi di Sassari
Dipartimento di Scienze Botaniche, Ecologiche e Geologiche
Via Piandanna, 4 - 07100 Sassari (Italia)
Tel.: +39 079 228616
Email: virdis@uniss.it

8

in ogni caso a me arcgis li apre senza problemi e li piazza anche nel
punto giusto

Il 15 aprile 2011 11:13, Luca Mandolesi <mandoluca@gmail.com> ha scritto:

2011/4/15 Salvatore Virdis <virdis@uniss.it>

il datum non è specificato!

Ma dovrei specificarlo io? Non è Qgis stesso a creare lo shape con tutte le
occorrenze del caso?
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
502 iscritti all'11.2.2011

9

Quello che non capisco è: ma se il datum non è specificato correttamente, è un baco di Qgis, dal momento che sono file generati ex nihilo con Qgis?

10

I files si leggono con arcgis 9.3, ma il file area è topologicamente sbagliato: infatti la features della provincia e quella del comune sono sovrapposte.
Questa cosa si vede anche in qgis
spero di esserti stata di aiuto, ciao Marta

At 10.47 15/04/2011, Luca Mandolesi wrote:

Per chi volesse provare a caricare due file ecco i link:

http://dl.dropbox.com/u/4627790/shape_test_aree.zip

http://dl.dropbox.com/u/4627790/shape_test_punti.zip

Ciao e grazie…

ps: mi sento così depresso…
_______________________________________________ Iscriviti all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione Gfoss@lists.gfoss.it http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e’ una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell’Associazione GFOSS.it. 502 iscritti all’11.2.2011

11

Non ho capito cosa intendi…mi spieghi meglio che magari è questo l’errore…

2011/4/15 Marta Puppo <m.puppo@awn.it>

I files si leggono con arcgis 9.3, ma il file area è topologicamente sbagliato: infatti la features della provincia e quella del comune sono sovrapposte.
Questa cosa si vede anche in qgis
spero di esserti stata di aiuto, ciao Marta

At 10.47 15/04/2011, Luca Mandolesi wrote:

Per chi volesse provare a caricare due file ecco i link:

http://dl.dropbox.com/u/4627790/shape_test_aree.zip

http://dl.dropbox.com/u/4627790/shape_test_punti.zip

Ciao e grazie…

ps: mi sento così depresso…

_______________________________________________ Iscriviti all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione Gfoss@lists.gfoss.it http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e’ una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell’Associazione GFOSS.it. 502 iscritti all’11.2.2011

12

infatti la features della provincia e quella del comune sono
sovrapposte.

in teoria quindi o fai due shapefiles diversi per provincia e comune, o ritagli il poligono della provincia per avere un buco corrispondente all’area del comune, cosa che ha poco senso visto che il territorio della provincia comprende l’area comunale.
quindi direi, prova a separare i due poligoni su due files

13

Per quanto lo shape file permetta errori topologici (tipo aree sovrapposte, vertici doppi, cuspidi ecc) molte regioni (tra le quli sicuramente la lombardia per i pgt) controllano la correttezza topologica (ottenibile con strumenti di editing anche con qgis) al fine di poter usare gli shape per successivi overlay. Per questo in un unico shape poligonale dovrebbero esserci solo poligoni non sovrapposti, nel tuo caso il poligono provincia dovrebbe essere bucato in corrispondenza del poligono comune. qgis permette di settare le regole di digitalizzazione al fine di controllare che non vengano immessi simili errori (impostazioni, progetto, abilita la modifica topologica),
essendo solo due poligoni è certamente semplice metterlo a posto.
ciao Marta

At 11.27 15/04/2011, Luca Mandolesi wrote:

Non ho capito cosa intendi…mi spieghi meglio che magari è questo l’errore…

2011/4/15 Marta Puppo <m.puppo@awn.it>

I files si leggono con arcgis 9.3, ma il file area è topologicamente sbagliato: infatti la features della provincia e quella del comune sono sovrapposte.
Questa cosa si vede anche in qgis
spero di esserti stata di aiuto, ciao Marta
At 10.47 15/04/2011, Luca Mandolesi wrote:
Per chi volesse provare a caricare due file ecco i link:
[http://dl.dropbox.com/u/4627790/shape_test_aree.zip](http://dl.dropbox.com/u/4627790/shape_test_aree.zip)
[http://dl.dropbox.com/u/4627790/shape_test_punti.zip](http://dl.dropbox.com/u/4627790/shape_test_punti.zip)
Ciao e grazie....
ps: mi sento così depresso...
_______________________________________________ Iscriviti all'associazione GFOSS.it: [http://www.gfoss.it/drupal/iscrizione](http://www.gfoss.it/drupal/iscrizione) [Gfoss@lists.gfoss.it](mailto:Gfoss@lists.gfoss.it) [http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss](http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss) Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011
14

Scusa ma l'attributo che tu vuoi che si legga è, a quanto vedo, grado_pote, nel comune assume il valore medio, mentre nel resto della provincia basso. Con lo shape fatto così nel comune quel dato è sia medio si basso, per questo va bucato il poligono della provincia. Se si vuole avere invece uno strato informativo con i limiti comunali provinciali sarà sempre uno shape unico con tutti i comuni adiacenti.

At 11.32 15/04/2011, diegoguidi@gmail.com wrote:

> infatti la features della provincia e quella del comune sono
> sovrapposte.

in teoria quindi o fai due shapefiles diversi per provincia e comune, o ritagli il poligono della provincia per avere un buco corrispondente all'area del comune, cosa che ha poco senso visto che il territorio della provincia comprende l'area comunale.
quindi direi, prova a separare i due poligoni su due files

15

L' errore è dato dal fatto che se in comune hanno il progetto in mxd
settato in Roma 40 GB est [1] e caricano il tuo .qpj [2] gli schiaffa
sullo schermo Unknown spatial .... etc perchè scritto così il .qpj non
rientra nel database di arcgis. Lui lo interpreta come una proiezione
custom ma lo carica e lo piazza al posto giusto. Dovrebbe dare errore
nel caso avessero un progetto settato in un altro sistema di
riferimento, in quanto la riproiezione on the fly on funzionerebbe.

[1]
PROJCS["Roma_1940_Gauss_Boaga_Est",GEOGCS["GCS_Roma_1940",DATUM["D_Roma_1940",SPHEROID["International_1924",6378388.0,297.0]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",2520000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",15.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]

[2]
PROJCS["unnamed",GEOGCS["International 1909
(Hayford)",DATUM["unknown",SPHEROID["intl",6378388,297]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",15],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",2520000],PARAMETER["false_northing",0],UNIT["Meter",1]]

Basta specificare il DATUM "Roma_1940_Gauss_Boaga_Est" e cambiare il
nome dell'ellissoide da International 1909 a International_1924
Ciao D.

Il 15 aprile 2011 11:09, Luca Mandolesi <mandoluca@gmail.com> ha scritto:

2011/4/15 Davide <riverlab@gmail.com>

Ciao
Sono GB EST corretti .... il qpj eprò da una definizione diversa di
quella del prj di ARCGIS
Ti mando il prj corretto per arcgis, associalo ad ogni shape
chiamandolo con lo stesso nome .prj
Ciao
D.

Ecco questo mi interessa....spiega un po' a me che son ignorante.
Io ho già un .prj ... quindi dovrei cancellare da tutti i miei shape il file
qpj e di contro, sostituire il contenuto dei file prj con la stringa che mi
hai mandato?
Mi sembra macchinoso...dovrei saperlo a priori? Dove sta l'inghippo???
Grazie

--
dott. Davide Zizioli
Dipartimento di Scienze della Terra
Università di Pavia
Via Ferrata 1, 27100 Pavia
Tel. +393498345440
Tel. Skype: Riverlab
davide.zizioli@manhattan.unipv.it
WMS http://geoserver1.unipv.it/cgi-bin/wms?

16

BINGOOOO!!! E’ probabilmente così!!! Il problema è il benedetto mxd.

Per quanto riguarda il problema topologico è vero, devo correggerlo… ma nn era quello il problema. Il problema è che secondo il comune gli shape non sono in gauss boaga est, ma credo che davide abbia centrato il problema…

Grazie a tutti!!!
Ciaooo

2011/4/15 Davide <riverlab@gmail.com>

L’ errore è dato dal fatto che se in comune hanno il progetto in mxd
settato in Roma 40 GB est [1] e caricano il tuo .qpj [2] gli schiaffa
sullo schermo Unknown spatial … etc perchè scritto così il .qpj non
rientra nel database di arcgis. Lui lo interpreta come una proiezione
custom ma lo carica e lo piazza al posto giusto. Dovrebbe dare errore
nel caso avessero un progetto settato in un altro sistema di
riferimento, in quanto la riproiezione on the fly on funzionerebbe.

[1]
PROJCS[“Roma_1940_Gauss_Boaga_Est”,GEOGCS[“GCS_Roma_1940”,DATUM[“D_Roma_1940”,SPHEROID[“International_1924”,6378388.0,297.0]],PRIMEM[“Greenwich”,0.0],UNIT[“Degree”,0.0174532925199433]],PROJECTION[“Transverse_Mercator”],PARAMETER[“False_Easting”,2520000.0],PARAMETER[“False_Northing”,0.0],PARAMETER[“Central_Meridian”,15.0],PARAMETER[“Scale_Factor”,0.9996],PARAMETER[“Latitude_Of_Origin”,0.0],UNIT[“Meter”,1.0]]

[2]
PROJCS[“unnamed”,GEOGCS[“International 1909
(Hayford)”,DATUM[“unknown”,SPHEROID[“intl”,6378388,297]],PRIMEM[“Greenwich”,0],UNIT[“degree”,0.0174532925199433]],PROJECTION[“Transverse_Mercator”],PARAMETER[“latitude_of_origin”,0],PARAMETER[“central_meridian”,15],PARAMETER[“scale_factor”,0.9996],PARAMETER[“false_easting”,2520000],PARAMETER[“false_northing”,0],UNIT[“Meter”,1]]

Basta specificare il DATUM “Roma_1940_Gauss_Boaga_Est” e cambiare il
nome dell’ellissoide da International 1909 a International_1924
Ciao D.

Il 15 aprile 2011 11:09, Luca Mandolesi <mandoluca@gmail.com> ha scritto:

2011/4/15 Davide <riverlab@gmail.com>

Ciao
Sono GB EST corretti … il qpj eprò da una definizione diversa di
quella del prj di ARCGIS
Ti mando il prj corretto per arcgis, associalo ad ogni shape
chiamandolo con lo stesso nome .prj
Ciao
D.

Ecco questo mi interessa…spiega un po’ a me che son ignorante.
Io ho già un .prj … quindi dovrei cancellare da tutti i miei shape il file
qpj e di contro, sostituire il contenuto dei file prj con la stringa che mi
hai mandato?
Mi sembra macchinoso…dovrei saperlo a priori? Dove sta l’inghippo???
Grazie

–
dott. Davide Zizioli
Dipartimento di Scienze della Terra
Università di Pavia
Via Ferrata 1, 27100 Pavia
Tel. +393498345440
Tel. Skype: Riverlab
davide.zizioli@manhattan.unipv.it
WMS http://geoserver1.unipv.it/cgi-bin/wms?

17

On Fri, Apr 15, 2011 at 11:16:59AM +0200, Antonio Falciano wrote:

Il 15/04/2011 10.06, Luca Mandolesi ha scritto:
>Ho un dilemma: mi è stato contestato dal mio comune che gli
>shapefiles da me realizzati con Qgis su CTR dal WMS regionale
>caricato come Montemario Italy Zona 2 - EPSG ID3004 non sono in
>GAUSS BOAGA EST perchè ArcGis non li carica (di conseguenza non mi
>pagano...).
>
>Questo è un file proj di partenza passatomi dal comune che usa ArcGis:
>
>PROJCS["Transverse_Mercator",GEOGCS["GCS_International 1909 (Hayford)",DATUM["D_unknown",SPHEROID["intl",6378388,297]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",15],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",2520000],PARAMETER["false_northing",0],UNIT["Meter",1]]
>
>Questo è un file proj generato da me con Qgis:
>
>PROJCS["Transverse_Mercator",GEOGCS["GCS_International 1909 (Hayford)",DATUM["D_unknown",SPHEROID["intl",6378388,297]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",15],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",2520000],PARAMETER["false_northing",0],UNIT["Meter",1]]
>
>Se qualcuno avesse arcGis gli potrei passare un mio shape e
>potrebbe dirmi se è vero che non li carica.

Perché ti chiedono a meridiano Greenwich invece che Monte Mario? Comunque
attenzione che alla risoluzione di CTR 1:5000, ovvero poco più di 1m di
risoluzione, potresti avere problemi di registrazione rispetto a dati
eventualmente materializzati con la rete di precisione. Chiederei
espressamente se stanno usando una proiezione ad-hoc o quella
generica di Arccoso. Il datum D_unknown non è confortante
in tal senso: di fatto non capisco come tu possa averlo passato
in qgis senza rinunciare al datum.

--
Francesco P. Lovergine

18

generica di Arccoso. Il datum D_unknown non è confortante
in tal senso: di fatto non capisco come tu possa averlo passato
in qgis senza rinunciare al datum.

Ciao Francesco,
scusa l’ignoranza, ma non capisco bene cosa mi vuoi dire…io ho solo creato con qgis uno shape con EPSG ID 3004 e non mi sono preoccupato di altro; inizio a capire però che se mi viene richiesto di lavorare in GAUSS BOAGA EST, non è scontato creare uno shape in EPSG ID 3004, ma devo fare attenzione a tante cose, che purtroppo non sono il mio campo, ma, ovviamente dovendo lavorare col GIS, dovrei sapere.

Come posso rimediare ai miei errori?

Grazie

luca

19

On Sat, Apr 16, 2011 at 09:43:41PM +0200, Luca Mandolesi wrote:

>
> generica di Arccoso. Il datum D_unknown non è confortante
> in tal senso: di fatto non capisco come tu possa averlo passato
> in qgis senza rinunciare al datum.

Ciao Francesco,
scusa l'ignoranza, ma non capisco bene cosa mi vuoi dire....io ho solo
creato con qgis uno shape con EPSG ID 3004 e non mi sono preoccupato di
altro; inizio a capire però che se mi viene richiesto di lavorare in GAUSS
BOAGA EST, non è scontato creare uno shape in EPSG ID 3004, ma devo fare
attenzione a tante cose, che purtroppo non sono il mio campo, ma, ovviamente
dovendo lavorare col GIS, dovrei sapere.

C'è un equivoco di fondo: 3003/4 non definiscono un datum in quanto
correttamente EPSG ritiene che convenga non specificarlo quando tale
specifica non è univoca, come appunto il caso in esame.

La materializzazione del datum è necessaria per effettuare le trasformazioni
di coordinate, e viene fatta in due modi da software come Proj o ArcCoso:
specificando i 7 (o peggio 3) parametri di rototraslazione dall'ellisoide
G-B a WGS84 oppure specificando un grigliato di raffittimento agganciato alla rete IGM
nella zona di interesse. Il metodo a parametri medi unico è usabile se non
si deve scendere a scale tipo 1:2000/5000 (il comune che ci deve fare?)
Se guardi Grass, per la penisola qualcuno (?) si è preso il disturbo
di calcolare un set di parametri accettabili:

GRASS 6.4.1 (gauss_boaga_est):~ > g.proj -d
GRASS datum code: rome40
WKT Name: Monte_Mario
Datum transformation parameters (PROJ.4 format):
        towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68

Una cosa simile la fa ArcCaz a modo suo chiaramente.

Se cerchi informazioni sui grigliati, mi pare molto ben fatto:
http://www.provincia.agrigento.it/flex/cm/pages/ServeBLOB.php/L/IT/IDPagina/309
(andrebbe aggiornata la procedura perché GDAL maneggia direttamente NTv2 ormai
da 1.8)

A me sembra piuttosto strano che il comune ti abbia passato una specifica
prj incompleta, mi sarei aspettato D_Monte_Mario come indicazione di datum
e magari qualche GEOTRAN come specifica di parametri esplicita. Su ArcMaz
questa cosa viene scelta al momento della trasformazione.

Come posso rimediare ai miei errori?

Forzare il datum a quello desiderato, soprattutto poi se di fatto non hai
applicato operazioni di trasformazione di alcun genere, ma usato solo
geometrie e attributi come ti venivano forniti da loro. Ma qual è il datum?
E uno medio basta? Se viceversa hai effettuato trasformazioni, ti tocca
applicare una trasformazione dal tuo datum 'custom' (aka +towgs84=0,0,0)
a quello target.

E per oggi basta che ho sproloquiato a sufficienza.

--
Francesco P. Lovergine

20

2011/4/17 Francesco P. Lovergine <frankie@debian.org>:

On Sat, Apr 16, 2011 at 09:43:41PM +0200, Luca Mandolesi wrote:

...

C'è un equivoco di fondo: 3003/4 non definiscono un datum in quanto
correttamente EPSG ritiene che convenga non specificarlo quando tale
specifica non è univoca, come appunto il caso in esame.

La materializzazione del datum è necessaria per effettuare le trasformazioni
di coordinate, e viene fatta in due modi da software come Proj o ArcCoso:
specificando i 7 (o peggio 3) parametri di rototraslazione dall'ellisoide
G-B a WGS84 oppure specificando un grigliato di raffittimento agganciato alla rete IGM
nella zona di interesse. Il metodo a parametri medi unico è usabile se non
si deve scendere a scale tipo 1:2000/5000 (il comune che ci deve fare?)
Se guardi Grass, per la penisola qualcuno (?) si è preso il disturbo
di calcolare un set di parametri accettabili:

GRASS 6.4.1 (gauss_boaga_est):~ > g.proj -d
GRASS datum code: rome40
WKT Name: Monte_Mario
Datum transformation parameters (PROJ.4 format):
towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68

Una cosa simile la fa ArcCaz a modo suo chiaramente.

Volendo, in GRASS la scelta del datum c'è anche nella GUI:

  http://grass.osgeo.org/wiki/GRASS_Location_Wizard
  -> l'ultimo screenshot

ciao
Markus

PS: Un (nostro) nuovo lavoro fatto con i GIS liberi :slight_smile:
       PLoS ONE: http://dx.plos.org/10.1371/journal.pone.0014800