layer WFS

Ricevere e visualizzare layer WFS

La classe che in OL3 è dedicata a gestire dati WFS è ol.format.WFS che appunto permette sia di leggere che scrivere geodati vettoriali nel formato WFS; ma questa non prevede dei metodi per effettuare una richiesta dati (GetFeature) ad  un server remoto WFS.

Dato che i diversi server WFS, possono comunque avere modalità di risposta con delle differenze e quindi era abbastanza difficile prevedere una funzione unica valida per tutti, in OL3 si è scelta la strada di lasciare all’utente di creare un loader ad hoc per ogni sorgente WFS.
Precisamente nell’oggetto ol.source.Vector si può definire come opzione loader (funzione per caricare delle features vettoriali da una sorgente remota) una jQuery AJAX che implementa la richiesta WFS GetFeature con tutti i parametri necessari.

Quando l’esecuzione del loader (jQuery) viene completata e si ricevono i dati WFS, a questo punto interviene il metodo readFeatures(..) dell’oggetto ol.format.WFS per leggere gli elementi (features) che lo compongono.

Per fare un esempio concreto, abbiamo scelto un servizio WFS  del Ministero della Cultura della Danimarca che espone diversi dati vettoriali tramite il seguente URL:

kulturav.dk

Per avere informazioni più dettagliate su quali sono i layer disponibili e le modalità di erogazione del servizio  facciamo una richiesta GetCapabilites; noi abbiamo scelto di leggere un layer di nome  “public:fundogfortidsminder_areal_alle”  e le seguenti righe sono la risposta della GetCapabilities che lo riguarda:

Tra le varie info, abbiamo l’elenco dei CRS (Coordinate Reference System) con i quali il layer viene esposto e notiamo che c’è anche l’EPSG 3857 ovvero il sistema di default di OpenLayers. Questo è uno dei motivi per cui abbiamo scelto questo servizio WFS, in quanto altrimenti le cose si complicano leggermente (lo vediamo più avanti).

Abbiamo quindi tutti gli elementi necessari per ricevere questo layer WFS; di seguito il codice essenziale per farlo con OL3:

Notiamo la jQuery AJAX abbreviata come $.ajax(…) che implementa la funzione del loader:  ovviamente per poterla usare abbiamo caricato la relativa libreria (jquery-1.11.2.min.js). Nel loader sono definiti tutti i parametri necessari per ricevere i dati dal server WFS, in particolare:

  • il suo URL,
  • il tipo di richiesta (GetFeature),
  • il nome del layer (typename),
  • l’EPSG del suo sistema di riferimento con si vuole ricevere
  • i limiti geografici (bbox) del layer nel dato CRS, oppure della porzione che ci interessa ricevere

Le dimensioni del bbox possono essere fisse e specificate con le coordinate [Xmin, Ymin, Xmax, Ymax] oppure, come si fa di solito, variabili in base all’estensione attuale (extent) della vista mappa. Notate anche che bisogna esplicitare il sistema di riferimento usato, nel nostro caso EPSG:3857.

Osservate che l’URL  adoperato è quello del servizio WFS scelto con anteposto l’indirizzo: cors-anywhere.herokuapp.com, per risolvere il problema della policy di CORS del browser. Brevemente, poichè il server WFS che abbiamo scelto non prevede gli header CORS, le sue risposte alle nostre richieste GetFeature verrebbero bloccate dal browser. Una soluzione (… non è l’unica) è  quella di inviare le richieste tramite un proxy-server (come appunto è cors-anywhere.herokuapp.com) che fa da tramite ed aggiunge gli header CORS.

Un’altra osservazione riguarda  la loadingstrategy, cioè la strategia di caricamento degli elementi del vettore; in OL3 sono previste tre modalità: allbbox, e tile (vedi API docs: ol.loadingstrategy) e noi abbiamo scelto la bbox. In generale la scelta più conveniente dipende da quanto è esteso il layer WFS e da come viene visualizzato di solito (per intero, zoomando una porzione, spostandosi spesso,… etc).

Naturalmente il layer WFS una volta caricato, può essere “vestito” come un normale layer vettoriale, definendone lo stile e le eventuali etichette.

Per vedere l’esempio completo e funzionante, cliccate sulla seguente immagine. Tenete presente che gli elementi del layer WFS  non appaiono subito, ma dopo una decina di secondi; ciò dipende sia dai tempi di risposta del server WFS sia dal proxy che c’è di mezzo.

layer_WFS

Servizi che non prevedono l’ EPSG 3857

Come abbiamo già accennato, se il servizio WFS tra i CRS disponibili non prevede anche l’EPSG 3857 (WGS84/PseudoMercator), pur rimanendo valido il metodo che abbiamo visto, le cose si complicano un pochettino. In pratica dobbiamo leggere e caricare i layer WFS usando un CRS tra quelli ammessi, per poi visualizzarli (riproiettarli) su una vista mappa che usa l’EPSG 3857, il sistema di riferimento adoperato da quasi  tutti i servizi di mappe base  (mappe di sfondo) ed anche sistema di default per OL.

Bisogna fare attenzione nell’esprimere correttamente il parametro bbox nel loader, indicando le coordinate degli spigoli con i valori e l’ordine degli assi validi per il CRS considerato. Per esempio se il layer WFS viene erogato in WGS84 (EPSG 4326), questo sistema ha gli assi espressi nell’ ordine Lat(Nord), Lng(Est) a differenza dell’EPSG 3857 che invece è nell’ordine X(Est), Y(Nord).

Quindi nel caso di WFS erogato in EPSG 4326, il loader va impostato così:

Oltre a questo, quando si vanno a leggere gli elementi vettoriali del layer WFS, bisogna ancora specificare il CRS di origine e quello della sistema che stiamo usando nella vista mappa:

Per fare un esempio concreto consideriamo i servizi WFS resi disponibili dal PCN (PCN servizio scaricamento WFS) che usano tutti il sistema WGS84; scegliamo un layer che rappresenta “bacini idrografici” di tutto il territorio nazionale e questa è la parte di codice che lo definisce:

Per vedere l’esempio completo cliccate sul seguente bottone:

webmap esempio

Layer in formato JSONP

L’uso della classe  ol.format.WFS non è comunque l’unico modo per leggere i dati proveniente da una sorgente WFS. Infatti i servizi WFS, come formato vettoriale di uscita, oltre al GML (quello di default), ne possono prevedere anche altri. Quando è supportato il formato text/javascript (JSONP), possiamo leggere i dati WFS usando la classe ol.format.geoJSON.

Un servizio WFS che tra i vari formati (outputFormat) prevede anche il text/javascript è il seguente (è un servizio demo):

inviandogli una richiesta GetCapabilities  possiamo vedere elencati i formati di uscita supportati:

WFS outputFormat

Questo server pubblica diversi layer; quello che usiamo come esempio si chiama “medford:parks”. Questo  è il codice OL3 che richiede e riceve i dati WFS come JSONP:

Notate che nel loader  abbiamo specificato come outputFormat: ‘text/javascript’, inoltre la funzione che legge gli elementi del vettore JSONformat.readFeatures(response) viene richiamata col metodo di callback quando la jQuery ha terminato.

Come loadingstrategy in questo caso, abbiamo usato il tipo tile, ma è solo per provare quest’altra tecnica, perchè avremmo potuto benissimo usare lo stesso tipo bbox come avevamo fatto prima. In ogni caso, potete fare delle prove cambiando la loadingstrategy e vedere quale tipo consente un caricamento degli elementi del vettore WFS più rapido, caso per caso (dimensione della vista, risoluzione, … etc).

WFS formato JSONP

Qui potete vedere l’esempio completo funzionante:

webmap esempio

condividi: