On Wed, May 23, 2012 at 03:03:10PM +0200, Margherita Di Leo wrote:
E' chiaro (ed evidente) che per l'uso quotidiano avere un +towsg84 di
default è meglio che niente.
L'utente generico, quindi, non può che goderne.
Il punto è se, concettualmente, è opportuno o meno infilare una
Altri invece, più pragmatici, preferiscono di sì perché perlomeno aiuta a non
commettere gravi errori di default.
Se per pragmatici si intende programmatori ed esperti e chi non accetta gli
errori di 120 metri...
Allora, io aggiungerei che paradossalmente questo aumenta i possibili errori
On Wed, 23 May 2012 00:50:10 +0200, G. Allegri wrote:
Proporrei anche un poll sull'opportunità o meno di avere i parametri
di trasformazione nei nostri 3003/3004. Se fosse ritenuto
inopportuno,
potremmo proporre d'aggiungere un'eccezione dentro
datum_shift_pref.csv.
dopo tante chiacchiere:
Sei instancabile Sandro!
E' chiaro (ed evidente) che per l'uso quotidiano avere un +towsg84 di
default è meglio che niente.
L'utente generico, quindi, non può che goderne.
Il punto è se, concettualmente, è opportuno o meno infilare una
trasformazione all'interno di un codice epsg ufficiale. Io, e
Ciao Alessandro,
a) ho preso lo SHP dei comuni ISTAT che e' in ED50 (23032 zona 32N)
purtroppo non ho trovato nessuna cartografia in GB che coprisse
l'intero territorio nazionale e che fosse open data.
comunque ED50 assomiglia abbastanza a GB, visto che neppure per
ED50 e' definito
Grazie per il punto Sandro e Giovanni,
2012/5/23 G. Allegri gioha...@gmail.com
E' chiaro (ed evidente) che per l'uso quotidiano avere un +towsg84 di
default è meglio che niente.
L'utente generico, quindi, non può che goderne.
Il punto è se, concettualmente, è opportuno o meno infilare una
Il 23/05/2012 15.03, Margherita Di Leo ha scritto:
Allora, io aggiungerei che paradossalmente questo aumenta i possibili
errori commessi di default, perche` uno si aspetta di utilizzare una
definizione standard di EPSG e di poter controllare gli errori attesi,
quando invece all'interno di quella
Il 21/05/2012 21:17, Geo DrinX ha scritto:
Esiste una zona in Italia in cui la trasformazione diretta ( senza
towgs84 ) produce un risultato corretto?
no, non e' matematicamente ammissibile.
Infatti, la mia domanda era oziosa.
Resta da chiedersi: cosa serve
Ottimo resoconto Sandro, questi giorni non ero riuscito a studiarmi
meglio il caso. Grazie.
Davo per scontato si sapesse che l'EPSG Registry non distribuisce il
file epsg così come lo conosciamo nel mondo GFOSS...
giovanni
Il 22 maggio 2012 15:47, a.furi...@lqt.it ha scritto:
On Mon, 21 May
allora, qualche novita' e qualche approfondimento, spero utili:
Molto interessante!
io capisco le ragioni qua esposte di entrambe le parti, ma spero che si
possa salvare capra e cavoli... non vivo/lavoro in Italia e
l'introduzione dei parametri towgs84 nei 3 sistemi piú comuni in
Portogallo
On Tue, 22 May 2012 16:57:12 +0100, Giovanni Manghi wrote:
io capisco le ragioni qua esposte di entrambe le parti, ma spero che
si
possa salvare capra e cavoli... non vivo/lavoro in Italia e
l'introduzione dei parametri towgs84 nei 3 sistemi piú comuni in
Portogallo ha risolto un bel problema
Ciao,
ho segnalato la cosa sulla ML di gdal, e forse abbiamo una pista:
http://lists.osgeo.org/pipermail/gdal-dev/2012-May/032891.html
ciao madi
--
Ing. Margherita Di Leo, Ph.D.
___
Gfoss@lists.gfoss.it
Grazie Margherita,
ho dato seguito all'email di Even.
giovanni
Il 22 maggio 2012 22:25, Margherita Di Leo direg...@gmail.com ha scritto:
Ciao,
ho segnalato la cosa sulla ML di gdal, e forse abbiamo una
pista: http://lists.osgeo.org/pipermail/gdal-dev/2012-May/032891.html
ciao madi
--
Riporto anche qua la logica adottata nella scelta dei parametri di
trasformazione, spiegata nella risposta di Frank [1] e implementata in
[2].
* Viene preferita la trasformazione che interessa l'area maggiore per
un dato GCS
* Viene evitata ogni trasformazione deprecata
* Vengono evitate i
Grazie innanzitutto a Sandro, Madi e Giovanni per lo sforzo profuso nel
cercare di chiarire ulteriormente questa faccenda...
Il 22/05/2012 23.16, G. Allegri ha scritto:
Riporto anche qua la logica adottata nella scelta dei parametri di
trasformazione, spiegata nella risposta di Frank [1] e
On Tue, 22 May 2012 22:48:17 +0200, G. Allegri wrote:
Grazie Margherita,
ho dato seguito all'email di Even.
altro giro di verifiche alla luce delle risposte di Even prima,
e di Frank Warmerdam a seguire.
e' definitivamente confermato che il file EPSG distribuito con
le Proj4 4.8.0 e' stato
Io comunque la proposta di un campo authority l'ho fatta a Frank, La
troverei comunque utile, nel caso ci fosse una volontà di non
allontanarsi troppo da EPSG ufficiale.
Proporrei anche un poll sull'opportunità o meno di avere i parametri
di trasformazione nei nostri 3003/3004. Se fosse ritenuto
Il 20/05/2012 19:55, Andrea Peri ha scritto:
la ProJ , per definizione, non applica mai una trasformazione towgs.
potete per cortesia segnalare la cosa come ticket di proj?
gia' che ci siamo, non sarebbe male introdurre i codici (extra EPSG, 4)
per le
varie correzioni +towgs, cosi' abbiamo
Giusto qualche noiosissimo dettaglio tecnico preliminare, visto che
si tratta di aspetti sicuramente poco noti, per quanto assolutamente
critici:
a) tutte le operazioni di conversione tra diversi SRS (riproiezione)
dipendono dalle Proj4, e quindi in ultima analisi dal file delle
On Mon, May 21, 2012 at 09:53:04AM +0200, Paolo Cavallini wrote:
Il 20/05/2012 19:55, Andrea Peri ha scritto:
la ProJ , per definizione, non applica mai una trasformazione towgs.
potete per cortesia segnalare la cosa come ticket di proj?
gia' che ci siamo, non sarebbe male introdurre i
On Mon, 21 May 2012 13:21:18 +0200, Francesco P. Lovergine wrote:
Sfortunatamente non è l'unico pasticcio introdotto in 4.8, ragion per
cui è
opportuno evitarne in toto l'impiego.
Ciao Frakie,
potresti dettagliare ?
quali altre criticita' ti risultano con la Proj 4.8 ?
grazie Sandro
--
Il
On Mon, May 21, 2012 at 01:25:17PM +0200, a.furi...@lqt.it wrote:
On Mon, 21 May 2012 13:21:18 +0200, Francesco P. Lovergine wrote:
Sfortunatamente non è l'unico pasticcio introdotto in 4.8, ragion
per cui è
opportuno evitarne in toto l'impiego.
Ciao Frakie,
potresti dettagliare ?
Il 21/05/2012 13:36, Francesco P. Lovergine ha scritto:
Pensavo fosse ormai ampiamente noto, quoto per esempio hamish_b in
immagino che ci siano gia' tickets aperti in proposito, giusto?
saluti.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Il 21/05/2012 13:37, Paolo Cavallini ha scritto:
Il 21/05/2012 13:36, Francesco P. Lovergine ha scritto:
Pensavo fosse ormai ampiamente noto, quoto per esempio hamish_b in
immagino che ci siano gia' tickets aperti in proposito, giusto?
in ogni caso, dato che i parametri sono molto comodi,
On Mon, 21 May 2012 13:36:02 +0200, Francesco P. Lovergine wrote:
Pensavo fosse ormai ampiamente noto, quoto per esempio hamish_b in
un recente scambio con lui in merito:
pps- AFAIK proj 1.8.0's epsg file makes a big problem for GRASS,
QGIS, and others as it has removed all the +datum= terms
On Mon, May 21, 2012 at 01:40:02PM +0200, Paolo Cavallini wrote:
Il 21/05/2012 13:37, Paolo Cavallini ha scritto:
Il 21/05/2012 13:36, Francesco P. Lovergine ha scritto:
Pensavo fosse ormai ampiamente noto, quoto per esempio hamish_b in
immagino che ci siano gia' tickets aperti in
Il 21/05/2012 14:05, Francesco P. Lovergine ha scritto:
Si, solo che i codici custom non sono standard e a quel punto chiunque può
adottare la convenzione che gli pare. Si arriva dritti dritti all'approccio
alla ESRI. Non solo secondo me non è il massimo, ma va in direzione opposta
a quello
ma non dare i parametri di correzione e' comunque un danno per gli utenti;
Concordo.
In piu' ho una domanda relativa ai codici 3003-4 :
Esiste una zona in Italia in cui la trasformazione diretta ( senza towgs84 )
produce un risultato corretto?
___
On Mon, 21 May 2012 14:37:18 +0200, Geodrinx wrote:
Esiste una zona in Italia in cui la trasformazione diretta ( senza
towgs84 ) produce un risultato corretto?
no, non e' matematicamente ammissibile.
il GB nacque nei remoti anni '40. l'ellissoide di riferimento su
cui si basa ha una forma
Il 21/05/2012 15:21, a.furi...@lqt.it ha scritto:
n.b.: dato che i grigliati introducono di per se una correzione
+towgs84, le nuove definizioni 4.8 che gia' includono un termine
+towgs84 al loro interno rischiano di rendere impossibile l'uso
dei grigliati
Per info: il nostro (RER+Faunalia)
capisco, ma non dare i parametri di correzione e' comunque un danno per gli
utenti;
alternative?
Non condivido. I parametri di proiezione variano a seconda del livello
di precisione che si richiede. Inserirli può essere fuorviante,
soprattutto per un utente medio, perché potrebbero indurlo a
Il 21/05/2012 15:54, G. Allegri ha scritto:
Non condivido. I parametri di proiezione variano a seconda del livello
di precisione che si richiede. Inserirli può essere fuorviante,
soprattutto per un utente medio, perché potrebbero indurlo a pensare
che siano esatti o corretti, quando invece
Il 21/05/2012 15:54, Paolo Cavallini ha scritto:
resta il fatto che operativamente e' molto meglio averli che non averli, e
che sono
soddisfacenti per molti scopi. non a caso GRASS li ha inseriti da anni.
salve.
qualcuno dei piu' esperti di proiezioni potrebbe aprire un ticket su proj, se
Esiste una zona in Italia in cui la trasformazione diretta ( senza
towgs84 ) produce un risultato corretto?
no, non e' matematicamente ammissibile.
Infatti, la mia domanda era oziosa.
Resta da chiedersi: cosa serve avere due codici che non servono a nulla, se
non ad ottenere risultati
non mi pare che fosse mai girata in precedenza ...
stavo provando un KML ottenuto da dati di partenza GB (srid=3003)
quando ho casualmente scoperto di avere ottenuto uno snap semplicemente
perfetto fin dal primo colpo e senza nessuna cautela speciale ...
se vi ricordate, in precedenza non era
On Sun, 20 May 2012 12:06:24 +0200, a.furi...@lqt.it wrote:
Proj.4 v.3.7.0 (vecchia versione, ancora molto diffusa)
Proj.4 v.3.8.0 (rilascio recentissimo, 6 marzo u.s.)
ovviamente prima ho sbagliato i riferimenti:
leggasi correttamente Proj v.4.7.0 e v.4.8.0
(e grazie mille all'anonimo socio
2012/5/20 a.furi...@lqt.it
On Sun, 20 May 2012 12:13:03 +0200, Margherita Di Leo wrote:
2012/5/20
Proj.4 v.3.7.0 (vecchia versione, ancora molto diffusa)
--**-
Proj.4 v.3.8.0 (rilascio recentissimo, 6 marzo u.s.)
forse
Il 20/05/2012 12.06, a.furi...@lqt.it ha scritto:
non mi pare che fosse mai girata in precedenza ...
stavo provando un KML ottenuto da dati di partenza GB (srid=3003)
quando ho casualmente scoperto di avere ottenuto uno snap semplicemente
perfetto fin dal primo colpo e senza nessuna cautela
On Sun, 20 May 2012 12:43:59 +0200, Antonio Falciano wrote:
grazie per averci fatto notare la cosa.
A mio modesto avviso, e' una cialtroneria questa. La definizione
rigorosa di EPSG:3003-4 non prevede l'uso dei parametri +towgs84
esattissimo, vedi anche qua:
Condivido, la definizione del CRS non dovrebbe prevedere i parametri
di trasformazione, e inoltre ci troviamo ad un fork delle
definizioni epsg Proj4 rispetto a quelle ufficiali, che potrebbe
generare non pochi mal di testa e inconsistenze...
giovanni
Il 20 maggio 2012 13:03, a.furi...@lqt.it
On Sun, 20 May 2012 12:43:59 +0200, Antonio Falciano wrote:
* grazie per averci fatto notare la cosa.** A mio modesto avviso, e' una
cialtroneria questa. La definizione** rigorosa di EPSG:3003-4 non prevede
l'uso dei parametri +towgs84*
Concordo pienamente.
Questa cosa e' un gran casino.
Ora un
41 matches
Mail list logo
