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

[a . furieri]

On Sat, 4 Nov 2017 17:57:55 +0100, Andrea Peri wrote:

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.



Andrea,

sostanzialmente concordo con la tua analisi che mi pare impeccabile.

purtroppo pero' il mondo reale non e' mai cosi' semplice, e prima o
poi inevitabilmene capita di incontrare dati prodotti da componenti
sw che non seguono le regole, oppure che le interpretano a capocchia.

ragion per cui e' sempre saggio gestire un parametro aggiuntivo ad
hoc che permetta di fare l'override dell'impostazione standard:
p.es. per le funzioni di supporto WFS / WMS di SpatiaLite e
RasterLite2 ho dovuto introdurre "swap_axes=0 | 1" che consente di
forzare o meno l'inversione degli assi quando eventualmente si
incontra un server non conforme alle regole (e capita di incontrarne
molto piu' spesso di quanto uno si immagini).
e mi par di capire che pure GDAL offre qualcosa di analogo per
il GML.

insomma, alla fin fine il fatto che tutti gli standard OGC piu'
recenti impongano di invertire gli assi quando si tratta di
sistemi di coordinate geografici (ed in pochi altri casi, come
i nostri ultimi italici IGM) non e' una tragedia, ma e'
sicuramente una fonte di confusione di cui si sarebbe fatto
volentieri a meno.

giusto per finire, penso che sia illuminante rocordare come e
perche' da un certo punto in poi le specifiche OGC hanno cambiato
improvvisamente rotta introducendo questo strano criterio di
inversione degli assi per le coordinate geografiche.
Sono personalmente al corrente dei fatti perche' me li ha
riferiti Paul Daisey di OGC quando collaboravamo per la messa
a punto della specifica GPKG.

- inizialmente tutte le specifiche OGC davano sempre per
  scontato che la prima coordinata rappresentasse la X e
  la seconda la Y.
  ergo, nel caso delle coordinate geografiche prima veniva
  la longitudine e seconda la latitudine, cosi' come pareva
  logico e scontato (almeno: agli occhi di tutte le persone
  di formazione prevalemente informatica).

- a quel punto pero' hanno iniziato a fioccare le proteste
  di chi invece aveva una formazione geografica nel senso
  piu' tradizionale: ormai da secoli vale la regola universale
  per cui si parla sempre di latitudine e longitudine in
  questo esatto ordine; e quindi l'ordine "informatico"
  longitudine e latitudine e' stato giudicato innaturale
  e da respingere tout court.

- ovviamente gli informatici hanno provato a resistere con
  le unghie e con i denti, ma alla fine hanno perso.
  ed ecco che ora tutti gli standard piu' recenti di OGC
  (WMS, WFS, GML etc) impongono l'inversione degli assi
  quando sono in ballo le coordinate geografiche.
  Peccato pero' che tutti gli Spatial DBMS si sono ben
  guardati dal seguire la nuova regola "inversa", e
  quindi si e' venuto a creare un ovvio punto di
  conflitto.

conclusione: a volte il meglio e' nemico del bene :-D

ciao Sandro




___
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

Re: [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  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

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

[aborruso]

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

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

[Andrea Peri]

Salve,
volevo ringraziare quanti si sono interessati del problema e hanno fornito
soluzioni.

Nel frattempo avevo risolto.
Infatti avevo segnalato il problema all'autore del nostro software di
conversione dipartimentale il quale pure esso aveva il "bugghe" di non
considerare l'inversione di coordinate in epsg:4326 nel formato GML.
L'autore, espertissimo della materia, ha corretto il software e ora siamo
di nuovo operativi su questo fronte.

Tra le risposte mi e' stato segnaalto un workaround tramite il comando
swapcoordinates (o qualcosa di simile) di spatialite e usato da pgr per
generare un nuovo GML con le coordinate invertite e quindi corrette per
qgis.

Il workaround e' sicuramente valido e aiuta nel momento del bisogno.
Pero' da un punto di vista piu' generale , il problema resta, infatti.
Doversi ricondurre da un GML in epsg:4326 che ha correttamente le
coordinate espresse in
"latitudine longitudine" a un altro GML che in coordinate pesg:4326 ha le
coordinate espresse in maniera errata
ovvero in "longitudine latitudine" e' una sconfitta.
Perche' siamo in un caso i cui uno standard deve piegarsi alla volonta' di
una serie di softwares che impongono una cosa differente.

Poi, mi domando quanti saranno gli utenti che di fronte a una mappa ruotata
capiranno che il problem e' dovuto a una non inversione di assi.
E non ultimo il fatto che mi sono accorto che la mappa era invertita
perche' lo stivale d'italia si riconosce abbastanza bene, se erano poligoni
di forma generica,
il fatto di rilevarli lontano dalla zona attesa poteva essere imputabile a
un errore di georefereniazione del dato originale.

Insomma capire dove sta il vero problema rischia di divenire difficile.
Per cui 'unica difesa e' ricordarselo e nel caso ci si trova di fronte a
cose di questo genere ricordarsi che forse siamo di fronte a una mancata
inversione di assi.

Anche in virtu' , ricordo, che il nuovo sistema di riferimento italiano
prevede anche lui gli assi invertiti , e quindi quando comincera' a
circolare del gml espresso in epsg:6707/6708 e' facile prevedere parecchi
problemi.
Il workaround segnalato da Paolo Craveri sara' veramente gettonato.

Infine una curiosita' su QGIS:
A questo proposito mi era stato fornito una risposta in merito a QGIS in
particolare:
Sembra infatti che qgis avesse un settaggio con cui lo si istruisce di non
eseguire l'inversione degli assi e mi hanno fatto notare che probabilmente
il mio qgis era settato per non eseguire l'inversione degli assi.
Non sapevo di questo settaggio , lo ho cercato in qgis , ma non sono
riuscito a trovarlo.
Se riesco a scoprire qualcosa faccio sapere.

Saluti e di nuovo grazie per i contributi.
A.


Il giorno 2 novembre 2017 08:58, Andrea Peri  ha
scritto:

> Salve,
> l'argomento mio riguarderebbe QGIS, ma penso che in realta' abbia una
> valenza piu' larga perche' sospetto che il problema possa essere presente
> anche in altri prodotti.
>
> In soldoni:
> mi sono scaricato dal portale nazionale un dataset italiano in epsg:4326 e
> in formato GML.
>
> Quando vado a visualizzarlo con QGIS (2.18), mi accorgo che viene
> visualizzato ribaltato sui due assi.
>
> La spiegazione che io mi do' e'che QGIS non gestisce correttamente i dati
> espressi in sistemi di riferimento ad assi invertiti quando pesca da
> formati che ribaltano i valori.
> Nel caso del GML, se si esprime dati in epsg:4326,
> le coordinate dei punti anziche' essere
>
>  
>
> diventano
>  
>
> Questa cosa qui provoca su qgis una visualizzazione errata.
>
> Sospetto che questo problema possa essere comune anche ad altri sistemi
> gis.
> E' importante notare che la comparsa del problema e' legata anche
> all'impiego del formato GML.
> Infatti uno shapefile non si comporta come il GML e non usa invertire il
> significato dei valori nella coppia  .
>
> Per cui unoshapefle in epsg:4326 e' sempre visualizzato correttamente.
>
> La questione non e' trascurabile se si considera che anche il sistema di
> riferimento epsg:6707 e epsg:6708 nuovi sistemi da usare per la produzione
> dei dati a livello nazionale sono ad assi invertiti.
> Per cui temo che un GML espresso in epsg:6707 sarebbe analogamente
> visualizzato male (e quindi gestito male) dai software gis che non
> supportano l'inversione degli assi.
>
> Andrea.
>
> --
> -
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -
>



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

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

[Andrea Peri]

In effetti e' un workaround interessante e valido .
Grazie.

A.


Il giorno 3 novembre 2017 09:20, Paolo Craveri  ha
scritto:

> non so se può essere utile
>
> https://trac.osgeo.org/gdal/wiki/FAQVector#HowdoIflipcoordinateswhentheya
> renotintheexpectedorder
>
> in pratica:
>
> ogr2ogr -dialect SQLite -sql "SELECT SwapCoordinates(geometry) AS
> geometry, * FROM source" dest.shp source.shp
>
>
>
> ciao
>
> Il giorno 2 novembre 2017 09:01, Luca Delucchi  ha
> scritto:
>
>> 2017-11-02 8:58 GMT+01:00 Andrea Peri :
>> > Salve,
>>
>> Ciao Andrea,
>>
>> > l'argomento mio riguarderebbe QGIS, ma penso che in realta' abbia una
>> > valenza piu' larga perche' sospetto che il problema possa essere
>> presente
>> > anche in altri prodotti.
>> >
>> > In soldoni:
>> > mi sono scaricato dal portale nazionale un dataset italiano in
>> epsg:4326 e
>> > in formato GML.
>> >
>>
>> potresti mandare il link così provo su GRASS?
>>
>> > Andrea.
>> >
>>
>>
>> --
>> ciao
>> Luca
>>
>> www.lucadelu.org
>> ___
>> 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
>>
>
>
>
> --
> --
> Paolo Craveri
>



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

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

[aborruso]

Ciao Andrea,
penso che tutto possa dipendere da questo

"Since OGR 1.8.0, the GML driver has coordinate system support. This is only
reported when all the geometries of a layer have a srsName attribute, whose
value is the same for all geometries. For srsName such as
"urn:ogc:def:crs:EPSG:" (or "http://www.opengis.net/def/crs/EPSG/0/;
starting with GDAL 2.1.2), for geographic coordinate systems (as returned by
WFS 1.1.0 for example), the axis order should be (latitude, longitude) as
required by the standards, but this is unusual and can cause issues with
applications unaware of axis order. So by default, the driver will swap the
coordinates so that they are in the (longitude, latitude) order and report a
SRS without axis order specified. It is possible to get the original
(latitude, longitude) order and SRS with axis order by setting the
configuration option GML_INVERT_AXIS_ORDER_IF_LAT_LONG to NO."

Quando anni fa ho avuto un problema simile (accedevo via GDAL), quanto letto
qui [1] fu risolutivo.

Saluti

[1] http://www.gdal.org/drv_gml.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

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

[Paolo Craveri]

non so se può essere utile

https://trac.osgeo.org/gdal/wiki/FAQVector#HowdoIflipcoordinateswhentheyarenotintheexpectedorder

in pratica:

ogr2ogr -dialect SQLite -sql "SELECT SwapCoordinates(geometry) AS geometry,
* FROM source" dest.shp source.shp



ciao

Il giorno 2 novembre 2017 09:01, Luca Delucchi  ha
scritto:

> 2017-11-02 8:58 GMT+01:00 Andrea Peri :
> > Salve,
>
> Ciao Andrea,
>
> > l'argomento mio riguarderebbe QGIS, ma penso che in realta' abbia una
> > valenza piu' larga perche' sospetto che il problema possa essere presente
> > anche in altri prodotti.
> >
> > In soldoni:
> > mi sono scaricato dal portale nazionale un dataset italiano in epsg:4326
> e
> > in formato GML.
> >
>
> potresti mandare il link così provo su GRASS?
>
> > Andrea.
> >
>
>
> --
> ciao
> Luca
>
> www.lucadelu.org
> ___
> 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
>



-- 
-- 
Paolo Craveri
___
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

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

[Luca Delucchi]

2017-11-02 8:58 GMT+01:00 Andrea Peri :
> Salve,

Ciao Andrea,

> l'argomento mio riguarderebbe QGIS, ma penso che in realta' abbia una
> valenza piu' larga perche' sospetto che il problema possa essere presente
> anche in altri prodotti.
>
> In soldoni:
> mi sono scaricato dal portale nazionale un dataset italiano in epsg:4326 e
> in formato GML.
>

potresti mandare il link così provo su GRASS?

> Andrea.
>


-- 
ciao
Luca

www.lucadelu.org
___
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