Errata traslazione tra coordinate 7791 e 3003

QGIS QGIS-it-user
1

Ciao a tutti,
Sto utilizzando qgis versione 4.0.3. ho postato lo stesso topic anche sul forum principale, ma mi sono accorto solo adesso che esiste anche il canale in italiano.

Ultimamente (da circa un mese) mi capita una cosa strana quando importo un layer 7791 dentro un progetto 3003.
Il layer importato risulta disallineato di circa 80 metri. Lo stesso layer importato qualche mese fa aveva una scostamento di circa 50 cm (accettabile, considerando che non ho i grigliati ufficiali IGM).
L’altra cosa strana, o per lo meno, che non capisco io, è che se imposto il layer 7791 con coordinate 3044, lo slittamento è di soli 70 cm.

È cambiata qualcosa in qgis con i vecchi grigliati di default 7791?
Grazie.

2

Ciao che io sappia la trasformazione tra 7791 e 3003 senza grigliati IGM si porta dietro quelle deformazioni e non c’è niente da fare. Con solo QGIS, anche se non ho mai provato, in linea teorica potresti provare riproiettando prima tra 7791 e WGS 84 UTM 32 N e poi in EPSG 3003, la deformazione dovrebbe attenuarsi. Anche se dovesse funzionare rimane comunque una procedura poco consistente se ti serve precisione metrica.

Il ven 5 giu 2026, 20:52 Dario <noreply@discourse.osgeo.org> ha scritto:

Dario
June 5

Ciao a tutti,
Sto utilizzando qgis versione 4.0.3. ho postato lo stesso topic anche sul forum principale, ma mi sono accorto solo adesso che esiste anche il canale in italiano.

Ultimamente (da circa un mese) mi capita una cosa strana quando importo un layer 7791 dentro un progetto 3003.
Il layer importato risulta disallineato di circa 80 metri. Lo stesso layer importato qualche mese fa aveva una scostamento di circa 50 cm (accettabile, considerando che non ho i grigliati ufficiali IGM).
L’altra cosa strana, o per lo meno, che non capisco io, è che se imposto il layer 7791 con coordinate 3044, lo slittamento è di soli 70 cm.

È cambiata qualcosa in qgis con i vecchi grigliati di default 7791?
Grazie.

3

Grazie per la risposta, Aldo.

Lo scarto di qualche decimetro l’ho sempre accettato quando devo fare delle prove in velocità. Diversamente utilizzo convergo e, appunto, converto i layer, ottenendo trasformazioni perfette.

La cosa che non mi capacito è come possa essere possibile che fino al mese scorso non avevo problemi. Se apro dei file vecchi, infatti, non ho alcun problema.

4

Questo è strano, dovresti indagare nella vera definizione nel file proj se è uno shp, solo lo puoi trovare la risposta, se ti serve solo visualizzare velocemente potresti anche provare a impostare sr del progetto a metà strada tra i due SR, ossia WGS 84 UT 32N, questo, per esempio, funziona tra i miei vettori catastali in 3003 e il vms del catasto. Ma effettivamente io non sono ancora passata in QGIS 4 anche se non credo che il comportamento anomalo dipenda dalla versione.

Il ven 5 giu 2026, 21:26 Dario <noreply@discourse.osgeo.org> ha scritto:

Someone replied to your post.

Dario
June 5

Grazie per la risposta, Aldo.

Lo scarto di qualche decimetro l’ho sempre accettato quando devo fare delle prove in velocità. Diversamente utilizzo convergo e, appunto, converto i layer, ottenendo trasformazioni perfette.

La cosa che non mi capacito è come possa essere possibile che fino al mese scorso non avevo problemi. Se apro dei file vecchi, infatti, non ho alcun problema.

5

Buonasera,

Mi ritrovo queste mail, ovviamente il Dario in questione non sono io, benché mi occupi anche io di GIS.

Sinceramente non so come possano essere finite nelle mie mail con me in copia

Il 5 giugno 2026 21:38:01 CEST, Aldo Gessa noreply@discourse.osgeo.org ha scritto:

Someone replied to a topic you are Watching.

Aldo_Gessa
June 5

Questo è strano, dovresti indagare nella vera definizione nel file proj se è uno shp, solo lo puoi trovare la risposta, se ti serve solo visualizzare velocemente potresti anche provare a impostare sr del progetto a metà strada tra i due SR, ossia WGS 84 UT 32N, questo, per esempio, funziona tra i miei vettori catastali in 3003 e il vms del catasto. Ma effettivamente io non sono ancora passata in QGIS 4 anche se non credo che il comportamento anomalo dipenda dalla versione.

Il ven 5 giu 2026, 21:26 Dario <noreply@discourse.osgeo.org> ha scritto:

Someone replied to your post.

Dario
June 5

Grazie per la risposta, Aldo.

Lo scarto di qualche decimetro l’ho sempre accettato quando devo fare delle prove in velocità. Diversamente utilizzo convergo e, appunto, converto i layer, ottenendo trasformazioni perfette.

La cosa che non mi capacito è come possa essere possibile che fino al mese scorso non avevo problemi. Se apro dei file vecchi, infatti, non ho alcun problema.

Dario Saccoccia

6

Ciao Dario Saccoccia,
evidentemente eri iscritto alla mailing list qgis-it-user che poi è stata chiusa e quindi sei iscritto al forum / mailing list QGIS-it-user che ha preso il posto della precedente mailing list qgis-it-user.

A presto.

Andrea

7

Ciao Dario,
in quale “forum principale” hai postato lo stesso messaggio?

Comunque, siccome mi par di capire che usando la stessa versione di QGIS e visualizzando “file vecchi” nello stesso progetto non riscontri alcun problema con tali file, ciò, a mio avviso, escluderebbe che sia cambiato qualcosa in QGIS. Se fosse cambiato qualcosa in QGIS, riscontreresti il problema anche visualizzando “file vecchi” nello stesso progetto.

Per quanto ne so, in QGIS non esistono e non sono mai esistiti “vecchi grigliati di default 7791”.

A presto.

Andrea

8

Ciao Andrea,

Ecco il link dove avevo postato inizialmente il messaggio”

Domani vi allego il messaggio di errore che adesso mi dà QGis, indicandomi che non è in grado di fare una traslazione da 7791 a 3003.

Ripeto, la cosa che mi fa diventare matto è che in passato erano due sistemi che usavo molto spesso insieme (geoportale Regione Liguria è quasi tutto in 3003, mentre alcuni layer del geoportale comune di Genova sono nativi 7791).

9

Avevi postato il messaggio non nel “forum principale”, ma nel forum degli ustenti USA di QGIS.

Attualmente esiste una mailing-list internazionale degli utenti di QGIS (non un forum) all’URL QGIS-User Info Page.

Ti consiglio di chiarire meglio il problema e le condizioni in cui si verifica, fornendo possibilmente un semplice file di progetto di QGIS e il o i file del layer usando i quali il problema si verifica, e un semplice file di progetto di QGIS e il o i file del layer usando i quali il problema non si verifica e il o i file del layer rispetto al quale riscontri uno disallineamento anomalo e specificando con quale versione di QGIS il problema si verifica e con quale non si verifica, quale sistema operativo stai utilizzando e come esattamente hai installato QGIS.

A presto.

Andrea

10

grazie Andrea.

Ho fatto un po’ di prove. Non vi posso allegare il file, perché dice che, essendo nuovo utente, non posso allegare file.

Lascio link per scaricare il file

Potete fare prove scaricando i dati direttamente dal geoportale del Comune di Genova, utilizzando queste capabilities WMF e WMS

WMS: https://mappe.comune.genova.it/geoserver/wms

WFS: https://mappe.comune.genova.it/geoserver/wfs

ho notato che i wfs presenti vengono caricati correttamente (con un leggero scarto)

image
image486×449 23.6 KB

mentre se carico le ortofoto (li trovate dalle WFS) o i las (scaricabili dal sito del geoportale), queste si discostano circa 80 metri

image
image890×606 162 KB

lo stesso se carico il file edifici che però avevo da archivio e che ora non trovate su geoportale (edifici in rosso).

image
image646×526 140 KB

Ho notato che se uso le info del prj presente nell’attuale livello del geoportale e lo uso per il layer precedente, l’allineamento è corretto.

scrivo qui di seguito i due prj (ma li trovate nel file da scaricare).
prj vecchio, non funzionante:
PROJCS[“RDN2008_UTM_zone_32N”,GEOGCS[“GCS_RDN2008”,DATUM[“D_Rete_Dinamica_Nazionale_2008”,SPHEROID[“GRS_1980”,6378137.0,298.257222101]],PRIMEM[“Greenwich”,0.0],UNIT[“Degree”,0.0174532925199433]],PROJECTION[“Transverse_Mercator”],PARAMETER[“False_Easting”,500000.0],PARAMETER[“False_Northing”,0.0],PARAMETER[“Central_Meridian”,9.0],PARAMETER[“Scale_Factor”,0.9996],PARAMETER[“Latitude_Of_Origin”,0.0],UNIT[“Meter”,1.0]]

prj dei livelli del geoportale che non hanno criticità:
PROJCS[“RDN2008 / UTM zone 32N”, GEOGCS[“RDN2008”, DATUM[“Rete Dinamica Nazionale 2008”, SPHEROID[“GRS 1980”, 6378137.0, 298.257222101, AUTHORITY[“EPSG”,“7019”]], TOWGS84[0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0], AUTHORITY[“EPSG”,“1132”]], PRIMEM[“Greenwich”, 0.0, AUTHORITY[“EPSG”,“8901”]], UNIT[“degree”, 0.017453292519943295], AXIS[“Geodetic longitude”, EAST], AXIS[“Geodetic latitude”, NORTH], AUTHORITY[“EPSG”,“6706”]], PROJECTION[“Transverse_Mercator”, AUTHORITY[“EPSG”,“9807”]], PARAMETER[“central_meridian”, 9.0], PARAMETER[“latitude_of_origin”, 0.0], PARAMETER[“scale_factor”, 0.9996], PARAMETER[“false_easting”, 500000.0], PARAMETER[“false_northing”, 0.0], UNIT[“m”, 1.0], AXIS[“Easting”, EAST], AXIS[“Northing”, NORTH], AUTHORITY[“EPSG”,“7791”]]

Si può assegnare un prj anche ad un raster? In questo modo risolverei il problema.

Grazie!

11

Ciao Dario,
appena posso, provo ad usare il progetto che hai condiviso.

Nel frattempo, potresti chiarire alcuni aspetti che non mi sono ben chiari?

Hai scritto che usi QGIS 4.0.3 e che da circa un mese riscontri il problema. Tuttavia QGIS 4.0.3 è stato rilasciato solo qualche giorno fa. Quindi suppongo che un mese fa, quando hai iniziato a riscontrare il problema, stavi usando un’altra versione di QGIS, e che quando il problema non si presentava ne stavi usando un’altra ancora.
Potresti indicare con quale versione di QGIS il problema non veniva riscontrato?

Hai anche scritto che “se apro dei file vecchi, infatti, non ho alcun problema”: quindi suppongo che con QGIS 4.0.3 c’è un file “vecchio” che viene visualizzato correttamente, mentre c’è un file “nuovo” che non viene visualizzato correttamente.
Potresti potresti indicare esattamente qual è il file vecchio e qual è il file nuovo? Il file “nuovo” viene visualizzato in maniera errata solo in QGIS 4.0.3 o anche nella versione precedente in cui il problema non veniva riscontrato?

Andrea

12

Inoltre, mi pare di capire, dall’ultimo messaggio, che il diverso allineamento di layer che riscontri in QGIS dipende dal diverso file prj usato per un layer rispetto ad un altro.
Potresti confermarlo?
Questo escluderebbe che il diverso allinemento dei layer dipenda da un diverso comportamento di QGIS.

Andrea

13

non ricordo quale fosse la versione di qualche mese fa, però sono andato a prendere un vecchio file creato con la versione 3.10.14-A Coruña. è un file 3003 con alcuni elementi 7791 (le ortofoto). lo apre correttamente. Ho pure inserito ex novo altre foto 7791 e non crea problemi. Ho infine aggiunto i layer del file precedentemente allegato (il layer che creava disallineamenti) e qui funziona bene. se faccio tutto con un nuovo file, ho di nuovo problemi.

ecco il link per scaricare il file vecchio:

Adesso provo ad installare da archivio la 3.10 e vedere cosa succede.

Grazie

14

Ciao Dario,
ho provato il tuo progetto con QGIS 4.0.3, QGIS LTR 3.44.11, QGIS LTR 3.40.15 (di 6 mesi fa), QGIS LTR 3.34.15 (di 1 anno fa), QGIS LTR 3.28.15 (di 2 anni fa), QGIS 3.22.6 (4 anni fa): mi pare che tutte queste versioni visualizzino il progetto e i suoi layer allo stesso identico modo.

Quindi non vedo nessun cambiamento di comportamento di QGIS con lo stesso progetto e gli stessi layer.

Il progetto che hai fornito ha come CRS EPSG:3003

  • un layer WMS EPSG:7791 (“Foto Aeree 2021”)
  • un layer ESRI Shapefile che QGIS riconosce come EPSG:3003 (“Edifici_3003”)
  • un layer ESRI Shapefile che QGIS riconosce come EPSG:7791 (“Edifici_7791”)
  • due layer ESRI Shapefile con CRS che QGIS (tramite le librerie GDAL/PROJ) non riconosce corrispondere a nessun CRS EPSG (“Edifici_7791_Da geoportale”, “Edifici_7791_con prj mod”)

Inoltre in tale progetto risultano impostate manualmente alcune trasformazioni di datum (come puoi vedere in Project->Properties->Transformation).

QGIS utilizza la libreria PROJ e il database ufficiale EPSG per effettuare le trasformazioni tra CRS e tra datum.

L’unica trasformazione (EPSG:9734 “Monte Mario to RDN2008 (5)”) definita nel database EPSG (così come fatta inserire dall’IGM) tra EPSG:7791 (datum RDN2008) e EPSG:3003 (datum ROMA40) prevede l’uso di appositi grigliati per tener conto del datum shift. In mancanza dei grigliati viene utilizzata una trasformazione “ballpark” che tiene conto solo della differenza di ellissoide e di false origini, ma non del datum shift, e che quindi introduce un errore variabile solitamente di circa 70/100 metri a seconda delle zone.
Tale trasformazione viene quindi applicata solo ai layer effettivamente riconosciuti come EPSG:7791 (il layer WMS “Foto Aeree 2021” e il layer ESRI Shapefile “Edifici_7791”) nel tuo progetto EPSG:3003.

Invece i layer “Edifici_7791_Da geoportale” e “Edifici_7791_con prj mod”, che non vengono riconosciuti come EPSG:7791 da GDAL/PROJ, vengono considerati alla stregua di CRS basati sul datum ETRS89 / WGS84 (come EPSG:25832 e EPSG:32632) e quindi viene applicata una delle varie trasformazioni (EPSG:1660 “Monte Mario to WGS 84 (4)”) di datum di tipo Helmert a 7 parametri tra i datum ETRS89 (assunto uguale a WGS84) e ROMA40 registrate nel database EPSG, che introduce un errore variabile intorno ad alcuni decimetri o metri o decametri a seconda delle zone.

Questo spiega perché riscontri differenze tra il modo in cui vengono riproiettati i layer effettivamente riconosciuti come aventi CRS EPSG:7791 e i layer non riconosciuti come effettivamente aventi CRS EPSG:7791.

Il motivo per cui il file ESRI proj dei layer “Edifici_7791_Da geoportale” e “Edifici_7791_con prj mod” non venga riconosciuto come EPSG:7791 dipende dalle librerie GDAL/PROJ e andrebbe quindi chiesto a Even Rouault, che ne è il principale sviluppatore.

EDIT: mi accorgo ora che il motivo è dovuto al fatto che la definizione del CRS nel file prj di tali ultimi due layer contiene la stringa “TOWGS84[0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]” che dichiara quindi che tale CRS deve essere trattato come avente un datum di fatto uguale a WGS84. Perciò il CRS non può essere trattato come avente datum RDN2008 e quindi correttamente non viene riconosciuto come EPSG:7791.

Spero di essere stato chiaro.

A presto.

Andrea

15

QGIS LTR 3.10.14 è una versione di QGIS rilasciata più di 5 anni fa.

Tale versione, su Windows, usava un database EPSG rilasciato nel 2020.

In tale database EPSG non era ancora presente la trasformazione predefinita EPSG:9734 “Monte Mario to RDN2008 (5)” tra EPSG:7791 (datum RDN2008) e EPSG:3003 (datum ROMA40) che prevede l’uso di appositi grigliati.

L’IGM fece registrare tale trasformazione nel database EPSG.solo nel 2021.

Pertanto, in QGIS 3.10, sia i layer “Edifici_7791” e “Foto Aeree 2021” (che QGIS effettivamente riconosce come EPSG:7791), sia i layer “Edifici_7791_Da geoportale” e “Edifici_7791_con prj mod” (che hanno un file prj non standard in cui è presente la stringa “TOWGS84[0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]” che dichiara che RDN2008 deve essere considerato uguale a WGS84 per tali layer), vengono trattati alla stessa maniera e per essi viene utilizzato la stessa trasformazione (EPSG:1660 “Monte Mario to WGS 84 (4)”).

A presto.

Andrea

1 Like
16

Bravissimo! Spiegato (il mio) arcano mistero. Ed ecco perché, stranamente per me, se dico di utilizzare il sistema 3044 ad un layer 7791, invece, funziona.

Grazie.

Ciao