Il 28/06/2011 19.30, Niccolo Rigacci ha scritto:
On Tue, Jun 28, 2011 at 04:00:56AM -0700, iomeneandrei wrote:
Ciao, ho notato che in QGIS 1.7 il CRS "EPSG:40003" Ú ancora
definito come: "+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996
+x_0=150 +y_0=0 +ellps=intl +units=m
+towgs84=-50.2,-50.4,84.8,
Ciao Niccolò,
Niccolo Rigacci wrote:
>
> Il srs custom EPSG:40003 vorrebbe servire per la Sicilia, che ricade nel
> fuso ovest del Gauss-Boaga, quindi lon_0=9 e x_0=150.
> Perché vorresti usare invece il fuso est di Gauss-Boaga?
>
lo vorrei fare perché la Sicilia cade (quasi) tutta nel fuso
On Tue, Jun 28, 2011 at 04:00:56AM -0700, iomeneandrei wrote:
> Ciao,
> ho notato che in QGIS 1.7 il CRS "EPSG:40003" è ancora definito come:
> "+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=150 +y_0=0 +ellps=intl
> +units=m +towgs84=-50.2,-50.4,84.8,-0.690,-2.012,0.459,-28.08 +no_defs"
>
> Se
Ciao,
ho notato che in QGIS 1.7 il CRS "EPSG:40003" è ancora definito come:
"+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=150 +y_0=0 +ellps=intl
+units=m +towgs84=-50.2,-50.4,84.8,-0.690,-2.012,0.459,-28.08 +no_defs"
Se deve rimanere codificato come "EPSG:40003", credo che dovrebbe essere
comu
Il 29/05/2011 12:33, aperi2007 ha scritto:
> Io conosco questa :)
>
> http://www.centrointerregionale-gis.it/
>
> Che tra l'altro e' l'ente che ha coordinato insieme a DigitPA e IGM la
> stesura del
> documento in cui si introduce il nuovo sistema di riferimento.
Grazie. Pensi che possano esser
Grazie mille andrea..
dato epr assunto che gli spostamenti di cui si parla sono molto limitati
(ci vogliono 50 anni per fare un metro di spostamento) è chiaro che la
questione esiste ed è interessante.
il problema si pone, come tu dici giustamente, se si passa da sistemi
locali a globali e vicever
Io conosco questa :)
http://www.centrointerregionale-gis.it/
Che tra l'altro e' l'ente che ha coordinato insieme a DigitPA e IGM la stesura
del documento in cui si introduce il nuovo sistema di riferimento.
Grazie Andrea per i links.
Due questioni:
- il nuovo sistema ufficiale ha gia' un suo
Infatti non e' per niente semplice, ma non e' che sia complicato di per
se' , cio' che lo rende complicato e' la filiera di impiego che e' molto
estesa e che finisce per incrociarsi con interpretazioni e esigenze
discordanti tra loro, perdendo di vista inevitabilmente la genesi
(Lineage nei M
Ciao Andrea,
grazie mille della segnalazione...
per mia massima ignoranza non sapevo del decreto...
se ho capito bene il nuovo sistema sarà un ETRS89 materializzato epr
l'Italia...
ma in sostanza l'ETRS89 è un WGS84 "preciso" e discostato da quello
globale (per l'europa) a causa della deriva dei co
Il 28/05/2011 13:06, aperi2007 ha scritto:
> DAll'entrata in vigore di tale DPCM, tutti i dati prodotti in Italia,
> salvo quelli di livello hobbistico e per passatempo , dovranno essere fatti
> in tale
> sistema di riferimento.
>
> Io eviterei di incasinare il discorso inventandosene degli altr
Il 28/05/2011 13:58, andrea antonello ha scritto:
> +1 mi sembra un'ottima idea. Pronto a cambiare appena ci mettiamo d'accordo.
> E non posso che darti ragione. E' stata un'inerzia alla quale
> volentieri pongo rimedio. :)
Same here ;)
Direi di evitare customizzazioni per quanto possibile: esis
Ciao,
grazie per tutte le informazioni e per gli spunti.
La mia segnalazione iniziale è "soltanto" da utente QGIS: ho notato una
definizione di SRS che non mi sembrava corretta e l'ho segnalata.
Buona domenica,
a
-
Andrea Borruso
email:
2011/5/28 Sandro Santilli :
> On Sat, May 28, 2011 at 01:17:50PM +0200, Antonio Falciano wrote:
>
>> Oggi comunque 900913 continua ad esistere nel db
>> EPSG [2], solo che dopo varie vicissitudini ha cambiato denominazione:
>> e' diventato EPSG:3857.
> Dubito che 900913 sia MAI esistito nel db EPSG
Ciao Antonio,
> sarebbe bello poter uniformare (o meglio ancora standardizzare) questi
> benedetti codici in tutte le applicazioni che hanno la possibilita' di
> farlo! Altrimenti, passando da un'applicazione ad un'altra si rischia di
> impelagarsi come e piu' di prima e ...addio l'interoperabilit
On Sat, May 28, 2011 at 01:17:50PM +0200, Antonio Falciano wrote:
> Oggi comunque 900913 continua ad esistere nel db
> EPSG [2], solo che dopo varie vicissitudini ha cambiato denominazione:
> e' diventato EPSG:3857.
Dubito che 900913 sia MAI esistito nel db EPSG.
E' stato "spacciato" come EPSG
Il 28/05/2011 13.06, aperi2007 ha scritto:
Non riesco a capire bene il senso della cosa che state discutendo..
Modificare dei sistemi di riferimento o inventarsene di nuovi
Il rischio di perdere la compatibilità e ritrovarsi con dei software
che "danno i numeri" .
Se uno dovesse realizza
Il 28/05/2011 12.52, Sandro Santilli ha scritto:
On Sat, May 28, 2011 at 12:39:54PM +0200, Antonio Falciano wrote:
Come prefisso, in ogni caso, non utilizzerei "EPSG:" ma mi inventerei
qualcos'altro poiche' questi codici non ci sono e non ci saranno nel db
EPSG, o sbaglio?
PostGIS ha cominciato
Non riesco a capire bene il senso della cosa che state discutendo..
Modificare dei sistemi di riferimento o inventarsene di nuovi
Il rischio di perdere la compatibilità e ritrovarsi con dei software che
"danno i numeri" .
Se uno dovesse realizzare un archivio usando tale nuovo sistema no
On Sat, 2011-05-28 at 12:52 +0200, Sandro Santilli wrote:
> spatialreferencing.org
é
http://www.spatialreference.org/
Ciao
-- G --
___
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@lists.gfoss.it
http://lists.gfos
On Sat, May 28, 2011 at 12:39:54PM +0200, Antonio Falciano wrote:
> Come prefisso, in ogni caso, non utilizzerei "EPSG:" ma mi inventerei
> qualcos'altro poiche' questi codici non ci sono e non ci saranno nel db
> EPSG, o sbaglio?
PostGIS ha cominciato ad usare "spatialreferencing.org".
E' usat
Il 28/05/2011 12.32, iomeneandrei ha scritto:
Ciao Andrea,
sempre avanti voi di uDig ;-)
Uniformare il tutto sarebbe un'ottima cosa. Magari comprendendo gvSIG e
ovviamente GRASS. A proposito in GRASS che codici sono usati?
gvSIG ad esempio non ha questa necessita', poiche' utilizza un db EPSG
Ciao Andrea,
sarebbe bello poter uniformare (o meglio ancora standardizzare) questi
benedetti codici in tutte le applicazioni che hanno la possibilita' di
farlo! Altrimenti, passando da un'applicazione ad un'altra si rischia di
impelagarsi come e piu' di prima e ...addio l'interoperabilita'!
Ne
Ciao Andrea,
sempre avanti voi di uDig ;-)
Uniformare il tutto sarebbe un'ottima cosa. Magari comprendendo gvSIG e
ovviamente GRASS. A proposito in GRASS che codici sono usati?
ciao,
a
-
Andrea Borruso
email: aborr...@tin.it
website: ht
Giusto per la cronaca, in uDig da un bel po' di tempo abbiamo aggiunto
(per il caso dei 3003,3004) :
30031000
30031001
30031002
30041000
30041001
30041002
con
1000 pensinsular
1001 sardinia
1002 sicily
prendendo i parametro da GRASS, che i parametri li ha.
Allora abbiamo preso dei codici aggiun
Il 28/05/2011 9.24, iomeneandrei ha scritto:
avevo pensato di introdurre il 40004 per assonanza geografica e
numerica con
il 3004. La mia modesta proposta è cancellare il 40003 ed introdurre il
40004. Ovviamente la cosa che mi sembra più importante è introdurre la
definizione proj più corretta.
Ciao Ivan,
ivan marchesini-2 wrote:
>
> Potremmo cambiare il 40003 direttamente... senza stare ad introdurre il
> 40004.
> in fin dei conti solo una piccolissima parte della sicilia occidentale
> (forse) ricade nel fuso ovest.
>
avevo pensato di introdurre il 40004 per assonanza geografica e n
Ciao,
grazie ad andrea per la segnalazione.
non mi ero accorto del problema.
In effetti il 40003 ha il meridiano centrale del fuso ovest ed anche la
falsa origine delle coordinate est ovviamente.
Di conseguenza mal si adatta per la sicilia che ricade per lo più (se
non totalmente, nel fuso est.
Qui
Il 27/05/2011 16:46, Antonio Falciano ha scritto:
> Pardon! Pero' EPSG:40004 non esiste nel db EPSG ufficiale, per cui le altre
> applicazioni lo ignorano (...addio interoperabilita'!). IMHO, almeno
> nell'ambito di
> QGIS, una denominazione articolata derivata dai codici EPSG effettivi (come
> d
Il 27/05/2011 16.24, Paolo Cavallini ha scritto:
Il 27/05/2011 16:17, Antonio Falciano ha scritto:
L'ultima correzione proposta da Andrea e' corretta, in quanto la Sicilia ricade
nel
fuso Est. Si dovrebbe partire quindi dalla definizione di EPSG:3004 e poi
applicare i
parametri di trasformazi
Il 27/05/2011 16:17, Antonio Falciano ha scritto:
> L'ultima correzione proposta da Andrea e' corretta, in quanto la Sicilia
> ricade nel
> fuso Est. Si dovrebbe partire quindi dalla definizione di EPSG:3004 e poi
> applicare i
> parametri di trasformazione EPSG:1664 [1].
> Tuttavia, l'unica cos
Il 27/05/2011 15.14, Paolo Cavallini ha scritto:
Il 27/05/2011 13:16, iomeneandrei ha scritto:
Buongiorno a tutti,
scusate se insisto con la richiesta, ma se la mia ipotesi fosse giusta
(anche solo in parte) penso che sarebbe importante fare le dovute correzioni
in QGIS.
Nel mio messaggio su qg
Il 27/05/2011 13:16, iomeneandrei ha scritto:
> Buongiorno a tutti,
> scusate se insisto con la richiesta, ma se la mia ipotesi fosse giusta
> (anche solo in parte) penso che sarebbe importante fare le dovute correzioni
> in QGIS.
>
> Nel mio messaggio su qgis-developer c'è comunque sicuramente un
Buongiorno a tutti,
scusate se insisto con la richiesta, ma se la mia ipotesi fosse giusta
(anche solo in parte) penso che sarebbe importante fare le dovute correzioni
in QGIS.
Nel mio messaggio su qgis-developer c'è comunque sicuramente un mio errore.
Ho scritto come proposta per lo SRS 4004:
"+p
33 matches
Mail list logo
