Anksčiau jau buvo rašyta, kaip lyginami išoriniai duomenų šaltiniai su atviro žemėlapio Open Street Map duomenimis (I dalis, II dalis). Tai taškinių (arba poligono centrų) duomenų lyginimas. Taškiniai duomenys yra paprastesni, todėl jų daugiau, juos paprasčiau rinkti, perduoti, gauti bei lyginti. Bet tai nereiškia, kad negalima lyginti ir kitokių tipų duomenis.

Lietuvos kelių duomenys

2014 metais iš Lietuvos automobilių kelių direkcijos buvo gauti (ir iki dabar gaunami atnaujinti) duomenys apie Lietuvos kelius: jų geometrija, numeriai ir dangos. Tai informacija, kurią galime matyti (ir naudoti pildant OSM žemėlapį) čia.

Bendras tikslas kaip ir aiškus – reikia patikrinti, ar sutampa LAKD ir OSM duomenys, t.y.:

• Ar nėra kelių LAKD, kurių nėra OSM
• Ar nėra kelių OSM, kurių nėra LAKD
• Ar sutampa LAKD ir OSM kelių duomenys – numeriai ir dangos

Pagrindinis tokio sulyginimo skirtumas: lyginame ne taškus ir jų žymas, o kelius ir jų žymas. Jei lyginant taškus rezultatas gali būti „yra/nėra“ arba „nesutampa žymos“, tai lyginant kelius dar gali būti ir „šito gabalo nėra“ arba „šitos dalies danga ar numeris nesutampa“.

Lyginimo techninė realizacija

Tikrinimas vykdomas PostgreSQL duombazėje su PostGIS priedu (standartinė OSM duombazė). Nėra (arba aš nežinau ir neradau) geografinės operacijos, kuri galėtų palyginti kelis vektorių rinkinius ir kažkaip parodyti jų skirtumus su nurodyta paklaida (tarkim 50 metrų paklaida). Taigi vieno rinkinio (tarkim LAKD duomenų) kelius (vektorius) prieš tikrindami keičiame į taškus, naudodami funkciją ST_DumpPoints. Rezultate vietoje kelio gauname rinkinį taškų, išdėstytų ant kelio kas nurodytą atstumą:

Tiesiog kuriant taškus iš vektorių gausime labai daug taškų (apie pusę milijono). Tokį taškų kiekį apdoroti reikės labai daug laiko. Taigi duomenis galime kažkiek supaprastinti. Tam pradžiai galime panaudoti funkciją ST_Simplify. Kadangi ST_DumpPoints iš vektoriaus padarys tiek taškų, kiek vektorius turi viršūnių, gali būti situacijų, kai labai ilgo vektoriaus segmento vidury duomenys skirsis, skirtumo mes nepastebėsime, jei tokių ilgų segmentų pradžiai nesuskaidysime į trumpesnius naudodami funkciją ST_Segmentize. Kuo mažiau apvalinsime ir daugiau segmentuosime – tuo gausime daugiau taškų, reiškia skaičiavimas užims daugiau laiko, bet rezultatas bus tikslesnis. Pradžiai imame stiprų apvalinimą ir nedarome jokio segmentavimo, taip skaičiavimus galima atlikti per kelias valandas.

Kiekvienas taškas turi tokias pat žymas (kelio numerį ir dangą), kaip kad turėjo vektoriai LAKD duomenyse.

Kai turime taškų (LAKD kelių) ir vektorių (OSM kelių) rinkinius, galima „eiti“ per visus turimus LAKD kelių taškus ir žiūrėti, ar per paklaidos (tarkim 100 metrų) atstumą yra OSM vektorius su reikiamomis žymomis, t.y. su tokiu pačiu kelio numeriu ir danga. Tikrindami gauname daugmaž tokį rezultatą:

...
51398 at 54.870567 25.250023 expected asphalt 108
52094 at 56.349779 22.745141 expected asphalt 1023
53819 at 54.871152 25.249397 expected asphalt 108
54990 at 56.173912 23.033801 expected unpaved 1018
...

Čia matome parodytas keturias klaidas, prie kiekvienos parodyta, kurioje vietoje buvo pagal LAKD duomenis tikėtasi kelio ir su kokia danga. Pavyzdžiui pirmoje eilutėje matome, kad taške 54.870567 25.250023 buvo tikėtasi rasti kelią su ref=108 ir danga asphalt.

Kadangi žinomos klaidų pozicijos, netgi nesutampančių vektorių geometrija ir savybės, naudodami QGIS nesunkiai galime padaryti neblogai atrodantį klaidų žemėlapį:

Rezultatai

Lyginant duomenis rastos tokios problemos:

• LAKD duomenyse yra aiškiai atskirti „pagrindiniai“ keliai ir „jungtys“. Pagrindiniai keliai turi numerius A1, A2, 108, 2025 ir pan., o jungtys turi ilgus devynių skaitmenų numerius. Pagrindiniai keliai turėtų OSM būti pažymėti kaip motorway, trunk, primary, secondary, tertiary, o jungiamieji su priesaga „_link“. Daugelyje vietų kol kas pažymėta bet kaip: arba be „_link“, arba pagrindinis kelias su „_link“, arba jungiamasis kelias apskritai pažymėtas kokiu nors „unclassified“ ar „residential“.
• Dangų nesutapimai dažniausiai aptinkami ten, kur per nedidelio miestelio ar kaimo teritoriją yra nutiesta nedidelė asfalto atkarpa. Bet yra nemažai neteisingai į OSM įvestų dangų.
• Geometrijos neatitikimų kol kas nerasta.

Greitaveika

Tikrinimas pagal aukščiau aprašytą algoritmą užtrunka ilgokai. Jei pradinių vektorių dalinimas į taškus su st_dumppoints, st_segmentize, st_simplify vyksta akimirksniu, tai va vėlesni milijonai st_distance(point, way) kvietimų jau užima labai daug laiko. Tikriausiai galima būtų procesą pagreitinti į taškus pavertus ne tik LAKD vektorius, bet ir OSM vektorius. Tada būtų galima ir galutinių OSM objektų aibę sumažinti. Na bet šituos bandymus optimizuoti paliksime ateičiai ar kitiems savanoriams 🙂

Apibendrinimas

Šio nedidelio tyrimo rezultatai sakyčiau tokie:

• OSM ir LAKD duomenys iš principo daugelyje vietų sutampa (nors yra labai daug smulkių neatitikimų). Kadangi duomenys suvesti nepriklausomai, tai galima sakyti, kad abu duomenų rinkiniai tikėtina yra teisingi ir pilni.
• Su OSM duomenimis galima lyginti išorinius ne tik taškinius, bet ir kitokių geometrijų objektus.
• Dar kartą parodyta, kad atvėrus duomenis ir leidus juos palyginti su OSM, naudą gauna abi pusės – tiek OSM, tiek duomenis atvėrusi organizacija/įmonė.