GaussBoaga / Proj4 v.3.8.0

[pcav]

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 che andrebbe fatto in un mondo perfetto.

capisco, ma non dare i parametri di correzione e' comunque un danno per gli utenti;
alternative?
saluti.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[geodrinx]

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

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[Luca Delucchi]

Il 21 maggio 2012 11:27, Vito Borneo <[hidden email]> 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
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

Il 21 maggio 2012 14:38, Luca Delucchi <[hidden email]> ha scritto:

> Il 21 maggio 2012 11:27, Vito Borneo <[hidden email]> 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
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[a.furieri]

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.

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[pcav]

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
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[pcav]

Il 21/05/2012 15:21, [hidden email] 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
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[giohappy]

Il 21 maggio 2012 15:30, Paolo Cavallini <[hidden email]> 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 migliori
>
> veramente 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
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> Non inviate messaggi commerciali.
> I messaggi di questa lista non rispecchiano necessariamente
> le posizioni dell'Associazione GFOSS.it.
> 584 iscritti al 7.4.2012

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[giohappy]

> 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
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> Non inviate messaggi commerciali.
> I messaggi di questa lista non rispecchiano necessariamente
> le posizioni dell'Associazione GFOSS.it.
> 584 iscritti al 7.4.2012

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[pcav]

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
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[pcav]

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
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[giohappy]

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

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[Vito Borneo-2]

Certo...

ehiweb

Vito

---

Da: "[hidden email]" <[hidden email]>
A: [hidden email]
Inviato: Lunedì 21 Maggio 2012 11:54
Oggetto: Re: [Gfoss] Consiglio PostgresSQL + Postgis + ...

Non per far pubblicità a qualcuno, ma dato che il tuo provider potrebbe
risutlare utile ad altri ci dici chi è?

Iacopo


_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[geodrinx]

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

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[pcav]

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
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[a.furieri]

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 :-D
    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 :-P

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 :-P

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 :-P

ciao Sandro




--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[giohappy]

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,  <[hidden email]> 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/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 :-D
>   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 :-P
>
> 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 :-P
>
> 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 :-P
>
> ciao Sandro
>
>
>
>
> --
> Il messaggio e' stato analizzato alla ricerca di virus o
> contenuti pericolosi da MailScanner, ed e'
> risultato non infetto.
>
>
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> Non inviate messaggi commerciali.
> I messaggi di questa lista non rispecchiano necessariamente
> le posizioni dell'Associazione GFOSS.it.
> 584 iscritti al 7.4.2012

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[Giovanni Manghi-2]

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

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[a.furieri]

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 :-D


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

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[margherita]

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.

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012