[Gfoss] riflessioni su pubblicazione WFS con apache e mapserver (e client qGis)

francesco marucci francesco.marucci a gmail.com
Mar 18 Nov 2014 16:51:34 CET


gentile lista,
vorrei condividere con voi tutti e tutte gioie e dolori di alcune ore
dedicate alla pubblicazione con Apache + Mapserver di un servizio WFS,
testato poi con qGis.

gioie perchè è bello lavorare con questi strumenti validissimi (e questo
non c'è neanche bisogno di dirlo), dolori perchè in qua e la trovo degli
"intoppi" che alla fine di questa storia sarete voi a dirmi se ci sono gli
"estremi" per segnalarli in modo ufficiale.


il mio obbiettivo è quello di pubblicare in modo "elegante" con Mapserver
un servizio WFS con un end point che non contenga il classico percorso al
.map, tipo
/cgi-bin/mapserv?map=/webgis/map/wfs.map&


premetto che ho notato un comportamento secondo me "anomalo" di qGis
(versione 2.4 win32 da osgeo4w): quando richiamo un servizio WFS da un
determinato end point, la costruzione delle successive richieste (dopo la
GetCapabilities) non avviene con i relativi indirizzi presenti nelle online
resources delle capabilities, ma qGis utilizza l'indirizzo usato per
richiamare il servizio (l'end point che inserisce l'utente, per
intenderci). secondo me questo è sbagliato, se c'è l'online resource perchè
non usarlo? e poi questo comportamento mi ha costretto ad andare avanti con
la mia ricerca, perchè anche se non elegantissimo, potevo mascherare
solamente l'end point iniziale del mio servizio, mantenendo l'indirizzo con
percorso al .map per le richieste successive "trasparenti" per l'utente.

quindi mi rimbocco le maniche e vado avanti:
leggo dalla documentazione di Mapserver (in realtà la pagina sul WFS mi
rimanda a quella del WMS):
http://mapserver.org/ogc/wms_server.html#online-resource-wms
tutti i vari metodi per "nascondere" il percorso completo al .map.

quindi nella mia bella root del web server mi sono creato la cartella
"wfs", ho applicato tutte le mie brave regole di rewrite in modo da
richiamare da qGis l'indirizzo (che è l'obbiettivo che voglio raggiungere):

http://www.miodominio.it/wfs


vedo dai log di Apache richiesta in GET proveniente da qGis per la
GetCapabilites:

192.168.1.82 - - [30/Oct/2014:12:55:09 +0100] "GET
/wfs?REQUEST=GetCapabilities&SERVICE=WFS&VERSION=1.0.0 HTTP/1.1" 301 647
"-" "-"
192.168.1.82 - - [30/Oct/2014:12:55:09 +0100] "GET
/wfs/?REQUEST=GetCapabilities&SERVICE=WFS&VERSION=1.0.0 HTTP/1.1" 200 3387
"-" "-"

e la lista dei layers mi arriva.

quando poi scelgo un layer dalla lista e lo aggiungo al progetto, qGis mi
restituisce un errore (layer non valido).

leggo dal log di apache la richiesta in POST proveniente da qGis per la
GetFeature:

192.168.1.82 - - [30/Oct/2014:12:55:11 +0100] "POST /wfs? HTTP/1.1" 301 472
"-" "-"
192.168.1.82 - - [30/Oct/2014:12:55:11 +0100] "GET /wfs/? HTTP/1.1" 200 209
"-" "-"

ci ho messo un bel po' a capire queste due righe del log, 301 è un
redirect, 200 va a buon fine,
perchè allora qGis mi da errore?

in Apache c'è una bella regola che aggiunge lo slash nell'indirizzo se non
c'è (il default è "DirectorySlash On") e questo è un redirect e la mia
bella richiesta da POST diventa GET, e ovviamente la GET non ha parametri e
Mapserver giustamente risponde ciccia.

ragazzi che fatica!

leggo da qui [http://httpd.apache.org/docs/current/mod/mod_dir.html]:

"Also note that some browsers may erroneously change POST requests into GET
(thus discarding POST data) when a redirect is issued."

quindi sembra che Apache dia la "colpa" di questo comportamento al
"browser" (che nel mio caso è qGis, giusto?): pensate che ci sia modo di
"evitare" questo comportamento da parte di qGis?

quindi provo a "evitare" l'aggiunta dello slash finale da parte di Apache:
aggiungo nella mia VirtualDirectory:

DirectorySlash Off

ma non risolvo perchè il /wfs? da errore, e non voglio costringere l'utente
a richiamare con /wfs/? (proprio bruttino).



la soluzione finale che ho trovato è:


abbandonare l'idea di gestire questa cosa con una cartella /wfs e ripiegare
sul un bel file python chiamato semplicemente "wfs" messo direttamente
nella root (al posto della cartella "wfs"): in questo modo viene saltato il
passaggio di aggiunta dello slash finale e del conseguente redirect con
perdita dei dati POST.

il mio file /var/www/wfs contiene semplicemente:

#!/usr/bin/python

import mapscript

req = mapscript.OWSRequest()
req.loadParams()
map = mapscript.mapObj('/webgis/map/wfs.map')
map.OWSDispatch(req)

e poi nella configurazione di Apache per la mia root:

        <Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
                Options +ExecCGI +SymLinksIfOwnerMatch
        </Directory>

e per abilitare il mio filettino python per l'esecuzione come cgi:

        <FilesMatch wfs$>
                 SetHandler cgi-script
        </FilesMatch>

e il gioco è fatto.

se pensate quindi che questa sia una buona soluzione spero che le mie ore
possano essere utili a qualcuno, altrimenti fatemi sapere se ci sono
soluzioni diverse, anche che prevedano comportamenti diversi da parte del
client.

questo l'indirizzo finale del mio WFS da provare:
http://www.patrimonioculturale-er.it/wfs



saluti,
francesco
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20141118/d2d0d5a0/attachment-0001.html>


Maggiori informazioni sulla lista Gfoss