WFS-opas - latuviitta.org

Web Feature Service (WFS) - Vektoreita netistä

1. WFS pähkinänkuoressa

WFS-palvelun avulla paikkatietoja voidaan ladata vektorimuodossa netin kautta.

Alkuun

2. WFS:n kolme peruskyselyä

GetCapabilities

Kysely, joka lähetetään WFS-palvelimelle ensimmäiseksi, ja jonka vastaukseksi saadaan palvelun perustiedot.
Esimerkkikyselyt eri WFS-versioille

Vastauksen pääsisältö:

luettelo palvelussa olevista karttatasoista
tieto kunkin karttatason koordinaattijärjestelmästä ja maantieteellisistä ulottuvuuksista
luettelo palvelimen tukemista operaatioista ja funktioista, joita voidaan käyttää hakutulosten suodattamiseen

DescribeFeatureType

Kysely, joka antaa lisätietoja yksittäisistä WFS-palvelussa olevista karttatasoista
Esimerkkikysely

http://hip.latuviitta.org/cgi-bin/tinyows?service=WFS&version=1.0.0&request=DescribeFeatureType&typeName=lv:hki_rakennus_2012

Vastauksen sisältö

karttatason tietorakenne eli skeema

luettelo tasoon kuuluvista ominaisuustiedoista ja niiden tietotyypeistä, esim, kokonaisluku, merkkijono tai päivämäärä
tieto geometrian tyypistä, esim. piste, viiva tai aluegeometria
tieto, onko ominaisuustieto pakollinen vai ei
tieto, voiko ominaisuustieto olla tyhjä

GetFeature

Pyyntö hakee paikkatietoaineiston palvelimelta
Esimerkkipyyntö, joka palauttaa Suomen maakuntien rajat WFS-tasolta "lv:mml_maaku1_p"

http://hip.latuviitta.org/cgi-bin/tinyows?service=WFS&version=1.0.0&request=GetFeature&typeName=lv:mml_maaku1_p

Alkuun

3. Tulosjoukon rajaaminen

WFS-palvelusta on mahdollista hakea koko karttataso sellaisenaan, kaikkine kohteineen, kuten yllä olevassa maakunta-aineistoesimerkissä. Tällaisessa palvelussa ei kuitenkaan olisi juuri etua verrattuna tavalliseen tiedostolataukseen. WFS-palvelusta on kuitenkin mahdollista valita kohteita niiden sijainnin ja ominaisuustietojen avulla, jolloin käyttäjä saa vain ja ainoastaan sen mitä tilaa.

3.1 Lukumäärärajoitus ja sivutus

Käyttäjä voi asettta ylärajan sille, kuinka monta kohdetta palvelu palauttaa, lisäämällä pyyntöön parametrin "maxFeatures" tai WFS 2.0 -versiossa "count". Esimerkki:

http://hip.latuviitta.org/cgi-bin/tinyows?service=WFS&version=1.0.0&request=GetFeature&typename=lv:mml_paikannimet20&maxFeatures=10

Tämä pyyntö palauttaa aina maksimissaan maxFeatures-arvon verran kohteita alkaen ensimmäisestä kohteesta. Rajoitus on hyvin käyttökelpoinen pikatestaukseen, jolloin voi vilkaista nopeasti vain muutaman ensimmäisen kohteen sisällön. Suurten aineistojen hakeminen pala kerrallaan ei kuitenkaan onnistu, koska pyyntö palauttaa aina samat ensimmäiset kohteet. Vasta WFS-versio 2.0 toi mukanaan sivutuksen, eli mahdollisuuden pyytää halutun määrän kohteita alkaen määrätystä kohdasta. Aloituskohta kerrotaan parametrillä "startIndex", ja monissa palvelinohjelmissa tätä mahdollisuutta tuetaan nykyisin kaikilla WFS-versioilla. StartIndex:in vaikutus jää parhaiten mieleen, kun ajattelee, että se kertoo, kuinka monen ensimmäisen kohteen yli hypätään.

Tämä pyyntö palauttaa kaksi ensimmäistä osavaltiota, jotka ovat Illinois ja Missouri

http://demo.opengeo.org/geoserver/wfs?service=WFS&version=1.0.0&request=GetFeature&typeName=topp:states&maxfeatures=2&startindex=0

Tämä pyyntö palauttaa kaksi kohdetta, mutta hyppää yhden yli, joten tulos on Missouri ja Arizona.

http://demo.opengeo.org/geoserver/wfs?service=WFS&version=1.0.0&request=GetFeature&typeName=topp:states&maxfeatures=2&startindex=1

Alkuun

3.2 Vain haluttujen ominaisuustietojen haku

Jos WFS-aineiston skeemaan kuuluu tarpeettomia ominaisuustietoja, niin palvelun palauttaman tiedon määrää voi vähentää luettelemalla GetMap-pyynnössä ne ominaisuustiedot, jotka nimenomaan tahdotaan saada. Tämä tehdään lisäämällä pyyntöön parametri "propertyname", jonka arvoksi annetaan pilkuilla erotettu luettelo haluttujen ominaisuustietojen nimistä kirjoitettuna täsmälleen siten, kuin aikaisemmin esitelty DescribeFeatureType-pyyntö ne palauttaa.

Esimerkkejä: Kymmenen Helsingin rakennuksen kaikki ominaisuustiedot

http://hip.latuviitta.org/cgi-bin/tinyows?service=WFS&version=1.0.0&request=GetFeature&typeName=lv:hki_rakennus_2012&maxFeatures=10

Muuten sama pyyntö, mutta haetaan vain rakennusten geometria ja osoite

http://hip.latuviitta.org/cgi-bin/tinyows?service=WFS&version=1.0.0&request=GetFeature&typeName=lv:hki_rakennus_2012&maxFeatures=10&propertyname=wkb_geometry,osoite

Alkuun

3.3 Yksinkertainen aluevalinta: BBOX

WFS-standardiin on määritelty yksinkertainen haku, jossa kiinnostuksen kohteena oleva alue annetaan suorakaiteena BBOX-parametrillä. WFS 1.0.0 palvelussu parametrin arvoiksi annetaan neljä pilkuilla erotettua lukua järjestyksessa MinX,MinY,MaxX,MaxY, ja tässä X merkitsee aina itäkoordinaattia/pituusastetta ja Y pohjoiskoordinaattia/leveysastetta. Hyvin yksinkertainen ja hyvin käytännöllinen haku, josta seuraavassa esimerkki.

http://hip.latuviitta.org/cgi-bin/tinyows?service=WFS&version=1.0.0&request=GetFeature&typeName=lv:mml_railway&BBOX=246700,6780800,436400,6924000

Valinta ominaisuustietojen perusteella

3.3. Valinta paikan perusteella

Alkuun

4. WFS-versioiden väliset erot

WFS 1.0.0

Tiedostomuoto: GML 2.1.2
Tukee vain yhtä koordinaattijärjestelmää kullekin WFS-tasolle
WFS 1.0.0:ssa koordinaattien ensimmäinen numero merkitsee aina itäkoordinaattia tai pituusastetta (longitudi) ja toinen numero pohjoiskoordinaattia tai leveysastetta (latitudi)

WFS 1.1.0

Tiedostomuoto: GML 3.1.1
Tuki eri koordinaattijärjestelmille, tiedot voidaan projisoida eri järjestelmään lennossa srsName-parametrin avulla
Koordinaattien järjestys riippuu käytettävästä järjestelmästä. Esimerkkejä:

WGS84 (EPSG:4326): leveysaste - pituusaste
Suomalainen KKJ-järjestelmä: pohjoinen-itäinen
Uusi suomalainen ETRS-TM35FIN: itäinen-pohjoinen
Suomalaiset Gauss-Krüger-kaistat: pohjoinen-itäinen
Kansainväliset UTM-kaistat: itäinen-pohjoinen

Uusi tapa kertoa käytettävä koordinaattijärjestelmä:

ennen esimerkiksi "EPSG:3067"
nyt "urn:ogc:def:crs:EPSG::3067"

WFS 2.0.0

Tiedostomuoto GML 3.2
Tuki sivutukselle "startIndex"-parametrin avulla
Tuki palvelimella etukäteen määritetyille pyyntörakenteille, "Stored Query"

Alkuun

5. WFS:n tukemat tiedostomuodot

WFS-standardi määrää, mitä tiedostomuotoa palvelun on pakko tukea ja minkä on samalla oltava sen oletusarvona. Standardi ei kuitenkaan kiellä tukemasta myös muita tiedostomuotoja. Eräät palvelimet, kuten deegree3, eivät todellakaan tue mitään muita tiedostomuotoja kuin pakollisia GML-versioita, kun taas esimerkiksi GeoServer tukee jo oletusasetuksillaan GML 2.1.2-, GML 3.1.1- ja GML 3.2-formaattien lisäksi zip-paketoitua ESRI Shapefile-, KML- ja GeoJSON-tiedostomuotoja sekä erotinmerkeillä jäsennettyä tekstimuotoa. Erikseen asennettavan laajennuksen avulla tuettuja vektoriformaatteja saadaan vielä lisää. MapServer-palvelin on mahdollista asentaa vastaavalla tavalla tukemaan lukuisia muita tiedostomuotoja.

WFS-palvelimen tukemat tiedostomuodot voidaan tarkistaa palvelimen GetCapabilities-vastauksesta.

Alkuun

6. WFS-ongelmia

6.1 BBOX-ongelmat

Ehkä yleisimmin käytettävä WFS-haun rajaamiseen käytettävä ehto on "Bounding Box" -suodatin. Sen tarkoituksena on hakea WFS-tasolta vain sellaiset kohteet, jotka ovat kokonaan tai osittain annetun suorakaiteen muotoisen alueen sisäpuolella. Aluerajaus voidaan antaa joko http GET -pyynnön BBOX-parametrillä avain-arvoparina tai sitten käyttämällä OGC:n Filter Encoding -standardin mukaista XML-muodossa annettavaa filter-elementtiä.

Esimerkki GET-pyynnöstä ja BBOX-parametristä

http://hip.latuviitta.org/cgi-bin/tinyows?service=WFS&version=1.0.0&request=GetFeature&typename=lv:mml_railway&BBOX=246700,6780800,436400,6924000

Esimerkki http POST -pyynnöstä johon sisältyy ogc:BBOX-suodatin

<wfs:GetFeature xmlns:ogc="http://www.opengis.net/ogc"
xmlns:gml="http://www.opengis.net/gml"
xmlns:wfs="http://www.opengis.net/wfs"
service="WFS" version="1.1.0" maxFeatures="1000"
outputFormat="text/xml; subtype=gml/3.1.1">
<wfs:Query xmlns:tows="http://www.tinyows.org/"
srsName="urn:ogc:def:crs:EPSG::27582" typeName="tows:france">
<wfs:PropertyName>tows:the_geom</wfs:PropertyName>
<ogc:Filter>
<ogc:BBOX>
<ogc:PropertyName>tows:the_geom</ogc:PropertyName>
<gml:Envelope
<gml:lowerCorner>500117 2150739 </gml:lowerCorner>
<gml:upperCorner>658850 2315484 </gml:upperCorner>
</gml:Envelope>
</ogc:BBOX>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>

Harmillista kyllä BBOX saattaa käyttäytyä eri tavalla sen mukaan, onko kyseessä WFS versio 1.0.0 vai 1.1.0, ja WFS 1.0.0 versiolla myös sen mukaan, annetaanko BBOX avain-arvoparina vai käytetäänkö XML-muotoista BBOX-elementtiä.

Seuraavissa esimerkeissä oletetaan, että kyseltävän WFS-tason oletuskoordinaattijärjestelmä on joku muu kuin EPSG:4326.

Tapaus 1.

WFS-versio 1.0.0 ja http GET

WFS 1.0.0 tukee vain yhden koordinaattijärjestelmän käyttöä, joten BBOX kuuluu antaa oletusjärjestelmän mukaan. Yllä olevan GET-esimerkin BBOX=246700,6780800,436400,6924000 tulkitaan siis käyttävän oletussysteemiä eli EPSG:3067:ää, ja haku löytää kohteita, jos niitä tuon laatikon sisältä löytyy.

Tapaus 2.

WFS-versio 1.1.0 ja http GET

Esimerkin 1. mukainen BBOX ei löydä kohteita standardin mukaan oikein toimivasta WFS-palvelusta. WFS 1.1.0 -standardiin on nimittäin määritelty, että jos BBOX annetaan ilman tietoa siitä, missa koordinaattijärjestelmässä laatikko annetaan, niin silloin oletetaan, että se käyttää EPSG:4326 -järjestelmää eli WGS84-maantieteellisiä koordinaatteja, ja koordinaattien järjestyksen on oltava leveysaste-pituusaste. Jos laatikko on jonkin muun järjestelmän mukainen, niin se täytyy antaa BBOX-parametrin viidentenä jäsenenä.

WFS 1.1.0 -standardin mukainen tapa tehdä GET esimerkin mukainen pyyntö käyttämällä EPSG:3067:n mukaista aluerajausta on siten

http://hip.latuviitta.org/cgi-bin/tinyows?service=wfs&version=1.1.0&request=GetFeature&typename=lv:mml_railway&BBOX=246700,6780800,436400,6924000,EPSG:3067

Ristiriita 1.

Tapaukset 1 ja 2 johtavat versioristiriitoihin.

BBOX-pyynnöt ilman koordinaattijärjestelmätermiä eivät voi tuottaa samaa tulosta standardia noudattavista WFS 1.0.0 ja WFS 1.1.0-palvelimista.
WFS 1.1.0 -palvelimelle kelpaava BBOX, joka sisältää tiedon koordinaattijärjestelmästä, ei välttämättä toimi WFS 1.0.0 -palvelimella, koska niihin ei ole edes tarvinnut rakentaa tukea eri järjestelmille.

Käytännön havaintoja:

WFS-palvelimien kehittäjät eivät ole välttämättä ottaneen huomioon sitä, että BBOX-termin oletuskoordinaattijärjestelmä WFS 1.0.0 ja 1.1.0 -versioissa on erilainen. Tämä johtuu joko siitä, että standardin muutosta ei ole huomattu, tai siitä, että muutosta on pidetty järjettömänä, koska se rikkoo asiakasohjelmista WFS-versioiden yhteensopivuuden. CITE-testit eivät tätä asiaa testaa, ja siitä syystä on mahdollista, että esimerkiksi kaikki CITE-testit läpäisevä Geoserver käyttää WFS 1.1.0 -versiossa samaa oletusta kuin 1.0.0 versiossa, jolloin siis BBOX ilman viidettä termiä tulkitaan olevan tason oletusjärjestelmässä.

Ristiriita 2.

Tilanne mutkistuu vielä siitä syystä, että BBOX voidaan antaa paitsi avain-arvo-parina, niin myös OGC:n filter-elementtinä, joka noudattaa Filter Encoding -standardia. Siinäpä määrätäänkin, että jos BBOX-vertailugeometrian koordinaattijärjestelmää ei kerrota, niin sen oletetaan olevan WFS-tason oletusjärjestelmän mukainen. Määrittely on siis sama kuin WFS 1.0.0 avain-arvo-pareilla, mutta eri kuin WFS 1.1.0 avain-arvo-pareille. Tämä johtaa yhteensopimattomuuteen WFS 1.1.0 versiolla avain-arvoparina annetun BBOX-parametrin ja XML-muotoisen BBOX-filterin välillä, jos geometrian koordinaattijärjestelmää ei nimenomaan kerrota.

Ristiriitojen välttäminen

Ristiriitojen välttämiseksi on parasta välttää tilannetta, jossa palvelin joutuu turvautumaan oletusten käyttöön. Oikeista oletusarvoista on tulkintaerimielisyyksiä ja tiedossa oleviakaan virheitä, joita ei haluta korjata, ettei rikottaisi olemassa olemien ohjelmien toimintaa. WFS 1.1.0:lla ristiriidat pitäisi ratketa, jos vertailugeometrian koordinaattijärjestelmä osoitetaan sekä avain-arvoparissa että XML-suodattimessa.

Avain-arvo-parin BBOX pitäisi siis aina rakentaa tämän mallin mukaan

BBOX=246700,6780800,436400,6924000,EPSG:3067

XML-muotoisessa BBOX:ssa pitäisi olla mukana srsName-määrittely

<ogc:BBOX>
<ogc:PropertyName>tows:the_geom</ogc:PropertyName>
<gml:Envelope srsName='urn:ogc:def:crs:EPSG::27582'>
<gml:lowerCorner>500117 2150739 </gml:lowerCorner>
<gml:upperCorner>658850 2315484 </gml:upperCorner>
</gml:Envelope>
</ogc:BBOX>

Bonus: Ristiriita 3.

Entäs jos WFS-taso käyttäisikin oletuskoordinaattijärjestelmänä WGS84:sta, EPSG:4326. Toimisiko silloin sama avain-arvoparina annettava BBOX sekä WFS 1.0.0 että 1.1.0 -versioilla? No ei tietenkään, koska edellisessa koordinaatit annetaan järjestyksessä pituusaste-leveysaste, ja jälkimmäisessä tapauksessa päin vastoin.

Alkuun

6.2 GetCapabilities voi olla raskas

Sovellusten kehittäjien olisi hyvä ymmärtää, että GetCapabilities-pyyntöjä ei kannata lähetellä turhan päiten. GetCapabilities-vastaukseen sisältyy usein tieto jokaisen palvelussa olevan WFS-tason (FeatureType) ulottuvuuksista eli niiden Bounding box:it. Monet WFS-palvelimet tarkistavat nämä ulottuvuudet jokaista GetCapabilities-pyyntöä varten suoraan tietolähteestä. Tämä on luotettava menetelmä ja se tuottaa oikean tuloksen myös usein päivitettävistä ja siten jatkuvasti muuttuvista tietolähteistä. Tarvittava kysely voi kuitenkin olla hyvin raskas ja hidas, jos ulottuvuudet on selvitettävä miljoonia kohteita sisältävästä tietokantataulusta. Oracle-tietokanta on tässä suhteessa kuuluisa hitaudestaan, ja hitaus vielä korostuu, jos palvelussa on paljon suuria WFS-tasoja. Yleensä palvelin on mahdollista asettaa myös lähettämään WFS-tasoille jotkin kiinteät ulottuvuudet tai pyytää sitä etsimään tietokannasta tason arvioidut ulottuvuudet. Nämä menetelmät ovat nopeita, mutta samalla Bounding box:in tarkkuus heikkenee.

Jos sovelluksen kehittäjän tai luettelopalvelun ylläpitäjän tarkoitus on vain tarkistaa esimerkiksi viiden minuutin välein vastaako WFS-palvelin ylipäätään kutsuihin, niin on kohteliasta palvelun ylläpitäjää kohtaan tehdä yksinkertainen GetFeature-pyyntö käyttämällä maxFeatures=1 -rajoitusta. Mahdolliset muutokset palvelusta saatavista WFS-tasoista ja niiden ulottuvuuksista voidaan selvittää vaikka kerran vuorokaudessa, yleensä ne eivät kuitenkaan muutu kovin usein.

Alkuun