GeoServer-rajapintapalvelinsovelluksessa on useita erinomaisia ominaisuuksia. Eräs näistä on mahdollisuus OGC-rajapintojen putkittamiseen (eng. cascading). OGC-rajapintojen putkitus tarkoittaa sitä, että GeoServerin datalähteenä käytetään paikallisen datalähteen sijaan jotakin toisella palvelimella olevaa OGC-rajapintaa, ja tätä aineistoa jaellaan edelleen putkittavan palvelimen OGC-rajapintojen kautta.
Artikkelissa tutustutaan Väyläviraston tuottaman julkisen Digiroad WFS-rajapinnan putkittamiseen siten, että putkitettavalta WFS-rajapinnalta noudettavan aineiston sisältöä suodatetaan ensiksi CQL Filter -suodatuksen avulla. Suodatuksen jälkeen toteutettavaa WFS-WMS-muunnosta maustetaan Apache FreeMarker Template -tekniikkaan perustuvalla paikkatietokohteiden ominaisuustietojen tuunauksella ja lopuksi komeus kuorrutetaan Väyläviraston GitHub-palvelussa julkaisemilla liikennemerkkisymboleilla.
Putkittamisen hyötyjä
OGC-rajapintojen putkitus mahdollistaa lennossa toteutettavan muunnoksen eri koordinaattijärjestelmien välillä. Tästä ominaisuudesta on hyötyä erityisesti silloin, kun putkitettava rajapintapalvelin ei pysty tarjoamaan aineistoa halutussa koordinaattijärjestelmässä. Toinen mainitsemisen arvoinen asia on GeoServerin tarjomat minipuoliset ratkaisut tietoturvaan liittyen; putkittamisen avulla voit esimerkiksi lukea aineistoa käyttäjätunnuksella ja salasanalla suojatulta OGC-rajapinnalta ja tarjota sitä eteenpäin UUID-muotoisen salausavaimen avulla.
Putkittaminen on mahdollista toisen karttakuvapalvelun (WMS), tiilitetyn karttakuvapalvelun (WMTS) ja paikkatietokohteiden kyselypalvelun (WFS) osalta. Eniten mahdollisuuksia on käytössä, kun putkitetaan paikkatietojen kyselypalvelua, jolloin mahdollista on mm. toisella rajapintapalvelimella majailevan WFS-rajapinnan muuttaminen lennossa WMS-rajapinnaksi.
Lennossa toteutettava WFS-WMS-muunnos mahdollistaa mm. GetFeatureInfo-kyselyn mukaiset paikkatietokohteiden ominaisuustietokyselyt, ominaisuustietojen suodatukset/rikastukset Apache FreeMarker Template -tekniikan avulla sekä omat kustomoidut kuvaustavat SLD-tyylien avulla.
WFS-WMS-muunnoksen tapauksessa saadaan aikaan ns. dynaaminen karttakuvapalvelu. Dynaamisen karttakuvapalvelun etuja ovat mm. pikselöitymättömät karttakuvat, mahdollisuus kuvaustavan ohjaamiseen SLD-tyylien avulla sekä jo mainitsemani GetFeatureInfo-ominauustietokyselyt. Dynaamisesta karttakuvapalvelusta olen kirjoittanut aikaisemmin WMS-rajapinta tutuksi -artikkelissa.
Mikäli käytössä on GeoServer-palvelimeen integroitu GeoWebCache (GWC), mahdollistaa OGC-rajapintojen putkitus myös suorituskykyparannuksia. GeoServer-GWC-integraation avulla on mahdollista nimittäin luoda välimuisti putkitettavan palvelimen aineistosta ja tarjota sitä eteenpäin WMTS- ja WMS-rajapintojen (ns. direct integration with GeoServer WMS -toiminnallisuus) kautta. Merkittävä parannus suorituskykyyn saavutetana erityisesti silloin, kun GWC:n välimuistin sisältö populoidaan valmiiksi.
Pohjois-Karjalan bussipysäkit kartalle
Putkittamisen tuomia mahdollisuuksia on selkeintä esitellä käytännön esimerkin avulla. Esimerkki liittyy kokemukseen, jossa rakentelimme yhdessä kollegan kanssa Oskari-pohjaisen karttaupokkeen Joensuun seudun joukkoliikenteen internetsivuille. Lisää Oskari-karttapalvelun käyttämisestä karttaupotusten tekoon voit lukea blogissa aikaisemmista julkaistuista artikkeleista Webbikartta Oskari-karttapalvelun avulla ja Oskari tuli kylään.
Kuvassa 1 nähtävässä karttaupokkeessa esitetään ns. Waltti-lippujärjestelmän vyöhykkeet ja Väyläviraston ylläpitämän Digiroad-järjestelmän sisältämät joukkoliikenteen pysäkit -aineisto. Ensiksi mainittua ylläpidetään itse omassa PostGIS-paikkatietokannassa QGIS-paikkatietosovelluksen avulla ja jälkimmäistä putkitetaan Väyläviraston julkisesta WFS-palvelusta. Upotusta voit tarkastella tästä.
Toimintamalli mahdollistaa joukkoliikenneaineistojen tehokkaan ylläpidon kansallisessa Digiroad-tietojärjestelmässä (kunnat ovat velvoitettuja tähän lainsäädännöllä) ja sen, että nämä suurella työllä kansallisessa järjestelmässä ylläpidettävät tiedot saadaan käyttöön myös kunnan omissa tarkoituksissa. Toimintamalli on omiaan vähentämään aineistojen ylläpitovastuuta useissa eri tietovarannoissa ja tuomaan näin tehokkuutta ja mielekkyyttä ylläpitoprosessiin.
OGC-rajapintojen putkitus GeoServerillä alkaa datalähteen määrittämisestä
Putkitettavan datalähteen lisääminen on helppoa GeoServerin www-selainpohjaisen hallintatyökalun kautta, sillä pakasta vedettynäkin GeoServer sisältää tähän tarvittavat toiminnallisuudet (ks. kuva 2). Tässä tapauksessa lisättiin vektorimuotoinen datalähde, joten asiassa lähettiin etenemään Web Feature Server (NG) -toiminnallisuuden kautta.
Mikäli OGC-rajapinnat eivät ole teknologisessa mielessä tuttuja, suosittelen tutustumaan esimerkiksi aikaisemmin kirjoittamaani artikkeliin WMS-rajapinta tutuksi. Artikkelin luettuaesi tiedät, mistä puhutaan kun kerrotaan rajapintaan lähetettävistä pyynnöistä vaikkakin ko. artikkelissa käsitelläänkin karttakuvapalvelua eli WMS-rajapintaa.
Web Feature Server (NG) -nappulaa painettaessa avautuu kuvassa 3 nähtävä näkymä. Tärkein täytettävä kenttä on Connection Parameters -kohdassa oleva putkitettavan WFS-palvelun GetCapabilities URL -kenttä, johon tulee syöttää putkitettavan palvelussa tarjolla olevat aineistot listaava URL-osoite. Huomaathan, että palvelun URL-osoitteen muoto voi vaihdella putkitettavan palvelinteknologian mukaan.
Mikäli kyseessä olisi HTTP Basic Authentication -menetelmällä autentikoitu rajapintapalvelu, voitaisiin tunnistautumisessa tarvittava käyttäjätunnus ja salasana syöttää niille varattuihin kenttiin. Mikäli putkitettavan WFS-palvelun suorituskyvyssä ilmenee ongelmia, voidaan Maximum number of Features to retrieve -kohtaan määritellä putkitettavasta palvelusta haettavien paikkatietokohteiden maksimimäärä.
Joissakin tapauksissa voi olla tarpeen muuttaa kohdassa WFS protocol strategy -pudotusvalikossa näkyvää arvoa, mutta tässä tapauksessa automaatti toimii hyvin. Valittavissa on mm. arcgis, geoserver ja mapserver. GeoServerin dokumentaatiossa tästä kohdasta ei juurikaan mainita, mutta oletettavasti kyse on putkitettavalle rajapintapalvelimelle lähtevien WFS-pyyntöjen optimoinnista käytetyn teknologian mukaan.
CQL Filter -tekniikan avulla verkkoliikennettä vähemmäksi palvelinten välillä
Common Query Language (CQL) on Open Geospatial Consortiumin luoma kyselykieli, jonka avulla paikkatietorajapinnoilla (kehitetty erityisesti metatietorajapintoja varten) olevia aineistoja on mahdollista suodattaa. GeoServer-palvelin tukee niin alkuperäistä CQL-kieltä kuin siitä jalostettua ECQL-kieltäkin. Em. teknologioiden käyttö ei rajoitu pelkästään putkitettuilta rajapintapalvelimilta noudettavien aineistojen suodattamiseen, vaan ko. teknologioita voidaan hyödyntää myös asiakassovelluksen ja rajapinnan välisessä kommunikaatiossa.
Tässä esimerkissä Väyläviraston palvelimella tarjolla olevaa aineistoa suodatetaan CQL Filter -tekniikalla siten, että rajapinnalta haetaan ainoastaan sellaiset pysäkit, joiden PYS_TYYPPI-kentän arvo on jotakin muuta kuin 5 (virtuaalipysäkki), VIIM_VO_PV-kentän arvo on NULL (pysäkin voimassaolo ei ole lakannut) ja kuntakoodi on jokin Pohjois-Karjalan alueella sijaitsevien kuntien koodeista.
Suodattamisessa käytettävä CQL Filter -määrittely on nähtävissä kuvassa 4. Määrittely annetaan GeoServerin Edit Layer -ikkunan Data-välilehden alaosassa olevaan Restrict the features on layer by CQL filter -kohtaan. GeoServerin kanssa puuhanneille ko. kohta lienee ainakin osittain tuttu, sillä sen avulla suodatusta voidaan tehdä käytännössä kaikille GeoServerin kautta julkaistaville vektorimuotoisille paikkatietoaineistoille.
CQL Filter -suodatuksen käyttö vähentää palvelinten välistä liikennettä ja putkitettavalle rajapintapalvelimelle aiheutuvaa kuormitusta. Tässä esimerkissä käytetty, ainoastaan valitut arvot palauttava, ratkaisu lienee kevyempi kuin esimerkiksi BBOX-rajaukseen perustuva suodatus, mikä sekin olisi varsin helposti tehtävissä CQL Filter -tekniikan avulla.
GetFeatureInfo-ominaisuustietokyselyn tuunaus FTL-pohjilla
OGC-rajapintojen putkitus mahdollistaa myös asiakassovelluksen tekemien GetFeatureInfo-ominaisuustietokyselyjen välittämisen putkitettavalle rajapintapalvelimelle. Tämä ominaisuus mahdollistaa monta hyvää asiaa, mutta kenties suurin hienous tässä on se, että putkitettavan rajapintapalvelimen paikkatietokohteiden ominaisuustietoihin pääsee käsiksi GeoServeriin sisäänrakennettujen Apache FreeMarker Template (FTL) -pohjien avulla lennosta.
FTL-pohjien käytöstä GeoServerillä olen kirjoittanut aikaisemmin artikkelin GeoServerillä enemmän irti GetFeatureInfo-kyselyistä. Esimerkin karttaupotuksessa nähtävästä GetFeatureInfo-ominaisuustietokyselyn vastauksesta näet kuvasta 5.
Ohessa lisäksi lyhennelmä karttaupotuksessa käytetystä FTL-pohjasta, jonka avulla kuvassa 5 esitetty vastaus generoidaan. Pohja tekee kolme mainitsemisen arvoista toimintoa. Tärkein toiminto on se, että pohja suodattaa pois klikatun paikkatietokohteen (bussipysäkin) ominaisuustietoja ja näyttää ainoastaan halutut ominaisuustiedot (lihavoidulla).
Toinen toiminto on pysäkkikohtaisen informaation jalostaminen visuaalisesti ymmärrettävämpään muotoon. Tämä tehdään IF-ehtolausekkeen avulla siten, että IF-lauseella tutkitaan klikatun bussipysäkin ominaisuustietokentän arvoa, ja ehdon täyttyessä piirretään haluttu visuaalinen symboli. Lopputulos on näin visuaalisesti ymmärrettävämpi kuin pelkän koodiarvon näyttäminen.
Kolmas toiminto liittyy siihen, että klikattua bussipysäkkiä on mahdollista siirtyä tarkastelemaan Digitransit-teknologiaan perustuvissa reittioppaissa (Jojo-reittiopas ja Matka.fi). Digitransit on alun perin Helsingin seudun liikenteen kehittämä avoimeen lähdekoodiin ja joukkoistamalla tuotettuun OpenStreetMap-karttaan perustuva reittiopasteknologia.
<#-- content.ftl -->
<#list features as feature>
<h3>Pysäkki: ${feature.NIMI_SU.value}</h3>
<img src="https:// ... /section_perustiedot.svg" height="33px" width="133px"><br />
<b>Vyöhyke:</b> ${feature.VYOHYKTIET.value} <br />
<b>Matkustajatunnus:</b> ${feature.MATK_TUNN.value} <br />
<b>Pysäkiltä liikennöidään:</b> ${feature.LIIK_SUUNTA.value} <br />
<br />
<img src="https:// ... /section_varustus.svg" height="33px" width="133px"><br />
<b>Aikataulu</b>
<#if feature.AIKATAULU.value?number == 1>
<img src="https:// ... /icon_no.svg" height="15px" width="15px">
<#elseif feature.AIKATAULU.value?number == 2>
<img src="https:// ... /icon_yes.svg" height="15px" width="15px">
<#elseif feature.AIKATAULU.value?number == 99>
<img src="https:// ... /icon_unknown.svg" height="15px" width="15px">
</#if>
...
<br /><br />
<img src="https:// ... /section_reittioppaat.svg" height="33px" width="230px"><br />
<br />
<a href ="https://joensuu.digitransit.fi/${feature.NIMI_SU.value?replace(",", "", "i")}%20${feature.MATK_TUNN.value}" target="_blank" title="Etsi pysäkkiä ${feature.NIMI_SU.value} Joensuun joukkoliikenteen reittioppaasta"><img src="https:// ... /icon_jojo_reittiopas.png" height="40px" width="135px"></a></b><br />
<a href ="https://opas.matka.fi/${feature.NIMI_SU.value?replace(",", "", "i")}%20${feature.MATK_TUNN.value}" target="_blank" title="Etsi pysäkkiä ${feature.NIMI_SU.value} kansallisesta Matka.fi-reittioppaasta"><img src="https:// ... /icon_matkafi_reittiopas.png" height="40px" width="80px"></a></b><br />
<br />
</#list>
Pysäkkisymbolit kartalle GitHubista
Lopuksi vielä määritellään, miten tavalla aineisto halutaan näyttää kartalla. Homma hoituu GeoServer-palvelimella ns. Styled Layer Descriptor -tekniikan avulla, joka on OGC:n standardi paikkatietoaineistojen kuvaustapojen määrittelemiseksi. SLD-kielestä olen kirjoittanut aikaisemmin blogissani artikkelissa, jossa tarkastelin erilaisten geometriatyyppien visualisointia SLD-kielen avulla.
SLD-tiedosto on varsin yksinkertainen, sillä tiedosto määrittelee kuvaustavan pistemäiselle paikkatietokohteelle. Kyseinen tyylitiedosto on luotu QGIS-paikkatietosovelluksen avulla, mistä näkyvimpänä merkkinä on SE-nimiavaruuden käyttö.
Mainitsemisen arvoinen yksityiskohta SLD-tyylitiedostossa on linkitys GitHub-palveluun, josta Väyläviraston SVG-muotoisia liikennemerkkisymboleita on mahdollista käyttää suoraan ilman, että symboleita tarvitsee ladata omalle koneelle. Riskinä tällaisessa ratkaisussa on toki se, että symbolit lakkaisivat olemasta GitHubissa. Pidän tätä riskiä kuitenkin varsin pienenä, sillä GitHub toimii lukuisten eri sovelluskehitysprojektien versionhallinnan tietovarastona.
<?xml version="1.0" encoding="UTF-8"?>
<StyledLayerDescriptor
xmlns="http://www.opengis.net/sld" version="1.1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:se="http://www.opengis.net/se" xmlns:ogc="http://www.opengis.net/ogc" xsi:schemaLocation="http://www.opengis.net/sld http://schemas.opengis.net/sld/1.1.0/StyledLayerDescriptor.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<NamedLayer>
<se:Name>Joukkoliikenteen pysäkit</se:Name>
<UserStyle>
<se:Name>Joukkoliikenteen pysäkit</se:Name>
<se:FeatureTypeStyle>
<se:Rule>
<se:Name>Keltainen pysäkkisymboli</se:Name>
<se:PointSymbolizer>
<se:Graphic>
<se:ExternalGraphic>
<se:OnlineResource xlink:type="simple" xlink:href="https://raw.githubusercontent.com/finnishtransportagency/liikennemerkit/35be7a6593e70c8ed5f4e3ef54372d69a3fef558/collections/new_signs/svg/E6.svg"/>
<se:Format>image/svg+xml</se:Format>
</se:ExternalGraphic>
<se:Size>15</se:Size>
</se:Graphic>
</se:PointSymbolizer>
</se:Rule>
</se:FeatureTypeStyle>
</UserStyle>
</NamedLayer>
</StyledLayerDescriptor>
Yhteentoimivia ratkaisuja tarvitaan
Tässä esimerkissä kuvattu toteutus on esimerkki siitä, mitä kansallinen paikkatietovarasto ja sen sisältävien paikkatietoaineistojen jakelu standardoituja OGC-rajapintoja hyödyntäen voi parhaillaan mahdollistaa. Esimerkissä käytetty Väyläviraston ylläpitämä Digiroad on hyvä esimerkki hyvästi dokumentoidusta ja toimivien OGC-rajapintojen yli jaettavasta kansallisesta paikkatietovarannosta.
Teknologiaa yhteentoimivien ratkaisujen rakentamiseen on jo olemassa. Paras vakuutus yhteentoimivan ratkaisun rakentamisessa ovat avoimet OGC-rajapintastandardit ja niiden toteuttaminen FOSS4G-teknologioilla. Tässä esimerkissä nähty GeoServer on hyvä ja erinomaisesti dokumentoitu kokonaisratkaisu.
Jos jotakin negatiivista haluaa nostaa esille, niin tällaiset ratkaisut ovat omiaan tuomaan esille puutteita tietovarannoissa. Tässä esimerkissä sellaisia ovat mm. bussipysäkkien vajaat ja virheelliset tiedot. Jos nämä haluaa korjata, tarkoittaa se ainakin joissain määrin panostamista joukkoliikenteen pysäkkiaineistojen ylläpitotyöhön. Pysäkkiaineistojen ylläpidosta vastaavat mm. ELY-keskukset, kunnat ja ns. toimivaltaiset viranomaiset (esim. HSL).
