GetCapabilities voi olla raskas kysely
Sovellusten kehittäjien olisi hyvä ymmärtää, että GetCapabilities-pyyntöjä ei kannata lähetellä turhan päiten. GetCapabilities-vastaukseen sisältyy 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 on kuitenkin varsin raskas ja hidas, jos ulottuvuudet on selvitettävä miljoonia kohteita sisältävästä tietokantataulusta. Oracle-tietokanta on tässä suhteessa kuuluisa hitaudestaan. Hitaus luonnollisesti 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 palvelimen 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 tunnissa, yleensä ne eivät kuitenkaan muutu kovin usein.
BBOX-ristiriidat
(Luonnos)
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ä
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 esimerkin BBOX
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 järjestyksessä leveysaste-pituusaste.
Oikea tapa WFS 1.1.0 -standardin mukaan olisi tehdä GET esimerkin mukainen pyyntö näin:
(Pyyntö tuottaa virheen, mutta se on palvelimen vika)
BBOX-parametrinä annetun suorakaiteen koordinaattijärjestelmä siis kerrotaan myös parametrin viidentenä terminä.
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ä 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ää myös WFS 1.1.0 -versiossa samaa oletusta kuin 1.0.0 versiossa, eli että BBOX ilman viidettä termiä tarkoittaa tason oletusjärjestelmää.
Ristiriita 2.
Tilanne mutkistuu vielä siitä syystä, että BBOX voidaan antaa paitsi avai-arvoparina 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 oletuksen mukainen. Määrittely on siis sama kuin WFS 1.0.0 avain-arvopari-menetelmällä, mutta eri kuin WFS 1.1.0 avain-arvopareille. 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 oleviakin 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-arvoparin 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>
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ä pituuspiiri-leveyspiiri, ja jälkimmäisessä tapauksessa päin vastoin.
|
