Ciao, lo so' e capisco la posizione espressa al link che hai postato.
Ma mi pare che il suo ragionamento sia piu' rivolto a come dovrebbe operare internamente un software GS, pouttosto che alla capacit'a di leggere/scrivere correttamente un formato di dati di esportazione. Secondo questi sono due aspetti differenti. Posso capire che per chi realizza il software GIS sia preferibile che il suo software debba sempre sempre ragionare nel medesimo modo. Anche io farei in tal modo, altrimenti sarebbe complicaissimo da gestire. Ma questo non vuol dire che esso non debba capire i dati "altri" quando li apre e li legge. Mi spiego meglio. Un software GIS quando apre un file di dati , le prime due cose che vede sono : il formato dei dati che puo' essere uno dei tanti supportati, vvero nel nostro caso potrebbe essere SHAPEFILE oppure GML. Poi la seconda cosa che il software GIS vede e' il sistema di riferimento di tali dati. Nel caso dello shapefile lo legge dal file PRJ associato, oppure lo chiede all'utente. Nel caso del GML lo trova espresso all'inizio del file GML o anche in ogni riga di dti del file stesso. Nel caso di un shapefile e di un dato in coordinate epsg:4326, ilsoftware puo' benissimo caricarsi i dati correttamente e trattarlilui come fossero espressi in X,Y anziche' in Y,X. Questo perche' il formato shapefile espreime sempre come X,Y. Nel caso del GML con dati in un sistema di riferimento che inverte gli assi. Il software GIS puo' dire: Hey! questo e' un sistema di riferimento ad assi invertiti per cui devo stare attento a leggere i suoi dati perche' gli assi sono invertiti. Quindi il primo valore che leggo e' Y e il secondo e' X. Poi una volta che il software GIS si e' caricato i dati puo' benissimo porseli in formato interno in X,Y perche' cosi' le sue procedure , che sono tutte realizzate per funzionare bene in X,Y funzionano al top. Quindi: internamente un software GIS puo' ragionare sempre in X,Y, ma quando esporta o importa dati da o verso formati che supportano l'inversione degli assi e in sistemi di riferimento che richiedono l'inversione degli assi, deve rispettare la specifica, altrimenti si pone fuori da una logica di colloquio con tutto il resto del mondo. A. Il giorno 4 novembre 2017 16:17, aborruso <aborr...@tin.it> ha scritto: > Ciao Andrea, > segnalo questa pagina https://macwright.org/lonlat/ > > Io sono d'accordo con Tom - "longitude, latitude is the right way" [1] - ma > il panorama è ricco > > Saluti > > [1] > https://macwright.org/2016/07/15/longitude-latitude-is-the-right-way.html > > ----- > Andrea Borruso > > ---------------------------------------------------- > twitter: https://twitter.com/aborruso > website: https://medium.com/tantotanto > 38° 7' 48" N, 13° 21' 9" E > ---------------------------------------------------- > -- > Sent from: http://gfoss-geographic-free-and-open-source-software- > italian-mailing.3056002.n2.nabble.com/ > _______________________________________________ > 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. > 801 iscritti al 19/07/2017 > -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ 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. 801 iscritti al 19/07/2017