[Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis server/Lizmap

Giro qui una domanda fatta a Cavallini e parzialmente risposta con suggerimento di discuterne in lista.

Ho un dubbio sui sistemi di coordinate che devo usare per catalogare i dati e poi servirli sul web.

Il nostro sistema di coordinate ufficiale italiano (fuso est) dovrebbe essere il 3045 (o 25833 non proprio corretto)

Questo è quanto emerso in questa discussione

https://groups.google.com/d/msg/qgis_utenti_fvg/84rUcjoqWOY/O5W1UwfaScUJ

Corretto?

Il datum di entrambi i sistemi sopra dovrebbe essere ETRS_1989 sferoide GRS_1980

A volte qui in regione si usa il 32633 che ha come datum/sferoide wgs84.

L’estensione in longitudine è la medesima, cambia quella in latitudine

3045 è 12.0000, 35.5000, 18.0000, 75.0000

32633 è 12.0000, 0.0000, 18.0000, 84.0000

La rototraslazione del ETRS_1989 su wgs84 è 0 per tutti i parametri.

La differenza dei due elissoidi è un decimo di millimetro sul semiasse maggiore.

Le differenze in coordinate alle nostre lat/long sono nell’ordine di 3-5cm

Messa così è una inezia… pochi centimetri, e sugli applicativi desktop la traslazione tra un sistema ed un altro non dovrebbe essere impegnativa.

Ma pensando al fatto che poi un certo numero di strati li devo mettere su web usando Qgis-server (lizmap) mi chiedo come è più opportuno trattare i dati.

In Lizmap il sistema di coordinate è quello impostato nel progetto di Qgis che sta sotto all’applicativo web e che viene letto da QGis-Server

Se io nel progetto metto più strati con sistemi di coordinate diverse immagino che il server impieghi tempo/processore a proiettarli al volo per generare le tiles.

Nel momento in cui vengono caricati gli strati di sfondo (Google/Bing/OSM) aggiungo sistemi di coordinate, tra cui il 3857 (che datum usa??), immagino che di mezzo ci stiano dei calcoli…

Più calcoli sono da fare minore sarà la prestazione del server cartografico…

Ammesso che lo stoccaggio del dato ufficiale immagino sia da fare in 3045 per allinearci allo standard nostro regionale, come conviene proiettare i dati da dare a Qgis-Server?

Conviene usare il 32633? Se il 3857 è simile al 3395 (world mercator), se usano lo stesso datum (wgs84)… i tempi di calcolo dovrebbero essere minori nel mettere assieme gli strati durante la riproiezione al volo se uso il 32633…

Se uso strati di sfondo con epsg 3857 conviene salvare il progetto direttamente in quel sistema di coordinate??

Che dite?

Grazie

Pietro

Ti rispondo alla prima parte della tua domanda:

Il 2 luglio 2015 14:53, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Giro qui una domanda fatta a Cavallini e parzialmente risposta con
suggerimento di discuterne in lista.

Ho un dubbio sui sistemi di coordinate che devo usare per catalogare i dati
e poi servirli sul web.

Il nostro sistema di coordinate ufficiale italiano (fuso est) dovrebbe
essere il 3045 (o 25833 non proprio corretto)

Cosa intendi per ufficiale ?

L'attuale (ad oggi) sistema ufficiale in Italia che sapessi io e' il
nuovissimo epsg:6707 e dintorni.

http://lists.gfoss.it/pipermail/gfoss/2014-March/031997.html

Prima di questo , noi in RT ad esempio usavamo il GaussBoaga (epsg:3003),
Il nuovo 6707 , ancora non e' stato recepito dai softwares come QGIS
(altri si, ma qgis ancora no)

Per cui non si puo' usare.

In attesa di poterlo usare facciamo ricorso all' epsg:25832 (RT e'
dall'altro lato rispetto al FVG)

Purtroppo per un baco delle definizioni prj usate da qgis ,
qando qgis apre un file con una definizione prj epsg:25832 lo confonde
con l' epsg:3044 (vado a memoria) e quindi imposta tale sistema come
riferimento del dataset.

Tra epsg:25832 e epsg:3044 cambia solamente l'ordine di esplicitazione
delle coordinate xy in un caso e yx nell'altro.

Saluti,

A.

Questo è quanto emerso in questa discussione

https://groups.google.com/d/msg/qgis_utenti_fvg/84rUcjoqWOY/O5W1UwfaScUJ

Corretto?

Il datum di entrambi i sistemi sopra dovrebbe essere ETRS_1989 sferoide
GRS_1980

A volte qui in regione si usa il 32633 che ha come datum/sferoide wgs84.

L’estensione in longitudine è la medesima, cambia quella in latitudine

3045 è 12.0000, 35.5000, 18.0000, 75.0000

32633 è 12.0000, 0.0000, 18.0000, 84.0000

La rototraslazione del ETRS_1989 su wgs84 è 0 per tutti i parametri.

La differenza dei due elissoidi è un decimo di millimetro sul semiasse
maggiore.

Le differenze in coordinate alle nostre lat/long sono nell’ordine di 3-5cm

Messa così è una inezia.. pochi centimetri, e sugli applicativi desktop la
traslazione tra un sistema ed un altro non dovrebbe essere impegnativa.

Ma pensando al fatto che poi un certo numero di strati li devo mettere su
web usando Qgis-server (lizmap) mi chiedo come è più opportuno trattare i
dati.

In Lizmap il sistema di coordinate è quello impostato nel progetto di Qgis
che sta sotto all’applicativo web e che viene letto da QGis-Server

Se io nel progetto metto più strati con sistemi di coordinate diverse
immagino che il server impieghi tempo/processore a proiettarli al volo per
generare le tiles.

Nel momento in cui vengono caricati gli strati di sfondo (Google/Bing/OSM)
aggiungo sistemi di coordinate, tra cui il 3857 (che datum usa??), immagino
che di mezzo ci stiano dei calcoli..

Più calcoli sono da fare minore sarà la prestazione del server
cartografico..

Ammesso che lo stoccaggio del dato ufficiale immagino sia da fare in 3045
per allinearci allo standard nostro regionale, come conviene proiettare i
dati da dare a Qgis-Server?

Conviene usare il 32633? Se il 3857 è simile al 3395 (world mercator), se
usano lo stesso datum (wgs84).. i tempi di calcolo dovrebbero essere minori
nel mettere assieme gli strati durante la riproiezione al volo se uso il
32633..

Se uso strati di sfondo con epsg 3857 conviene salvare il progetto
direttamente in quel sistema di coordinate??

Che dite?

Grazie

Pietro

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel
messaggio o nei suoi allegati. Se non siete i destinatari indicati nel
messaggio, o responsabili per la sua consegna alla persona, o se avete
ricevuto il messaggio per errore, siete pregati di non trascriverlo,
copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il
messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential
information may be contained in this message or in its attachments. If you
are not the addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in error,
you may not transcribe, copy or deliver this message to anyone. In that
case, you should delete this message and its attachments. Thank you.

_______________________________________________
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.
750 iscritti al 18.3.2015

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

Altri numeri ancora...

EPSG 3045 (ETRS89-TM33)
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

6706 RDN2008
        +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
6707 RDN2008 / TM32
        +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
6708 RDN2008 / TM33
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

Volendo fare un confronto tra 3045 e 6708 che è quello definite ufficiale in metri fuso 33, cosa cambia???

p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:33
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis server/Lizmap

Ti rispondo alla prima parte della tua domanda:

Il 2 luglio 2015 14:53, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Giro qui una domanda fatta a Cavallini e parzialmente risposta con
suggerimento di discuterne in lista.

Ho un dubbio sui sistemi di coordinate che devo usare per catalogare i
dati e poi servirli sul web.

Il nostro sistema di coordinate ufficiale italiano (fuso est) dovrebbe
essere il 3045 (o 25833 non proprio corretto)

Cosa intendi per ufficiale ?

L'attuale (ad oggi) sistema ufficiale in Italia che sapessi io e' il nuovissimo epsg:6707 e dintorni.

http://lists.gfoss.it/pipermail/gfoss/2014-March/031997.html

Prima di questo , noi in RT ad esempio usavamo il GaussBoaga (epsg:3003), Il nuovo 6707 , ancora non e' stato recepito dai softwares come QGIS (altri si, ma qgis ancora no)

Per cui non si puo' usare.

In attesa di poterlo usare facciamo ricorso all' epsg:25832 (RT e'
dall'altro lato rispetto al FVG)

Purtroppo per un baco delle definizioni prj usate da qgis , qando qgis apre un file con una definizione prj epsg:25832 lo confonde con l' epsg:3044 (vado a memoria) e quindi imposta tale sistema come riferimento del dataset.

Tra epsg:25832 e epsg:3044 cambia solamente l'ordine di esplicitazione delle coordinate xy in un caso e yx nell'altro.

Saluti,

A.

Questo è quanto emerso in questa discussione

https://groups.google.com/d/msg/qgis_utenti_fvg/84rUcjoqWOY/O5W1UwfaSc
UJ

Corretto?

Il datum di entrambi i sistemi sopra dovrebbe essere ETRS_1989 sferoide
GRS_1980

A volte qui in regione si usa il 32633 che ha come datum/sferoide wgs84.

L’estensione in longitudine è la medesima, cambia quella in latitudine

3045 è 12.0000, 35.5000, 18.0000, 75.0000

32633 è 12.0000, 0.0000, 18.0000, 84.0000

La rototraslazione del ETRS_1989 su wgs84 è 0 per tutti i parametri.

La differenza dei due elissoidi è un decimo di millimetro sul semiasse
maggiore.

Le differenze in coordinate alle nostre lat/long sono nell’ordine di
3-5cm

Messa così è una inezia.. pochi centimetri, e sugli applicativi
desktop la traslazione tra un sistema ed un altro non dovrebbe essere impegnativa.

Ma pensando al fatto che poi un certo numero di strati li devo mettere
su web usando Qgis-server (lizmap) mi chiedo come è più opportuno
trattare i dati.

In Lizmap il sistema di coordinate è quello impostato nel progetto di
Qgis che sta sotto all’applicativo web e che viene letto da
QGis-Server

Se io nel progetto metto più strati con sistemi di coordinate diverse
immagino che il server impieghi tempo/processore a proiettarli al volo
per generare le tiles.

Nel momento in cui vengono caricati gli strati di sfondo
(Google/Bing/OSM) aggiungo sistemi di coordinate, tra cui il 3857 (che
datum usa??), immagino che di mezzo ci stiano dei calcoli..

Più calcoli sono da fare minore sarà la prestazione del server
cartografico..

Ammesso che lo stoccaggio del dato ufficiale immagino sia da fare in
3045 per allinearci allo standard nostro regionale, come conviene
proiettare i dati da dare a Qgis-Server?

Conviene usare il 32633? Se il 3857 è simile al 3395 (world mercator),
se usano lo stesso datum (wgs84).. i tempi di calcolo dovrebbero
essere minori nel mettere assieme gli strati durante la riproiezione
al volo se uso il 32633..

Se uso strati di sfondo con epsg 3857 conviene salvare il progetto
direttamente in quel sistema di coordinate??

Che dite?

Grazie

Pietro

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute
nel messaggio o nei suoi allegati. Se non siete i destinatari indicati
nel messaggio, o responsabili per la sua consegna alla persona, o se
avete ricevuto il messaggio per errore, siete pregati di non
trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo
a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY
NOTICE Confidential information may be contained in this message or in
its attachments. If you are not the addressee indicated in this
message, or responsible for message delivering to that person, or if
you have received this message in error, you may not transcribe, copy
or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

_______________________________________________
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.
750 iscritti al 18.3.2015

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

Se vuoi sapere cosa cambia non devi basarti solo sull' prj, ma devi
consultare il db dell'epsg.
Vai qui:

http://www.epsg.org/

click su "online registry"
selezioni retrieve by code e digiti
prima 6708 e poi 3045

e poi click su view.

Li' trovi tutte ledifferenze tra i due.

Intanto l'area di impiego e' differente.

6708 e' su italia, mentre 3045 e' su germania.
Il resto va confrontato punto per punto, ma io non mi porrei troppi problemi .

Quando qgis e gli altri software supporteranno 6707 e dintorni ,
quelli andranno usati.
Nel frattempo , si puo' usare (noialmeno) epsg:25832
che come area di impiego copre l'europa con coordinate che inglobano
anche l'italia.

Ovviamento il bacone di qgis che sostituisce a 25832 il 3044 e' una
cosa che crea sicuramente problemi, ma poco ci si puo' fare, cosi' e'
e cosi' ci si deve tenere.
Perche' l'errore deriva da come qgis gestisce la memorizzazione dei
sistemi di riferimento dentro i progetti.

Saluti,

A.

Il 2 luglio 2015 15:42, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Altri numeri ancora...

EPSG 3045 (ETRS89-TM33)
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

6706 RDN2008
        +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
6707 RDN2008 / TM32
        +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
6708 RDN2008 / TM33
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

Volendo fare un confronto tra 3045 e 6708 che è quello definite ufficiale in metri fuso 33, cosa cambia???

p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:33
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis server/Lizmap

Ti rispondo alla prima parte della tua domanda:

Il 2 luglio 2015 14:53, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Giro qui una domanda fatta a Cavallini e parzialmente risposta con
suggerimento di discuterne in lista.

Ho un dubbio sui sistemi di coordinate che devo usare per catalogare i
dati e poi servirli sul web.

Il nostro sistema di coordinate ufficiale italiano (fuso est) dovrebbe
essere il 3045 (o 25833 non proprio corretto)

Cosa intendi per ufficiale ?

L'attuale (ad oggi) sistema ufficiale in Italia che sapessi io e' il nuovissimo epsg:6707 e dintorni.

http://lists.gfoss.it/pipermail/gfoss/2014-March/031997.html

Prima di questo , noi in RT ad esempio usavamo il GaussBoaga (epsg:3003), Il nuovo 6707 , ancora non e' stato recepito dai softwares come QGIS (altri si, ma qgis ancora no)

Per cui non si puo' usare.

In attesa di poterlo usare facciamo ricorso all' epsg:25832 (RT e'
dall'altro lato rispetto al FVG)

Purtroppo per un baco delle definizioni prj usate da qgis , qando qgis apre un file con una definizione prj epsg:25832 lo confonde con l' epsg:3044 (vado a memoria) e quindi imposta tale sistema come riferimento del dataset.

Tra epsg:25832 e epsg:3044 cambia solamente l'ordine di esplicitazione delle coordinate xy in un caso e yx nell'altro.

Saluti,

A.

Questo è quanto emerso in questa discussione

https://groups.google.com/d/msg/qgis_utenti_fvg/84rUcjoqWOY/O5W1UwfaSc
UJ

Corretto?

Il datum di entrambi i sistemi sopra dovrebbe essere ETRS_1989 sferoide
GRS_1980

A volte qui in regione si usa il 32633 che ha come datum/sferoide wgs84.

L’estensione in longitudine è la medesima, cambia quella in latitudine

3045 è 12.0000, 35.5000, 18.0000, 75.0000

32633 è 12.0000, 0.0000, 18.0000, 84.0000

La rototraslazione del ETRS_1989 su wgs84 è 0 per tutti i parametri.

La differenza dei due elissoidi è un decimo di millimetro sul semiasse
maggiore.

Le differenze in coordinate alle nostre lat/long sono nell’ordine di
3-5cm

Messa così è una inezia.. pochi centimetri, e sugli applicativi
desktop la traslazione tra un sistema ed un altro non dovrebbe essere impegnativa.

Ma pensando al fatto che poi un certo numero di strati li devo mettere
su web usando Qgis-server (lizmap) mi chiedo come è più opportuno
trattare i dati.

In Lizmap il sistema di coordinate è quello impostato nel progetto di
Qgis che sta sotto all’applicativo web e che viene letto da
QGis-Server

Se io nel progetto metto più strati con sistemi di coordinate diverse
immagino che il server impieghi tempo/processore a proiettarli al volo
per generare le tiles.

Nel momento in cui vengono caricati gli strati di sfondo
(Google/Bing/OSM) aggiungo sistemi di coordinate, tra cui il 3857 (che
datum usa??), immagino che di mezzo ci stiano dei calcoli..

Più calcoli sono da fare minore sarà la prestazione del server
cartografico..

Ammesso che lo stoccaggio del dato ufficiale immagino sia da fare in
3045 per allinearci allo standard nostro regionale, come conviene
proiettare i dati da dare a Qgis-Server?

Conviene usare il 32633? Se il 3857 è simile al 3395 (world mercator),
se usano lo stesso datum (wgs84).. i tempi di calcolo dovrebbero
essere minori nel mettere assieme gli strati durante la riproiezione
al volo se uso il 32633..

Se uso strati di sfondo con epsg 3857 conviene salvare il progetto
direttamente in quel sistema di coordinate??

Che dite?

Grazie

Pietro

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute
nel messaggio o nei suoi allegati. Se non siete i destinatari indicati
nel messaggio, o responsabili per la sua consegna alla persona, o se
avete ricevuto il messaggio per errore, siete pregati di non
trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo
a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY
NOTICE Confidential information may be contained in this message or in
its attachments. If you are not the addressee indicated in this
message, or responsible for message delivering to that person, or if
you have received this message in error, you may not transcribe, copy
or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

_______________________________________________
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.
750 iscritti al 18.3.2015

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

Vabbè, data un'occhiata non mi sembra vi siano delle differenze sostanziali, a parte la decisione di usare i due codici in aree diverse dell'europa
In termini pratici mi sembra che il 6708 sia un sotto insieme del 3045, così come il 6706 mi sembra il ritaglio del 4258 su un'area più piccola (Ilalia)
Ma caratteristiche dell'elissoide e punti di emanazione non cambiano da quanto ho capito..

Bai de uei
Risolto il baco su Qgis per cui andremo a scegliere il 6708, resta la parte qgis-server.
Che sistema di coordinate mi conviene scegliere avendo tra i layer anche strati tipo OSM o Google
A livello webgis non interessa tanto l'accuratezza topologica, interessa piuttosto la velocità di resa..

Grazie!
p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:52
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis server/Lizmap

Se vuoi sapere cosa cambia non devi basarti solo sull' prj, ma devi consultare il db dell'epsg.
Vai qui:

http://www.epsg.org/

click su "online registry"
selezioni retrieve by code e digiti
prima 6708 e poi 3045

e poi click su view.

Li' trovi tutte ledifferenze tra i due.

Intanto l'area di impiego e' differente.

6708 e' su italia, mentre 3045 e' su germania.
Il resto va confrontato punto per punto, ma io non mi porrei troppi problemi .

Quando qgis e gli altri software supporteranno 6707 e dintorni , quelli andranno usati.
Nel frattempo , si puo' usare (noialmeno) epsg:25832 che come area di impiego copre l'europa con coordinate che inglobano anche l'italia.

Ovviamento il bacone di qgis che sostituisce a 25832 il 3044 e' una cosa che crea sicuramente problemi, ma poco ci si puo' fare, cosi' e'
e cosi' ci si deve tenere.
Perche' l'errore deriva da come qgis gestisce la memorizzazione dei sistemi di riferimento dentro i progetti.

Saluti,

A.

Il 2 luglio 2015 15:42, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Altri numeri ancora...

EPSG 3045 (ETRS89-TM33)
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

6706 RDN2008
        +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
6707 RDN2008 / TM32
        +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
6708 RDN2008 / TM33
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

Volendo fare un confronto tra 3045 e 6708 che è quello definite ufficiale in metri fuso 33, cosa cambia???

p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:33
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Ti rispondo alla prima parte della tua domanda:

Il 2 luglio 2015 14:53, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Giro qui una domanda fatta a Cavallini e parzialmente risposta con
suggerimento di discuterne in lista.

Ho un dubbio sui sistemi di coordinate che devo usare per catalogare
i dati e poi servirli sul web.

Il nostro sistema di coordinate ufficiale italiano (fuso est)
dovrebbe essere il 3045 (o 25833 non proprio corretto)

Cosa intendi per ufficiale ?

L'attuale (ad oggi) sistema ufficiale in Italia che sapessi io e' il nuovissimo epsg:6707 e dintorni.

http://lists.gfoss.it/pipermail/gfoss/2014-March/031997.html

Prima di questo , noi in RT ad esempio usavamo il GaussBoaga
(epsg:3003), Il nuovo 6707 , ancora non e' stato recepito dai
softwares come QGIS (altri si, ma qgis ancora no)

Per cui non si puo' usare.

In attesa di poterlo usare facciamo ricorso all' epsg:25832 (RT e'
dall'altro lato rispetto al FVG)

Purtroppo per un baco delle definizioni prj usate da qgis , qando qgis apre un file con una definizione prj epsg:25832 lo confonde con l' epsg:3044 (vado a memoria) e quindi imposta tale sistema come riferimento del dataset.

Tra epsg:25832 e epsg:3044 cambia solamente l'ordine di esplicitazione delle coordinate xy in un caso e yx nell'altro.

Saluti,

A.

Questo è quanto emerso in questa discussione

https://groups.google.com/d/msg/qgis_utenti_fvg/84rUcjoqWOY/O5W1UwfaS
c
UJ

Corretto?

Il datum di entrambi i sistemi sopra dovrebbe essere ETRS_1989 sferoide
GRS_1980

A volte qui in regione si usa il 32633 che ha come datum/sferoide wgs84.

L’estensione in longitudine è la medesima, cambia quella in
latitudine

3045 è 12.0000, 35.5000, 18.0000, 75.0000

32633 è 12.0000, 0.0000, 18.0000, 84.0000

La rototraslazione del ETRS_1989 su wgs84 è 0 per tutti i parametri.

La differenza dei due elissoidi è un decimo di millimetro sul
semiasse maggiore.

Le differenze in coordinate alle nostre lat/long sono nell’ordine di
3-5cm

Messa così è una inezia.. pochi centimetri, e sugli applicativi
desktop la traslazione tra un sistema ed un altro non dovrebbe essere impegnativa.

Ma pensando al fatto che poi un certo numero di strati li devo
mettere su web usando Qgis-server (lizmap) mi chiedo come è più
opportuno trattare i dati.

In Lizmap il sistema di coordinate è quello impostato nel progetto di
Qgis che sta sotto all’applicativo web e che viene letto da
QGis-Server

Se io nel progetto metto più strati con sistemi di coordinate diverse
immagino che il server impieghi tempo/processore a proiettarli al
volo per generare le tiles.

Nel momento in cui vengono caricati gli strati di sfondo
(Google/Bing/OSM) aggiungo sistemi di coordinate, tra cui il 3857
(che datum usa??), immagino che di mezzo ci stiano dei calcoli..

Più calcoli sono da fare minore sarà la prestazione del server
cartografico..

Ammesso che lo stoccaggio del dato ufficiale immagino sia da fare in
3045 per allinearci allo standard nostro regionale, come conviene
proiettare i dati da dare a Qgis-Server?

Conviene usare il 32633? Se il 3857 è simile al 3395 (world
mercator), se usano lo stesso datum (wgs84).. i tempi di calcolo
dovrebbero essere minori nel mettere assieme gli strati durante la
riproiezione al volo se uso il 32633..

Se uso strati di sfondo con epsg 3857 conviene salvare il progetto
direttamente in quel sistema di coordinate??

Che dite?

Grazie

Pietro

AVVISO DI RISERVATEZZA Informazioni riservate possono essere
contenute nel messaggio o nei suoi allegati. Se non siete i
destinatari indicati nel messaggio, o responsabili per la sua
consegna alla persona, o se avete ricevuto il messaggio per errore,
siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In
tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati.
Grazie. CONFIDENTIALITY NOTICE Confidential information may be
contained in this message or in its attachments. If you are not the
addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in
error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

_______________________________________________
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.
750 iscritti al 18.3.2015

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

Per avere velocita' occorre che ti richiedano i dati nel sistema di
riferimento nativo in cui sono i tuoi dati.

Se vuoi essere veloce, basta che fissi su qgis-server un solo sistema
di riferimento, escludendo la possibilia' che ti chiedano mapp in
qalsiasi altro sistema diriferimento.

Ovviamente se i tuoi dati sono nel 3044, vuol dire che chi usa i tuoi
wms potr' avere dati solo in 3044.
Ci vuole usarli per sovrapporli ad altri dati in altri sistemi, non
potra' falro, oppure fa' conversioni lui locali, che pero' facendole
senza grigliati (a differenza di te sul server) soffrira' un errore
diche puo' andare da 10 a 50 metri tipicamente.

Se ammetti che possano richiederle anche in altri sisyem, allora sar'a
piu' lento perche' deve convertirle.

A.

Il 2 luglio 2015 16:18, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Vabbè, data un'occhiata non mi sembra vi siano delle differenze sostanziali, a parte la decisione di usare i due codici in aree diverse dell'europa
In termini pratici mi sembra che il 6708 sia un sotto insieme del 3045, così come il 6706 mi sembra il ritaglio del 4258 su un'area più piccola (Ilalia)
Ma caratteristiche dell'elissoide e punti di emanazione non cambiano da quanto ho capito..

Bai de uei
Risolto il baco su Qgis per cui andremo a scegliere il 6708, resta la parte qgis-server.
Che sistema di coordinate mi conviene scegliere avendo tra i layer anche strati tipo OSM o Google
A livello webgis non interessa tanto l'accuratezza topologica, interessa piuttosto la velocità di resa..

Grazie!
p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:52
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis server/Lizmap

Se vuoi sapere cosa cambia non devi basarti solo sull' prj, ma devi consultare il db dell'epsg.
Vai qui:

http://www.epsg.org/

click su "online registry"
selezioni retrieve by code e digiti
prima 6708 e poi 3045

e poi click su view.

Li' trovi tutte ledifferenze tra i due.

Intanto l'area di impiego e' differente.

6708 e' su italia, mentre 3045 e' su germania.
Il resto va confrontato punto per punto, ma io non mi porrei troppi problemi .

Quando qgis e gli altri software supporteranno 6707 e dintorni , quelli andranno usati.
Nel frattempo , si puo' usare (noialmeno) epsg:25832 che come area di impiego copre l'europa con coordinate che inglobano anche l'italia.

Ovviamento il bacone di qgis che sostituisce a 25832 il 3044 e' una cosa che crea sicuramente problemi, ma poco ci si puo' fare, cosi' e'
e cosi' ci si deve tenere.
Perche' l'errore deriva da come qgis gestisce la memorizzazione dei sistemi di riferimento dentro i progetti.

Saluti,

A.

Il 2 luglio 2015 15:42, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Altri numeri ancora...

EPSG 3045 (ETRS89-TM33)
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

6706 RDN2008
        +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
6707 RDN2008 / TM32
        +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
6708 RDN2008 / TM33
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

Volendo fare un confronto tra 3045 e 6708 che è quello definite ufficiale in metri fuso 33, cosa cambia???

p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:33
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Ti rispondo alla prima parte della tua domanda:

Il 2 luglio 2015 14:53, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Giro qui una domanda fatta a Cavallini e parzialmente risposta con
suggerimento di discuterne in lista.

Ho un dubbio sui sistemi di coordinate che devo usare per catalogare
i dati e poi servirli sul web.

Il nostro sistema di coordinate ufficiale italiano (fuso est)
dovrebbe essere il 3045 (o 25833 non proprio corretto)

Cosa intendi per ufficiale ?

L'attuale (ad oggi) sistema ufficiale in Italia che sapessi io e' il nuovissimo epsg:6707 e dintorni.

http://lists.gfoss.it/pipermail/gfoss/2014-March/031997.html

Prima di questo , noi in RT ad esempio usavamo il GaussBoaga
(epsg:3003), Il nuovo 6707 , ancora non e' stato recepito dai
softwares come QGIS (altri si, ma qgis ancora no)

Per cui non si puo' usare.

In attesa di poterlo usare facciamo ricorso all' epsg:25832 (RT e'
dall'altro lato rispetto al FVG)

Purtroppo per un baco delle definizioni prj usate da qgis , qando qgis apre un file con una definizione prj epsg:25832 lo confonde con l' epsg:3044 (vado a memoria) e quindi imposta tale sistema come riferimento del dataset.

Tra epsg:25832 e epsg:3044 cambia solamente l'ordine di esplicitazione delle coordinate xy in un caso e yx nell'altro.

Saluti,

A.

Questo è quanto emerso in questa discussione

https://groups.google.com/d/msg/qgis_utenti_fvg/84rUcjoqWOY/O5W1UwfaS
c
UJ

Corretto?

Il datum di entrambi i sistemi sopra dovrebbe essere ETRS_1989 sferoide
GRS_1980

A volte qui in regione si usa il 32633 che ha come datum/sferoide wgs84.

L’estensione in longitudine è la medesima, cambia quella in
latitudine

3045 è 12.0000, 35.5000, 18.0000, 75.0000

32633 è 12.0000, 0.0000, 18.0000, 84.0000

La rototraslazione del ETRS_1989 su wgs84 è 0 per tutti i parametri.

La differenza dei due elissoidi è un decimo di millimetro sul
semiasse maggiore.

Le differenze in coordinate alle nostre lat/long sono nell’ordine di
3-5cm

Messa così è una inezia.. pochi centimetri, e sugli applicativi
desktop la traslazione tra un sistema ed un altro non dovrebbe essere impegnativa.

Ma pensando al fatto che poi un certo numero di strati li devo
mettere su web usando Qgis-server (lizmap) mi chiedo come è più
opportuno trattare i dati.

In Lizmap il sistema di coordinate è quello impostato nel progetto di
Qgis che sta sotto all’applicativo web e che viene letto da
QGis-Server

Se io nel progetto metto più strati con sistemi di coordinate diverse
immagino che il server impieghi tempo/processore a proiettarli al
volo per generare le tiles.

Nel momento in cui vengono caricati gli strati di sfondo
(Google/Bing/OSM) aggiungo sistemi di coordinate, tra cui il 3857
(che datum usa??), immagino che di mezzo ci stiano dei calcoli..

Più calcoli sono da fare minore sarà la prestazione del server
cartografico..

Ammesso che lo stoccaggio del dato ufficiale immagino sia da fare in
3045 per allinearci allo standard nostro regionale, come conviene
proiettare i dati da dare a Qgis-Server?

Conviene usare il 32633? Se il 3857 è simile al 3395 (world
mercator), se usano lo stesso datum (wgs84).. i tempi di calcolo
dovrebbero essere minori nel mettere assieme gli strati durante la
riproiezione al volo se uso il 32633..

Se uso strati di sfondo con epsg 3857 conviene salvare il progetto
direttamente in quel sistema di coordinate??

Che dite?

Grazie

Pietro

AVVISO DI RISERVATEZZA Informazioni riservate possono essere
contenute nel messaggio o nei suoi allegati. Se non siete i
destinatari indicati nel messaggio, o responsabili per la sua
consegna alla persona, o se avete ricevuto il messaggio per errore,
siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In
tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati.
Grazie. CONFIDENTIALITY NOTICE Confidential information may be
contained in this message or in its attachments. If you are not the
addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in
error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

_______________________________________________
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.
750 iscritti al 18.3.2015

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

A livello di webgis (Lizmap) non credo si possa operare una scelta di sistema di coordinate..
Quindi io di solito per rendere il sistema funzionale uso il 3045 (dati nel mio archivio) il 3857 (Google) ed il 4326 (wgs84)

Solo che mi chiedevo, lascio così e mescolo strati a sistemi di coordinata differente o magari i miei dati da 3045 me li riproietto con viste materializzate e li carico ad esempio in 3857 di modo che non vi siano calcoli per la riproiezione al volo??

P

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 16:29
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis server/Lizmap

Per avere velocita' occorre che ti richiedano i dati nel sistema di riferimento nativo in cui sono i tuoi dati.

Se vuoi essere veloce, basta che fissi su qgis-server un solo sistema di riferimento, escludendo la possibilia' che ti chiedano mapp in qalsiasi altro sistema diriferimento.

Ovviamente se i tuoi dati sono nel 3044, vuol dire che chi usa i tuoi wms potr' avere dati solo in 3044.
Ci vuole usarli per sovrapporli ad altri dati in altri sistemi, non potra' falro, oppure fa' conversioni lui locali, che pero' facendole senza grigliati (a differenza di te sul server) soffrira' un errore diche puo' andare da 10 a 50 metri tipicamente.

Se ammetti che possano richiederle anche in altri sisyem, allora sar'a piu' lento perche' deve convertirle.

A.

Il 2 luglio 2015 16:18, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Vabbè, data un'occhiata non mi sembra vi siano delle differenze
sostanziali, a parte la decisione di usare i due codici in aree
diverse dell'europa In termini pratici mi sembra che il 6708 sia un sotto insieme del 3045, così come il 6706 mi sembra il ritaglio del 4258 su un'area più piccola (Ilalia) Ma caratteristiche dell'elissoide e punti di emanazione non cambiano da quanto ho capito..

Bai de uei
Risolto il baco su Qgis per cui andremo a scegliere il 6708, resta la parte qgis-server.
Che sistema di coordinate mi conviene scegliere avendo tra i layer
anche strati tipo OSM o Google A livello webgis non interessa tanto l'accuratezza topologica, interessa piuttosto la velocità di resa..

Grazie!
p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:52
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Se vuoi sapere cosa cambia non devi basarti solo sull' prj, ma devi consultare il db dell'epsg.
Vai qui:

http://www.epsg.org/

click su "online registry"
selezioni retrieve by code e digiti
prima 6708 e poi 3045

e poi click su view.

Li' trovi tutte ledifferenze tra i due.

Intanto l'area di impiego e' differente.

6708 e' su italia, mentre 3045 e' su germania.
Il resto va confrontato punto per punto, ma io non mi porrei troppi problemi .

Quando qgis e gli altri software supporteranno 6707 e dintorni , quelli andranno usati.
Nel frattempo , si puo' usare (noialmeno) epsg:25832 che come area di impiego copre l'europa con coordinate che inglobano anche l'italia.

Ovviamento il bacone di qgis che sostituisce a 25832 il 3044 e' una cosa che crea sicuramente problemi, ma poco ci si puo' fare, cosi' e'
e cosi' ci si deve tenere.
Perche' l'errore deriva da come qgis gestisce la memorizzazione dei sistemi di riferimento dentro i progetti.

Saluti,

A.

Il 2 luglio 2015 15:42, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Altri numeri ancora...

EPSG 3045 (ETRS89-TM33)
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

6706 RDN2008
        +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
6707 RDN2008 / TM32
        +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
6708 RDN2008 / TM33
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

Volendo fare un confronto tra 3045 e 6708 che è quello definite ufficiale in metri fuso 33, cosa cambia???

p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:33
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Ti rispondo alla prima parte della tua domanda:

Il 2 luglio 2015 14:53, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Giro qui una domanda fatta a Cavallini e parzialmente risposta con
suggerimento di discuterne in lista.

Ho un dubbio sui sistemi di coordinate che devo usare per catalogare
i dati e poi servirli sul web.

Il nostro sistema di coordinate ufficiale italiano (fuso est)
dovrebbe essere il 3045 (o 25833 non proprio corretto)

Cosa intendi per ufficiale ?

L'attuale (ad oggi) sistema ufficiale in Italia che sapessi io e' il nuovissimo epsg:6707 e dintorni.

http://lists.gfoss.it/pipermail/gfoss/2014-March/031997.html

Prima di questo , noi in RT ad esempio usavamo il GaussBoaga
(epsg:3003), Il nuovo 6707 , ancora non e' stato recepito dai
softwares come QGIS (altri si, ma qgis ancora no)

Per cui non si puo' usare.

In attesa di poterlo usare facciamo ricorso all' epsg:25832 (RT e'
dall'altro lato rispetto al FVG)

Purtroppo per un baco delle definizioni prj usate da qgis , qando qgis apre un file con una definizione prj epsg:25832 lo confonde con l' epsg:3044 (vado a memoria) e quindi imposta tale sistema come riferimento del dataset.

Tra epsg:25832 e epsg:3044 cambia solamente l'ordine di esplicitazione delle coordinate xy in un caso e yx nell'altro.

Saluti,

A.

Questo è quanto emerso in questa discussione

https://groups.google.com/d/msg/qgis_utenti_fvg/84rUcjoqWOY/O5W1Uwfa
S
c
UJ

Corretto?

Il datum di entrambi i sistemi sopra dovrebbe essere ETRS_1989 sferoide
GRS_1980

A volte qui in regione si usa il 32633 che ha come datum/sferoide wgs84.

L’estensione in longitudine è la medesima, cambia quella in
latitudine

3045 è 12.0000, 35.5000, 18.0000, 75.0000

32633 è 12.0000, 0.0000, 18.0000, 84.0000

La rototraslazione del ETRS_1989 su wgs84 è 0 per tutti i parametri.

La differenza dei due elissoidi è un decimo di millimetro sul
semiasse maggiore.

Le differenze in coordinate alle nostre lat/long sono nell’ordine di
3-5cm

Messa così è una inezia.. pochi centimetri, e sugli applicativi
desktop la traslazione tra un sistema ed un altro non dovrebbe essere impegnativa.

Ma pensando al fatto che poi un certo numero di strati li devo
mettere su web usando Qgis-server (lizmap) mi chiedo come è più
opportuno trattare i dati.

In Lizmap il sistema di coordinate è quello impostato nel progetto
di Qgis che sta sotto all’applicativo web e che viene letto da
QGis-Server

Se io nel progetto metto più strati con sistemi di coordinate
diverse immagino che il server impieghi tempo/processore a
proiettarli al volo per generare le tiles.

Nel momento in cui vengono caricati gli strati di sfondo
(Google/Bing/OSM) aggiungo sistemi di coordinate, tra cui il 3857
(che datum usa??), immagino che di mezzo ci stiano dei calcoli..

Più calcoli sono da fare minore sarà la prestazione del server
cartografico..

Ammesso che lo stoccaggio del dato ufficiale immagino sia da fare in
3045 per allinearci allo standard nostro regionale, come conviene
proiettare i dati da dare a Qgis-Server?

Conviene usare il 32633? Se il 3857 è simile al 3395 (world
mercator), se usano lo stesso datum (wgs84).. i tempi di calcolo
dovrebbero essere minori nel mettere assieme gli strati durante la
riproiezione al volo se uso il 32633..

Se uso strati di sfondo con epsg 3857 conviene salvare il progetto
direttamente in quel sistema di coordinate??

Che dite?

Grazie

Pietro

AVVISO DI RISERVATEZZA Informazioni riservate possono essere
contenute nel messaggio o nei suoi allegati. Se non siete i
destinatari indicati nel messaggio, o responsabili per la sua
consegna alla persona, o se avete ricevuto il messaggio per errore,
siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In
tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati.
Grazie. CONFIDENTIALITY NOTICE Confidential information may be
contained in this message or in its attachments. If you are not the
addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in
error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

_______________________________________________
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.
750 iscritti al 18.3.2015

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

Il problema non e' per i tuoi sistemi , ma per il client che accedera'
ail tuo server wms.

Se il client wms che puntera' il tuo wms server prevede la validazione
del sistema di rifeirmneto, rifiutera' le invocazioni di mappe sul FVG
perche' sa' che il 3044 non è valido al di fuori dell''area della germania.

se il client invece non fa' controlli sul srs allora chiamera'
qualsiasi cosa e in ogni e con ogni box gli si dica di chiamare.

Questo tipo di controllo non viene effettuto dai client web, stile
openlayer, ma bensj' e' roba piu' da sistemi desktop.

QGIS sicuramente non lo fa', ma qualcun' altro sono sicuro che lo fa'
perche' anni fa' mi ritrovai a gestire questo genere di problematiche.
All'epoca non sapevo perche' e come mai il software mi diceva che la
zona che invocavo su un tal sistema di riferimento non era valida nel
srs usato.
Poi lo scoprii.

Non ricordo che software era.

Comunque se il tuo obiettivo e' mettere in piedi un server wms per
supportare dei portali web che usano openlayer o sistemi di tale
genere probabilmente di questa cosa puoi disinteressarti.

A.

Il 2 luglio 2015 16:18, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Vabbè, data un'occhiata non mi sembra vi siano delle differenze sostanziali, a parte la decisione di usare i due codici in aree diverse dell'europa
In termini pratici mi sembra che il 6708 sia un sotto insieme del 3045, così come il 6706 mi sembra il ritaglio del 4258 su un'area più piccola (Ilalia)
Ma caratteristiche dell'elissoide e punti di emanazione non cambiano da quanto ho capito..

Bai de uei
Risolto il baco su Qgis per cui andremo a scegliere il 6708, resta la parte qgis-server.
Che sistema di coordinate mi conviene scegliere avendo tra i layer anche strati tipo OSM o Google
A livello webgis non interessa tanto l'accuratezza topologica, interessa piuttosto la velocità di resa..

Grazie!
p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:52
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis server/Lizmap

Se vuoi sapere cosa cambia non devi basarti solo sull' prj, ma devi consultare il db dell'epsg.
Vai qui:

http://www.epsg.org/

click su "online registry"
selezioni retrieve by code e digiti
prima 6708 e poi 3045

e poi click su view.

Li' trovi tutte ledifferenze tra i due.

Intanto l'area di impiego e' differente.

6708 e' su italia, mentre 3045 e' su germania.
Il resto va confrontato punto per punto, ma io non mi porrei troppi problemi .

Quando qgis e gli altri software supporteranno 6707 e dintorni , quelli andranno usati.
Nel frattempo , si puo' usare (noialmeno) epsg:25832 che come area di impiego copre l'europa con coordinate che inglobano anche l'italia.

Ovviamento il bacone di qgis che sostituisce a 25832 il 3044 e' una cosa che crea sicuramente problemi, ma poco ci si puo' fare, cosi' e'
e cosi' ci si deve tenere.
Perche' l'errore deriva da come qgis gestisce la memorizzazione dei sistemi di riferimento dentro i progetti.

Saluti,

A.

Il 2 luglio 2015 15:42, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Altri numeri ancora...

EPSG 3045 (ETRS89-TM33)
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

6706 RDN2008
        +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
6707 RDN2008 / TM32
        +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
6708 RDN2008 / TM33
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

Volendo fare un confronto tra 3045 e 6708 che è quello definite ufficiale in metri fuso 33, cosa cambia???

p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:33
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Ti rispondo alla prima parte della tua domanda:

Il 2 luglio 2015 14:53, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Giro qui una domanda fatta a Cavallini e parzialmente risposta con
suggerimento di discuterne in lista.

Ho un dubbio sui sistemi di coordinate che devo usare per catalogare
i dati e poi servirli sul web.

Il nostro sistema di coordinate ufficiale italiano (fuso est)
dovrebbe essere il 3045 (o 25833 non proprio corretto)

Cosa intendi per ufficiale ?

L'attuale (ad oggi) sistema ufficiale in Italia che sapessi io e' il nuovissimo epsg:6707 e dintorni.

http://lists.gfoss.it/pipermail/gfoss/2014-March/031997.html

Prima di questo , noi in RT ad esempio usavamo il GaussBoaga
(epsg:3003), Il nuovo 6707 , ancora non e' stato recepito dai
softwares come QGIS (altri si, ma qgis ancora no)

Per cui non si puo' usare.

In attesa di poterlo usare facciamo ricorso all' epsg:25832 (RT e'
dall'altro lato rispetto al FVG)

Purtroppo per un baco delle definizioni prj usate da qgis , qando qgis apre un file con una definizione prj epsg:25832 lo confonde con l' epsg:3044 (vado a memoria) e quindi imposta tale sistema come riferimento del dataset.

Tra epsg:25832 e epsg:3044 cambia solamente l'ordine di esplicitazione delle coordinate xy in un caso e yx nell'altro.

Saluti,

A.

Questo è quanto emerso in questa discussione

https://groups.google.com/d/msg/qgis_utenti_fvg/84rUcjoqWOY/O5W1UwfaS
c
UJ

Corretto?

Il datum di entrambi i sistemi sopra dovrebbe essere ETRS_1989 sferoide
GRS_1980

A volte qui in regione si usa il 32633 che ha come datum/sferoide wgs84.

L’estensione in longitudine è la medesima, cambia quella in
latitudine

3045 è 12.0000, 35.5000, 18.0000, 75.0000

32633 è 12.0000, 0.0000, 18.0000, 84.0000

La rototraslazione del ETRS_1989 su wgs84 è 0 per tutti i parametri.

La differenza dei due elissoidi è un decimo di millimetro sul
semiasse maggiore.

Le differenze in coordinate alle nostre lat/long sono nell’ordine di
3-5cm

Messa così è una inezia.. pochi centimetri, e sugli applicativi
desktop la traslazione tra un sistema ed un altro non dovrebbe essere impegnativa.

Ma pensando al fatto che poi un certo numero di strati li devo
mettere su web usando Qgis-server (lizmap) mi chiedo come è più
opportuno trattare i dati.

In Lizmap il sistema di coordinate è quello impostato nel progetto di
Qgis che sta sotto all’applicativo web e che viene letto da
QGis-Server

Se io nel progetto metto più strati con sistemi di coordinate diverse
immagino che il server impieghi tempo/processore a proiettarli al
volo per generare le tiles.

Nel momento in cui vengono caricati gli strati di sfondo
(Google/Bing/OSM) aggiungo sistemi di coordinate, tra cui il 3857
(che datum usa??), immagino che di mezzo ci stiano dei calcoli..

Più calcoli sono da fare minore sarà la prestazione del server
cartografico..

Ammesso che lo stoccaggio del dato ufficiale immagino sia da fare in
3045 per allinearci allo standard nostro regionale, come conviene
proiettare i dati da dare a Qgis-Server?

Conviene usare il 32633? Se il 3857 è simile al 3395 (world
mercator), se usano lo stesso datum (wgs84).. i tempi di calcolo
dovrebbero essere minori nel mettere assieme gli strati durante la
riproiezione al volo se uso il 32633..

Se uso strati di sfondo con epsg 3857 conviene salvare il progetto
direttamente in quel sistema di coordinate??

Che dite?

Grazie

Pietro

AVVISO DI RISERVATEZZA Informazioni riservate possono essere
contenute nel messaggio o nei suoi allegati. Se non siete i
destinatari indicati nel messaggio, o responsabili per la sua
consegna alla persona, o se avete ricevuto il messaggio per errore,
siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In
tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati.
Grazie. CONFIDENTIALITY NOTICE Confidential information may be
contained in this message or in its attachments. If you are not the
addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in
error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

_______________________________________________
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.
750 iscritti al 18.3.2015

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

On conosco lizmap come client e quindi non so dirti.

In merito al tuo sistema, e' rilevante mettercene 1 solo o piu' di uno
se ilproblema e' legato solo al tuo portale.
Perche' la velocita' e'sulla chiamata.

Te puoi mettercene anche piu' di uno.
Poi se la chiamata la farai in sistema nativo sara' piu' rapido, se la
farai in altro sistema sara' piu' lento perche' deve riproiettare al
volo.

Se ammetti altri srs faciliti l'utilizzo a eventuali utenti esterni
che puntano sul tuo wms.

Per te non e' rilevante in merito al tuo portale.

Certo che se hai i dati in 3044 e fai un portale in altro sistema di
riferimento, allora te la cerchi...
:slight_smile:

Il 2 luglio 2015 16:35, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

A livello di webgis (Lizmap) non credo si possa operare una scelta di sistema di coordinate..
Quindi io di solito per rendere il sistema funzionale uso il 3045 (dati nel mio archivio) il 3857 (Google) ed il 4326 (wgs84)

Solo che mi chiedevo, lascio così e mescolo strati a sistemi di coordinata differente o magari i miei dati da 3045 me li riproietto con viste materializzate e li carico ad esempio in 3857 di modo che non vi siano calcoli per la riproiezione al volo??

P

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 16:29
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis server/Lizmap

Per avere velocita' occorre che ti richiedano i dati nel sistema di riferimento nativo in cui sono i tuoi dati.

Se vuoi essere veloce, basta che fissi su qgis-server un solo sistema di riferimento, escludendo la possibilia' che ti chiedano mapp in qalsiasi altro sistema diriferimento.

Ovviamente se i tuoi dati sono nel 3044, vuol dire che chi usa i tuoi wms potr' avere dati solo in 3044.
Ci vuole usarli per sovrapporli ad altri dati in altri sistemi, non potra' falro, oppure fa' conversioni lui locali, che pero' facendole senza grigliati (a differenza di te sul server) soffrira' un errore diche puo' andare da 10 a 50 metri tipicamente.

Se ammetti che possano richiederle anche in altri sisyem, allora sar'a piu' lento perche' deve convertirle.

A.

Il 2 luglio 2015 16:18, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Vabbè, data un'occhiata non mi sembra vi siano delle differenze
sostanziali, a parte la decisione di usare i due codici in aree
diverse dell'europa In termini pratici mi sembra che il 6708 sia un sotto insieme del 3045, così come il 6706 mi sembra il ritaglio del 4258 su un'area più piccola (Ilalia) Ma caratteristiche dell'elissoide e punti di emanazione non cambiano da quanto ho capito..

Bai de uei
Risolto il baco su Qgis per cui andremo a scegliere il 6708, resta la parte qgis-server.
Che sistema di coordinate mi conviene scegliere avendo tra i layer
anche strati tipo OSM o Google A livello webgis non interessa tanto l'accuratezza topologica, interessa piuttosto la velocità di resa..

Grazie!
p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:52
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Se vuoi sapere cosa cambia non devi basarti solo sull' prj, ma devi consultare il db dell'epsg.
Vai qui:

http://www.epsg.org/

click su "online registry"
selezioni retrieve by code e digiti
prima 6708 e poi 3045

e poi click su view.

Li' trovi tutte ledifferenze tra i due.

Intanto l'area di impiego e' differente.

6708 e' su italia, mentre 3045 e' su germania.
Il resto va confrontato punto per punto, ma io non mi porrei troppi problemi .

Quando qgis e gli altri software supporteranno 6707 e dintorni , quelli andranno usati.
Nel frattempo , si puo' usare (noialmeno) epsg:25832 che come area di impiego copre l'europa con coordinate che inglobano anche l'italia.

Ovviamento il bacone di qgis che sostituisce a 25832 il 3044 e' una cosa che crea sicuramente problemi, ma poco ci si puo' fare, cosi' e'
e cosi' ci si deve tenere.
Perche' l'errore deriva da come qgis gestisce la memorizzazione dei sistemi di riferimento dentro i progetti.

Saluti,

A.

Il 2 luglio 2015 15:42, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Altri numeri ancora...

EPSG 3045 (ETRS89-TM33)
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

6706 RDN2008
        +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
6707 RDN2008 / TM32
        +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
6708 RDN2008 / TM33
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

Volendo fare un confronto tra 3045 e 6708 che è quello definite ufficiale in metri fuso 33, cosa cambia???

p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:33
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Ti rispondo alla prima parte della tua domanda:

Il 2 luglio 2015 14:53, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Giro qui una domanda fatta a Cavallini e parzialmente risposta con
suggerimento di discuterne in lista.

Ho un dubbio sui sistemi di coordinate che devo usare per catalogare
i dati e poi servirli sul web.

Il nostro sistema di coordinate ufficiale italiano (fuso est)
dovrebbe essere il 3045 (o 25833 non proprio corretto)

Cosa intendi per ufficiale ?

L'attuale (ad oggi) sistema ufficiale in Italia che sapessi io e' il nuovissimo epsg:6707 e dintorni.

http://lists.gfoss.it/pipermail/gfoss/2014-March/031997.html

Prima di questo , noi in RT ad esempio usavamo il GaussBoaga
(epsg:3003), Il nuovo 6707 , ancora non e' stato recepito dai
softwares come QGIS (altri si, ma qgis ancora no)

Per cui non si puo' usare.

In attesa di poterlo usare facciamo ricorso all' epsg:25832 (RT e'
dall'altro lato rispetto al FVG)

Purtroppo per un baco delle definizioni prj usate da qgis , qando qgis apre un file con una definizione prj epsg:25832 lo confonde con l' epsg:3044 (vado a memoria) e quindi imposta tale sistema come riferimento del dataset.

Tra epsg:25832 e epsg:3044 cambia solamente l'ordine di esplicitazione delle coordinate xy in un caso e yx nell'altro.

Saluti,

A.

Questo è quanto emerso in questa discussione

https://groups.google.com/d/msg/qgis_utenti_fvg/84rUcjoqWOY/O5W1Uwfa
S
c
UJ

Corretto?

Il datum di entrambi i sistemi sopra dovrebbe essere ETRS_1989 sferoide
GRS_1980

A volte qui in regione si usa il 32633 che ha come datum/sferoide wgs84.

L’estensione in longitudine è la medesima, cambia quella in
latitudine

3045 è 12.0000, 35.5000, 18.0000, 75.0000

32633 è 12.0000, 0.0000, 18.0000, 84.0000

La rototraslazione del ETRS_1989 su wgs84 è 0 per tutti i parametri.

La differenza dei due elissoidi è un decimo di millimetro sul
semiasse maggiore.

Le differenze in coordinate alle nostre lat/long sono nell’ordine di
3-5cm

Messa così è una inezia.. pochi centimetri, e sugli applicativi
desktop la traslazione tra un sistema ed un altro non dovrebbe essere impegnativa.

Ma pensando al fatto che poi un certo numero di strati li devo
mettere su web usando Qgis-server (lizmap) mi chiedo come è più
opportuno trattare i dati.

In Lizmap il sistema di coordinate è quello impostato nel progetto
di Qgis che sta sotto all’applicativo web e che viene letto da
QGis-Server

Se io nel progetto metto più strati con sistemi di coordinate
diverse immagino che il server impieghi tempo/processore a
proiettarli al volo per generare le tiles.

Nel momento in cui vengono caricati gli strati di sfondo
(Google/Bing/OSM) aggiungo sistemi di coordinate, tra cui il 3857
(che datum usa??), immagino che di mezzo ci stiano dei calcoli..

Più calcoli sono da fare minore sarà la prestazione del server
cartografico..

Ammesso che lo stoccaggio del dato ufficiale immagino sia da fare in
3045 per allinearci allo standard nostro regionale, come conviene
proiettare i dati da dare a Qgis-Server?

Conviene usare il 32633? Se il 3857 è simile al 3395 (world
mercator), se usano lo stesso datum (wgs84).. i tempi di calcolo
dovrebbero essere minori nel mettere assieme gli strati durante la
riproiezione al volo se uso il 32633..

Se uso strati di sfondo con epsg 3857 conviene salvare il progetto
direttamente in quel sistema di coordinate??

Che dite?

Grazie

Pietro

AVVISO DI RISERVATEZZA Informazioni riservate possono essere
contenute nel messaggio o nei suoi allegati. Se non siete i
destinatari indicati nel messaggio, o responsabili per la sua
consegna alla persona, o se avete ricevuto il messaggio per errore,
siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In
tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati.
Grazie. CONFIDENTIALITY NOTICE Confidential information may be
contained in this message or in its attachments. If you are not the
addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in
error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

_______________________________________________
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.
750 iscritti al 18.3.2015

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

Lizmap ha qgis server sotto usato come fast cgi.
I miei dati li ho in 3045 ed il progetto lo salvo in 3045. Solo che poi in lizmap aggiungo layer di sfondo in 3857.
Quindi… boh!
Farò delle prove a questo punto

Sent by MailWise – Your emails, with style.:slight_smile:

-------- Messaggio originale --------
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis server/Lizmap
Da: Andrea Peri aperi2007@gmail.com
A: Rossin Pietro pietro.rossin@arpa.fvg.it
CC: gfoss@lists.gfoss.it

On conosco lizmap come client e quindi non so dirti.

In merito al tuo sistema, e’ rilevante mettercene 1 solo o piu’ di uno
se ilproblema e’ legato solo al tuo portale.
Perche’ la velocita’ e’sulla chiamata.

Te puoi mettercene anche piu’ di uno.
Poi se la chiamata la farai in sistema nativo sara’ piu’ rapido, se la
farai in altro sistema sara’ piu’ lento perche’ deve riproiettare al
volo.

Se ammetti altri srs faciliti l’utilizzo a eventuali utenti esterni
che puntano sul tuo wms.

Per te non e’ rilevante in merito al tuo portale.

Certo che se hai i dati in 3044 e fai un portale in altro sistema di
riferimento, allora te la cerchi…
:slight_smile:

Il 2 luglio 2015 16:35, Rossin Pietro pietro.rossin@arpa.fvg.it ha scritto:

A livello di webgis (Lizmap) non credo si possa operare una scelta di sistema di coordinate…
Quindi io di solito per rendere il sistema funzionale uso il 3045 (dati nel mio archivio) il 3857 (Google) ed il 4326 (wgs84)

Solo che mi chiedevo, lascio così e mescolo strati a sistemi di coordinata differente o magari i miei dati da 3045 me li riproietto con viste materializzate e li carico ad esempio in 3857 di modo che non vi siano calcoli per la riproiezione al volo??

P

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 16:29
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis server/Lizmap

Per avere velocita’ occorre che ti richiedano i dati nel sistema di riferimento nativo in cui sono i tuoi dati.

Se vuoi essere veloce, basta che fissi su qgis-server un solo sistema di riferimento, escludendo la possibilia’ che ti chiedano mapp in qalsiasi altro sistema diriferimento.

Ovviamente se i tuoi dati sono nel 3044, vuol dire che chi usa i tuoi wms potr’ avere dati solo in 3044.
Ci vuole usarli per sovrapporli ad altri dati in altri sistemi, non potra’ falro, oppure fa’ conversioni lui locali, che pero’ facendole senza grigliati (a differenza di te sul server) soffrira’ un errore diche puo’ andare da 10 a 50 metri tipicamente.

Se ammetti che possano richiederle anche in altri sisyem, allora sar’a piu’ lento perche’ deve convertirle.

A.

Il 2 luglio 2015 16:18, Rossin Pietro pietro.rossin@arpa.fvg.it ha scritto:

Vabbè, data un’occhiata non mi sembra vi siano delle differenze
sostanziali, a parte la decisione di usare i due codici in aree
diverse dell’europa In termini pratici mi sembra che il 6708 sia un sotto insieme del 3045, così come il 6706 mi sembra il ritaglio del 4258 su un’area più piccola (Ilalia) Ma caratteristiche dell’elissoide e punti di emanazione non cambiano da quanto ho capito…

Bai de uei
Risolto il baco su Qgis per cui andremo a scegliere il 6708, resta la parte qgis-server.
Che sistema di coordinate mi conviene scegliere avendo tra i layer
anche strati tipo OSM o Google A livello webgis non interessa tanto l’accuratezza topologica, interessa piuttosto la velocità di resa…

Grazie!
p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:52
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Se vuoi sapere cosa cambia non devi basarti solo sull’ prj, ma devi consultare il db dell’epsg.
Vai qui:

http://www.epsg.org/

click su “online registry”
selezioni retrieve by code e digiti
prima 6708 e poi 3045

e poi click su view.

Li’ trovi tutte ledifferenze tra i due.

Intanto l’area di impiego e’ differente.

6708 e’ su italia, mentre 3045 e’ su germania.
Il resto va confrontato punto per punto, ma io non mi porrei troppi problemi .

Quando qgis e gli altri software supporteranno 6707 e dintorni , quelli andranno usati.
Nel frattempo , si puo’ usare (noialmeno) epsg:25832 che come area di impiego copre l’europa con coordinate che inglobano anche l’italia.

Ovviamento il bacone di qgis che sostituisce a 25832 il 3044 e’ una cosa che crea sicuramente problemi, ma poco ci si puo’ fare, cosi’ e’
e cosi’ ci si deve tenere.
Perche’ l’errore deriva da come qgis gestisce la memorizzazione dei sistemi di riferimento dentro i progetti.

Saluti,

A.

Il 2 luglio 2015 15:42, Rossin Pietro pietro.rossin@arpa.fvg.it ha scritto:

Altri numeri ancora…

EPSG 3045 (ETRS89-TM33)
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

6706 RDN2008
+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
6707 RDN2008 / TM32
+proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
6708 RDN2008 / TM33
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

Volendo fare un confronto tra 3045 e 6708 che è quello definite ufficiale in metri fuso 33, cosa cambia???

p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:33
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Ti rispondo alla prima parte della tua domanda:

Il 2 luglio 2015 14:53, Rossin Pietro pietro.rossin@arpa.fvg.it ha scritto:

Giro qui una domanda fatta a Cavallini e parzialmente risposta con
suggerimento di discuterne in lista.

Ho un dubbio sui sistemi di coordinate che devo usare per catalogare
i dati e poi servirli sul web.

Il nostro sistema di coordinate ufficiale italiano (fuso est)
dovrebbe essere il 3045 (o 25833 non proprio corretto)

Cosa intendi per ufficiale ?

L’attuale (ad oggi) sistema ufficiale in Italia che sapessi io e’ il nuovissimo epsg:6707 e dintorni.

http://lists.gfoss.it/pipermail/gfoss/2014-March/031997.html

Prima di questo , noi in RT ad esempio usavamo il GaussBoaga
(epsg:3003), Il nuovo 6707 , ancora non e’ stato recepito dai
softwares come QGIS (altri si, ma qgis ancora no)

Per cui non si puo’ usare.

In attesa di poterlo usare facciamo ricorso all’ epsg:25832 (RT e’
dall’altro lato rispetto al FVG)

Purtroppo per un baco delle definizioni prj usate da qgis , qando qgis apre un file con una definizione prj epsg:25832 lo confonde con l’ epsg:3044 (vado a memoria) e quindi imposta tale sistema come riferimento del dataset.

Tra epsg:25832 e epsg:3044 cambia solamente l’ordine di esplicitazione delle coordinate xy in un caso e yx nell’altro.

Saluti,

A.

Questo è quanto emerso in questa discussione

https://groups.google.com/d/msg/qgis_utenti_fvg/84rUcjoqWOY/O5W1Uwfa
S
c
UJ

Corretto?

Il datum di entrambi i sistemi sopra dovrebbe essere ETRS_1989 sferoide
GRS_1980

A volte qui in regione si usa il 32633 che ha come datum/sferoide wgs84.

L’estensione in longitudine è la medesima, cambia quella in
latitudine

3045 è 12.0000, 35.5000, 18.0000, 75.0000

32633 è 12.0000, 0.0000, 18.0000, 84.0000

La rototraslazione del ETRS_1989 su wgs84 è 0 per tutti i parametri.

La differenza dei due elissoidi è un decimo di millimetro sul
semiasse maggiore.

Le differenze in coordinate alle nostre lat/long sono nell’ordine di
3-5cm

Messa così è una inezia… pochi centimetri, e sugli applicativi
desktop la traslazione tra un sistema ed un altro non dovrebbe essere impegnativa.

Ma pensando al fatto che poi un certo numero di strati li devo
mettere su web usando Qgis-server (lizmap) mi chiedo come è più
opportuno trattare i dati.

In Lizmap il sistema di coordinate è quello impostato nel progetto
di Qgis che sta sotto all’applicativo web e che viene letto da
QGis-Server

Se io nel progetto metto più strati con sistemi di coordinate
diverse immagino che il server impieghi tempo/processore a
proiettarli al volo per generare le tiles.

Nel momento in cui vengono caricati gli strati di sfondo
(Google/Bing/OSM) aggiungo sistemi di coordinate, tra cui il 3857
(che datum usa??), immagino che di mezzo ci stiano dei calcoli…

Più calcoli sono da fare minore sarà la prestazione del server
cartografico…

Ammesso che lo stoccaggio del dato ufficiale immagino sia da fare in
3045 per allinearci allo standard nostro regionale, come conviene
proiettare i dati da dare a Qgis-Server?

Conviene usare il 32633? Se il 3857 è simile al 3395 (world
mercator), se usano lo stesso datum (wgs84)… i tempi di calcolo
dovrebbero essere minori nel mettere assieme gli strati durante la
riproiezione al volo se uso il 32633…

Se uso strati di sfondo con epsg 3857 conviene salvare il progetto
direttamente in quel sistema di coordinate??

Che dite?

Grazie

Pietro

AVVISO DI RISERVATEZZA Informazioni riservate possono essere
contenute nel messaggio o nei suoi allegati. Se non siete i
destinatari indicati nel messaggio, o responsabili per la sua
consegna alla persona, o se avete ricevuto il messaggio per errore,
siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In
tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati.
Grazie. CONFIDENTIALITY NOTICE Confidential information may be
contained in this message or in its attachments. If you are not the
addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in
error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.


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.
750 iscritti al 18.3.2015

Andrea Peri
. . . . . . . . .
qwerty àèìòù

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

Andrea Peri
. . . . . . . . .
qwerty àèìòù

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

Andrea Peri
. . . . . . . . .
qwerty àèìòù

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

Andrea Peri
. . . . . . . . .
qwerty àèìòù

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

Messa in questi termini, non e' ottimale.

Perche' lascia presupporre che demandi a lizmap il compito di fre
cambio di sistema di riferimento e lizmap e' un client javascript che
sicuramente e' lento su queste operazioni e pure molto poco preciso.

Sei dati di sfondo in 3857 li prendi da una altra parte (es: OSM),
allora ti conviene sicuramente aggiungere
il SRS 3857 nella lista dei SRS forniti dal tuo qgis-server e fare una
richiesta anche dei tuoi in 3857.

Di piu' non posso dirti, visot che lizmap non loconosco.
Noi usiamo qgisserver ma lo puntimoa con un client wms puro (nel
nostro caso tolomeo, un framework sviluppato e mantenuto dal comune di
prato)

Tolomeo non fa' cambi al volo di sistemi di riferimento e quindi
giocoforza questo problema di mixing srs gestiti lato client non
esiste.

NAturalmente questo e' un difett dal punto di vista della
flessibilita' perche' non si puo' aggiungere a un portale wms che non
forniscano il srs previsto nel prtale.

Nel vostro caso lizmap se capisco bene invece questo e' possibile.
ero' io cercherei comunque di tenere tutto piu' preciso possibile e
quindi userei il srs del sistema OSM.
Questo ti garantirebbe maggiore precisione.

A.

Il 2 luglio 2015 17:40, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Lizmap ha qgis server sotto usato come fast cgi.
I miei dati li ho in 3045 ed il progetto lo salvo in 3045. Solo che poi in
lizmap aggiungo layer di sfondo in 3857.
Quindi.. boh!
Farò delle prove a questo punto

Sent by MailWise – Your emails, with style.:slight_smile:

-------- Messaggio originale --------
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap
Da: Andrea Peri <aperi2007@gmail.com>
A: Rossin Pietro <pietro.rossin@arpa.fvg.it>
CC: gfoss@lists.gfoss.it

On conosco lizmap come client e quindi non so dirti.

In merito al tuo sistema, e' rilevante mettercene 1 solo o piu' di uno
se ilproblema e' legato solo al tuo portale.
Perche' la velocita' e'sulla chiamata.

Te puoi mettercene anche piu' di uno.
Poi se la chiamata la farai in sistema nativo sara' piu' rapido, se la
farai in altro sistema sara' piu' lento perche' deve riproiettare al
volo.

Se ammetti altri srs faciliti l'utilizzo a eventuali utenti esterni
che puntano sul tuo wms.

Per te non e' rilevante in merito al tuo portale.

Certo che se hai i dati in 3044 e fai un portale in altro sistema di
riferimento, allora te la cerchi...
:slight_smile:

Il 2 luglio 2015 16:35, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha
scritto:

A livello di webgis (Lizmap) non credo si possa operare una scelta di
sistema di coordinate..
Quindi io di solito per rendere il sistema funzionale uso il 3045 (dati
nel mio archivio) il 3857 (Google) ed il 4326 (wgs84)

Solo che mi chiedevo, lascio così e mescolo strati a sistemi di coordinata
differente o magari i miei dati da 3045 me li riproietto con viste
materializzate e li carico ad esempio in 3857 di modo che non vi siano
calcoli per la riproiezione al volo??

P

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 16:29
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Per avere velocita' occorre che ti richiedano i dati nel sistema di
riferimento nativo in cui sono i tuoi dati.

Se vuoi essere veloce, basta che fissi su qgis-server un solo sistema di
riferimento, escludendo la possibilia' che ti chiedano mapp in qalsiasi
altro sistema diriferimento.

Ovviamente se i tuoi dati sono nel 3044, vuol dire che chi usa i tuoi wms
potr' avere dati solo in 3044.
Ci vuole usarli per sovrapporli ad altri dati in altri sistemi, non potra'
falro, oppure fa' conversioni lui locali, che pero' facendole senza
grigliati (a differenza di te sul server) soffrira' un errore diche puo'
andare da 10 a 50 metri tipicamente.

Se ammetti che possano richiederle anche in altri sisyem, allora sar'a
piu' lento perche' deve convertirle.

A.

Il 2 luglio 2015 16:18, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha
scritto:

Vabbè, data un'occhiata non mi sembra vi siano delle differenze
sostanziali, a parte la decisione di usare i due codici in aree
diverse dell'europa In termini pratici mi sembra che il 6708 sia un sotto
insieme del 3045, così come il 6706 mi sembra il ritaglio del 4258 su
un'area più piccola (Ilalia) Ma caratteristiche dell'elissoide e punti di
emanazione non cambiano da quanto ho capito..

Bai de uei
Risolto il baco su Qgis per cui andremo a scegliere il 6708, resta la
parte qgis-server.
Che sistema di coordinate mi conviene scegliere avendo tra i layer
anche strati tipo OSM o Google A livello webgis non interessa tanto
l'accuratezza topologica, interessa piuttosto la velocità di resa..

Grazie!
p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:52
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Se vuoi sapere cosa cambia non devi basarti solo sull' prj, ma devi
consultare il db dell'epsg.
Vai qui:

http://www.epsg.org/

click su "online registry"
selezioni retrieve by code e digiti
prima 6708 e poi 3045

e poi click su view.

Li' trovi tutte ledifferenze tra i due.

Intanto l'area di impiego e' differente.

6708 e' su italia, mentre 3045 e' su germania.
Il resto va confrontato punto per punto, ma io non mi porrei troppi
problemi .

Quando qgis e gli altri software supporteranno 6707 e dintorni , quelli
andranno usati.
Nel frattempo , si puo' usare (noialmeno) epsg:25832 che come area di
impiego copre l'europa con coordinate che inglobano anche l'italia.

Ovviamento il bacone di qgis che sostituisce a 25832 il 3044 e' una cosa
che crea sicuramente problemi, ma poco ci si puo' fare, cosi' e'
e cosi' ci si deve tenere.
Perche' l'errore deriva da come qgis gestisce la memorizzazione dei
sistemi di riferimento dentro i progetti.

Saluti,

A.

Il 2 luglio 2015 15:42, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha
scritto:

Altri numeri ancora...

EPSG 3045 (ETRS89-TM33)
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

6706 RDN2008
        +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
6707 RDN2008 / TM32
        +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
+no_defs
6708 RDN2008 / TM33
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

Volendo fare un confronto tra 3045 e 6708 che è quello definite
ufficiale in metri fuso 33, cosa cambia???

p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:33
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Ti rispondo alla prima parte della tua domanda:

Il 2 luglio 2015 14:53, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha
scritto:

Giro qui una domanda fatta a Cavallini e parzialmente risposta con
suggerimento di discuterne in lista.

Ho un dubbio sui sistemi di coordinate che devo usare per catalogare
i dati e poi servirli sul web.

Il nostro sistema di coordinate ufficiale italiano (fuso est)
dovrebbe essere il 3045 (o 25833 non proprio corretto)

Cosa intendi per ufficiale ?

L'attuale (ad oggi) sistema ufficiale in Italia che sapessi io e' il
nuovissimo epsg:6707 e dintorni.

http://lists.gfoss.it/pipermail/gfoss/2014-March/031997.html

Prima di questo , noi in RT ad esempio usavamo il GaussBoaga
(epsg:3003), Il nuovo 6707 , ancora non e' stato recepito dai
softwares come QGIS (altri si, ma qgis ancora no)

Per cui non si puo' usare.

In attesa di poterlo usare facciamo ricorso all' epsg:25832 (RT e'
dall'altro lato rispetto al FVG)

Purtroppo per un baco delle definizioni prj usate da qgis , qando qgis
apre un file con una definizione prj epsg:25832 lo confonde con l' epsg:3044
(vado a memoria) e quindi imposta tale sistema come riferimento del dataset.

Tra epsg:25832 e epsg:3044 cambia solamente l'ordine di esplicitazione
delle coordinate xy in un caso e yx nell'altro.

Saluti,

A.

Questo è quanto emerso in questa discussione

https://groups.google.com/d/msg/qgis_utenti_fvg/84rUcjoqWOY/O5W1Uwfa
S
c
UJ

Corretto?

Il datum di entrambi i sistemi sopra dovrebbe essere ETRS_1989
sferoide
GRS_1980

A volte qui in regione si usa il 32633 che ha come datum/sferoide
wgs84.

L’estensione in longitudine è la medesima, cambia quella in
latitudine

3045 è 12.0000, 35.5000, 18.0000, 75.0000

32633 è 12.0000, 0.0000, 18.0000, 84.0000

La rototraslazione del ETRS_1989 su wgs84 è 0 per tutti i parametri.

La differenza dei due elissoidi è un decimo di millimetro sul
semiasse maggiore.

Le differenze in coordinate alle nostre lat/long sono nell’ordine di
3-5cm

Messa così è una inezia.. pochi centimetri, e sugli applicativi
desktop la traslazione tra un sistema ed un altro non dovrebbe essere
impegnativa.

Ma pensando al fatto che poi un certo numero di strati li devo
mettere su web usando Qgis-server (lizmap) mi chiedo come è più
opportuno trattare i dati.

In Lizmap il sistema di coordinate è quello impostato nel progetto
di Qgis che sta sotto all’applicativo web e che viene letto da
QGis-Server

Se io nel progetto metto più strati con sistemi di coordinate
diverse immagino che il server impieghi tempo/processore a
proiettarli al volo per generare le tiles.

Nel momento in cui vengono caricati gli strati di sfondo
(Google/Bing/OSM) aggiungo sistemi di coordinate, tra cui il 3857
(che datum usa??), immagino che di mezzo ci stiano dei calcoli..

Più calcoli sono da fare minore sarà la prestazione del server
cartografico..

Ammesso che lo stoccaggio del dato ufficiale immagino sia da fare in
3045 per allinearci allo standard nostro regionale, come conviene
proiettare i dati da dare a Qgis-Server?

Conviene usare il 32633? Se il 3857 è simile al 3395 (world
mercator), se usano lo stesso datum (wgs84).. i tempi di calcolo
dovrebbero essere minori nel mettere assieme gli strati durante la
riproiezione al volo se uso il 32633..

Se uso strati di sfondo con epsg 3857 conviene salvare il progetto
direttamente in quel sistema di coordinate??

Che dite?

Grazie

Pietro

AVVISO DI RISERVATEZZA Informazioni riservate possono essere
contenute nel messaggio o nei suoi allegati. Se non siete i
destinatari indicati nel messaggio, o responsabili per la sua
consegna alla persona, o se avete ricevuto il messaggio per errore,
siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In
tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati.
Grazie. CONFIDENTIALITY NOTICE Confidential information may be
contained in this message or in its attachments. If you are not the
addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in
error, you may not transcribe, copy or deliver this message to anyone.
In that case, you should delete this message and its attachments. Thank you.

_______________________________________________
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.
750 iscritti al 18.3.2015

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute
nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel
messaggio, o responsabili per la sua consegna alla persona, o se avete
ricevuto il messaggio per errore, siete pregati di non trascriverlo,
copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il
messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential
information may be contained in this message or in its attachments. If you
are not the addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in error,
you may not transcribe, copy or deliver this message to anyone. In that
case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute
nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel
messaggio, o responsabili per la sua consegna alla persona, o se avete
ricevuto il messaggio per errore, siete pregati di non trascriverlo,
copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il
messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential
information may be contained in this message or in its attachments. If you
are not the addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in error,
you may not transcribe, copy or deliver this message to anyone. In that
case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel
messaggio o nei suoi allegati. Se non siete i destinatari indicati nel
messaggio, o responsabili per la sua consegna alla persona, o se avete
ricevuto il messaggio per errore, siete pregati di non trascriverlo,
copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il
messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential
information may be contained in this message or in its attachments. If you
are not the addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in error,
you may not transcribe, copy or deliver this message to anyone. In that
case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel
messaggio o nei suoi allegati. Se non siete i destinatari indicati nel
messaggio, o responsabili per la sua consegna alla persona, o se avete
ricevuto il messaggio per errore, siete pregati di non trascriverlo,
copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il
messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential
information may be contained in this message or in its attachments. If you
are not the addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in error,
you may not transcribe, copy or deliver this message to anyone. In that
case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

Ok vediamo se Paolo Cavallini che conosce molto meglio di me il sistema ha qualche dettaglio in più…
Grazie mille per le spiegazioni
Buona serata
Pietro

Sent by MailWise – Your emails, with style.:slight_smile:

-------- Messaggio originale --------
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis server/Lizmap
Da: Andrea Peri aperi2007@gmail.com
A: Rossin Pietro pietro.rossin@arpa.fvg.it
CC: gfoss@lists.gfoss.it

Messa in questi termini, non e’ ottimale.

Perche’ lascia presupporre che demandi a lizmap il compito di fre
cambio di sistema di riferimento e lizmap e’ un client javascript che
sicuramente e’ lento su queste operazioni e pure molto poco preciso.

Sei dati di sfondo in 3857 li prendi da una altra parte (es: OSM),
allora ti conviene sicuramente aggiungere
il SRS 3857 nella lista dei SRS forniti dal tuo qgis-server e fare una
richiesta anche dei tuoi in 3857.

Di piu’ non posso dirti, visot che lizmap non loconosco.
Noi usiamo qgisserver ma lo puntimoa con un client wms puro (nel
nostro caso tolomeo, un framework sviluppato e mantenuto dal comune di
prato)

Tolomeo non fa’ cambi al volo di sistemi di riferimento e quindi
giocoforza questo problema di mixing srs gestiti lato client non
esiste.

NAturalmente questo e’ un difett dal punto di vista della
flessibilita’ perche’ non si puo’ aggiungere a un portale wms che non
forniscano il srs previsto nel prtale.

Nel vostro caso lizmap se capisco bene invece questo e’ possibile.
ero’ io cercherei comunque di tenere tutto piu’ preciso possibile e
quindi userei il srs del sistema OSM.
Questo ti garantirebbe maggiore precisione.

A.

Il 2 luglio 2015 17:40, Rossin Pietro pietro.rossin@arpa.fvg.it ha scritto:

Lizmap ha qgis server sotto usato come fast cgi.
I miei dati li ho in 3045 ed il progetto lo salvo in 3045. Solo che poi in
lizmap aggiungo layer di sfondo in 3857.
Quindi… boh!
Farò delle prove a questo punto

Sent by MailWise – Your emails, with style.:slight_smile:

-------- Messaggio originale --------
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap
Da: Andrea Peri aperi2007@gmail.com
A: Rossin Pietro pietro.rossin@arpa.fvg.it
CC: gfoss@lists.gfoss.it

On conosco lizmap come client e quindi non so dirti.

In merito al tuo sistema, e’ rilevante mettercene 1 solo o piu’ di uno
se ilproblema e’ legato solo al tuo portale.
Perche’ la velocita’ e’sulla chiamata.

Te puoi mettercene anche piu’ di uno.
Poi se la chiamata la farai in sistema nativo sara’ piu’ rapido, se la
farai in altro sistema sara’ piu’ lento perche’ deve riproiettare al
volo.

Se ammetti altri srs faciliti l’utilizzo a eventuali utenti esterni
che puntano sul tuo wms.

Per te non e’ rilevante in merito al tuo portale.

Certo che se hai i dati in 3044 e fai un portale in altro sistema di
riferimento, allora te la cerchi…
:slight_smile:

Il 2 luglio 2015 16:35, Rossin Pietro pietro.rossin@arpa.fvg.it ha
scritto:

A livello di webgis (Lizmap) non credo si possa operare una scelta di
sistema di coordinate…
Quindi io di solito per rendere il sistema funzionale uso il 3045 (dati
nel mio archivio) il 3857 (Google) ed il 4326 (wgs84)

Solo che mi chiedevo, lascio così e mescolo strati a sistemi di coordinata
differente o magari i miei dati da 3045 me li riproietto con viste
materializzate e li carico ad esempio in 3857 di modo che non vi siano
calcoli per la riproiezione al volo??

P

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 16:29
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Per avere velocita’ occorre che ti richiedano i dati nel sistema di
riferimento nativo in cui sono i tuoi dati.

Se vuoi essere veloce, basta che fissi su qgis-server un solo sistema di
riferimento, escludendo la possibilia’ che ti chiedano mapp in qalsiasi
altro sistema diriferimento.

Ovviamente se i tuoi dati sono nel 3044, vuol dire che chi usa i tuoi wms
potr’ avere dati solo in 3044.
Ci vuole usarli per sovrapporli ad altri dati in altri sistemi, non potra’
falro, oppure fa’ conversioni lui locali, che pero’ facendole senza
grigliati (a differenza di te sul server) soffrira’ un errore diche puo’
andare da 10 a 50 metri tipicamente.

Se ammetti che possano richiederle anche in altri sisyem, allora sar’a
piu’ lento perche’ deve convertirle.

A.

Il 2 luglio 2015 16:18, Rossin Pietro pietro.rossin@arpa.fvg.it ha
scritto:

Vabbè, data un’occhiata non mi sembra vi siano delle differenze
sostanziali, a parte la decisione di usare i due codici in aree
diverse dell’europa In termini pratici mi sembra che il 6708 sia un sotto
insieme del 3045, così come il 6706 mi sembra il ritaglio del 4258 su
un’area più piccola (Ilalia) Ma caratteristiche dell’elissoide e punti di
emanazione non cambiano da quanto ho capito…

Bai de uei
Risolto il baco su Qgis per cui andremo a scegliere il 6708, resta la
parte qgis-server.
Che sistema di coordinate mi conviene scegliere avendo tra i layer
anche strati tipo OSM o Google A livello webgis non interessa tanto
l’accuratezza topologica, interessa piuttosto la velocità di resa…

Grazie!
p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:52
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Se vuoi sapere cosa cambia non devi basarti solo sull’ prj, ma devi
consultare il db dell’epsg.
Vai qui:

http://www.epsg.org/

click su “online registry”
selezioni retrieve by code e digiti
prima 6708 e poi 3045

e poi click su view.

Li’ trovi tutte ledifferenze tra i due.

Intanto l’area di impiego e’ differente.

6708 e’ su italia, mentre 3045 e’ su germania.
Il resto va confrontato punto per punto, ma io non mi porrei troppi
problemi .

Quando qgis e gli altri software supporteranno 6707 e dintorni , quelli
andranno usati.
Nel frattempo , si puo’ usare (noialmeno) epsg:25832 che come area di
impiego copre l’europa con coordinate che inglobano anche l’italia.

Ovviamento il bacone di qgis che sostituisce a 25832 il 3044 e’ una cosa
che crea sicuramente problemi, ma poco ci si puo’ fare, cosi’ e’
e cosi’ ci si deve tenere.
Perche’ l’errore deriva da come qgis gestisce la memorizzazione dei
sistemi di riferimento dentro i progetti.

Saluti,

A.

Il 2 luglio 2015 15:42, Rossin Pietro pietro.rossin@arpa.fvg.it ha
scritto:

Altri numeri ancora…

EPSG 3045 (ETRS89-TM33)
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

6706 RDN2008
+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
6707 RDN2008 / TM32
+proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
+no_defs
6708 RDN2008 / TM33
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

Volendo fare un confronto tra 3045 e 6708 che è quello definite
ufficiale in metri fuso 33, cosa cambia???

p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:33
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Ti rispondo alla prima parte della tua domanda:

Il 2 luglio 2015 14:53, Rossin Pietro pietro.rossin@arpa.fvg.it ha
scritto:

Giro qui una domanda fatta a Cavallini e parzialmente risposta con
suggerimento di discuterne in lista.

Ho un dubbio sui sistemi di coordinate che devo usare per catalogare
i dati e poi servirli sul web.

Il nostro sistema di coordinate ufficiale italiano (fuso est)
dovrebbe essere il 3045 (o 25833 non proprio corretto)

Cosa intendi per ufficiale ?

L’attuale (ad oggi) sistema ufficiale in Italia che sapessi io e’ il
nuovissimo epsg:6707 e dintorni.

http://lists.gfoss.it/pipermail/gfoss/2014-March/031997.html

Prima di questo , noi in RT ad esempio usavamo il GaussBoaga
(epsg:3003), Il nuovo 6707 , ancora non e’ stato recepito dai
softwares come QGIS (altri si, ma qgis ancora no)

Per cui non si puo’ usare.

In attesa di poterlo usare facciamo ricorso all’ epsg:25832 (RT e’
dall’altro lato rispetto al FVG)

Purtroppo per un baco delle definizioni prj usate da qgis , qando qgis
apre un file con una definizione prj epsg:25832 lo confonde con l’ epsg:3044
(vado a memoria) e quindi imposta tale sistema come riferimento del dataset.

Tra epsg:25832 e epsg:3044 cambia solamente l’ordine di esplicitazione
delle coordinate xy in un caso e yx nell’altro.

Saluti,

A.

Questo è quanto emerso in questa discussione

https://groups.google.com/d/msg/qgis_utenti_fvg/84rUcjoqWOY/O5W1Uwfa
S
c
UJ

Corretto?

Il datum di entrambi i sistemi sopra dovrebbe essere ETRS_1989
sferoide
GRS_1980

A volte qui in regione si usa il 32633 che ha come datum/sferoide
wgs84.

L’estensione in longitudine è la medesima, cambia quella in
latitudine

3045 è 12.0000, 35.5000, 18.0000, 75.0000

32633 è 12.0000, 0.0000, 18.0000, 84.0000

La rototraslazione del ETRS_1989 su wgs84 è 0 per tutti i parametri.

La differenza dei due elissoidi è un decimo di millimetro sul
semiasse maggiore.

Le differenze in coordinate alle nostre lat/long sono nell’ordine di
3-5cm

Messa così è una inezia… pochi centimetri, e sugli applicativi
desktop la traslazione tra un sistema ed un altro non dovrebbe essere
impegnativa.

Ma pensando al fatto che poi un certo numero di strati li devo
mettere su web usando Qgis-server (lizmap) mi chiedo come è più
opportuno trattare i dati.

In Lizmap il sistema di coordinate è quello impostato nel progetto
di Qgis che sta sotto all’applicativo web e che viene letto da
QGis-Server

Se io nel progetto metto più strati con sistemi di coordinate
diverse immagino che il server impieghi tempo/processore a
proiettarli al volo per generare le tiles.

Nel momento in cui vengono caricati gli strati di sfondo
(Google/Bing/OSM) aggiungo sistemi di coordinate, tra cui il 3857
(che datum usa??), immagino che di mezzo ci stiano dei calcoli…

Più calcoli sono da fare minore sarà la prestazione del server
cartografico…

Ammesso che lo stoccaggio del dato ufficiale immagino sia da fare in
3045 per allinearci allo standard nostro regionale, come conviene
proiettare i dati da dare a Qgis-Server?

Conviene usare il 32633? Se il 3857 è simile al 3395 (world
mercator), se usano lo stesso datum (wgs84)… i tempi di calcolo
dovrebbero essere minori nel mettere assieme gli strati durante la
riproiezione al volo se uso il 32633…

Se uso strati di sfondo con epsg 3857 conviene salvare il progetto
direttamente in quel sistema di coordinate??

Che dite?

Grazie

Pietro

AVVISO DI RISERVATEZZA Informazioni riservate possono essere
contenute nel messaggio o nei suoi allegati. Se non siete i
destinatari indicati nel messaggio, o responsabili per la sua
consegna alla persona, o se avete ricevuto il messaggio per errore,
siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In
tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati.
Grazie. CONFIDENTIALITY NOTICE Confidential information may be
contained in this message or in its attachments. If you are not the
addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in
error, you may not transcribe, copy or deliver this message to anyone.
In that case, you should delete this message and its attachments. Thank you.


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.
750 iscritti al 18.3.2015

Andrea Peri
. . . . . . . . .
qwerty àèìòù

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute
nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel
messaggio, o responsabili per la sua consegna alla persona, o se avete
ricevuto il messaggio per errore, siete pregati di non trascriverlo,
copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il
messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential
information may be contained in this message or in its attachments. If you
are not the addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in error,
you may not transcribe, copy or deliver this message to anyone. In that
case, you should delete this message and its attachments. Thank you.

Andrea Peri
. . . . . . . . .
qwerty àèìòù

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute
nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel
messaggio, o responsabili per la sua consegna alla persona, o se avete
ricevuto il messaggio per errore, siete pregati di non trascriverlo,
copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il
messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential
information may be contained in this message or in its attachments. If you
are not the addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in error,
you may not transcribe, copy or deliver this message to anyone. In that
case, you should delete this message and its attachments. Thank you.

Andrea Peri
. . . . . . . . .
qwerty àèìòù

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel
messaggio o nei suoi allegati. Se non siete i destinatari indicati nel
messaggio, o responsabili per la sua consegna alla persona, o se avete
ricevuto il messaggio per errore, siete pregati di non trascriverlo,
copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il
messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential
information may be contained in this message or in its attachments. If you
are not the addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in error,
you may not transcribe, copy or deliver this message to anyone. In that
case, you should delete this message and its attachments. Thank you.

Andrea Peri
. . . . . . . . .
qwerty àèìòù

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel
messaggio o nei suoi allegati. Se non siete i destinatari indicati nel
messaggio, o responsabili per la sua consegna alla persona, o se avete
ricevuto il messaggio per errore, siete pregati di non trascriverlo,
copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il
messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential
information may be contained in this message or in its attachments. If you
are not the addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in error,
you may not transcribe, copy or deliver this message to anyone. In that
case, you should delete this message and its attachments. Thank you.

Andrea Peri
. . . . . . . . .
qwerty àèìòù

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

Una precisazione.

Io basavo la mia risposta sulla ipotesi che al wms dei dati OSM
accedesse direttamente il client lizmap.
Pero' mi e' venuto in mente che forse il client lizmap demanda
l'accesso a OSM al qgis-server che opererebbe una sorta di cascading.

Se cosi' fosse allora le mie considerazioni non sono piu' valide.
Perche' qgis-server riesce a fare un cambio di srs sicuramente piu'
rapido he non un client javascript.

Questo per dimostrare che serve sapere come funziona una
infrastruttura per poter valutare quali sono le ottimizzazioni giuste,
e non sempre le stesse ottimizzazioni in situazioni differenti vanno
ugualmente bene.

Quindi direi di finirla qui.
:slight_smile:

Saluti,

A.

Il 2 luglio 2015 18:01, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Ok vediamo se Paolo Cavallini che conosce molto meglio di me il sistema ha
qualche dettaglio in più..
Grazie mille per le spiegazioni
Buona serata
Pietro

Sent by MailWise – Your emails, with style.:slight_smile:

-------- Messaggio originale --------
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap
Da: Andrea Peri <aperi2007@gmail.com>
A: Rossin Pietro <pietro.rossin@arpa.fvg.it>
CC: gfoss@lists.gfoss.it

Messa in questi termini, non e' ottimale.

Perche' lascia presupporre che demandi a lizmap il compito di fre
cambio di sistema di riferimento e lizmap e' un client javascript che
sicuramente e' lento su queste operazioni e pure molto poco preciso.

Sei dati di sfondo in 3857 li prendi da una altra parte (es: OSM),
allora ti conviene sicuramente aggiungere
il SRS 3857 nella lista dei SRS forniti dal tuo qgis-server e fare una
richiesta anche dei tuoi in 3857.

Di piu' non posso dirti, visot che lizmap non loconosco.
Noi usiamo qgisserver ma lo puntimoa con un client wms puro (nel
nostro caso tolomeo, un framework sviluppato e mantenuto dal comune di
prato)

Tolomeo non fa' cambi al volo di sistemi di riferimento e quindi
giocoforza questo problema di mixing srs gestiti lato client non
esiste.

NAturalmente questo e' un difett dal punto di vista della
flessibilita' perche' non si puo' aggiungere a un portale wms che non
forniscano il srs previsto nel prtale.

Nel vostro caso lizmap se capisco bene invece questo e' possibile.
ero' io cercherei comunque di tenere tutto piu' preciso possibile e
quindi userei il srs del sistema OSM.
Questo ti garantirebbe maggiore precisione.

A.

Il 2 luglio 2015 17:40, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha
scritto:

Lizmap ha qgis server sotto usato come fast cgi.
I miei dati li ho in 3045 ed il progetto lo salvo in 3045. Solo che poi
in
lizmap aggiungo layer di sfondo in 3857.
Quindi.. boh!
Farò delle prove a questo punto

Sent by MailWise – Your emails, with style.:slight_smile:

-------- Messaggio originale --------
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap
Da: Andrea Peri <aperi2007@gmail.com>
A: Rossin Pietro <pietro.rossin@arpa.fvg.it>
CC: gfoss@lists.gfoss.it

On conosco lizmap come client e quindi non so dirti.

In merito al tuo sistema, e' rilevante mettercene 1 solo o piu' di uno
se ilproblema e' legato solo al tuo portale.
Perche' la velocita' e'sulla chiamata.

Te puoi mettercene anche piu' di uno.
Poi se la chiamata la farai in sistema nativo sara' piu' rapido, se la
farai in altro sistema sara' piu' lento perche' deve riproiettare al
volo.

Se ammetti altri srs faciliti l'utilizzo a eventuali utenti esterni
che puntano sul tuo wms.

Per te non e' rilevante in merito al tuo portale.

Certo che se hai i dati in 3044 e fai un portale in altro sistema di
riferimento, allora te la cerchi...
:slight_smile:

Il 2 luglio 2015 16:35, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha
scritto:

A livello di webgis (Lizmap) non credo si possa operare una scelta di
sistema di coordinate..
Quindi io di solito per rendere il sistema funzionale uso il 3045 (dati
nel mio archivio) il 3857 (Google) ed il 4326 (wgs84)

Solo che mi chiedevo, lascio così e mescolo strati a sistemi di
coordinata
differente o magari i miei dati da 3045 me li riproietto con viste
materializzate e li carico ad esempio in 3857 di modo che non vi siano
calcoli per la riproiezione al volo??

P

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 16:29
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Per avere velocita' occorre che ti richiedano i dati nel sistema di
riferimento nativo in cui sono i tuoi dati.

Se vuoi essere veloce, basta che fissi su qgis-server un solo sistema di
riferimento, escludendo la possibilia' che ti chiedano mapp in qalsiasi
altro sistema diriferimento.

Ovviamente se i tuoi dati sono nel 3044, vuol dire che chi usa i tuoi wms
potr' avere dati solo in 3044.
Ci vuole usarli per sovrapporli ad altri dati in altri sistemi, non
potra'
falro, oppure fa' conversioni lui locali, che pero' facendole senza
grigliati (a differenza di te sul server) soffrira' un errore diche puo'
andare da 10 a 50 metri tipicamente.

Se ammetti che possano richiederle anche in altri sisyem, allora sar'a
piu' lento perche' deve convertirle.

A.

Il 2 luglio 2015 16:18, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha
scritto:

Vabbè, data un'occhiata non mi sembra vi siano delle differenze
sostanziali, a parte la decisione di usare i due codici in aree
diverse dell'europa In termini pratici mi sembra che il 6708 sia un
sotto
insieme del 3045, così come il 6706 mi sembra il ritaglio del 4258 su
un'area più piccola (Ilalia) Ma caratteristiche dell'elissoide e punti
di
emanazione non cambiano da quanto ho capito..

Bai de uei
Risolto il baco su Qgis per cui andremo a scegliere il 6708, resta la
parte qgis-server.
Che sistema di coordinate mi conviene scegliere avendo tra i layer
anche strati tipo OSM o Google A livello webgis non interessa tanto
l'accuratezza topologica, interessa piuttosto la velocità di resa..

Grazie!
p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:52
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Se vuoi sapere cosa cambia non devi basarti solo sull' prj, ma devi
consultare il db dell'epsg.
Vai qui:

http://www.epsg.org/

click su "online registry"
selezioni retrieve by code e digiti
prima 6708 e poi 3045

e poi click su view.

Li' trovi tutte ledifferenze tra i due.

Intanto l'area di impiego e' differente.

6708 e' su italia, mentre 3045 e' su germania.
Il resto va confrontato punto per punto, ma io non mi porrei troppi
problemi .

Quando qgis e gli altri software supporteranno 6707 e dintorni , quelli
andranno usati.
Nel frattempo , si puo' usare (noialmeno) epsg:25832 che come area di
impiego copre l'europa con coordinate che inglobano anche l'italia.

Ovviamento il bacone di qgis che sostituisce a 25832 il 3044 e' una cosa
che crea sicuramente problemi, ma poco ci si puo' fare, cosi' e'
e cosi' ci si deve tenere.
Perche' l'errore deriva da come qgis gestisce la memorizzazione dei
sistemi di riferimento dentro i progetti.

Saluti,

A.

Il 2 luglio 2015 15:42, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha
scritto:

Altri numeri ancora...

EPSG 3045 (ETRS89-TM33)
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

6706 RDN2008
        +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
6707 RDN2008 / TM32
        +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
+no_defs
6708 RDN2008 / TM33
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

Volendo fare un confronto tra 3045 e 6708 che è quello definite
ufficiale in metri fuso 33, cosa cambia???

p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:33
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Ti rispondo alla prima parte della tua domanda:

Il 2 luglio 2015 14:53, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha
scritto:

Giro qui una domanda fatta a Cavallini e parzialmente risposta con
suggerimento di discuterne in lista.

Ho un dubbio sui sistemi di coordinate che devo usare per catalogare
i dati e poi servirli sul web.

Il nostro sistema di coordinate ufficiale italiano (fuso est)
dovrebbe essere il 3045 (o 25833 non proprio corretto)

Cosa intendi per ufficiale ?

L'attuale (ad oggi) sistema ufficiale in Italia che sapessi io e' il
nuovissimo epsg:6707 e dintorni.

http://lists.gfoss.it/pipermail/gfoss/2014-March/031997.html

Prima di questo , noi in RT ad esempio usavamo il GaussBoaga
(epsg:3003), Il nuovo 6707 , ancora non e' stato recepito dai
softwares come QGIS (altri si, ma qgis ancora no)

Per cui non si puo' usare.

In attesa di poterlo usare facciamo ricorso all' epsg:25832 (RT e'
dall'altro lato rispetto al FVG)

Purtroppo per un baco delle definizioni prj usate da qgis , qando qgis
apre un file con una definizione prj epsg:25832 lo confonde con l'
epsg:3044
(vado a memoria) e quindi imposta tale sistema come riferimento del
dataset.

Tra epsg:25832 e epsg:3044 cambia solamente l'ordine di esplicitazione
delle coordinate xy in un caso e yx nell'altro.

Saluti,

A.

Questo è quanto emerso in questa discussione

https://groups.google.com/d/msg/qgis_utenti_fvg/84rUcjoqWOY/O5W1Uwfa
S
c
UJ

Corretto?

Il datum di entrambi i sistemi sopra dovrebbe essere ETRS_1989
sferoide
GRS_1980

A volte qui in regione si usa il 32633 che ha come datum/sferoide
wgs84.

L’estensione in longitudine è la medesima, cambia quella in
latitudine

3045 è 12.0000, 35.5000, 18.0000, 75.0000

32633 è 12.0000, 0.0000, 18.0000, 84.0000

La rototraslazione del ETRS_1989 su wgs84 è 0 per tutti i parametri.

La differenza dei due elissoidi è un decimo di millimetro sul
semiasse maggiore.

Le differenze in coordinate alle nostre lat/long sono nell’ordine di
3-5cm

Messa così è una inezia.. pochi centimetri, e sugli applicativi
desktop la traslazione tra un sistema ed un altro non dovrebbe essere
impegnativa.

Ma pensando al fatto che poi un certo numero di strati li devo
mettere su web usando Qgis-server (lizmap) mi chiedo come è più
opportuno trattare i dati.

In Lizmap il sistema di coordinate è quello impostato nel progetto
di Qgis che sta sotto all’applicativo web e che viene letto da
QGis-Server

Se io nel progetto metto più strati con sistemi di coordinate
diverse immagino che il server impieghi tempo/processore a
proiettarli al volo per generare le tiles.

Nel momento in cui vengono caricati gli strati di sfondo
(Google/Bing/OSM) aggiungo sistemi di coordinate, tra cui il 3857
(che datum usa??), immagino che di mezzo ci stiano dei calcoli..

Più calcoli sono da fare minore sarà la prestazione del server
cartografico..

Ammesso che lo stoccaggio del dato ufficiale immagino sia da fare in
3045 per allinearci allo standard nostro regionale, come conviene
proiettare i dati da dare a Qgis-Server?

Conviene usare il 32633? Se il 3857 è simile al 3395 (world
mercator), se usano lo stesso datum (wgs84).. i tempi di calcolo
dovrebbero essere minori nel mettere assieme gli strati durante la
riproiezione al volo se uso il 32633..

Se uso strati di sfondo con epsg 3857 conviene salvare il progetto
direttamente in quel sistema di coordinate??

Che dite?

Grazie

Pietro

AVVISO DI RISERVATEZZA Informazioni riservate possono essere
contenute nel messaggio o nei suoi allegati. Se non siete i
destinatari indicati nel messaggio, o responsabili per la sua
consegna alla persona, o se avete ricevuto il messaggio per errore,
siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In
tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati.
Grazie. CONFIDENTIALITY NOTICE Confidential information may be
contained in this message or in its attachments. If you are not the
addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in
error, you may not transcribe, copy or deliver this message to anyone.
In that case, you should delete this message and its attachments.
Thank you.

_______________________________________________
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.
750 iscritti al 18.3.2015

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute
nel messaggio o nei suoi allegati. Se non siete i destinatari indicati
nel
messaggio, o responsabili per la sua consegna alla persona, o se avete
ricevuto il messaggio per errore, siete pregati di non trascriverlo,
copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il
messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE
Confidential
information may be contained in this message or in its attachments. If
you
are not the addressee indicated in this message, or responsible for
message
delivering to that person, or if you have received this message in
error,
you may not transcribe, copy or deliver this message to anyone. In that
case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute
nel messaggio o nei suoi allegati. Se non siete i destinatari indicati
nel
messaggio, o responsabili per la sua consegna alla persona, o se avete
ricevuto il messaggio per errore, siete pregati di non trascriverlo,
copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il
messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE
Confidential
information may be contained in this message or in its attachments. If
you
are not the addressee indicated in this message, or responsible for
message
delivering to that person, or if you have received this message in
error,
you may not transcribe, copy or deliver this message to anyone. In that
case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute
nel
messaggio o nei suoi allegati. Se non siete i destinatari indicati nel
messaggio, o responsabili per la sua consegna alla persona, o se avete
ricevuto il messaggio per errore, siete pregati di non trascriverlo,
copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il
messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential
information may be contained in this message or in its attachments. If
you
are not the addressee indicated in this message, or responsible for
message
delivering to that person, or if you have received this message in error,
you may not transcribe, copy or deliver this message to anyone. In that
case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel
messaggio o nei suoi allegati. Se non siete i destinatari indicati nel
messaggio, o responsabili per la sua consegna alla persona, o se avete
ricevuto il messaggio per errore, siete pregati di non trascriverlo,
copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il
messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential
information may be contained in this message or in its attachments. If you
are not the addressee indicated in this message, or responsible for
message
delivering to that person, or if you have received this message in error,
you may not transcribe, copy or deliver this message to anyone. In that
case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel
messaggio o nei suoi allegati. Se non siete i destinatari indicati nel
messaggio, o responsabili per la sua consegna alla persona, o se avete
ricevuto il messaggio per errore, siete pregati di non trascriverlo,
copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il
messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential
information may be contained in this message or in its attachments. If you
are not the addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in error,
you may not transcribe, copy or deliver this message to anyone. In that
case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

Il 02/07/2015 18:11, Andrea Peri ha scritto:

Pero' mi e' venuto in mente che forse il client lizmap demanda
l'accesso a OSM al qgis-server che opererebbe una sorta di cascading.

Se cosi' fosse allora le mie considerazioni non sono piu' valide.
Perche' qgis-server riesce a fare un cambio di srs sicuramente piu'
rapido he non un client javascript.

esatto.
saluti.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html

Grazie
Quindi tornando al ragionamento sui SRS, se si usano OSM o Google layers come sfondo conviene usare il 3857 nei progetti??

p

-----Messaggio originale-----
Da: gfoss-bounces@lists.gfoss.it [mailto:gfoss-bounces@lists.gfoss.it] Per conto di Paolo Cavallini
Inviato: giovedì 2 luglio 2015 18:21
A: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis server/Lizmap

Il 02/07/2015 18:11, Andrea Peri ha scritto:

Pero' mi e' venuto in mente che forse il client lizmap demanda
l'accesso a OSM al qgis-server che opererebbe una sorta di cascading.

Se cosi' fosse allora le mie considerazioni non sono piu' valide.
Perche' qgis-server riesce a fare un cambio di srs sicuramente piu'
rapido he non un client javascript.

esatto.
saluti.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
_______________________________________________
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.
750 iscritti al 18.3.2015
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

Risolto il dilemma sui sistemi di coodinate (non ancora su lizmap..)!
In regione li hanno trattati con l'accetta :wink:

Nel documento
http://www.regione.fvg.it/rafvg/export/sites/default/RAFVG/ambiente-territorio/strumenti-per-conoscere/allegati/La_costruzione_delle_banche_dati_territoriali_IRDATfvg_v1.3.pdf
A pagina 25 trattano dei sistemi di coordinate ed in particolare a pagina 29 è riportato:

"Nei prodotti GIS correntemente utilizzati, ai fini della trasformazione di coordinate, ETRS89 e WGS84 sono
quasi sempre considerati come sistemi di riferimento identici; sussistono quindi le seguenti equivalenze:
• epsg:4258 = epsg :4326
• epsg :25833 = epsg :32633 = epsg:3045
• epsg :25832 = epsg :32632 = epsg:3044"

Ciao

-----Messaggio originale-----
Da: gfoss-bounces@lists.gfoss.it [mailto:gfoss-bounces@lists.gfoss.it] Per conto di Rossin Pietro
Inviato: giovedì 2 luglio 2015 16:19
A: Andrea Peri
Cc: gfoss@lists.gfoss.it
Oggetto: [Gfoss] R: Dubbio su sistemi di proiezione e webgis/Qgis server/Lizmap

Vabbè, data un'occhiata non mi sembra vi siano delle differenze sostanziali, a parte la decisione di usare i due codici in aree diverse dell'europa In termini pratici mi sembra che il 6708 sia un sotto insieme del 3045, così come il 6706 mi sembra il ritaglio del 4258 su un'area più piccola (Ilalia) Ma caratteristiche dell'elissoide e punti di emanazione non cambiano da quanto ho capito..

Bai de uei
Risolto il baco su Qgis per cui andremo a scegliere il 6708, resta la parte qgis-server.
Che sistema di coordinate mi conviene scegliere avendo tra i layer anche strati tipo OSM o Google A livello webgis non interessa tanto l'accuratezza topologica, interessa piuttosto la velocità di resa..

Grazie!
p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:52
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis server/Lizmap

Se vuoi sapere cosa cambia non devi basarti solo sull' prj, ma devi consultare il db dell'epsg.
Vai qui:

http://www.epsg.org/

click su "online registry"
selezioni retrieve by code e digiti
prima 6708 e poi 3045

e poi click su view.

Li' trovi tutte ledifferenze tra i due.

Intanto l'area di impiego e' differente.

6708 e' su italia, mentre 3045 e' su germania.
Il resto va confrontato punto per punto, ma io non mi porrei troppi problemi .

Quando qgis e gli altri software supporteranno 6707 e dintorni , quelli andranno usati.
Nel frattempo , si puo' usare (noialmeno) epsg:25832 che come area di impiego copre l'europa con coordinate che inglobano anche l'italia.

Ovviamento il bacone di qgis che sostituisce a 25832 il 3044 e' una cosa che crea sicuramente problemi, ma poco ci si puo' fare, cosi' e'
e cosi' ci si deve tenere.
Perche' l'errore deriva da come qgis gestisce la memorizzazione dei sistemi di riferimento dentro i progetti.

Saluti,

A.

Il 2 luglio 2015 15:42, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Altri numeri ancora...

EPSG 3045 (ETRS89-TM33)
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

6706 RDN2008
        +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
6707 RDN2008 / TM32
        +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
6708 RDN2008 / TM33
+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
++no_defs

Volendo fare un confronto tra 3045 e 6708 che è quello definite ufficiale in metri fuso 33, cosa cambia???

p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 2 luglio 2015 15:33
A: Rossin Pietro
Cc: gfoss@lists.gfoss.it
Oggetto: Re: [Gfoss] Dubbio su sistemi di proiezione e webgis/Qgis
server/Lizmap

Ti rispondo alla prima parte della tua domanda:

Il 2 luglio 2015 14:53, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Giro qui una domanda fatta a Cavallini e parzialmente risposta con
suggerimento di discuterne in lista.

Ho un dubbio sui sistemi di coordinate che devo usare per catalogare
i dati e poi servirli sul web.

Il nostro sistema di coordinate ufficiale italiano (fuso est)
dovrebbe essere il 3045 (o 25833 non proprio corretto)

Cosa intendi per ufficiale ?

L'attuale (ad oggi) sistema ufficiale in Italia che sapessi io e' il nuovissimo epsg:6707 e dintorni.

http://lists.gfoss.it/pipermail/gfoss/2014-March/031997.html

Prima di questo , noi in RT ad esempio usavamo il GaussBoaga
(epsg:3003), Il nuovo 6707 , ancora non e' stato recepito dai
softwares come QGIS (altri si, ma qgis ancora no)

Per cui non si puo' usare.

In attesa di poterlo usare facciamo ricorso all' epsg:25832 (RT e'
dall'altro lato rispetto al FVG)

Purtroppo per un baco delle definizioni prj usate da qgis , qando qgis apre un file con una definizione prj epsg:25832 lo confonde con l' epsg:3044 (vado a memoria) e quindi imposta tale sistema come riferimento del dataset.

Tra epsg:25832 e epsg:3044 cambia solamente l'ordine di esplicitazione delle coordinate xy in un caso e yx nell'altro.

Saluti,

A.

Questo è quanto emerso in questa discussione

https://groups.google.com/d/msg/qgis_utenti_fvg/84rUcjoqWOY/O5W1UwfaS
c
UJ

Corretto?

Il datum di entrambi i sistemi sopra dovrebbe essere ETRS_1989 sferoide
GRS_1980

A volte qui in regione si usa il 32633 che ha come datum/sferoide wgs84.

L’estensione in longitudine è la medesima, cambia quella in
latitudine

3045 è 12.0000, 35.5000, 18.0000, 75.0000

32633 è 12.0000, 0.0000, 18.0000, 84.0000

La rototraslazione del ETRS_1989 su wgs84 è 0 per tutti i parametri.

La differenza dei due elissoidi è un decimo di millimetro sul
semiasse maggiore.

Le differenze in coordinate alle nostre lat/long sono nell’ordine di
3-5cm

Messa così è una inezia.. pochi centimetri, e sugli applicativi
desktop la traslazione tra un sistema ed un altro non dovrebbe essere impegnativa.

Ma pensando al fatto che poi un certo numero di strati li devo
mettere su web usando Qgis-server (lizmap) mi chiedo come è più
opportuno trattare i dati.

In Lizmap il sistema di coordinate è quello impostato nel progetto di
Qgis che sta sotto all’applicativo web e che viene letto da
QGis-Server

Se io nel progetto metto più strati con sistemi di coordinate diverse
immagino che il server impieghi tempo/processore a proiettarli al
volo per generare le tiles.

Nel momento in cui vengono caricati gli strati di sfondo
(Google/Bing/OSM) aggiungo sistemi di coordinate, tra cui il 3857
(che datum usa??), immagino che di mezzo ci stiano dei calcoli..

Più calcoli sono da fare minore sarà la prestazione del server
cartografico..

Ammesso che lo stoccaggio del dato ufficiale immagino sia da fare in
3045 per allinearci allo standard nostro regionale, come conviene
proiettare i dati da dare a Qgis-Server?

Conviene usare il 32633? Se il 3857 è simile al 3395 (world
mercator), se usano lo stesso datum (wgs84).. i tempi di calcolo
dovrebbero essere minori nel mettere assieme gli strati durante la
riproiezione al volo se uso il 32633..

Se uso strati di sfondo con epsg 3857 conviene salvare il progetto
direttamente in quel sistema di coordinate??

Che dite?

Grazie

Pietro

AVVISO DI RISERVATEZZA Informazioni riservate possono essere
contenute nel messaggio o nei suoi allegati. Se non siete i
destinatari indicati nel messaggio, o responsabili per la sua
consegna alla persona, o se avete ricevuto il messaggio per errore,
siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In
tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati.
Grazie. CONFIDENTIALITY NOTICE Confidential information may be
contained in this message or in its attachments. If you are not the
addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in
error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

_______________________________________________
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.
750 iscritti al 18.3.2015

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.
_______________________________________________
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.
750 iscritti al 18.3.2015
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.