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?
Il 21 maggio 2012 11:27, Vito Borneo <vitoborneo@yahoo.it> ha scritto:
QGIS server sarebbe davvero l'ideale, soprattutto perchè conoscendo Qgis
desktop,
si tratterebbe solo di copiare il file di progetto sul server...
secondo me non è la soluzione migliore per alcuni motivi:
- qgis non è nato per fornire servizi OGC e secondo me non dovrebbe
essere la sua finalità, esistono software dedicati che ottengono
risultati secondo me migliori
- installare qgis vuol dire installare un numero abbastanza esteso di
librerie che secondo me su un server di produzione non dovrebbero
esserci.
vito
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
Il 21 maggio 2012 14:38, Luca Delucchi <lucadeluge@gmail.com> ha scritto:
Il 21 maggio 2012 11:27, Vito Borneo <vitoborneo@yahoo.it> ha scritto:
QGIS server sarebbe davvero l'ideale, soprattutto perchè conoscendo Qgis
desktop,
si tratterebbe solo di copiare il file di progetto sul server...secondo me non è la soluzione migliore per alcuni motivi:
- qgis non è nato per fornire servizi OGC e secondo me non dovrebbe
essere la sua finalità, esistono software dedicati che ottengono
risultati secondo me migliori
- installare qgis vuol dire installare un numero abbastanza esteso di
librerie che secondo me su un server di produzione non dovrebbero
esserci.
La soluzione QGis è ottima se viene utilizzata per generare tile che
poi carichi sul server, ma dipende dalla frequenza con cui aggiorni le
informazioni.
C'è da dire che se ti appoggi a MapProxy puoi rigenerare solo le aree
che sono cambiate e quindi ti risparmi molta fatica.
Come ti ha detto Paolo, puoi anche usare formati vettoriali per
visualizzare direttamente i dati..in questo caso ti potrebbe tornar
utile ST_AsGeoJSON di Postgis (magari affiancato ai cluster di OL)
Ci sono molte soluzione possibili, ma servirebbe un maggior dettaglio
sui servizi che vuoi offrire (non solo visualizzazione, ma anche
interrogazione/modifica).
Ciao!
L.
--
Luca Casagrande
http://www.lucacasagrande.net
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 significativamente diversa da quella
ritenuta valida oggi (dopo tutte le osservazioni satellitari etc).
non esiste nessun modo matematico rigoroso per convertire
automaticamente da GB p.es. a WGS84 o RTEF2000.
proprio perche' si tratta di due "pianeti terra" diversi,
con una forma significativamente differente.
soluzione *vera* (robusta e generalizzata):
passare una matrice bursa-wolfe contenente gli opportuni parametri
di correzione locale per ciascun singolo punto ...
il famoso +towsg84 con i suoi 7 numeretti:
3 rotazioni (una per ciascun asse x, y, z) + 3 traslazioni (sempre
per ciascun asse) + 1 fattore di scala.
n.b.: "correzione locale" significa esattamente "locale";
se e' perfetta per Viterbo, gia' a Civitavecchia non e' piu'
tanto perfetta, ed a Grosseto e' ancora piu' approssimativa 
soluzione *buona*:
usare i grigliati: cioe' un set ragionevolmente denso di
punti calibrati con elevata precesione che formano una griglia.
quando caschi a meta' strada tra due nodi puoi interpolare le
matrici relative ai nodi piu' vicini, senza introdurre errori
eccessivi.
diciamo che realisticamente puoi arrivare al millimetro/centimetro.
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
soluzione *a spanne*:
usi le 4 macro-regioni (sicilia, sardegna, penisola est, penisola
ovest), ciascuna con la sua matrice +towgs84.
n.b.: non e' affatto una correzione rigorosa; avrai comunque
errori dell'ordine di qualche metro (probabilmente poco rilevanti
e quindi accettabili per molti casi d'uso normali e poco sofisticati).
soluzione *as is*:
usi la definizione base "nuda e cruda"; nei casi peggiori puoi
anche avere errori di decine o centinaia di metri.
quindi, come vedi, usare le macro-regioni rappresenta semplicemente
un approssimazione "un pelo meno schifosa".
ma non e' sicuramente la panacea.
mettiti infine nei panni di chi deve p.es. gestire sia civitavecchia
che la sardegna nella stessa mappa (diciamo per studiare i traghetti
etc): evidentemente, in questo caso l'approccio per macro-regioni non
funzionera' mai
se tiri la coperta sul lazio, padelli la sardegna; e viceversa.
ciao Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
Il 21/05/2012 14:38, Luca Delucchi ha scritto:
- qgis non è nato per fornire servizi OGC e secondo me non dovrebbe
essere la sua finalità, esistono software dedicati che ottengono
risultati secondo me migliori
veramente QGIS Server è nato esattamente per questo: FUD? 
- installare qgis vuol dire installare un numero abbastanza esteso di
librerie che secondo me su un server di produzione non dovrebbero
esserci.
non mi risulta: a quali fai riferimento?
Saluti.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Il 21/05/2012 15:21, a.furieri@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) plugin per QGIS strippa towgs84 e ci mette tutto
il necessario a funzionare con le griglie, dunque non dovrebbe avere nessuna
conseguenza (e menomale!).
Saluti.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Il 21 maggio 2012 15:30, Paolo Cavallini <cavallini@faunalia.it> ha scritto:
Il 21/05/2012 14:38, Luca Delucchi ha scritto:
- qgis non è nato per fornire servizi OGC e secondo me non dovrebbe
essere la sua finalità, esistono software dedicati che ottengono
risultati secondo me miglioriveramente QGIS Server è nato esattamente per questo: FUD?
Diciamo che, a fronte di software nati ed ottimizzate ai fini
dell'esposizione di servizi OGC, QGis Server risulta ancora un po'
poco performante se usato per produrre dinamicamente dati/immagini, e
forse ha ancora una ristretta base di casi d'impieghi per poter trarre
valutazioni più oggettive. Credo non ci siano controindicazioni per un
utilizzo sotto cache.
giovanni
Saluti.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012
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 pensare
che siano "esatti" o "corretti", quando invece sono soltanto
un'approssimazione a scala di macroregioni, oltretutto solo valida per
un'area nel caso del +towgs84 introdotto da Proj 4.8).
giovanni
saluti.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012
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 sono soltanto
un'approssimazione a scala di macroregioni
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.
alternative?
saluti, e grazie.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
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 non e'
stato gia' fatto?
Grazie.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Ho dato un'occhiata all'epsg in trunk, rispetto a quello del tag 4.7.
Non ho trovato una regola globale riguardo i cambiamenti apportati. In
alcuni casi il +datum è stato rimosso, ma in molti altri è stato
mantenuto e tolto il +ellips (es. 4326). Anche i +towgs84 non sono
sempre presenti, immagino ci siano quelli disponibili e reputati
rappresentativi (e su questo ci sono mille ragioni per discordare
dalla scelta!).
Ho l'impressione che abbiano voluto fare, a modo loro, un po' di
pulizia. A questo punto però o dichiarano un fork (e sarebbe da
evitare come la peste!) oppure viene adottato un metodo per
distinguere i codici ufficiali da quelli proposti da authority non
EPSG.
Nota riguardo il problema dell'impiego di +nadgrids. Senza il
parametro +datum non si può definire quale trasformazione impiegare.
Va tenuto però di conto di una nota di Proj4 presente da sempre tra i
Caveats:
"PROJ.4 always assumes that grids contain a shift to NAD83
(essentially WGS84). Other types of grids might or might not be
usable"
giovanni
Il 21 maggio 2012 15:54, Paolo Cavallini <cavallini@faunalia.it> ha scritto:
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 sono soltanto
un'approssimazione a scala di macroregioniresta 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.
alternative?
saluti, e grazie.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
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 errati ?
Perche’ non dichiararli obsoleti ?
Saluti
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 avere due codici che non servono a nulla, se non ad
ottenere risultati errati ?
Perche' non dichiararli obsoleti ?
scusate se insisto: potete per cortesia spostare questa interessante discussione sul
trac di proj? altrimenti rimane lettera morta, e mi pare un peccato.
grazie.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
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 and
replaced them with +towgs84= coefficients. ------ cut -----Quindi il casino sembra un po' più esteso della sola zona italiana...
Tra parentesi, si potrebbe pensare che ci siano gli estremi per una
violazione di licenza dei dati EPSG ----- cut -----
allora, qualche novita' e qualche approfondimento, spero utili:
a) Proj4 non e' affatto il punto di partenza; e' semplicemente
il punto d'arrivo finale.
come gia' segnalavo ieri (ma forse e' passato inosservato ad
alcuni) le definizioni CRS nascono da GDAL, passano da GeoTIFF
e solo all'ultimo confluiscono in PROJ.4
tutto il ciclo di gestione del file EPSG e' spiegato chiaramente qua:
http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/README
b) non esiste nessun omino che prepara a mano il file delle definizioni
EPSG: e' semplicemente il risultato di un processo completamente
automatico; per l'esattezza, di uno script Python dentro a GDAL
c) giusto per pedanteria: il file EPSG ... col cavolo che e' EPSG 
il deliverable offerto direttamente da EPSG usa su un medello dati
complicatissimo, basato su decine di tavole e viste DBMS.
non assomiglia minimamente alle semplici stringhe geodetiche di Proj4,
assomiglia piuttosto alla definizioni SRS-WKT
http://www.epsg.org/geodetic.html
d) quindi, correttamente, il famoso e benedetto file EPSG e' semplicemente
un file di testo prodotto internamente da GDAL a beneficio di Proj.4
e di tutti gli altri packages che dipendono dalle Proj.4
ma e' comunque il frutto di una rielaborazione, non e' affatto un
prodotto supportato direttamente da EPSG.
e) per motivi che sfuggono all'umana comprensione, ad un certo punto
qualche sviluppatore di GDAL ha deciso di introdurre dalla 1.8.0
un'opzione (infelicissima ...) che consentisse di sostituire tutte
le definizioni +datum con una +towgs84
f) saggiamente, si trattava di un'opzione facoltativa: secondo la doc
citata in a) il modo standard per generare il file EPSG era quindi:
epsg_tr.py --config OVERRIDE_PROJ_DATUM_WITH_TOWGS84 FALSE -proj4 \
-skip -list gcs.csv > epsg
(insomma, seguire la vecchia strada consolidata, non la nuova).
g) mi sono appena divertito a fare una veloce sessione di debugging
con GDAL trunk: l'opzione OVERRIDE_PROJ_DATUM_WITH_TOWGS84 e'
sicuramente presente nel codice, ma evidentemente nell'implementazione
attuale (e suppongo fin dalla 1.9.0 o addirittura dalla 1.8.0) c'e'
sotto qualche bel bug che la rende assolutamente inefficace.
... da cui nasce a catena tutto il casino a seguire 
h) n.b.: si tratta di un bug dalla storia lunga e tormentata.
vedi ticket #122 PROJ4 [guarda caso, aperto proprio da Hamish]
http://trac.osgeo.org/proj/ticket/122
questo bug viene dato come "closed"; ed infatti il problema non e'
affatto nella Proj4, e' tutto dentro a GDAL
cose che capitano quando si apre un ticket nel trac sbagliato
h) giusto per conferma e verifica quick&dirty, ho brutalmente macellato
il codice di GDAL, eliminando radicalmente tutta la sezione legata
all'opzione OVERRIDE_PROJ_DATUM_WITH_TOWGS84
Sorpresa, in questo modo lo script python epsg_tr.py ora mi genera un
"sano" file EPSG vecchio stile, senza piu' nessuna assurdita' +towgs84
giusto se qualche avventuroso si vuole divertire a fare due verifiche,
lo trovate qua: http://www.gaia-gis.it/epsg-trick.zip
------------------
qualche volonteroso se la sente cortesemente di aprire un ticket su GDAL
in base alle informazioni disponibili ???
se permettere, penso di avere gia' dato abbastanza per la causa
ciao Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
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.furieri@lqt.it> ha scritto:
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 and
replaced them with +towgs84= coefficients. ------ cut -----Quindi il casino sembra un po' più esteso della sola zona italiana...
Tra parentesi, si potrebbe pensare che ci siano gli estremi per una
violazione di licenza dei dati EPSG ----- cut -----allora, qualche novita' e qualche approfondimento, spero utili:
a) Proj4 non e' affatto il punto di partenza; e' semplicemente
il punto d'arrivo finale.
come gia' segnalavo ieri (ma forse e' passato inosservato ad
alcuni) le definizioni CRS nascono da GDAL, passano da GeoTIFF
e solo all'ultimo confluiscono in PROJ.4
tutto il ciclo di gestione del file EPSG e' spiegato chiaramente qua:
http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/READMEb) non esiste nessun omino che prepara a mano il file delle definizioni
EPSG: e' semplicemente il risultato di un processo completamente
automatico; per l'esattezza, di uno script Python dentro a GDALc) giusto per pedanteria: il file EPSG ... col cavolo che e' EPSG
il deliverable offerto direttamente da EPSG usa su un medello dati
complicatissimo, basato su decine di tavole e viste DBMS.
non assomiglia minimamente alle semplici stringhe geodetiche di Proj4,
assomiglia piuttosto alla definizioni SRS-WKT
http://www.epsg.org/geodetic.htmld) quindi, correttamente, il famoso e benedetto file EPSG e' semplicemente
un file di testo prodotto internamente da GDAL a beneficio di Proj.4
e di tutti gli altri packages che dipendono dalle Proj.4
ma e' comunque il frutto di una rielaborazione, non e' affatto un
prodotto supportato direttamente da EPSG.e) per motivi che sfuggono all'umana comprensione, ad un certo punto
qualche sviluppatore di GDAL ha deciso di introdurre dalla 1.8.0
un'opzione (infelicissima ...) che consentisse di sostituire tutte
le definizioni +datum con una +towgs84f) saggiamente, si trattava di un'opzione facoltativa: secondo la doc
citata in a) il modo standard per generare il file EPSG era quindi:
epsg_tr.py --config OVERRIDE_PROJ_DATUM_WITH_TOWGS84 FALSE -proj4 \
-skip -list gcs.csv > epsg
(insomma, seguire la vecchia strada consolidata, non la nuova).g) mi sono appena divertito a fare una veloce sessione di debugging
con GDAL trunk: l'opzione OVERRIDE_PROJ_DATUM_WITH_TOWGS84 e'
sicuramente presente nel codice, ma evidentemente nell'implementazione
attuale (e suppongo fin dalla 1.9.0 o addirittura dalla 1.8.0) c'e'
sotto qualche bel bug che la rende assolutamente inefficace.
... da cui nasce a catena tutto il casino a seguireh) n.b.: si tratta di un bug dalla storia lunga e tormentata.
vedi ticket #122 PROJ4 [guarda caso, aperto proprio da Hamish]
http://trac.osgeo.org/proj/ticket/122
questo bug viene dato come "closed"; ed infatti il problema non e'
affatto nella Proj4, e' tutto dentro a GDAL
cose che capitano quando si apre un ticket nel trac sbagliatoh) giusto per conferma e verifica quick&dirty, ho brutalmente macellato
il codice di GDAL, eliminando radicalmente tutta la sezione legata
all'opzione OVERRIDE_PROJ_DATUM_WITH_TOWGS84
Sorpresa, in questo modo lo script python epsg_tr.py ora mi genera un
"sano" file EPSG vecchio stile, senza piu' nessuna assurdita' +towgs84
giusto se qualche avventuroso si vuole divertire a fare due verifiche,
lo trovate qua: http://www.gaia-gis.it/epsg-trick.zip------------------
qualche volonteroso se la sente cortesemente di aprire un ticket su GDAL
in base alle informazioni disponibili ???
se permettere, penso di avere gia' dato abbastanza per la causaciao Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto._______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012
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 ha risolto un bel problema agli utOnti piú comuni.
Infatti qua l'errore dovuto alla riproiezione senza parametri tra questi
3 sistemi é piú *alto* della differenza che c'é tra le origini dei
sistemi stessi potete capire che é una cosa da mal di testa... e
anche se i parametri hanno una "precisione localizzata" vanno bene per
la maggior parte degli usi.
OT
Tra le curiositá geografiche tutte Portoghesi anche quella per cui i
limiti ufficiali del Portogallo continentale sono rappresentanti da una
linea *aperta*...
scaricate il vettore da qua (istituto geografico)
http://mapas.igeo.pt/wfs/sc500k.1
oppure date un'occhiata qua
http://mapas.igeo.pt/Openviewer/sc500k_wms_cont.html
e noterete che all'altezza di Évora/Badajoz il confine tra Portogallo e
Spagna non é marcato...
chi indovina il perché vince un premio!
-- Giovanni --
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 agli utOnti piú comuni.anche se i parametri hanno una "precisione localizzata" vanno bene per
la maggior parte degli usi.
Ciao Giovanni,
nessuno si sogna di sostenere che i parametri +towgs84 non siano utili;
al contrario, sono utilissimi, anzi direi praticamente indispensabili.
ma proprio per questo non possono e non devo stare direttamente dentro alle
EPSG standard (ed infatti, nella versione "pura", non sono affatto previsti).
come giustamente dici anche tu, sono a "precisione localizzata"; e quindi
richiedono una qualche opportuna forma di intervento/scelta da parte
dell'utEnte a seconda della zona di specifico interesse (con buona pace
per gli utOnti ... che poi forse non sono neppure tanto utOnti, quanto
piuttosti mal informati e tratti in inganno dalle magiche "silver bullets"
che alcuni produttori proprietari dispensano a piene mani senza farsi
troppi scrupoli).
presumo che nel caso portoghese tutto sia piu' semplice, considerata la
piu' modesta estensione territoriale. BTW il portogallo (per sua fortuna)
e' quasi esattamente allineato lungo il meridiano, ed ha una modesta
estensione est-ovest.
sfortunatametne l'italia invece e' molto estesa sia in senso nord-sud
(circa 12 gradi) che in senso est-ovest (anche qua, circa 12 gradi).
al di la dell'errata percezione che ci hanno sciaguratamente instillato alle
Elementari, l'italia non e' affatto allineata sul meridiano; e' piuttosto
un bel quadrato, se la misuri correttamente in gradi, che e' l'unica
misura che conta in geodesia.
imporre "sulla punta delle baionette" una specifica versione localizzata
valida sostanzialmente solo per l'Italia centrale lascia malamente scoperte
un sacco di regioni che si trovano in posizioni meno baricentriche: e non
e' quindi una bella soluzione nel nostro caso.
oltre al fatto che complica notevolmente l'uso dei grigliati (occorre prima
ripulire qualsiasi definizione +towgs84 eventualmente presente nella
definizione ESPG di base)
quindi parrebbe abbastanza ovvio che dovremmo inventarci una soluzione piu'
sofisticata (= piu' furba), magari "a due stadi":
- le definizioni "pure" EPSG di base
- piu' altre definizione extra (customizzate, non-EPSG) adatte alle varie
macro-regioni.
se hai seguito il thread, abbiamo anche iniziato a delineare i termini tecnici
per rendere possibile una possibile soluzione di questo tipo, che ovviamente
salverebbe tanto la capra quanto il cavolo:
http://lists.gfoss.it/pipermail/gfoss/2012-May/023090.html
se credi, puoi portare anche tu il tuo personale contributo alla discussione,
sicuramente ben accetto e piu' che gradito visto che ci puoi portare elementi
di conoscenza e di esperienza che esulano dal GB
Tra le curiositá geografiche tutte Portoghesi anche quella per cui i
limiti ufficiali del Portogallo continentale sono rappresentanti da una
linea *aperta*...chi indovina il perché vince un premio!
mica c'entra per caso questo motivo qua ?
http://en.wikipedia.org/wiki/Geography_of_Portugal
Portugal's border with Spain remains a unresolved territorial dispute between
the two countries. Portugal does not recognise the border between Caia and
Cuncos River deltas, since the beginning of the 1801 occupation of Olivenza
by Spain. This territory, though under de facto Spanish occupation, remains
a de jure part of Portugal, consequently no border is henceforth recognised
in this area.
ciao Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
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.
Grazie Margherita,
ho dato seguito all'email di Even.
giovanni
Il 22 maggio 2012 22:25, Margherita Di Leo <diregola@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.htmlciao madi
--
Ing. Margherita Di Leo, Ph.D._______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012
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 record che sono stati ridefiniti ("superceeded")
da altre regole
E' possibile forzare una trasformazione indicandola dentro [3].
Frank invita a suggerire una logica alternativa che permetta di
evitare la "questione italiana". Non credo ci siano opzioni diverse se
dei parametri vanno definiti. Il punto è se sia opportuno definirli
per il 3003 e il 3004...
giovanni
[1] http://lists.osgeo.org/pipermail/gdal-dev/2012-May/032895.html
[2] http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/build_pcs.py
[3] http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/datum_shift_pref.csv
Il 22 maggio 2012 22:48, G. Allegri <giohappy@gmail.com> ha scritto:
Grazie Margherita,
ho dato seguito all'email di Even.giovanni
Il 22 maggio 2012 22:25, Margherita Di Leo <diregola@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.htmlciao madi
--
Ing. Margherita Di Leo, Ph.D._______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012