Atvirasis Vilnius

Vilniuje išrinktas naujas meras, atsinaujino taryba ir administracijos aparatas. Ir ši valdžia nuo pat pirmų dienų imasi spręsti atvirų duomenų klausimą. Klausimą, kuris ilgą laiko buvo kaip tabu. Gerai pamenu, kaip prieš porą metų teko bendrauti su savivaldybės ir „Vilniaus plano” darbuotojais dėl bendradarbiavimo su OSM bendruomene. Tie susitikimai nebuvo tokia jau paprasti, o rezultato pasiekti nepavyko. Savivaldybės duomenys, jei ir buvo publikuojami, tai tik labai atkaklių asmenų dėka. Šiandien situacija keičiasi kardinaliai.

Nežinau ar buvo specialiai tam kviestas, ar kažkaip išrinktas, bet atvirų duomenų klausimo ėmėsi spręsti portalo freedata.lt įkūrėjas Povilas Poderskis. Netrukus Povilas pradėjo dalintis soc. tinkluose ir opendata.lt portale savo įspūdžiais iš savivaldybės. Dar po kurio laiko Vilniaus susikūrė savo github.com paskyrą. WOW! Čia tai bent šuolis – nuo visiško tabu iki pačios populiariausios atviro kodo platformos.

Ir nuo pat pirmos dienos github.com/vilnius atsirado tokių duomenų, kaip reklamos plotai, darželinų sąrašai, žemės nuomos sutartys, mažos vertės pirkimai ir net spausdintuvų naudojimas pačioje savivaldybėje. Yra ir geografinių duomenų – 2015 metų bendrasis planas. Tiesa, duomenų rinkinys skurdokas, bet iniciatyva puiki.

Ir tai dar ne viskas. Povilas iš tiesų pasistengė ir per tokį trumpą laiką paleido savivaldybės atvirų geografinių duomenų portalą! Pagaliau atsirado pilnavertis daiktas, su paieška ir duomenų peržiūra tiek žemėlapyje, tiek duomenų lentelėse. Pačių duomenų dar nedaug, reikia turėti omeny, kad tai tik pradžia (tikiuosi), bet iniciatyva puiki, tikrai 🙂

Ir tai dar ne viskas 🙂 Pasirodo, greitu metu atsiras dar vienas dviračių žemėlapis bikes.vilnius.lt. Kolkas šis puslapis neveikia ir sunku pasakyti, kuo jis bus geresnis už eilę kitų dviračių žemėlapių. Neaišku, ar bus galimybė panaudoti duomenis, kaip jie atrodys lyginant su OSM.

Taipogi Povilui pavyko atrasti dar vieną savivaldybės iniciatyvą. Šį kart tai kapinių žemėlapis cemety.lt. Sistema leidžia peržiūrėti kapų poligonus kapinių teritorijoje, vykdyti paiešką pagal vardą arba gimimo/mirties metus. Žemėlapio bazinis sluoksnis – standartinis OSM. Viskas būtų gerai, bet yra tik vienos kapinės ir kažin ar atsiras daugiau.

Naujienų daug ir paminėjau ne visas. Plačiau iš paties Povilo galima pasiskaityti pinigų kartoje. Nauji vėjai savivaldybėje pradėjo daug gerų iniciatyvų. Atvirų duomenų srityje, vos per porą mėnesių buvo padaryta daugiau, nei per pastaruosius 5 metus. Jei taip ir toliau, tai po metų-kitų Vilnius taps pavyzdine savivaldybe. Belieka palinkėti, kad šios iniciatyvos neišblėstų, o naujasis meras su komanda ir toliau taip ryžtingai imtųsi reikalingų darbų.

Share

Lankytinų vietų sinchronizavimas (I dalis)

Lankytinų vietų informacija

Tikriausiai viena išskirtinių atviro žemėlapio savybių – lankytinų vietų (toliau – LV) skaičius ir įvairovė – kavinės, restoranai, muziejai, piliakalniai, parduotuvės, istorinės vietos, bankomatai, elektromobilių įkrovimo vietos ir t.t. ir pan.

lankytinos_vietos

LV atvirame žemėlapyje atsiranda įvairiais keliais:

  • įvedamos po vieną pagal vietines žinias. T.y. kažkoks žymėtojas pamato kavinę ar muziejų ir įveda jį į atvirą žemėlapį.
  • LV informacija gauta iš išorinių šaltinių ir importuojama į žemėlapį. Gal tai degalinių ar parduotuvių informacija iš tinklo valdytojo, gal turizmo objektų informacija iš regioninio parko ir pan.

Informacijos priežiūra

Nesvarbu, kuriuo iš aukščiau išvardintų būdų lankytinos vietos beatsirastų žemėlapyje, gali iškilti kelios problemos/uždaviniai:

  • Prieš įkeliant informaciją apie LV reikia patikrinti, ar LV dar nėra įrašyta (galbūt kitu pavadinimu, su kiek kitokia informacija, kitaip klasifikuota, šiek tiek kitoje vietoje ir pan.)
  • Dėl vienų ar kitų priežasčių jau įvesta LV informacija kartais gali būti netyčia pašalinta ar kažkieno netyčia neteisingai pakeista
  • Informacija gali būti netiksli arba pasikeisti po LV įvedimo į duomenų bazę

Šias problemas teoriškai galima spręsti rankiniu informacijos peržiūrėjimu, tikrinimu ir keitimu, bet tai visiškai nepraktiška, ypač kai objektų skaičius didelis (šiuo metu Lietuvoje yra virš 30000 LV).

Sinchronizavimas

Vienas iš galimų sprendimų – dvi objektų aibės, kurios periodiškai lyginamos viena su kita. T.y. iš išorinio šaltinio gauname kažkokių objektų (tarkim piliakalnių) sąrašą (su koordinatėmis, pavadinimu, tipu ir kita informacija) – tai mūsų „išorinis šaltinis“. Tada imame informaciją apie piliakalnius iš atviro žemėlapio (irgi koordinates, pavadinimą ir kitą informaciją) ir taip gauname „OSM duomenis“. Išorinio šaltinio duomenis keičia tik išorinis šaltinis (tas, kas teikia informaciją), o OSM duomenis keičia ir tas, kas perkelia išorinius duomenis į OSM, ir visi kiti atviro žemėlapio naudotojai/žymėtojai. Tada belieka periodiškai palyginti abi šias aibes ir rasti neatitikimus:

  • objektai, kurių trūksta žemėlapyje
  • objektai, kurių trūksta išoriniame šaltinyje (gali būti, kad ir išorinio šaltinio duomenys nepilni ar pasenę)
  • objektai, kurių informacija išoriniame šaltinyje ir žemėlapyje nesutampa (koordinatės kitoje vietoje, neatitinka pavadinimas, tipas ar kita informacija)

sinchronizacija

Gavus tokią informaciją pildomi/keičiami trūkstami duomenys OSM bei siunčiama informacija išorinių duomenų tiekėjui apie netikslumus jų duomenų rinkinyje.

Ką laimime?

Vieną kartą suvedus duomenis mes galime sekti, kad tie duomenys nebūtų netyčia sugadinti. Jei duomenis žemėlapyje kažkas pakeičia, tai gali rodyti, kad:

  • LV informacija pasikeitė ir pasikeitimai dar neperkelti į išorinį šaltinį
  • Kažkas padarė klaidą keisdamas LV informaciją žemėlapyje

Pirmu atveju žinome, kad reikia informuoti pradinės informacijos tiekėją, kad jie ir savo duomenis pasikeistų (gali būti, kad reikia tiesiog atsisiųsti naują informacijos rinkinį iš pradinio tiekėjo).

Antru atveju operatyviai pataisome duomenis ir informuojame apie tai klaidą padariusį žymėtoją – paaiškiname kaip, kur, kas ir kodėl.

Taigi turime balansą tarp masinio importo ir rankinio įvedimo po vietinės apžiūros: masinis importas padeda greitai suvesti duomenis, įvedimas po vietinės apžiūros leidžia tikslinti ir prižiūrėti duomenis.

Naudą gauna tiek atviras žemėlapis, tiek ir išorinis duomenų tiekėjas:

  • Atviras žemėlapis gauna aibę duomenų, didėja bendras turimų duomenų kiekis
  • Duomenų tiekėjas gauna informaciją apie klaidas/netikslumus turimuose duomenyse, platinami išorinio tiekėjo duomenys

Kas toliau?

Tokį sinchronizavimą daryti žymiai patogiau, kai naudojama informacinė sistema. Kaip tokia sinchronizavimo sistema realizuota Lietuvoje bus aprašyta kitame įraše.

Share

100000 km kelių!

Pasiekėme apvalų skaičių – jau sužymėjome 100 000 km kelių! Sveikinimai visiems!

Skaičius gražus, bet norėtųsi žinoti, koks skirtumas nuo kitų žemėlapių, kiek dar liko ir pan.

Garmin žemėlapis „Lietuvos keliai“

Paprasčiausias būdas įvertinti pasiektą kelių ilgio rezultatą – palyginti su kokiu nors kitu žemėlapiu. Prieš pusmetį oficialiuose Garmin „Lietuvos kelių“ žemėlapiuose kelių ilgis padidėjo iki 114 000 km. Iki šio rodiklio mums trūksta 14 000 km. Dabartiniais tempais tokį ilgį pasieksime po 300 dienų.

Bendras OSM duomenų palyginimas su komerciniu Garmin žemėlapiu (raudonas – komercinis, žalias – OSM žemėlapis):

Palyginimas su Garmin žemėlapiu

Pilnumo įvertinimas be kitų šaltinių

Praėjusių metų OSM susitikime buvo įdomus pranešimas apie tai, kaip įvertinti GIS duomenų rinkinio kokybę nenaudojant jokio kito duomenų rinkinio. Vienas iš būdų – suklasifikuoti kelius: nuo svarbiausių – automagistralių iki mažiausių – miško kelių ar pėsčiųjų takų. Tada galima pažiūrėti, kurios klasifikacijos kelių ilgiai stabilizavosi, o kurių – vis dar keičiasi. Paprastai pirmiausia užpildomi svarbiausi keliai (automagistralės) ir taip palaipsniui baigiami pildyti vis mažesnio svarbumo/matomumo keliai.

Šiai dienai kelių ilgiai pagal klasifikacijas Lietuvoje pasiskirsto taip:

Kelių ilgiai pagal klasifikaciją

Taigi matome, kad jau sužymėta absoliuti dauguma pagrindinių kelių iki pat klasifikacijos „unclassified“ („unclassified“ – svarbūs keliai, kurie neturi valstybinės/oficialios klasifikacijos). Paskutinius pusę metų pagrinde pildomi tik smulkūs privažiuojamieji arba miško keliai ir takai.

Žodžiu, duomenų jau turime pakankamai, tad galime drąsiai lygintis su komerciniai žemėlapiais. Dabar pagrindinis mūsų tikslas – rinkti informaciją apie iš oro nematomus miško kelius ir takus. Sėkmės!

Share

ORT10LT klasteris

Kaip žinot, šiais metais gavome oficialų leidimą naudoti ORT10LT ortografines nuotraukas žemėlapių kūrimui. Buvo super, įvyko didžiulis proveržis bendraujant su valstybinėm institucijomis, gautos puikios kokybės nuotraukos, bet jos teikiamos ne itin patogiu servisu ir lėtai. Buvo nuspręsta paleisti proxy servisą, kuris automatiškai konvertuotų į reikiamą failų struktūrą ir pagreitintų veikimą. Bet šis serveris pareikalavo resursų(~100GB 2013 liepą), kuriuos turėti duomenų centre kainuoja, gal ir nedaug, bet suma vis dėl to susidaro. Poreikis bėgant laikui vis auga.

Po poros nesėkmingų bandymų susitvarkyti su tokiais duomenų kiekiais, buvo nuspręsta ieškoti pilnai decentralizuotos platformos ORT10LT paveikslų saugojimui. Turint klasterį, visi norintys ir galintys galėtų prisijungti prie jo ir tokiu būdu panaudoti savo asmeninius kompiuterius bendram reikalui. Tokia platforma buvo pasirinktas Riak ir jis pateisino savo vardą. Šiandien veikia 4 mazgai, kiekvienas iš jų saugo ~40GB duomenų. Tokiu būdu pasiskirsto tiek duomenų tūris, tiek ir jų srautas. Kuo daugiau mazgų, tuo mažiau reikia resursų iš kiekvienio iš jų. Iš esmės Riak veikia P2P principu ir klasteryje nėra nei vieno centrinio mazgo. Vienam mazgui sustojus, jo darbą automatiškai perima ir tęsia likusieji. Taigi, Riak leidžia paprastai turėti net ir labai didelę duomenų saugyklą. Problema kaip ir išspręsta, belieka tik rast savanorių, kurie galėtų ir norėtų panaudoti dalį savo asmeninių kompiuterinių resursų bendram tikslui.

Ką prarasiu, kokie reikalavimai? – pirmieji klausimai, ateinantys į galvą svarstant tokią galimybę. Atsakymas paprastas – prarasit ~50GB kieto disko vietos, 512MB operatyvinės atminties ir truputi duomenų srauto. Na o Jūsų kompiuteris/serveris turėtų būti bent dvigubai talpesnis, kad klasterio mazgas neužgoštų kitos veiklos.

Kam ir kokia iš to nauda? Naudą gaus visi, kas naudoja ORT10LT OSM vystyme. Juk kuo daugiau klasterio mazgų, tuo labiau pasiskirsto duomenys ir jų srautas, tuo mažesnė tikimybė sutrikdyti klasterio veikimą vienam iš mazgų „nulūžus”, tuo labiau išlošia OSM bendruomenė. Nei aš, nei kas nors kitas, jokios asmeninės naudos iš šio klasterio neturės. Klasteris naudojamas išskirtinai tik ORT10LT paveikslams.

Taigi, jei nusprendėte prisidėti, tai padaryti galim dviem būdais:

Antrasis būdas sunkesnis, ypač jei nenaudojate Debian šeimos operacinės sistemos, todėl pradžiai rekomenduočiau naudoti pirmąjį būdą. Kilus klausimams visada galima kreiptis į mane, Ramūną, arba Tomą asmeniškai arba per talk-lt.

Share

Vilniaus adresai

Kiek anksčiau jau buvo rašyta apie Vilniaus adresų papildymą. Šį kartą parašysiu apie tai, kaip adresų informacija yra atnaujinama ir prižiūrima.

Adresų informacijos pasikeitimai

Gali pasirodyti, kad pastovus adresų palaikymas nėra labai svarbus. Jei Vilniaus savivaldybė pateikiamų adresų sąrašą atnaujins kas metus, užteks kartą per metus adresus iš naujo įkelti ir viskas? Tikriausiai ne, nes neaišku, kas kiek laiko Vilniaus savivaldybė atnaujins dabar pateikiamą adresų sąrašą, o ir Vilniaus adresų informacija pakankamai sparčiai keičiasi. Štai adresų pasikeitimo grafikas:

adr_change

Kaip matome, kiekvieną mėnesį atsiranda 300 naujų adresų. Tai apie 10 adresų per dieną! Taipogi po 50 senų adresų yra panaikinama. Tokiais tempais per metus bus sukurta 3500 naujų adresų, o tai sudaro daugmaž 7% visų Vilniaus adresų.

Taigi norisi adresus atnaujinti daugmaž tuo pačiu metu, kai adresų informaciją keičia Vilniaus savivaldybė. Laimei adresų pokyčių informacija (adresų keitimo įsakymai) yra viešai prieinama Vilniaus savivaldybės svetainėje, o pagal šiuo metu galiojančius įstatymus, ši informacija yra ir vieša, ir atvira (t.y. ją ramiai galime naudoti OSM pildymui).

Adresų pasikeitimų įsakymai publikuojami pdf formatu. Šis formatas nėra toks patogus, kaip tarkime xml, bet visgi tai ne piešinys, reiškia jį galima apdoroti automatiškai. Kiekviename įsakyme yra viena arba daugiau eilučių, kiekvienoje iš kurių yra naikinamo ir/ar sukuriamo adreso informacija (gatvė, numeris, korpusas) bei tikslios adreso koordinatės.

Šią informaciją perskaito sukurti skriptai ir tada gauname daugmaž tokį įsakymo detalizavimą:

adresu_isakymo_detales

Kaip matome, įsakymo informacija sulyginama su esama adresų informacija. Patikrinama ar kuriamas adresas jau yra OSM duomenų bazėje. Jei yra, ar jis nėra per daug nutolęs nuo įsakyme pateikiamos padėties. Jei adreso informacijos nėra, trūkstamą informaciją vienu paspaudimu galima perduoti į JOSM redaktorių.

Kadangi didžioji dalis šio proceso yra automatizuota, vieno adreso informacijos pasikeitimas apdorojamas per kelias sekundes. Tai leidžia negaištant daug laiko greitai atnaujinti adresų informaciją.

Vilniaus savivaldybės adresų informacijos lyginimas su OSM DB

OSM duomenų bazė yra atvira. Informaciją bet kas gali tiek skaityti, tiek ir keisti. O tai reiškia, kad žymėtojai gali netyčia sugadinti adresų informaciją, pavyzdžiui keičiant pastato geometriją panaikinti egzistuojančio adreso žymas ar pridėti seniai jau panaikintą adresą (žinau atvejų, kai gyventojai po adreso pasikeitimo nežinojo savo naujo adreso ir pyko ant taksi vairuotojų, kurie važiavo pagal naują adresų informaciją, tokie gyventojai gali norėti „pataisyti“ adresų informaciją OSM duombazėje). Taigi reikia karts nuo karto palyginti Vilniaus Savivaldybės adresų db (atnaujinamą naudojant įsakymų duomenis) su informacija, esančia OSM duomenų bazėje.

Palyginę gauname dvi adresų grupes:

  • Adresai, kurie yra VS db, bet kurių nėra OSM. Tokius adresus pridedame į OSM.
  • Adresai, kurie yra OSM db, bet kurių nėra VS db. Tokius adresus iš OSM db išimame.

Taigi turint šiuos du sąrašus galima pastoviai palaikyti švarią ir šviežią adresų informaciją.

Bendras adresų informacijos kelias

Taigi galutinį informacijos kelią matome šioje schemoje:

adresu_informacijos_eiga

  • Periodiškai (kol kas neaišku, kas kiek laiko VS atnaujins savo skelbiamą adresų sąrašą) adresai gaunami iš Vilniaus Savivaldybės. Gauta informacija naudojama pradiniam tarpinės adresų db užpildymui ir periodiškam jos sinchronizavimui.
  • VS adresų keitimo įsakymai naudojami greitam adresų informacijos pasikeitimų įkėlimui į tarpinę adresų db
  • Duomenys tarpinėje adresų db naudojami atnaujinant ir prižiūrint Vilniaus adresų duuomenis OSM duomenų bazėje.

P.S. Na, realybėje gal nėra viskas taip paprasta, viena-kita klaida gali pasitaikyti ir VS duombazėje, bet tai jau visai kita tema 🙂

Share