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