[Gfoss] Visualizzazione dati espressi in sistemi di riferimento ad assi invertiti

[Andrea Peri]

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 <aborruso a 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 a 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 àèìòù
-----------------