SRS: "EPSG:40003" e QGIS

[aborruso]

Buongiorno a tutti,
giro anche qui un post che riguarda un SRS tutto italiano, e di come sia descritto in QGIS:
http://bit.ly/jQMXo8

Vorrei sapere che ne pensate, perché non sono cintura nera di SRS. Se però ci fosse qualcosa di corretto, penso che possa essere una annotazione utile.

Grazie,

a

[aborruso]

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:
"+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=2520000 +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 la proposta fosse corretta, c'è da fare infatti questa modifica (ho corretto il meridiano centrale):
"+proj=tmerc +lat_0=0 +lon_0=15 +k=0.9996 +x_0=2520000 +y_0=0 +ellps=intl +units=m +towgs84=-50.2,-50.4,84.8,-0.690,-2.012,0.459,-28.08 +no_defs"

Grazie e scusatemi ancora

[pcav]

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 mio errore.
> Ho scritto come proposta per lo SRS 4004:
> "+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=2520000 +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 la proposta fosse corretta, c'è da fare infatti questa modifica (ho
> corretto il meridiano centrale):
> "+proj=tmerc +lat_0=0 +lon_0=15 +k=0.9996 +x_0=2520000 +y_0=0 +ellps=intl
> +units=m +towgs84=-50.2,-50.4,84.8,-0.690,-2.012,0.459,-28.08 +no_defs"

Nessun esperto di proiezioni che ci possa dare una risposta definitiva su questo?
Grazie.

--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[Antonio Falciano]

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 qgis-developer c'è comunque sicuramente un mio errore.
>> Ho scritto come proposta per lo SRS 4004:
>> "+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=2520000 +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 la proposta fosse corretta, c'è da fare infatti questa modifica (ho
>> corretto il meridiano centrale):
>> "+proj=tmerc +lat_0=0 +lon_0=15 +k=0.9996 +x_0=2520000 +y_0=0 +ellps=intl
>> +units=m +towgs84=-50.2,-50.4,84.8,-0.690,-2.012,0.459,-28.08 +no_defs"
> Nessun esperto di proiezioni che ci possa dare una risposta definitiva su questo?
> Grazie.

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 cosa che mi spiazza e' la denominazione di tale CRS:
non puo' essere definito/denominato come EPSG:4004 [2], in quanto
rappresenta tutt'altro (Unknown datum based upon the Bessel 1841
ellipsoid) e quindi potrebbe confondere qualche ignaro utente. A mio
modesto avviso, sarebbe comunque preferibile utilizzarlo tra i custom
CRS, proprio come avveniva in passato, o al limite battezzarlo in
maniera piu' articolata come EPSG:3004_1664 o addirittura (se possibile)
come EPSG:3004_Sicily, in modo tale da eliminare possibili ambiguita'.

buon pomeriggio
Antonio

[1] http://bit.ly/ldtOVV
[2] http://bit.ly/iUIVFf

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

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[pcav]

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 cosa che mi spiazza e' la denominazione di tale CRS: non puo'
> essere definito/denominato come EPSG:4004 [2], in quanto rappresenta tutt'altro

manca uno 0: 40004 non dovrebbe confliggere.
saluti, e grazie.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[Antonio Falciano]

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 trasformazione EPSG:1664 [1].
>> Tuttavia, l'unica cosa che mi spiazza e' la denominazione di tale CRS: non puo'
>> essere definito/denominato come EPSG:4004 [2], in quanto rappresenta tutt'altro
> manca uno 0: 40004 non dovrebbe confliggere.
> saluti, e grazie.

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 dicevo prima) sarebbe preferibile...

ciao

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

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[pcav]

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 dicevo
> prima) sarebbe preferibile...

E' intenzionale: EPSG lascia un range di ID liberi per le definizioni ad hoc (come e'
il nostro caso, visto che EPSG non si preoccupa dei parametri +towgs per gauss-boaga.
Per essere interoperabili, EPSG dovrebbe definire un ID, cosa che non credo voglia
fare, per ragioni plausibili.
Sabglio?
Saluti.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[ivan marchesini-2]

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.
Quindi usare il meridiano 15 e la falsa origine a 2520000 è sicuramente
opportuno.
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.


ciao

Ivan



Il giorno ven, 27/05/2011 alle 16.52 +0200, Paolo Cavallini ha scritto:

> 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 dicevo
> > prima) sarebbe preferibile...
>
> E' intenzionale: EPSG lascia un range di ID liberi per le definizioni ad hoc (come e'
> il nostro caso, visto che EPSG non si preoccupa dei parametri +towgs per gauss-boaga.
> Per essere interoperabili, EPSG dovrebbe definire un ID, cosa che non credo voglia
> fare, per ragioni plausibili.
> Sabglio?
> Saluti.
> --
> Paolo Cavallini: http://www.faunalia.it/pc
> _______________________________________________
> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
> [hidden email]
> 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

--
Ti prego di cercare di non inviarmi files .dwg, .doc, .xls, .ppt.
Preferisco formati liberi.
Please try to avoid to send me .dwg, .doc, .xls, .ppt files.
I prefer free formats.
http://it.wikipedia.org/wiki/Formato_aperto
http://en.wikipedia.org/wiki/Open_format

Ivan Marchesini
Perugia (Italy)
Socio fondatore GFOSS "Geospatial Free and Open Source Software" http://www.gfoss.it
e-mail: [hidden email]
        [hidden email]
fax (mailfax): [phone]
jabber: [hidden email]
skype: geoivan73

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[aborruso]

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 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.

Buona domenica a tutti,

a

[Antonio Falciano]

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.

IMHO, l'assegnazione di questi codici poteva essere ottimizzata dal
principio. Ad esempio, si sarebbe potuto procedere cosi':
40001 --> Monte Mario / Italy zone 1 (mainland)
40002 --> Monte Mario / Italy zone 2 (mainland)
40003 --> Monte Mario / Italy zone 1 (Sardegna)
40004 --> Monte Mario / Italy zone 2 (Sicily)
in modo tale da avere l'1 o il 2 finale che richiama la zona (fuso) nei
primi due casi, il 3 e il 4 finale che richiama il 3003 e il 3004 (come
Andrea osserva) negli ultimi due.

ciao
Antonio

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

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[Andrea Antonello]

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 aggiungendo i 1000 dietro e sembrava
una buona idea, ma sarei contento di adattarci se si decide per dei
codici comuni.

Andrea



2011/5/28 Antonio Falciano <[hidden email]>:

> 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.
>
> IMHO, l'assegnazione di questi codici poteva essere ottimizzata dal
> principio. Ad esempio, si sarebbe potuto procedere cosi':
> 40001 --> Monte Mario / Italy zone 1 (mainland)
> 40002 --> Monte Mario / Italy zone 2 (mainland)
> 40003 --> Monte Mario / Italy zone 1 (Sardegna)
> 40004 --> Monte Mario / Italy zone 2 (Sicily)
> in modo tale da avere l'1 o il 2 finale che richiama la zona (fuso) nei
> primi due casi, il 3 e il 4 finale che richiama il 3003 e il 3004 (come
> Andrea osserva) negli ultimi due.
>
> ciao
> Antonio
>
> --
> Antonio Falciano
> http://www.linkedin.com/in/antoniofalciano
>
> _______________________________________________
> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
> [hidden email]
> 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

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[aborruso]

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

[Antonio Falciano]

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 approfitto per ribadire la mia proposta: trattandosi di CRS e di
trasformazioni derivanti dal database EPSG, sarebbe piu' corretto
combinare insieme il codice del CRS e quello della trasformazione.

30031660 --> Monte Mario / Italy zone 1 (mainland)
30041660 --> Monte Mario / Italy zone 2 (mainland)
30031662 --> Monte Mario / Italy zone 1 (Sardegna)
30041664 --> Monte Mario / Italy zone 2 (Sicily)

ed eventualmente anche

230321133 --> ED50 / UTM zone 32N (with params)
230331133 --> ED50 / UTM zone 33N (with params)

Non mi sembra che siano difficili da memorizzare e, inoltre, hanno una
logica coerente con la loro provenienza.

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?

Il 28/05/2011 11.56, andrea antonello ha scritto:

> 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

Nel vs caso, 30031002 e 30041001 non hanno granche' senso, essendo la
Sardegna nel fuso Ovest (3003) e la Sicilia in quello Est (3004). ;-)

> prendendo i parametro da GRASS, che i parametri li ha.

...e che sempre da EPSG provengono! ;-)

> Allora abbiamo preso dei codici aggiungendo i 1000 dietro e sembrava
> una buona idea, ma sarei contento di adattarci se si decide per dei
> codici comuni.

Vediamo cosa ne pensano gli utilizzatori di altre applicazioni.

ciao
Antonio

> Andrea
>
>
>
> 2011/5/28 Antonio Falciano<[hidden email]>:
>> 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.
>> IMHO, l'assegnazione di questi codici poteva essere ottimizzata dal
>> principio. Ad esempio, si sarebbe potuto procedere cosi':
>> 40001 -->  Monte Mario / Italy zone 1 (mainland)
>> 40002 -->  Monte Mario / Italy zone 2 (mainland)
>> 40003 -->  Monte Mario / Italy zone 1 (Sardegna)
>> 40004 -->  Monte Mario / Italy zone 2 (Sicily)
>> in modo tale da avere l'1 o il 2 finale che richiama la zona (fuso) nei
>> primi due casi, il 3 e il 4 finale che richiama il 3003 e il 3004 (come
>> Andrea osserva) negli ultimi due.
>>
>> ciao
>> Antonio
>>
>> --
>> Antonio Falciano
>> http://www.linkedin.com/in/antoniofalciano
>>
>> _______________________________________________
>> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
>> [hidden email]
>> 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
> _______________________________________________
> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
> [hidden email]
> 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

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

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[Antonio Falciano]

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 e
ha una procedura guidata che filtra anche per area di interesse.
Oh ragassi... siam matti? :-) Dovremmo stare qui a parlare di grigliati
NTv2 "liberi" (visto che ora anche QGIS ha il suo plugin), mentre invece
stiamo ancora discutendo su come standardizzare il nome dei CRS, vi pare?

ciao
Antonio

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

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[Sandro Santilli]

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' usato come auth_name per il 900913 (l'unico non-epsg).
Mi sembra una buona idea riferirsi a spatialreferencing.org, dove
si possono trovare anche maggiori informazioni sulla proiezione.
E' un community effort, iniziativa di hobu e crschmidt, se non sbaglio.

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[Giovanni Manghi]

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
[hidden email]
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

[Andrea Peri]

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  non
avrebbe alcuna chance di vederselo riconosciuto da
alcuno. E poi non trattandosi di sistemi di riferimento universalmente
gestiti finirebbe in un angolo.

Occorre stare attenti a non cascare nel equivoco che fino ad oggi veniva
rinfacciato ai softwares commerciali,
altrimenti si predica bene e si razzola male....

se introducete dei sistemi di riferimento che nei softwares commerciali
non sono supportati sperando con questo di costringere l'utente a
legarsi ancora di piu' al software
GFOss perche' unico che li supporta,
otterrete l'effetto opposto.

Ovvero di essere esclusi perche' i softwares "danno i numeri".

E poi nel mondo dei sistemi di riferimento da usare a breve avverrà un
cambiamento,
come potete leggere in queste pagine.

http://www.digitpa.gov.it/altre-attivit%C3%A0/sistema-di-riferimento-geodetico-nazionale

In particolare questo documento:
http://www.digitpa.gov.it/sites/default/files/normativa/SIstema%20geodetico%20DPCM%201_0.pdf

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 altri...

Andrea.

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[Antonio Falciano]

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 ad usare "spatialreferencing.org".
> E' usato come auth_name per il 900913 (l'unico non-epsg).
> Mi sembra una buona idea riferirsi a spatialreferencing.org, dove
> si possono trovare anche maggiori informazioni sulla proiezione.
> E' un community effort, iniziativa di hobu e crschmidt, se non sbaglio.

"spatialreference.org" e' un gran bel servizio. Tuttavia, se cerco ad
esempio 900913 [1] mi offre una serie di codici custom compatibili e no
con la sua originaria definizione, il che non e' poi tanto un indice di
elevata attendibilita'. Oggi comunque 900913 continua ad esistere nel db
EPSG [2], solo che dopo varie vicissitudini ha cambiato denominazione:
e' diventato EPSG:3857.

ciao
Antonio

[1] http://spatialreference.org/ref/?search=900913
[2] http://www.epsg-registry.org/

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

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[Antonio Falciano]

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 realizzare un archivio usando tale nuovo sistema  non
> avrebbe alcuna chance di vederselo riconosciuto da
> alcuno. E poi non trattandosi di sistemi di riferimento universalmente
> gestiti finirebbe in un angolo.
>
> Occorre stare attenti a non cascare nel equivoco che fino ad oggi
> veniva rinfacciato ai softwares commerciali,
> altrimenti si predica bene e si razzola male....
>
> se introducete dei sistemi di riferimento che nei softwares
> commerciali non sono supportati sperando con questo di costringere
> l'utente a legarsi ancora di piu' al software
> GFOss perche' unico che li supporta,
> otterrete l'effetto opposto.
>
> Ovvero di essere esclusi perche' i softwares "danno i numeri".

Ottima questione! Si era partiti dalla correzione di un CRS
personalizzato presente solo in QGIS, e' emerso poi che anche uDig
utilizza dei codici suoi e il rischio giustamente e' quello di avere una
babele di codici inutilizzabili in altre applicazioni e quindi fuori
standard.
Personalmente la vedo cosi': non si puo' lavorare con l'informazione
geografica senza comprendere quello che ci sta dietro, in primis i
sistemi cartografici. Tutto qua. Se poi ognuno di noi ha bisogno di
scorciatoie, sono fatti suoi.

>
> E poi nel mondo dei sistemi di riferimento da usare a breve avverrà un
> cambiamento,
> come potete leggere in queste pagine.
>
> http://www.digitpa.gov.it/altre-attivit%C3%A0/sistema-di-riferimento-geodetico-nazionale 
>
>
> In particolare questo documento:
> http://www.digitpa.gov.it/sites/default/files/normativa/SIstema%20geodetico%20DPCM%201_0.pdf 
>
>
> 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.

Benissimo! E' di questo che dovremmo parlare.

> Io eviterei di incasinare il discorso inventandosene degli altri...

D'accordissimo con te. Il mio voleva essere solo un tentativo di
uniformare quantomeno le cose. Giustamente gli standard ufficiali fanno
testo e occorrerebbe utilizzare solo quelli. Penso che sia stato un
veramente un bene discuterne. E qui chiudo.

buon fine settimana
Antonio

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

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[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.
E' stato "spacciato" come EPSG da proj4 perche' (ahime') la specifica
WMS non supporta altro che "epsg" come nome di autority..

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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