caricamento layer WMS in qGis

[francesco marucci-2]

gentile lista,
abbiamo trovato alcuni comportamenti di qGis rispettto al caricamento di servizi WMS che secondo noi andrebbero migliorati
ed altre funzionalità che potrebbero essere aggiunte.

ci rivolgiamo a questa lista, prima di aprire eventuali ticket in qGis, per avere anche il vostro prezioso contributo in proposito e/o per sapere se stiamo proponendo argomenti che sono stati già trattati (e/o scartati) nell'ambito della cerchia di sviluppatori/utenti di qGis.

i nostri ragionamenti riguardano soprattutto il caricamento dei layer di un servizio WMS;

1.
comportamento secondo noi scorretto:

nella finestra "Aggiungi layer dal server", dopo la lettura delle capabilities qGis mostra i layer nello stesso ordine con il quale sono stati catalogati nelle capabilities e fin qua tutto a posto:
il primo in alto nelle capabilities corrisponde al primo in altro nella lista di qGis, e cosi' via.

quando pero' l'utente sceglie la root dei layer e (combinazione non poco frequente) questa root non possiede nelle capabilities il tag Name (che la rende a tutti gli effetti un gruppo di layer), qGis si appresta a caricare nella mappa tutti i layer appartenenti alla root, ma nell'ordine INVERSO a quello che ci si aspetterebbe, ovvero prima quello che nell'ordine delle capabilities si trova piu' in basso fino ad arrivare a quello piu' in alto, con la conseguenza (per noi disastrosa) che nella mappa il primo ad essere caricato si ritrova in fondo e l'ultimo sopra tutti gli altri (e non e' quello che volevamo).
se volete fare una prova, il seguente WMS puo' chiarire le idee:
http://servizigis.regione.emilia-romagna.it/wms/geologia50k

e voi a questo punto chiederete, e perche' non mettete il tag Name nella root, in modo che qGis costruisca la getMap con quel nome gestito come un layer, delegando l'ordine dei layer al server (che non puo' sbagliare) ? La risposta è molto semplice: perchè il nostro server WMS (Arcgis Server) non gestisce assolutamente i gruppi di layer (è proprio un concetto che non ha nel suo cervelletto, almeno la 9.3, dalla 10 chissà), ed è per quello che non mette il tag Name, in modo che a nessun utente venga in mente di costruire una getMap&LAYERS=[nome root], che poi lui non e' in grado di risolvere.

in ogni modo, non stiamo chiedendo che qGis si adatti ad una plateale mancanza di Arcgis Server, ma questa mancaza ci ha fatto notare che qGis, quando costruisce la concatenazione di layers per il parametro LAYERS della GetMap lo fa in modo inverso a quello che ci si aspetterebbe; anche selezionando manualmente i singoli layer, il primo selezionato finisce sempre in fondo alla lista LAYERS mentre l'ultimo selezionato rimane primo della lista: quando poi la GetMap viene eseguita, nella mappa il primo layer richiesto sarà il background della canvas e l'ultimo sarà sopra tutti gli altri; ma l'ordine letto dalle capabilities suggeriva esattamente il contrario.
per assurdo, per caricare i layer nell'ordine corretto, nella finestra "Aggiungi layer dal server" di qGis bisogna selezionarli dal basso verso l'altro, per ottenere un ordine di caricamento nella mappa corretto.
secondo noi questo è profondamente scorretto, perchè non permette all'utente di caricare in modo intuitivo i diversi layer nell'ordine corretto.

per fare un esempio, abbiamo un WMS che espone tre layer, il layer A di punti, il B di linee e il C di poligoni.
noi vogliamo che l'utente quando carichi il WMS come un pacchetto, si ritrovi con i layer nel seguente ordine:
il layer C come background della mappa, il B sopra i poligoni e sopra a tutto i layer A di punti;
le nostre capabilities saranno quindi:

- layer C
- layer B
- layer A

in modo che la corretta richiesta GetMap sia costruita per &LAYERS=C,B,A, prima vengono disegnati i poligoni, poi le linee e poi i punti, e tutto torna.
qGis invece costruisce tale richiesta &LAYERS=A,B,C, cioe' in ordine inverso rispetto a quello che legge nelle capabilities.

da notare che tutti i client WMS che abbiamo sotto mano si comportano in modo da disegnare per primo i layer che nelle capabilities viene indicato per primo e così via fino all'ultimo.
anche lato server l'ordine di un lista di layer esprime la volontà di avere nella mappa il primo layer della lista in basso (poligoni) e l'ultimo della lista in alto (punti): penso ad esempio al .map di mapserver.

è anche vero che la finestra "Aggiungi layer dal server" possiede anche una linguetta "Ordine layer", che permette di cambiare manualmente l'ordine dei layer, ma, sinceramente non ci è molto chiaro a cosa serva, visto che poi l'ordine dei layer nella richiesta GetMap costruito da qGis è comunque inverso a quello che ci si aspetta.

è anche vero che nella finestra "Aggiungi layer dal server" è possibile ordinare i layer per nome, per titolo e anche per l'ID di qGis: ordinando inversamente per questo ID otteniamo esattamente l'ordine che noi abbiamo voluto esprimere nelle capabilities, pero' riteniamo che questo ordine dovrebbe essere quello di default che si trova l'utente, non che debba ogni volta essere riordinato in questo modo (ordine inverso dell'ID), anche piuttosto nascosto, sinceramente.

nell'immagine:
http://geo.regione.emilia-romagna.it/fra/finestra_aggiungi_layer_attuale.jpg
abbiamo catturato l'attuale comportamento secondo noi impreciso,
mentre nell'immagine:
http://geo.regione.emilia-romagna.it/fra/finestra_aggiungi_layer_proposta.jpg
quello che secondo noi potrebbe essere auspicabile.
 


2.
come proposto nella immagine sopracitata, riteniamo utile poter caricare diversi layer di un servizio WMS, continuando a gestirli in modo separato nella TOC (anche eventualmente per cambiarne l'ordine): proponiamo dunque un checkbox che se attivato carica i layer scelti (ovviamente se ce n'e' piu' di uno) come diversi layer nella TOC, costruendo una GetMap per ogni layer.



3.
altro aspetto che riteniamo piuttosto importante è la questione dei limiti di scala associati ad un layer WMS, che attualmente non credo siano gestiti in qGis: lato server, molto spesso, un layer ha dei limiti di visualizzazione delle entità in funzione della scala, nel senso che se richiedo una GetMap ad una scala che risulta aldifuori del range di visualizzazione, otterrò una mappa bianca (a meno che il WMS non sia stato costruito intelligentemente in modo da indicare nell'immagine che la mappa è fuori scala, ma spesso non e' così). le capabilities, per avvertire gli utenti che puo' avvenire un comportamento del genere (immagine bianca) hanno due tag dedicati: nelle versioni 1.0.0, 1.1.0 e 1.1.1 il tag è lo scalehint (min e max), mentre dalla 1.3.0 sono il minscaledenom e maxscaledenom. sarebbe bello che qGis leggesse questi valori (per lo scalehint non e' immediato per risalire alla scala ma si fa) e li mostrasse in qualche modo (indicazione nella finestra "Aggiungi layer dal server" o nei metadati oppure layer sgrigiato nella toc) all'utente in modo che capisca il motivo dell'immagine bianca. una soluzione elegante potrebbe essere che al caricamento di un layer WMS qGis assegni gli stessi limiti di scala, se presenti, dalle capabilities al layer nella TOC, spuntando nella linguetta "Generale" delle proprietà del layer la voce "Visibilità dipendente dalla scala" ed inserendo i valori letti dalle capabilities, in modo che l'utente possa risalire al motivo per il quale non vede nulla nella mappa. Ancor più bello sarebbe (in linea generale per tutti i tipi di layer) che in funzione di quei valori e della scala della mappa, nella TOC il nome del layer fosse sgrigiato se fuori scala.


 
4.
potrebbe essere utile che un layer WMS venga caricato nella TOC prendendo il nome non dal tag Name ma dal tag Title; ovviamente questo aspetto si accentua molto con servizi WMS esposti da prodotti ESRI, ArcIMS e ArcGis server (dicono che dalla versione 10 questo cambierà, ma chissà quanto tempo passerà prima che si esponga con quella versione) che notoriamente indicano nel tag Name un indentificativo non parlante (numero da zero in poi), ed è quindi poi difficile distinguerli nella TOC.



5.
nella finestra "Aggiungi layer dal server" riteniamo importante poter visualizzare il campo "Abstract" per intero (puo' essere anche piuttosto lungo, se deve descrivere cosa contiene un layer): proponiamo dunque di poter "vedere" su piu' righe il contenuto del tag, oppure poter scorrere per interno il testo fino alla fine, o soluzioni simili



rimaniamo in attesa di vostro prezioso contributo, prima di eventualmente coinvolgere la comunità di sviluppatori di qGis.

saluti,
francesco
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011

[Andrea Peri]

E' un problema che conosco abbastanza bene anche io :)

Le specifiche OGC-WMS dicono chiaramente che se ho una lista del tipo:

layers=id-0,id-1,id-2,id-3

il server wms deve tracciare
prima id-0 , poi ci deve tracciare sopra (coprente)  l' di-1 , poi l'id-2, etc....

>A WMS shall render the requested layers by drawing the leftmost in the list bottommost, the next one over that,
>and so on.

Purtroppo, il problema sta nel get-capabilities.
Personalmente non ho mai trovaot scritto da nessuna parte che il primo strato elencato nel get-capabilities fosse il bottom-layer e l'ultimo il top-layer.

Non essendo normata , questa cosa, va all'i9nterpretazione del client-gis. Il quale a seconda di come gli gira (e di come gli torna meglio con la tecnologia che sua)
decide che il primo strato del get-capabilities e' il top-layer o il bottom-layer.

Di conseguenza chiedere che ti cambino il senso di interpretazione e' troppoo drastico (se era un errore di interpretazione delle specifiche era un altro conto),
cambiarlo potrebbe  interferire con un qualcosa che altri hanno gia' costruito seguendo l'attuale sistema di qgis.

Piu' ragionevole e' chiedere che venga messa tra i settaggi una checkbox che indichi a qgis in che modo interpretare il get-capabilities, partendo dal top-layer o dal bottom-layer.

L'utente sceglierebbe cosi' a livello di customizzazione personale se qgis nel wms deve agire in senso ascendente o discendente.


--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------


_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011

[Andrea Peri]

>2.
>come proposto nella immagine sopracitata, riteniamo utile poter caricare
>diversi layer di un servizio WMS, continuando a gestirli in modo separato
>nella TOC (anche eventualmente per cambiarne l'ordine): proponiamo dunque un
>checkbox che se attivato carica i layer scelti (ovviamente se ce n'e' piu'
>di uno) come diversi layer nella TOC, costruendo una GetMap per ogni layer.


Un comando veramente interessante.
Richiede una certa competenza da parte dell'utente.
Il problema infatti e' il tipo di immagine che vuoi produrre.
Infatti se vuoi una mappa composta di 10 strati e li tratti come 10 chiamate getmap distinte,
il primo risultato sicuro e' che a costruirtela ci mette 10 volte il tempo che ci mette a costruirtela
mettendoli tutti insieme.
Poi hai un altro problema:
Se l'immagine e' JPEG, il jpeg non consente la trasparenza e quindi uno strato (che se vuoto ) copre l'altro .
Per cui devi fare ricorso necessariamente a GIF o PNG.
Poi pero' con il GIF hai il problema che esso non consente piu' di 256 colori e quindi non va assolutamente bene
per proporre mappe derivanti da OFC a colori.
E quindi resta solo il PNG.

Come dicevo serve un utente competente, che capisce che deve anche chiedere una immagine in formato PNG altrimenti
viene fuori un pastrocchio.

>3.
>altro aspetto che riteniamo piuttosto importante è la questione dei limiti
>di scala associati ad un layer WMS, che attualmente non credo siano gestiti
>in qGis: lato server, molto spesso, un layer ha dei limiti di
>visualizzazione delle entità in funzione della scala, nel senso che se
>richiedo una GetMap ad una scala che risulta aldifuori del range di
>visualizzazione, otterrò una mappa bianca (a meno che il WMS non sia stato
>costruito intelligentemente in modo da indicare nell'immagine che la mappa è
>fuori scala, ma spesso non e' così). le capabilities, per avvertire gli
>utenti che puo' avvenire un comportamento del genere (immagine bianca) hanno
>due tag dedicati: nelle versioni 1.0.0, 1.1.0 e 1.1.1 il tag è lo scalehint
>(min e max), mentre dalla 1.3.0 sono il minscaledenom e maxscaledenom.
>sarebbe bello che qGis leggesse questi valori (per lo scalehint non e'
>immediato per risalire alla scala ma si fa) e li mostrasse in qualche modo
>(indicazione nella finestra "Aggiungi layer dal server" o nei metadati
>oppure layer sgrigiato nella toc) all'utente in modo che capisca il motivo
>dell'immagine bianca. una soluzione elegante potrebbe essere che al
>caricamento di un layer WMS qGis assegni gli stessi limiti di scala, se
>presenti, dalle capabilities al layer nella TOC, spuntando nella linguetta
>"Generale" delle proprietà del layer la voce "Visibilità dipendente dalla
>scala" ed inserendo i valori letti dalle capabilities, in modo che l'utente
>possa risalire al motivo per il quale non vede nulla nella mappa. Ancor più
>bello sarebbe (in linea generale per tutti i tipi di layer) che in funzione
>di quei valori e della scala della mappa, nella TOC il nome del layer fosse
>sgrigiato se fuori scala.

Probabilmente questa strategia è utile in certi casi di uso, ma in altri potrebbe
generare dei fraintendimenti.
Ad esempio se l'utente chiede una mappa composta di tre strati:

uno che si accende a tutte le scale, uno che si accende da 1:1 - 1:10.000 e uno che si accende da 1:5.000 - 1:1.15.000

da quello che capisco il sistema dovrebbe renderle attivabili solo nell'intervallo 1:5.000-1:10.000

Non vi e' il rischio di rendere il sistema assolutamente complicato e quindi semplicemente scoraggiare l'utente dall'impiegarlo ?

Una proposta del genere va bene solo nel caso in cui a una getmap e' abbinato un unico strato.

>4.
>potrebbe essere utile che un layer WMS venga caricato nella TOC prendendo il
>nome non dal tag Name ma dal tag Title; ovviamente questo aspetto si
>accentua molto con servizi WMS esposti da prodotti ESRI, ArcIMS e ArcGis
>server (dicono che dalla versione 10 questo cambierà, ma chissà quanto tempo
>passerà prima che si esponga con quella versione) che notoriamente indicano
>nel tag Name un indentificativo non parlante (numero da zero in poi), ed è
>quindi poi difficile distinguerli nella TOC.

Ma senti un po' che ti combina l'arcgis-server :))

Io conosco abbastanza bene arcims di esri, e li' assolutamente il title lo metti te come ti pare meglio.
Altro che 0,1,2,3....

Per il resto l'ipotesi non mi convince proprio per il fatto che
l'id e' di solito piu' condensato.
Noi ad esempio ci scriviamo "idcomuni", "idprovince", "idparticella".
Quando compongo la mappa e ne faccio una sola che ci mette dentro tutti e tre, il buon qgis,
parte chiamandolo:

"idcomuni/idprovince/idparticella"

se ci scrivesse:
"Ambito amministrativo comunale/Ambito amministrativo provinciale/particelle catastali"

Troppo estesa,


>5.
>nella finestra "Aggiungi layer dal server" riteniamo importante poter
>visualizzare il campo "Abstract" per intero (puo' essere anche piuttosto
>lungo, se deve descrivere cosa contiene un layer): proponiamo dunque di
>poter "vedere" su piu' righe il contenuto del tag, oppure poter scorrere per
>interno il testo fino alla fine, o soluzioni simili

Non capisco l'utilità della cosa (almeno per voi).

Voi fate tanti servizi distinti.
Uno per ogni singolo strato.
Pertanto l'utente prima di scegliere deve gia' sapere cosa sta scegliendo.
Secondo me dovreste potenziare un sistema di ricerca su ISO19115.
A che vi serve spedire l'abstract sul WMS?

Lo capirei se metteste tutti i vostri archivi in un unico servizio WMS, e allora l'utente si legge
la descrizione di tutti gli strati e decide quali vuole.
Ma pouiche' avete tutto distribuito in tanti servizi WMS distinti, l'utente dovrebbe chiamarseli tutti
uno per uno per leggersi l'abstract di ciascuno di essi ?

Vale la pena fare uno sforzo per metterci l'abstract ?
Che oltre tutto richiede di superare alcune problematiche, tra cui anche la pesantezza.
Un getcapabilities completo di abstract e' grande almeno 10 volte un get-capabilities normale.

Piuttosto,
se ho cpatio i vostri problemi di base:
avrei un suggerimento  alternativo :

Perche' non mettete in linea una serie di progetti QGIS gia' pronti e confezionati per consultare i vostri dati,
ove ci inserite nella legenda gli strati che ritenete utili, li etichettate come e' giusto fare e impostate le giuste scale.
L'utente si scarica il progetto qgis e lo apre, et-voila vede il progetto come pensato e come è giusto che sia visto.

QGIS permette di avere il settaggio del server wms direttamente nel progetto e quindi se mettete in linea i progetti qgis gia' confezionati,
lutente si scarica quelli e vede subito i vostri dati presi a modino dai vostri servers WMS.

A me pare una soluzione ottimale.

Saluti,

Andrea.


--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------






--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------


_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011

[amefad]

2011/8/24 francesco marucci <[hidden email]>

gentile lista,
abbiamo trovato alcuni comportamenti di qGis rispettto al caricamento di servizi WMS che secondo noi andrebbero migliorati
ed altre funzionalità che potrebbero essere aggiunte.

Dissento su tutta la linea, ma forse sono io che ho una concezione particolare degli utenti.

1.
l'orinde dei layer non è intuitivo, quasi sempre ci si trova di fronte ad una pagina bianca.

Chi usa i servizi WMS deve comunque essere un utente un po' evoluto o che ha voglia di evolversi, occorre perlomeno avere chiari i concetti di CRS e proiezione al volo, oltre a qualche nozione su http, reti, proxy etc.
La risposta del GetCapabilities è non a caso human-readable ed è bene che i bipedi che intendono usare un servizio WMS la leggano prima di lanciare il proprio client preferito.
Non si riuscirà mai a fare un WMS "a prova di stupido" (come diceva mio padre) e anche se io non ho mai provato ad usarli ho visto passare in lista ottimi metodi per salvare il progetto di Qgis con la TOC nell'ordine desiderato.
Gran parte dei servizi offerti dalle regioni e dal PCN inoltre hanno una singola URL per ciascun layer, per cui il problema non si pone.

in ogni modo, non stiamo chiedendo che qGis si adatti ad una plateale mancanza di Arcgis Server.

 Ah, meno male, avevo preso paura all'inizio...

2.
Layer separati nella TOC

E' una feature che ha senso, ma non vedo la necessità di inserirla in Qgis a meno che non ci sia un ente o azienda disposto a finanziare questo lavoro e metterlo a disposizione di tutti.

3.
Limiti di scala

Come sopra, ritengo che non si aggiungono layer WMS a un progetto come gli amici su fb: come utente mi informo prima su cosa contiene il livello e a quali scale è distribuito (nel metadato non c'è?)

4.
Usare il tag Title al posto del tag Name

Questo mi pare adattarsi a ESRI, commercialmente non si fa.


5.
Visualizzare il tag abstract su più righe

Su questo, sorpresa, sono d'accordo, anche se immagino che i contenuti dell'abstract siano diponibili anche alla pagina web dove è disponibile l'URL del servizio o nel sommario del metadato.

---
Considerazione più generale: cosa significa promuovere e far crescere il sw libero?
Aumentare il numero di utenti? No.
Quello è l'obbiettivo di chi vende il software o ci vende pubblicità sopra (vedi Google) per il SW GFOSS significa solo avere più richiesta di aiuto e di nuove feature a cui rispondere.

Credo che l'obbiettivo sia quello di aumentare il numero di persone che contribuiscono al sw con soldi o codice, gli utenti crescono di conseguenza.
Chi produce SW commerciale lascia volutamente alcune funzionalità oscure e fuori standard, perché i menu ben nascosti  sono pane per i consulenti e i corsi di formazione mentre dissuadono l'utente dall'usare un altro sw che "ha i menu tutti diversi".

Detto questo ovviamente può essere opportuno coinvolgere gli sviluppatori su queste richieste, visto che è stato chiesto un parere, questi sono i miei 2 cent.

amefad

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
527 iscritti al 7.7.2011