-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Salve.
Sto convertendo tutti i miei dati italiani, dal vecchio 3003 al nuovo ETRS89.
Vedo che almeno in QGIS ci sono due codici: 3045 e 25833; entrambi paiono avere la
stessa deifinizione:
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
Qualcuno sa come mai questa duplicazione, e quale sia il codice preferibile (immagino
il primo)?
Grazie.
- --
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlMlbB8ACgkQ/NedwLUzIr7xAgCgoMvPAwUf7ykMJ4OCnuMtxTLO
meoAniC/rnAZd4IUcCAhhA1uyfNcBN3s
=4EAR
-----END PGP SIGNATURE-----
credo che dipenda dal tipo di catalogo da cui sono estratti… il II credo sia del’EPSG o sbaglio? sostanzialmente identici ma nomi diversi in cataloghi diversi. E’ un’ipotesi… se c’e’ chi puo’ verificarla meglio 
···
2014-03-16 10:17 GMT+01:00 Paolo Cavallini <cavallini@faunalia.it>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Salve.
Sto convertendo tutti i miei dati italiani, dal vecchio 3003 al nuovo ETRS89.
Vedo che almeno in QGIS ci sono due codici: 3045 e 25833; entrambi paiono avere la
stessa deifinizione:
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
Qualcuno sa come mai questa duplicazione, e quale sia il codice preferibile (immagino
il primo)?
Grazie.
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlMlbB8ACgkQ/NedwLUzIr7xAgCgoMvPAwUf7ykMJ4OCnuMtxTLO
meoAniC/rnAZd4IUcCAhhA1uyfNcBN3s
=4EAR
-----END PGP SIGNATURE-----
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
666 iscritti al 22.7.2013
ciao a tutti,
differenze di definizione non ce ne sono.
noi in Regione Emilia-Romagna abbiamo adottato il secondo (25832 e 25833), e questo ci crea non pochi problemi con qGis perche’ essendo il file .prj identico, qGis lo interpreta come 3044 e 3045 (immagino perche’ sono i primi che trova con quella definizione). Abbiamo risolto questa questione aggiungendo nel .prj anche il parametro Authority.
saluti,
francesco
···
Il giorno 16 marzo 2014 10:21, Gino Pirelli <luipir@gmail.com> ha scritto:
credo che dipenda dal tipo di catalogo da cui sono estratti… il II credo sia del’EPSG o sbaglio? sostanzialmente identici ma nomi diversi in cataloghi diversi. E’ un’ipotesi… se c’e’ chi puo’ verificarla meglio
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
666 iscritti al 22.7.2013
2014-03-16 10:17 GMT+01:00 Paolo Cavallini <cavallini@faunalia.it>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Salve.
Sto convertendo tutti i miei dati italiani, dal vecchio 3003 al nuovo ETRS89.
Vedo che almeno in QGIS ci sono due codici: 3045 e 25833; entrambi paiono avere la
stessa deifinizione:
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
Qualcuno sa come mai questa duplicazione, e quale sia il codice preferibile (immagino
il primo)?
Grazie.
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlMlbB8ACgkQ/NedwLUzIr7xAgCgoMvPAwUf7ykMJ4OCnuMtxTLO
meoAniC/rnAZd4IUcCAhhA1uyfNcBN3s
=4EAR
-----END PGP SIGNATURE-----
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
666 iscritti al 22.7.2013
Anche noi adottiamo epsg:25832.
E anche a noi qgis quando vede un prj del 25832lo codifica come 3045.
Il problema emerge se poi si va a tentare di mettere nel progetto anche uno strato wms.
Infatti i nostri wms non conoscono 3045 ma conocono 25832 e di conseguenza se qgis gli chiede una mappa in 3045
gli rispondono picche.
La soluzione di metterci l’authority non la conoscevo.
Ottima soluzione, ma se capisco bene il tuo discorso, qgis non ce la mette e quindi costringe a editersi a mano il file prj.
In questo caso pero’ si tratterebbe di un bug.
Perche’ se qgis riconosce il campo authority tra 25832 e 3045 allora dovrebbe anche popolarlo quando genera i prj.
Che ne pensate ?
···
Il giorno 16 marzo 2014 10:34, francesco marucci <francesco.marucci@gmail.com> ha scritto:
ciao a tutti,
differenze di definizione non ce ne sono.
noi in Regione Emilia-Romagna abbiamo adottato il secondo (25832 e 25833), e questo ci crea non pochi problemi con qGis perche’ essendo il file .prj identico, qGis lo interpreta come 3044 e 3045 (immagino perche’ sono i primi che trova con quella definizione). Abbiamo risolto questa questione aggiungendo nel .prj anche il parametro Authority.
saluti,
francesco
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
666 iscritti al 22.7.2013
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
Il giorno 16 marzo 2014 10:21, Gino Pirelli <luipir@gmail.com> ha scritto:
credo che dipenda dal tipo di catalogo da cui sono estratti… il II credo sia del’EPSG o sbaglio? sostanzialmente identici ma nomi diversi in cataloghi diversi. E’ un’ipotesi… se c’e’ chi puo’ verificarla meglio
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
666 iscritti al 22.7.2013
2014-03-16 10:17 GMT+01:00 Paolo Cavallini <cavallini@faunalia.it>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Salve.
Sto convertendo tutti i miei dati italiani, dal vecchio 3003 al nuovo ETRS89.
Vedo che almeno in QGIS ci sono due codici: 3045 e 25833; entrambi paiono avere la
stessa deifinizione:
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
Qualcuno sa come mai questa duplicazione, e quale sia il codice preferibile (immagino
il primo)?
Grazie.
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlMlbB8ACgkQ/NedwLUzIr7xAgCgoMvPAwUf7ykMJ4OCnuMtxTLO
meoAniC/rnAZd4IUcCAhhA1uyfNcBN3s
=4EAR
-----END PGP SIGNATURE-----
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
666 iscritti al 22.7.2013
On Sun, 16 Mar 2014 11:08:28 +0100, Andrea Peri wrote:
Anche noi adottiamo epsg:25832.
E anche a noi qgis quando vede un prj del 25832lo codifica come 3045.
risalendo alle fonti ufficiali EPSG [1],[2] diventa tutto chiaro.
si tratta di due CRS sostanzialmente analoghi della famiglia ETRS,
che pero' sono concepiti per scopi sostanzialmente diversi.
[1] http://spatialreference.org/ref/epsg/3045/
[2] http://spatialreference.org/ref/epsg/25832/
confrontando le definizione complete originali (OGC WKT) emerge un'unica
differenza significativa a parte il nome ed il codice (che va poi perduta
del tutto quando i parametri vengono tradotti nel formato PROJ.4):
3045: PARAMETER["central_meridian",15]
25832: PARAMETER["central_meridian",9]
la differenza reale la si percepisce facilmente leggendo i "dati di targa"
riportati nelle rispettive declaratorie:
3045
-----
Scope: Zoned CRS covering all Europe. Used for conformal mapping
at scales larger than 1:500,000.
Area: Europe - 12°E to 18°E
25832
-----
Scope: Large and medium scale topographic mapping and engineering
survey.
Area: Europe - 6°E to 12°E and ETRS89 by country
riassumendo:
- 25832 e' il classico fuso UTM esteso su 6 soli gradi di longitudine.
- invece 3045 e' piuttosto una specie di "super-fuso", che si estende
addirittura lungo ben 30 gradi di longitudine.
lo scopo ovvio e' quello di coprire l'intera EU in un solo colpo:
e conseguentemente andrebbe utilizzato solo per le mappe complessive
a grandissima scala di tipo "continentale" visto che avra' sicuramente
una precisione sostanzialmente degradata specie agli estremi Est ed
Ovest (Spagna - Polonia)
ciao Sandro
Grazie per il chiarimento.
quindi il 3045 è da evitare come la peste.
Il problema è che QGIS quando vede 25832 lo “converte” in 3045.
Come diceva murphy, ne sceglie una e sicuramente sceglie quella errata.
Infine una precisazione.
Capisco che è poco intuitivo,
Te usi il concetto di grande scala in modo opposto a come viene usato normalmente in cartografia.
In cartografia si parla di grande scala intendendo il grande dettaglio, e non la grande estensione
Per cui in termini cartografici: 3045 va usato alle piccolissime scale , che sono quelle delle mappe che inglobano tutta europa o giu’ di li’.
il 25832 va usato alla grande scala , ovvero nelle mappe di dettaglio, che sono quelle piu’ locali:
Andrea.
···
Il giorno 16 marzo 2014 11:51, <a.furieri@lqt.it> ha scritto:
On Sun, 16 Mar 2014 11:08:28 +0100, Andrea Peri wrote:
Anche noi adottiamo epsg:25832.
E anche a noi qgis quando vede un prj del 25832lo codifica come 3045.
risalendo alle fonti ufficiali EPSG [1],[2] diventa tutto chiaro.
si tratta di due CRS sostanzialmente analoghi della famiglia ETRS,
che pero’ sono concepiti per scopi sostanzialmente diversi.
[1] http://spatialreference.org/ref/epsg/3045/
[2] http://spatialreference.org/ref/epsg/25832/
confrontando le definizione complete originali (OGC WKT) emerge un’unica
differenza significativa a parte il nome ed il codice (che va poi perduta
del tutto quando i parametri vengono tradotti nel formato PROJ.4):
3045: PARAMETER[“central_meridian”,15]
25832: PARAMETER[“central_meridian”,9]
la differenza reale la si percepisce facilmente leggendo i “dati di targa”
riportati nelle rispettive declaratorie:
3045
Scope: Zoned CRS covering all Europe. Used for conformal mapping
at scales larger than 1:500,000.
Area: Europe - 12°E to 18°E
25832
Scope: Large and medium scale topographic mapping and engineering
survey.
Area: Europe - 6°E to 12°E and ETRS89 by country
riassumendo:
- 25832 e’ il classico fuso UTM esteso su 6 soli gradi di longitudine.
- invece 3045 e’ piuttosto una specie di “super-fuso”, che si estende
addirittura lungo ben 30 gradi di longitudine.
lo scopo ovvio e’ quello di coprire l’intera EU in un solo colpo:
e conseguentemente andrebbe utilizzato solo per le mappe complessive
a grandissima scala di tipo “continentale” visto che avra’ sicuramente
una precisione sostanzialmente degradata specie agli estremi Est ed
Ovest (Spagna - Polonia)
ciao Sandro
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
666 iscritti al 22.7.2013
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
infatti ci siamo costruiti un .prj così:
PROJCS[“ETRS_1989_UTM_Zone_32N”,GEOGCS[“GCS_ETRS_1989”,DATUM[“D_ETRS_1989”,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],AUTHORITY[“EPSG”,“25832”]]
···
in questo modo qGis (lo avevamo fatto per la 1.8, adesso con la 2.x non ho ancora provato…) riconosce il 25832 correttamente.
noi ad esempio lo abbiamo messo nel pacchetto ConvER che è il nostro strumento desktop ufficiale per convertire da Gauss-Boaga a ETRS89, in modo che i poveri utenti quando caricano in qGis lo shapefile prodotto dal ConvER il sistema di riferimento venga interpretato correttamente (evitando appunto “come la peste” il 3044).
spero possa esservi utile.
saluti,
francesco
Il giorno 16 marzo 2014 11:08, Andrea Peri <aperi2007@gmail.com> ha scritto:
La soluzione di metterci l’authority non la conoscevo.
Ottima soluzione, ma se capisco bene il tuo discorso, qgis non ce la mette e quindi costringe a editersi a mano il file prj.
In questo caso pero’ si tratterebbe di un bug.
Perche’ se qgis riconosce il campo authority tra 25832 e 3045 allora dovrebbe anche popolarlo quando genera i prj.
Che ne pensate ?
scusate, ma come già scritto qualche settimana fa, IGM ha fatto registrare il
nuovo codice epsg indicato nel DM 10-11-2011
si chiama RDN2008 e qua ci sono tutti i parametri
http://www.epsg-registry.org/
so che stanno preparando una nota che farà un po' di chiarezza su tutto
questo pasticciaccio.
s.
ps: 1/10'000 > 1/100'000
--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/EPSG-3045-o-25833-tp7587223p7587238.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.
In questo discorso non aiuta molto.
Il problema è che se i dati sono espressi in epsg:25832, tali restano anche in presenza di un nuovo codice, almeno finche’ non vengono riconvertiti.
Ma occorre prestare attenzione a fare questa operazione.
Perche’ occorre prima avere la certezza di riuscire a supportarlo in ogni dove.
Non basta che sia recepito nelle proj.
Ad esempio credo che Geoserver non usi le proj (ma potrei sbagliare).
E poi occorre vedere che succede sui DBMS stile postgres dove non è affatto banale passare da una versione a una altra.
Non ho idea se sara’ facile oppure no adottare il nuovo sistema senza andare a doversi ricostruire interamente tutta la base dati.
A.
···
Il giorno 16 marzo 2014 14:03, stefano campus <skampus@gmail.com> ha scritto:
scusate, ma come già scritto qualche settimana fa, IGM ha fatto registrare il
nuovo codice epsg indicato nel DM 10-11-2011
si chiama RDN2008 e qua ci sono tutti i parametri
http://www.epsg-registry.org/
so che stanno preparando una nota che farà un po’ di chiarezza su tutto
questo pasticciaccio.
s.
ps: 1/10’000 > 1/100’000
–
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/EPSG-3045-o-25833-tp7587223p7587238.html
Sent from the Gfoss – Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
666 iscritti al 22.7.2013
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
confermo che qGis (2.2) quando si genera un nuovo shapefile a partire dall’epsg:25832 (ad esempio),
produce un .prj SENZA Authority (quindi quando viene riletto non verrebbe interpretato come 25832 ma come 3044)
ma produce anche un .qpj che si che contiene l’Authority, e quindi al successivo caricamento viene interpretato come 25832 perchè il qpj vince sul prj.
quindi non riesco a dire che si tratti effettivamente di un bug.
saluti,
francesco
···
Il giorno 16 marzo 2014 11:08, Andrea Peri <aperi2007@gmail.com> ha scritto:
In questo caso pero’ si tratterebbe di un bug.
Perche’ se qgis riconosce il campo authority tra 25832 e 3045 allora dovrebbe anche popolarlo quando genera i prj.
Che ne pensate ?
a.furieri wrote
risalendo alle fonti ufficiali EPSG [1],[2] diventa tutto chiaro.
si tratta di due CRS sostanzialmente analoghi della famiglia ETRS,
che pero' sono concepiti per scopi sostanzialmente diversi.
[1] http://spatialreference.org/ref/epsg/3045/
[2] http://spatialreference.org/ref/epsg/25832/
3045
-----
Scope: Zoned CRS covering all Europe. Used for conformal mapping
at scales larger than 1:500,000.
Area: Europe - 12°E to 18°E
25832
-----
Scope: Large and medium scale topographic mapping and engineering
survey.
Area: Europe - 6°E to 12°E and ETRS89 by country
riassumendo:
- 25832 e' il classico fuso UTM esteso su 6 soli gradi di longitudine.
- invece 3045 e' piuttosto una specie di "super-fuso", che si estende
addirittura lungo ben 30 gradi di longitudine.
lo scopo ovvio e' quello di coprire l'intera EU in un solo colpo:
e conseguentemente andrebbe utilizzato solo per le mappe complessive
a grandissima scala di tipo "continentale" visto che avra'
sicuramente
una precisione sostanzialmente degradata specie agli estremi Est ed
Ovest (Spagna - Polonia)
Riprenderei il filo del discorso, abbandonando le questioni sulle piccole e
grandi scale, per provare a suggerire una soluzione al doppio SR.
Leggendo direttamente dal sito EPSG, di cui allego uno screenshot, il
sistema 3045 è fatto per essere utilizzato solamente in Germania.
<http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/file/n7587263/epsg3045.png>
Domanda operativa: credo a questo punto che, per evitare che nelle fasi di
editing e riproiezione vengano assegnati PRJ e sistemi errati, la soluzione
migliore sarebbe quella di inserire sempre il campo AUTHORITY con indicato
il codice EPSG di riferimento.
Ma... è un "baco" di QGIS o di PROJ?
A chi segnalarlo?
Mattia
--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/EPSG-3045-o-25833-tp7587223p7587263.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.
Condivido che "la soluzione migliore sarebbe quella di inserire sempre
il campo AUTHORITY con indicato il codice EPSG di riferimento."
Anzi, credo sia urgente operare tale intervento.
Ciao,
Maurizio
Il 17/03/14, Mattia De Agostino<mattia.deagostino@gmail.com> ha scritto:
a.furieri wrote
risalendo alle fonti ufficiali EPSG [1],[2] diventa tutto chiaro.
si tratta di due CRS sostanzialmente analoghi della famiglia ETRS,
che pero' sono concepiti per scopi sostanzialmente diversi.
[1] http://spatialreference.org/ref/epsg/3045/
[2] http://spatialreference.org/ref/epsg/25832/
3045
-----
Scope: Zoned CRS covering all Europe. Used for conformal mapping
at scales larger than 1:500,000.
Area: Europe - 12°E to 18°E
25832
-----
Scope: Large and medium scale topographic mapping and engineering
survey.
Area: Europe - 6°E to 12°E and ETRS89 by country
riassumendo:
- 25832 e' il classico fuso UTM esteso su 6 soli gradi di longitudine.
- invece 3045 e' piuttosto una specie di "super-fuso", che si estende
addirittura lungo ben 30 gradi di longitudine.
lo scopo ovvio e' quello di coprire l'intera EU in un solo colpo:
e conseguentemente andrebbe utilizzato solo per le mappe complessive
a grandissima scala di tipo "continentale" visto che avra'
sicuramente
una precisione sostanzialmente degradata specie agli estremi Est ed
Ovest (Spagna - Polonia)
Riprenderei il filo del discorso, abbandonando le questioni sulle piccole e
grandi scale, per provare a suggerire una soluzione al doppio SR.
Leggendo direttamente dal sito EPSG, di cui allego uno screenshot, il
sistema 3045 è fatto per essere utilizzato solamente in Germania.
<http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/file/n7587263/epsg3045.png>
Domanda operativa: credo a questo punto che, per evitare che nelle fasi di
editing e riproiezione vengano assegnati PRJ e sistemi errati, la soluzione
migliore sarebbe quella di inserire sempre il campo AUTHORITY con indicato
il codice EPSG di riferimento.
Ma... è un "baco" di QGIS o di PROJ?
A chi segnalarlo?
Mattia
--
View this message in context:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/EPSG-3045-o-25833-tp7587223p7587263.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian
mailing list mailing list archive at Nabble.com.
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 17/03/2014 20:30, Maurizio Trevisani ha scritto:
Condivido che "la soluzione migliore sarebbe quella di inserire sempre
il campo AUTHORITY con indicato il codice EPSG di riferimento."
Anzi, credo sia urgente operare tale intervento.
FYI, abbiamo aperto un ticket in merito:
http://hub.qgis.org/issues/9696
Aggiungete pure li' le vostre considerazioni.
NB: a quel che so io, il .prj non prevede il campo authority; questo e' il motivo per
cui in QGIS produciamo (anche) il .qpj, secondo standard OGC, che lo prevede.
In qualche modo questo puo' essere visto come un problema di retrocompatibilita'.
Cordiali saluti.
- --
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlMoZT8ACgkQ/NedwLUzIr6XbACfRFokKkskxj6D4q0uv5ERxWSE
b5sAnjAGcVq/D2LQBF8SwYGI8EUL2mry
=KK9h
-----END PGP SIGNATURE-----
Ma il qpj vale solo per gli shapefile ? Se ad esempio si usa un TIFF con TFW esso chiede in avvio il srs ? Te gli dici 25832 e salvi il progetto. Poi quando riapri qgis resterebbe su 25832 o si sposta su l’altro ? Ora sono fuori, ma stasera se me ne ricordo faccio una prova.
Il 18/mar/2014 16:24 “Paolo Cavallini” <cavallini@faunalia.it> ha scritto:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 17/03/2014 20:30, Maurizio Trevisani ha scritto:
Condivido che “la soluzione migliore sarebbe quella di inserire sempre
il campo AUTHORITY con indicato il codice EPSG di riferimento.”
Anzi, credo sia urgente operare tale intervento.
FYI, abbiamo aperto un ticket in merito:
http://hub.qgis.org/issues/9696
Aggiungete pure li’ le vostre considerazioni.
NB: a quel che so io, il .prj non prevede il campo authority; questo e’ il motivo per
cui in QGIS produciamo (anche) il .qpj, secondo standard OGC, che lo prevede.
In qualche modo questo puo’ essere visto come un problema di retrocompatibilita’.
Cordiali saluti.
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlMoZT8ACgkQ/NedwLUzIr6XbACfRFokKkskxj6D4q0uv5ERxWSE
b5sAnjAGcVq/D2LQBF8SwYGI8EUL2mry
=KK9h
-----END PGP SIGNATURE-----
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
666 iscritti al 22.7.2013
