> 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 error
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
> > t
On Wed, 23 May 2012 14:57:48 +0200, Geo DrinX wrote:
volevo segnalarti, tra l'altro, uno strano comportamento di QGis
usando i confini di regione "non generalizzati" di Istat:
trascinando il file il QGis, invece di ED50, il SR risulta essere:
ELD79 / UTM zone 32N ovvero EPSG:2077
mentre il
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
Grazie per il punto Sandro e Giovanni,
2012/5/23 G. Allegri
>
> 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
> trasformazion
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
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 a
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: c
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 i
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 pro
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 imple
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 reco
Grazie Margherita,
ho dato seguito all'email di Even.
giovanni
Il 22 maggio 2012 22:25, Margherita Di Leo 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
>
> --
> Ing. Margher
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
http://lists.gfoss.it/cgi-bin/mailman/listinfo/g
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 ag
> 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
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, ha scritto:
> On Mon, 21 May 2012 13:36:02 +020
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 an
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
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
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
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
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 in
> 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
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+Faunali
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 sign
> 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/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 quell
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 ap
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 an
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 com
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
_
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 dettag
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 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 introdurr
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
definizioni
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' abbiam
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.
O
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, ha scritto:
> On
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:
http://spatialreference.org/ref/eps
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 spec
2012/5/20
> 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.)
>>>
>>
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
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 aff
44 matches
Mail list logo