Pääkaupunkiseudun seutukartta avoimena datana

Huomasin, että taas on julkaistu hieno uusi paikkatietoaineisto.

http://www.hri.fi/fi/data/seutukartta/#comment-127

Tavalliseen tapaan tiedot on avattu niin, että tarvitaan ammattilainen tai pätevä amatööri niiden haltuunottamiseen. Tiedostot ovat ensinkin MapInfo TAB-muodossa, ja lisäksi koordinaattijärjestelmänä on KKJ:n 2-kaista. Aineisto on pilkottu 60 erilliseen TAB-tiedostonippuun (DAT, ID, MAP ja TAB) ja jotain pientä hankaluutta näyttää olevan muutamien teemojen ominaisuustiedoissa.

Seutukartta tulee pikapuoleen jalostettuna Latuviitan tiedostolatauksiin Spatialite-tietokantana, minkä lisäksi teen kertomuksen siitä, mitä aineiston haltuunottamiseksi piti tehdä. Luultavasti laitan aineistot myös WFS-palveluun, mutta taidan ensin vähän yhdistellä niitä, ettei ihan kuuttakymmentä tasoa sentään tarvitsisi julkaista.

Aineiston luvataan sisältävän mm. kaikki tiet nimineen päivineen.

Muistetaan nyt että on parempi laittaa julkinen aineisto sellaisenaan julkisuuteen nopeasti. Vaihtoehtona olisi, että ruvettaisiin komiteatyönä miettimään parasta mahdollista tiedostoformaattia ja koordiinaatistoa…ja joskus 2020-luvulla saataisiin työ valmiiksi.

Entäs sitten äänestysalueiden rajat: http://www.hri.fi/fi/data/paakaupunkiseudun-aanestysaluejako/ Tosin kaiketi vielä korjailun alla…

Kyllä, nopeasti vaan tarjolle. Kyllä ne siitä sitten Spatialiteksi ja WFS:ksi muuttuvat…

Ei sillä, että ne olisivat parasta, mitä kuvitella saattaa (varsinkaan WFS), mutta molemmissa on paljon hyviä puolia. Eikä niiden kanssa joudu umpikujaan, vaan valmiilla ilmaisilla työkaluilla pääsee sitten eteenpäin ilman ammattiauttajan apua.

Seutukartta on saataville ETRS-TM35FIN -järjestelmässä (EPSG:3067) Spatialite-tietokantana täältä:
http://latuviitta.org/documents/PK_seutukartta_2012_Spatialite.zip

Tietokannassa on 60 tasoa niin kuin ne olivat HRI:n paketissa. Hirveän suuria ongelmia muunnoksessa ei ollut, mitä nyt pientä päänvaivaa sekalaisten geometriatyyppien kanssa, ääkkösiä sisältävien ominaisuustietojan nimien kanssa ja merkistökoodauksen WindowsLatin1 <-> UTF-8 takia. Tietokanta tuntuu toimivan nyt hyvin ainakin seuraavilla ohjelmaversioilla: GDAL 1.9, Quantum GIS 1.7.0, Spatialite-gui 1.5.0 Final.

Ikävin työvaihe oli tehdä tietokantaan QGis-ohjelmalle kelpaavat spatiaalinäkymät, joille annoin pitkät nimet selvällä suomen kielellä.

Muunnosta tehtäessä törmäsin kolmeen erikoisuuteen GDAL:in toiminnassa, mutta en tiedä vielä, tulkitaanko niitä bugeiksi.

Aineisto ei ollut ihan niin hieno kuin ajattelin. Teiden määrä oli pettymys, ja paras sijaintitarkkuuskin on yleistyksessä menetettty. Aineistolla on varmaan eniten annettavaa niille, jotka kaipaavat kuntien sisäisiä aluerajauksia.

No sehän tarkoittaa minua, mutta olen vain ollut laiska opettelemaan GIS-työkaluja.

Eräs tapa toteuttaa Garmin-osoitehaku olisi määritellä kaupungit alueiksi ja kaupunginosat kaupungeiksi. Onko tuossa aineistossa kaikkien Suomen kuntien kaupunginosat?

Aineisto sisältää vain Helsingin seudun (14+ kuntaa?)

Onhan sekin alku. En lupaa mitään, mutta saatan yrittää lisätä joitain kaupunginosia OSM-kartalle.

Samaten voisin jossain vaiheessa kokeilla viritellä Garminin osoitehakuun aluejakoa. Esimerkiksi niin, että pääkaupunkiseudun kunnat ovat ‘alueita’ ja kaupunginosat ‘kaupunkeja’. Muualla Suomessa ‘alue’ olisi joko maakunta tai Suomi ja kaupungit ‘kaupunkeja’.

Noissa hallinnollissa rajoissa, jotka menevät kuntien sisäpuolelle tulee sitten ainakin yksi ongelma: rajat eivät välttämättä noudata aina samaa logiikkaa. Kaupungiosat, äänestysalueet, tilastoalueet yms. sotku on aikamoinen.

Mutta varmaan viralliset kaupunginosat löytyvät, ne eivät varmaan sitten noudata kiinteistörekisterin kyläjakoa.

Verestin Perl-taitojani ja tein pulauttimen, jolla latasin kokeeksi JOSMiin Vantaan suuralueiden rajat. Muuten hyvä, mutta Vantaan koilliskulma OSMissa (60.359479, 25.1551421) näyttää olevan parisataa metriä liian idässä.

spatialite> select astext(pointn(exteriorring(transform(geometry,4326)),78)) from a_va_suu where nimi='Korso';
POINT(25.151721 60.359279)

Muilla rajoilla näkyy olevan vain muutama metri heittoa. Bing-kuvien perusteella Vantaan koilliskulmalla (Pohjois-Nikinmäessä) on idässä peltoa. Tonttien rajat näyttävät noudattavan tuota ‘uutta’ rajaa. Muutama talo on naapurikunnan puolella, vaikka ainoa ajoreitti on Vantaalla. Se ei ole ihan tavatonta näillä nurkilla. Vantaan kartta- ja paikkatietopalvelu näyttää olevan samaa mieltä koillisrajasta: Siikatien kulma (60.3568208, 25.1476409) hipoo rajaa.

Mistähän tuo OSMissa oleva Vantaan raja on peräisin?

Sitten toinen kysymys: sivulla boundary=administrative sanotaan, että admin_level=9 tarkoittaa kylää ja admin_level=10 kaupunginosaa. Olisiko kylä sama kuin suuralue? Joskus muinoin ainakin osa Korson suuralueesta on ollut Ali-Keravan kylää.

Näillä näkymin lisäisin aluksi vain Vantaan suuralueet ja kaupunginosat, koska tunnen ne parhaiten.

Pulauttimeni toimii seuraavasti:

echo 'select kokotun,nimi,astext(transform(geometry,4326)) from a_va_kos;'|
spatialite pk_seutukartta.sqlite|
./spatial2osm.pl >vantaa_kaupunginosat.osm

Se yhdistää samassa paikassa olevat pisteet ja tekee jokaisesta alueesta oman way:n. JOSMissa tehtäväksi jää alueiden pilkkominen viivanpätkiin ja relaatioihin sekä tagien asettaminen. Katsotaan nyt, milloin ehdin niin pitkälle.

Olen käynyt Vantaan suuralue- ja kaupunginosarajoja läpi. Pakkalan alueessa oli risteys itsensä kanssa (ylimääräinen pisto Aviapolis/Ylästö-rajaviivaa pitkin). Muutamassa kohtaa on toisessa rajaviivassa ollut enemmän taitepisteitä kuin toisessa. Monet pisteet ovat lähes samassa paikassa vaan eivät täsmälleen, joten skriptini ei yhdistänyt niitä yhdeksi pisteeksi. Olen korjaillut näitä käsin JOSMissa.

Vierekkäiset alueet pitää pilkkoa viivanpätkiksi ja relaatioiksi. Onkohan siihen jotain valmista koodia?

OSM-tietokantaan vienti on oma ongelmansa. Vantaan ja Tuusulan rajalla näkyi olevan ylimääräisiä pisteitä. Osa niistä kuuluu rajaa myötäilevään polkuun. Yhteen oli virheellisesti yhdistetty tien päätepiste. Vaikuttaa siltä, että OSMiin vienti edellyttää, että kaikista useaan viivaan kuuluvista pisteistä on ladattava myös ne naapuriviivat, ettei rajaa siirtäessään tule vahingossa siirtäneeksi samaan pisteeseen kuuluvia muita polkuja tai poistaneeksi pisteitä muista poluista. Mutta miten? JOSMin ctrl-alt-d (lataa emopolut) vaikuttaa lataavan samat polut moneen kertaan. Niin voisi kuvitella bbox-haunkin tekevän. Tuntuisi järkevimmältä ottaa koko Suomen vedos ja valita siitä annetun pistejoukon sisältävät polut ja relaatiot. Mutta kuinka? Osmosis ei vaikuta osaavan sitä.

No niin, sain lopulta muunnetuksi Vantaan rajat 69 relaatioksi, 179 viivaksi ja 1572 pisteeksi. Aikamoista turaamista se oli. Toivottavasti seuraavia kaupunginosia varten työkalut osaavat jo yhdistää ne melkein samanlaiset pisteet ja viivat.

OSMiin vientiä varten koostan vielä karttaotteen jossa on kaikki nykyisiin rajapisteisiin liittyvät viivat ja relaatiot. Ainakin yhdessä kohtaa nykyisellä Vantaan rajalla on yhteisiä pisteitä metsäpolun kanssa, joten en voi sokkona siirrellä enkä poistella vanhan rajan pisteitä. Rajat olisi mielestäni hyvä pitää kokonaan erillisinä olioina, mutta minkäs teet, kun OSMissa ei ole kuin yksi karttataso.

Lähtöaineistossa on tosiaan topologiavirheitä. Vilkaisin itse Vantaan kaupunginosajakoa, ja sieltä löytyi aikakin pistoviiva Pakkalasta, muutamia taitepisteitä, jotka erosivat naapurialueilla parin senttimetrin verran toisistaan, ja naapurialueiden rajaviivoja, joilla oli eri määrä taitepisteitä, josta seuraa sitten päällekkäisyysalueita ja aukkoja. Niiden korjaaminen ei ole ihan helppoa kokeilemillani avoimen lähdekoodin työkaluilla.

Tästä voi tehdä johtopäätöksiä puoleen jos toiseenkin. OSM:in topologinen tietomalli on etevämpi kuin Simple Feature -malli alueille, koska yhteinen rajaviiva on olemassa vain yhteen kertaan eikä aukkoja ja päällekkäisyyksia siten synny. Toisaalta on vaikea keksiä käyttötarkoituksia, joissa aluekohteet ja Simple Feature malli ei toimisi kunnanrajoille, koska parin sentin raoista ja päällekkäisyyksistä ei ole mitään haittaa. Kunnanrajoja pitkin tuskin navigoidaan.

Usean päivän puurtaminen 69 kaupunginosarelaation vääntämiseksi valmiista aineistosta on kyllä surkean hidas työsaavutus. Jos joku käyttäisi palkattua työvoimaa tuollaiseen työhön, niin työkaluille ja tietomallille tehtäisiin jotain ja nopeasti.

Alku aina hankalaa, sanoisin. Työkalut kyllä voivat kehittyä, kun on olemassa selkeä tarve.

Näköjään ogr2osm käyttää hash-taulua pisteiden muuntamiseen, niin kuin omatekoinen skriptinikin käytti. Mahtaakohan jossain Python-kirjastossa olla valmiiksi jokin R-tree tai quadtree, jolla voisi näppärästi yhdistää pisteet, jos ne ovat muutaman senttimetrin (tai annetun rajan) päässä toisistaan?

OSM-vientiä varten kokeilen, osaanko tehdä Osmosis-ohjelman used-way-suodinta muuttamalla suotimen, joka valitsee kaikki annettuihin pisteisiin liittyvät viivat. Sitten irrottaisin JOSMissa rajaviivat kaikista muista viivoista ja lopuksi siirtäisin rajapisteet uuden aineiston mukaisiin paikkoihin. Vai olisikohan helpointa vain poistaa vanha raja ja ladata kokonaan uusi? OSMissa olevassa Vantaan rajassa näkyy olevan 693 pistettä.

Lisäys: Taitaa olla paras odotella, että kaikki kuntarajat on saatu siirtymään MML:n aineiston vapauduttua. Sitten voi helpommin täydennellä noita suuralue- ja kaupunginosarajoja, kun ei tarvitse siirrellä eikä poistaa vääriä taitepisteitä…

Valtaosa seutukartta-aineistosta on nyt myös WFS-palvelussa http://hip.latuviitta.org/cgi-bin/tinyows. Jonkinlaisia käyttöohjeitahan on sekä http://hip.latuviitta.org että http://latuviitta.org -sivustoilla. Kahta WFS-aineistoa ei saa toistaiseksi auki nirsoilla GIS-ohjelmilla niissä olevien topologiavirheiden takia. Tasolla pks_pienalue on yksi saarekkeellinen polygoni, jonka saarekkeessa on vain kolme pistettä eli kyseessä on “tuonne ja takaisin” tai A-B-A -tapaus. Tasolla pks_junarata on puolestaan yksi multilinestring, jonka yksi osa muodostuu yhdestä pisteestä.

Lähes kaikilla muillakin tasoilla on topologiavirheitä, eli löytyy itseään leikkaavia kohteita, peräkkäisiä samoja koordinaatteja, väärään suuntaan kiertäviä aluekohteita tai saarekkeita. Näiden lisäksi on sitten massoittain noita OSM-käyttöä haittaavia tapauksia, jossa yhteinen rajaviiva on vierekkäisillä alueilla enemmän tai vähemmän erilainen. Ne eivät ole kohde kerrallaan tarkasteltuna topologiavirheitä, mutta kylläkin silloin, jos tasoa ajatellaan yhtenä kokonaisuutena. Valtaosa virheistä ei haittaa GIS-käytössä ollenkaan, ja koska on oikeastaan ihan hyvä, että on palvelu, josta voi milloin tahansa hakea aineistoja, joissa on topologiavirheitä, niin jätän ne korjaamatta. Tuon pienaluetason ehkä kuitenkin korjaan, koska siitä voisi olla jollekin hyötyä ehjänä.

Voisikohan olla järkevää vihjaista ‘ylävirtaan’ päin noista virheistä, vai johtaisiko se sitten siihen, että ‘lahjahevosen suuhun ei ole katsomista’ ja ‘vienpäs leluni pois hiekkalaatikolta’? Idealistisesti ajatellen olisi kaikkien etu, että olisi yksi kunnollinen aineisto, jota kaikki kopioivat. Jos jokainen tarvitsija korjaa topologiavirheet ja irvistelevät aluerajat omin päin, niin sitten tietojen myöhempi päivittäminen hankaloituu.

ogr2osm:n tekijä oli muuten sitä mieltä, ettei muunnostyökalun tehtävä ole korjata virheitä.

Lähetin ilmoituksen löytämistäni virheistä mutta toistaiseksi en ole saanut vastausta.

Kirjoitin myös ohjeen seutukartta-aineiston haltuunotosta. Ohjeen kirjoittamisen yhteydessä jouduin myös selvittämään GDAL:in Mapinfo- ja GML-ajureiden toimintaa ja sitä, kuinka ne käsittelevät eri merkistökoodauksia, ja tuo osuus viekin ohjeesta melko suuren osan. Ohjeeseen sisältyy myös komentojonot, joilla voi muuntaa seutukartta-aineiston 60 karttatasoa yhtä moneksi Spatialite-tietokannan tauluksi mittausteni mukaan 102 sekunnissa.
Ohje löytyy osoitteesta http://latuviitta.org/documents/Mapinfo_GDAL_ogr2ogr_ja_UTF-8.pdf

Nekin ovat nyt saatavilla Latuviitan WFS-palvelusta. Ei ollut kuin yksi pahempi topologiavirhe jäljellä, eli pistoviiva, joka esti alueen sulkeutumisen. Tässäkään aineistossa vierekkäiset alueet eivät kuitenkaan läheskään aina kohtaa, ja rajaviivoilla on taitepisteitä joissain paikoin aika tiheässä. Alle senttimetrin välejäkin on 4 ja alle metrin välein olevia taitepisteitä on 1844 kpl. Mutta topologia on niiden osalta kunnossa, vaikka vähemmilläkin pisteillä tällaisessa kartassa pärjättäisiin. Ei ole tarkoitus morkata tiedojen julkaisijaa, hyvä että julkaisee, mutta esimerkiksi OSM-käyttöä varten olisi luvassa varsin paljon yleistämistä ja vierekkäisten alueiden sovittelua.