Re: [Gfoss] Visualizzazione dati espressi in sistemi di riferimento ad assi invertiti
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
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
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
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
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
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
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
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
