Tekninen seuranta: Kuinka rakensimme maailman kauneimpia automaattisesti luomia kuljetuskarttoja

kirjoittanut Anton Dubrau

Kuusi viikkoa sitten käynnistimme Transit Mapsin ja kirjoitimme tämän blogiviestin siitä, miksi otimme mammutin tehtävän luoda automaattisesti luodut, mutta esteettisesti miellyttävät kartat. Yleisö reagoi ponnisteluihimme meihin, vaikka emme olekaan yllättäviä ottaen huomioon niiden luomiseen tarvittavaa aikaa, ajatusta ja inspiraatiota. Tänään toteutamme lupauksemme julkaista tekniset jatkotoimet Antonin, asukaskarttatoiminnon, joka selittää paljon yksityiskohtaisemmin näiden karttojen rakentamiseen.

Kun ajattelet Transit-palvelua, saatat ajatella tyylikästä ja värikkäästä käyttöliittymästä. Ottaen huomioon, että olemme erityisen kiinnostuneita sovelluksen tekemisestä mahdollisimman kauniiksi ja käytettäväksi, se ei ole suuri yllätys. Mutta käyttöliittymä ei ole ainoa asia, josta meillä on: tiimimme ulottuu huomattavasti asiantuntija-suunnittelijoiden ulkopuolelle, ja sovelluksemme on paljon enemmän kuin vain kaunis. Pinnan alla on paljon "kovaa" tekniikkaa, joka ajaa sitä hiljaa.

Ensinnäkin tehokas taustaohjelmamme tarkistaa satoja siirtotietosyötteitä, korjaa automaattisesti rikkoutuneet tiedot ja merkitsee tutkimusta tarvitsevat ongelmat. Järjestelmä antaa meille mahdollisuuden hallita 350 kauttakulkuviestiä 125 kaupungissa pienellä ryhmällä.

Sitten on pakkausalgoritmi. Se kutistuu kauttakuljetusaikatauluista jopa 100 kertaa pienemmäksi kuin passitusvirastojen tarjoamat zip-tiedostot. Tämän avulla Transit voi ladata käyttäjän koko alueen aikataulut, tallentaa tiedot käyttäjän laitteelle ja palauttaa hakutulokset ... kaiken niin kauan kuin muut sovellukset vaativat ja lataavat yhden aikataulun. Ja vaikka käyttäjät ovat nyt tottuneet sovelluksemme nopeuteen, kun ominaisuus otettiin ensimmäisen kerran käyttöön, se lyhensi reagointiaikaa useasta sekunnista 0,1 sekuntiin. Se on nopeaa.

Mutta on olemassa yksi tietty tekniikka, jota olemme työskennelleet vuosia. Suurena iloksemme (ja helpotukseemme) julkaisimme sen vihdoin kesällä: automaattisesti luodut kauttakulkukartat.

Transit Maps: Transit App (vasen), Apple Maps (keskellä) ja Google Maps (oikea)

Itse idea ei ole tuskin uusi: Google julkaisi kauttakulkukartansa melkein kuusi vuotta sitten. Mutta osoittautuu, että se on melko ongelma ratkaista, ja Google (myös näiden vuosien jälkeen) ei silti pysty tuottamaan kovin kauniita tai jopa erittäin hyödyllisiä kauttakulkukarttoja.

Joten miten saimme sen? Hikeellä, kyyneleillä ja luovalla ajattelulla.

1. Muodot kartalla

Ajatus luoda automaattisesti karttoja on jotain, joka on kiehtonut minua jo ennen liittymistä Transit App -sovellukseen kolme vuotta sitten. Tuolloin Google oli alan ainoa toimija, ja rehellisesti sanottuna niiden kauttakulkukartat olivat tavallaan hulluja. Olimme juuri valmistaneet yllä mainitun superkompressioalgoritmimme ja tunsimme olevansa valmiita käsittelemään uutta ongelmaa. Kuvittelimme melko naiivisti, että se vie noin kolme kuukautta. Tiesimmekö vähän ...

Ensimmäinen askel oli näyttää lähdetiedot kartalla. Monet perustana olevien kauttakulkutietojen matkoista sisälsivät jo muotoja, jotka edustavat kauttakulkuajoneuvojen kulkevia reittejä. Jos piirtäisimme kaikki kaikkien matkojen määrittelemät muodot, saisimme yksinkertaistetun tyyppisen kauttakulkukartan:

Transit Maps -tekniikkamme, noin marraskuu 2014

Tämän tekeminen oli suhteellisen yksinkertaista: perustimme prosessointiputken, jonka avulla muodot voidaan poimia lähdetiedoista; tallensi muodot datanvaihtomuotoon; varmisti, että tiedot olivat laitteen käytettävissä; ja piirsi uuden karttakerroksen datan avulla laitteen kartoituskirjastoihin.

Helppo. Meillä oli tämä valmiina ja pari viikkoa.

Mutta vaikka se on lähellä, se ei ole oikea kuljetuskartta. Kaikki viivat piirrettiin päällekkäin. Et voi kertoa, mitkä viivat menevät minne - ja ainoa näkyvä viiva oli viimeksi piirretty. Oikeiden kaavamaisten karttojen saamiseksi, joissa voit seurata viivoja sormella, sinun on piirrettävä ne yhdensuuntaisesti ja leikkattava mahdollisimman vähän.

2. Yhdistäminen OpenStreetMap-ohjelmaan

Karttojen rakentaminen muotoilla aiheutti muita ongelmia: mitä meidän pitäisi tehdä, kun toimisto ei tarjoa muodotietoja tai jos toimisto tarjoaa erittäin huonoja muotoja? Ainoa maantieteellinen tieto, joka meillä olisi sellaisissa tapauksissa, olisi pysähdyspaikat. Toki, voisimme piirtää suoria linjoja pysähtyneiden väliin, mutta se on ruma, sotkuinen ja hämmentävä.

Se on ongelma myös Googlen Transit Maps -palvelussa. Berliinissä Google muodostaa suorat yhteydet pysäkkien välillä; Lontoossa he käyttävät jonkinlaista spline-interpolaatiota, joka ei seuraa todellisia raitoja; ja LA: ssa he käyttävät viraston tarjoamia muotoja, vaikka muotojen laatu on todella melko huono.

Google Maps Berliinissä (vasemmalla) ja Lontoossa (oikealla)

Hauskaa on, että kun zoomaat karttoja, huomaat, että Googlella on usein tietoja taustalla olevista raiteista, mikä herättää kysymyksen: miksi he eivät yhdistä raiteita muodotietoihin? Päättivätkö he, ettei sillä ole merkitystä?

Vaikka Google ei ehkä ajattele sen olevan tärkeätä, teemme varmasti. Toki, meillä ei ole pääsyä Googlen rikkaisiin karttatietoihin, mutta voimme käyttää seuraavaa parasta: OpenStreetMap (OSM). Ja kiitos heidän vapaaehtoistyöntekijöiden yhteisönsä ansiosta OSM: llä on käytännössä kaikki julkisen liikenteen rautatiet, joita käytämme sovelluksessamme.

OpenStreetMap-raidetiedot

Luomalla OSM-katuruudukkoon muodon, joka yhdistää kaikki tietyn reitin pisteet, voisimme luoda kuljetusmuodomme! Joten loimme dynaamisen ohjelmointialgoritmin, joka seuraa teitä tai raitoja, joita todennäköisesti käytetään kauttakulkulinjoilla. Muodonvalmistusalgoritmi pohtii, minkä tyyppinen ajoneuvo kulkee linjalla, ja minimoi sovitusvirheet (ts. Generoidun muodon ja lähteiden todellisten sijaintien väliset etäisyydet).

Tässä on esimerkki. Alla olevassa kaaviossa meillä on matka kolmella pysähdyksellä, ilman muotoilutietoja. Otamme matkan käyttämän raitasarjan OSM: sta (harmaat viivat). Vastaava algoritmimme löytää sitten kulkuradan (musta viiva), joka seuraa OSM: ää, minimoimalla samalla sen pituus ja pysäytysvirheet (e1, e2, e3).

Muoto-OSM-sovitusprosessi

On vaikea saada tämä algoritmi toimimaan kaikissa tapauksissa, joten joskus meidän on toimitettava parametrit, jotta tietyt rivit toimivat. Kaiken kaikkiaan se antaa meille laadukkaita muotoja kaikille julkisen liikenteen linjoille, joita tarvitsemme tänään, ja suurimman osan niistä, joita tarvitsemme tulevaisuudessa - jopa kehitysmaissa, joissa OSM on usein paras käytettävissä oleva tieto.

Yksi esimerkki, joka motivoi OSM-sovitusta silloinkin, kun muotoja on saatavana ja hyvälaatuisia: Montreal-Westissä toimitetut muodot eivät seuraa rataa (kuva vasemmalla), joten katutasolla se näyttää kauhealta. OSM-sovituksen (oikealla) jälkeen linjat ovat paljon tasaisempia.

3. Prosessointi pikselitilassa: Skeletonization

OSM antoi meille muodot, mutta viivoja vedettiin silti toistensa päälle. Oikeissa kauttakulkukarttoissa on viivat, jotka on piirretty samanaikaisesti. Mitä meidän piti tehdä, oli tunnistaa yhteiset segmentit, joissa ne kulkevat samalla kadulla, ja sitten "napsauttaa" nämä linjat yhteen.

Joten miten Google tekee sen? Ne näyttävät laskevan jaetut segmentit katsomalla pysäkkiä. Niin kauan kuin kahdella rivillä on samat pysäkit, ne "napsautetaan" yhteen. Mutta kun seuraavaa pysäkkiä ei jaeta, rivit puretaan:

Googlen linjat unohtavat tuntevansa toisensa heti viimeisessä pysähdyspaikassa, jossa lopetetaan yhdessä.

Mutta niin ei junat ja linja-autot oikeasti matkusta! Linjat pysyvät yhdessä jonkin verran ennen kuin ne eroavat toisistaan. Tarvitsimme algoritmin, joka löysi mistä linjat alkavat harkita tosielämässä.

Yritimme laskea reittierottelut vektoriavaruudessa, mikä näytti aluksi yksinkertaiselta: ota kaksi riviä, jotka kulkevat tiiviisti yhdessä, ja löydä sitten jaetun segmentin keskilinja. Tämä osoittautui kuitenkin yllättävän monimutkaiseksi, koska jatkoimme esiin yksinkertaisia ​​esimerkkejä, jotka rikkoisivat algoritmejamme. Pieni silmukka reitillä heittäisi keskilinjan äärettömyyteen, ja meidän piti myös käsitellä useita linjoja, useita haaraa, erilaisia ​​pysäytyskuvioita ...

Kahden kuukauden kuluttua uimasta aivomme näppäimistömme suhteen, heitimme lopulta pyyhettä. Emme vain löytäneet vakaata, yleistä ratkaisua, joka toimisi luotettavasti, kunnes ...

Pikseli tilaa pelastamiseksi!

Sen sijaan, että käsittelisimme viivoja vektoriavaruudessa, päätimme kokeilla jotain hullua. Käytimme pikselitilaa.

Pikselipohjainen käsittely tapahtuu yleensä kuvapohjaiselle tiedolle. Se on hyvin epätavallista GIS-prosessoinnissa, koska kuvan tarkkuus 1 px / metri olisi 64 teratavua. Muisti on halpaa nykyään ... mutta ei niin halpaa!

Joten miten teimme sen? Toteutimme erityisen harvan kuvakirjaston, joka pystyi käsittelemään näitä erittäin suuria monokromaattisia kuvia, joissa on suhteellisen vähän valkoisia alueita.

Sitten loimme algoritmin piirtää kuljetusmuotoja jättiläiselle mustavalkoiselle kankaalle, joka edustaa koko maailmaa, jossa jokainen pikseli vastaa yhtä neliömetriä. Jokainen viiva piirrettiin paksusti kankaalle, joten missä pisteet olivat lähellä, niiden pikselit sulautuivat yhteen.

Kun kaikki viivat oli piirretty, käytimme “luurankointi” -prosessia viivojen peräkkäiseksi ohuttamiseksi, kunnes molemmat olivat vain yhden pikselin paksuisia. Joten vaikka viivoja ei enää sulautettu, ne pysyivät yhteydessä, säilyttäen saman topologian. Nämä ohuet viivat edustavat kuljetuslinjojen kulkua yhdessä ja paljastavat verkon rakenteen.

Valkoinen edustaa piirrettyjä kuljetuslinjoja. Luuranko on päällekkäin punaisella.

Vaikka meillä oli nyt verkon keskilinjat, olimme tuhottaneet enemmän tietoa kuin olimme saaneet. Se mitä meillä oli nyt, oli joukko pikseliä, jotka osoittivat luurankoa, mikä tarkoitti, että tiesimme, että jokaisen linjan on kuljettava tätä luurankoa pitkin, mutta meidän oli silti selvitettävä, mitkä linjat kulkevat mihin.

Luurankoilla rakensimme nyt uudet linjat toisin kuin aikaisemmin käytetyillä muodoilla. Käsittelemme sitten syntynyttä verkkoa päästäksemme eroon luurankoinnin aiheuttamista häiriöistä.

Tämä askel oli pitkä ja työläs. Kaikkiaan piirtäminen, luurankointi, verkon rakentaminen ja häiriöiden poisto kesti noin kuusi kuukautta. (Niin paljon, että koko asia tehtiin kolmessa!)

Mutta lopputulokset olivat tyydyttäviä. Meillä oli sisäinen esitys linjoista, jotka kulkevat yhdessä ja eroavat toisistaan. Se näytti tältä:

Kun renderoimme linjat rinnakkain, saimme tämän:

Menestys!

Melko hyvä versiolle 1. Paljon parempi kuin Google, sillä näet, koska voit enemmän tai vähemmän kiusata missä linjat kulkevat. Olimme valmiina ottamaan käyttöön kauttakulkukarttoja! Ja sitten… Apple Maps tapahtui.

Kesällä 2015 oltuaan työskennellyt karttoissamme paremman vuoden ajan, olimme vihdoin valmiit julkaisemaan ensimmäisen version Transit Maps -sovelluksesta. Sitten Apple rullasi heidän kauttakulkukarttojaan, ja ne olivat todella kauniita.

Applen kauniit kauttakulkukartat

He nostivat heti palkin siitä, millaisten kauttakulkukarttojen tulisi näyttää. Piirustuksissamme ja päämäärissämme oli jotain samanlaista (tai parempi kuin) mitä Apple myöhemmin julkaisi, mutta suunnittelemme sinne pääsemistä julkaistuaan version 1.

Verrattuna Appleen ehdotettu versio 1 oli tavallaan keskinkertainen. Suunnittelijamme-toimitusjohtajamme päätti, että Googlen lyöminen ei ollut tarpeeksi hyvä - meidän piti myös ainakin pelata samassa liigassa kuin Apple.

Tarkemman tutkinnan jälkeen oletimme, että Apple piirtää heidän karttojaan manuaalisesti. Uusien kaupunkien julkaisemisen välillä oli valtavia viiveitä, ja karttojen ulkoasussa oli jotain outoa - ikään kuin ihmisten piirtämä, ei tietokoneiden. Tämä tarkoitti, että vaikka karttamme eivät olleet aivan yhtä kauniita, algoritmimme oli silti edessään heidän omaaan.

Tässä vaiheessa tiesimme myös, että kova osa oli takana. Olimme keksineet verkon, jonka avulla voimme vetää viivoja samanaikaisesti. Nyt meidän oli tehtävä vain näyttämään hyvältä.

4. Siirtolinjojen tilaaminen kokonaislukuinen lineaariohjelmointi

Ennen karttojen julkaisua meidän piti päästä eroon rumasta, tarpeettomasta rivien risteyksestä, joka muutti ne kauhistuttavaksi spagetti-sotkuksi.

Jos voisimme lajitella linjat minimoidaksesi visuaalisen sotkun risteyksien lähellä, meillä olisi julkaistava kartta. Tätä varten meidän oli päätettävä, mitkä linjat menevät vasemmalle ja mitkä menevät oikealle, jotta niiden risteykset voidaan minimoida.

Googlella oli (ja on edelleen) samanlainen ongelma - paitsi niiden linjat ristiin ristikkäin myös silloin, kun vain pysäkkiä ei ole eikä risteyksiä.

Voi, tule Googleen! Linjojen tulisi pysyä järjestettyinä.

Meille risteys tapahtui vain siellä, missä linjat tosiasiallisesti liittyivät ja erottuivat, joten menestyimme jo paremmin kuin Googlen algoritmi. Tämä johtuu siitä, että varastoimme jaettuja maantieteellisiä osioita.

Joten miten pääsimme eroon spagetista? Ensin kokeilimme heuristista ratkaisua - lajittelulinjoja sen perusteella, missä ne päättyvät - mutta tämä epäonnistui usein, toimien joissain paikoissa, mutta ei muissa.

Heuristisen ratkaisun parantamiseksi perustimme matemaattisen mallin, joka 'pisteyttää' tietyn viivojen järjestyksen, rankaisemalla linjojen ylitystä ja muuta visuaalista sotkua.

Useita mahdollisia leikkausskenaarioita, joissa rangaistuslähteet merkitään punaisilla ympyröillä

Kuten saatat odottaa, kartan yhdessä paikassa tapahtuvan ylityksen välttäminen voi luoda toisen jonnekin muualle. Kaikki on kytketty! Joten mitä teimme? Löysimme rivien tilauksen, joilla oli alhaisin globaali rangaistuspiste.

Kokonaisluku-lineaarinen-ohjelmointi antoi meille mahdollisuuden tutkia kaikkia mahdollisuuksia ja löytää ratkaisu, joka minimoi globaalisti rangaistustoiminnon. Mutta kokonaisluku-lineaariohjelmoinnin käsittelyaika on eksponentiaalinen ongelman koosta: yhden ongelman ratkaiseminen voi viedä yhden sekunnin; toinen vaikeampi ongelma voi viedä vuoden! Tämän vuoksi käytöstä oli riskialtista, jopa offline-esikäsittelyssä taustan sisällä.

Olimme huolissamme. Chicagon tietojen käsitteleminen kesti meiltä tunteja. Suurempi alue, kuten Koillisväylä (Bostonista Washingtoniin), voi viedä viikkoja! Onneksi löysimme toisen hyökkäyssuunnitelman: sellaisen, joka antoi kokonaisluku-lineaariohjelmoinnin ratkaisijalle mahdollisuuden tutkia ongelma-tilaa tehokkaammin ja löytää optimaaliset ratkaisut nopeammin. Mikä kesti aikaisemmin tunnin, kesti nyt 0,2 sekuntia.

Tällaisen optimoinnin näkeminen käytännössä on hankala: kun näet algoritmin tekevän päätöksiä, se on kuin todistamassa jotakin loistavaa matemaatikkoa ratkaisematta ongelmia selkeimmin ja tiiviimmin.

Ennen / jälkeen rivilajittelu

Muiden käsittelyvaiheiden ollessa jo suoritettu valmiiksi palvelimen esikäsittelyssä, tiedot tallennettiin nyt binaaritiedostoihin ja lähetettiin laitteelle karttojen todellista esittämistä varten halutulla zoomaustasolla.

5. Linjojen ympyräkaari-pyöristys

Emme silti vielä olleet aivan valmiita. Käsin piirretyt kaavamaiset kauttakulkukartat eivät vieläkään oikeastaan ​​näytä yllä esitetyiltä karttoilta. Niiden linjat ovat hienosti pyöristettyjä ja sujuvia siirtymiä risteyksissä. Halusimme karttoidemme olevan samanlainen pyöristetty.

Kun linjat kulkivat kulmien ympärille, halusimme niiden pysyvän täysin yhdensuuntaisina, jopa mahdollisesti rappeuttavissa tapauksissa, kuten Chicagossa. Siellä suuri joukko viivoja kulkee yhdessä terävien käyrien ympäri, joten niiden vetäminen samansuuntaisesti voi johtaa linjojen niputtamiseen mutkan sisäpuolelle.

Yleensä pyöristys tehdään bezier-käyrillä, jotka näyttävät siltä, ​​että ne taipuvat käyrään. Mutta pysyäkseen uskollisena kaavamaisten kauttakulkukarttojen ulkoasulle, bezier-käyrät eivät olleet aivan oikein. Kauttakulkukarttoissa on suorat linjat, jotka putoavat jyrkästi ympyräkaarisegmentteihin. Joten käyimme kaarisegmenttejä pyöristämiseen.

Lisäksi, toisin kuin bezier-käyrät, mikä tahansa ympyräkaarin suuntainen viiva on itsessään ympyräkaari. Niin kauan kuin säde on riittävän suuri, meille taattiin, ettei meillä ole rappeuttavia tapauksia.

Olemme keksineet mukautetun algoritmin, joka muotoon saakka poistaisi ja lisäisi pisteitä sen pyöristämiseksi ympyräkaarisegmenttien avulla. Se takaa tietyn minimisäteen yksinkertaistamalla geometriaa tarvittaessa. Pienin säde riippuu kaikkien rinnakkaisviivojen kokonaisleveydestä.

Tuloksena oleva muoto on sileä. Se koostuu kokonaan suoria ja kaarisegmenttejä, mikä tarkoittaa, että voimme aina piirtää viivoja samanaikaisesti ilman esineitä tai rappeuttavia tapauksia.

Tämä lähestymistapa antoi meille jotain tällaista:

Pyöristys tapahtuu vain jaetuilla segmenteillä. Saatat myös huomata, että poistimme kaikki risteykset. Risteysten käsittely oli suuri ongelma, koska meidän oli varmistettava, että jokainen rivi jatkui segmentistä toiseen ja linkittyi oikein. Käytimme myös kaarien muodostavaa algoritmia samaan pyöristettyyn ulkoasuun. Tässä on lopputulos:

Aika hienoa, eikö niin? Mutta vaikka he olivat kauniita… he näyttivät silti omituisesti alasti. Se johtuu siitä, että heiltä puuttui pysähdyspaikkoja.

Joten päätimme lykätä julkaisua vielä kerran - ja lisätä yhden viimeisen vaiheen.

6. Pysäytysten lisääminen

Pysäytysten lisääminen voi tuntua suoraviivaiselta, mutta se vaatii tosiasiallisesti kohtuullisen määrän käsittelyä pysäyttääksesi tiedot levittääksemme pitkän putkilinjan, jonka olimme luoneet.

Olemme havainneet myös monia tapauksia, joissa useat datan pysähtymiset tosiasiallisesti vastasivat yhtä fyysistä asemaa, joten meidän piti tiivistää ne yhteen kohtaan.

Tässä olemme mitä teimme. Pysähdyksiä varten, joissa on useita linjoja, piirrimme valkoisen palkin, jossa on musta ääriviiva (kontrastina) kaikkien linjojen yli. Pysähdyksiä varten yhdellä rivillä piirrimme yksinkertaisen ympyrän käyttäen kyseisen kuljetuslinjan väriä. Lisäsimme myös valkoisen peittokuvan vähentääksesi alla olevan karttakerroksen kontrastia. Tämä on lopputulos:

Jotta käyttäjät voisivat kytkeä linjat päälle ja pois päältä valikoivasti sovelluksemme asetussivulta, päätimme, että pyöristäminen, samoin kuin jotkut pysäytyskäsittelyt ja renderoinnit olisi tehtävä laitteella. Joten New York Cityssä voit poistaa kaikki New Jersey -pohjaiset kauttakulkulinjat (tai kaikki NYC-linjat, jos asut New Jerseyssä). Koska tietyillä alueilla on niin paljon kuljetuslinjoja, käyttäjät voivat luoda täysin räätälöityjä karttoja.

Huomaa, kuinka linjat tulevat uudelleen sen perusteella, mikä linja on aktiivinen, ja kuinka pysäytysvaihe muuttaa väriä.

johtopäätös

Joten näin me teimme sen. Varmasti, että automaattisesti luotujen kauttakulkukarttojen toteuttaminen vaati paljon työtä, mutta se oli sen arvoista. Karttamme ovat helvetin paljon tehokkaampia kuin PDF-tiedostot, jotka olet tottunut hankkimaan virastoilta. Älä koskaan unohda taitetut paperit ja juuttuneet lompakkoosi. Mitkä ovat tärkeimmät erot?

Kuljetuskartat ovat skaalattavia, joten voimme helposti lisätä uusia kaupunkeja samassa visuaalisessa tyylissä, minne tahansa päin maailmaa laajennamme seuraavaan. Ne ovat muokattavissa, joten käyttäjät voivat ottaa verkot ja tilat päälle / pois päältä luodakseen omat henkilökohtaiset kuljetuskarttansa. Ja ne ovat myös asiayhteydessä: toisin kuin edustajakartan PDF-tiedostossa, karttamme sisältävät sijaintisi, mikä antaa sinulle käsityksen siitä, missä olet suhteessa lähellä oleviin linjoihin, ja säädä ulkonäköä zoomaustason mukaan.

Ja viime kädessä kaavamaiset kauttakulkukartat tarjoavat enemmän kuin vain perustiedot kauttakulkujärjestelmistä. He ovat symbolit itse kaupungeista: tärkeitä funktionaalisia taiteita, jotka yhdistävät ihmiset ympäristöönsä. Haluamme auttaa luomaan kyseistä yhteyttä ja uskomme, että uudet kauttakulkukarttamme tekevät juuri sen.

Olemme innoissamme jatkuvasta paranemisesta, mutta olemme tyytyväisiä siihen, mitä olemme tähän mennessä saavuttaneet. Aloitimme 55 kaupungin kanssa. Vastaus blogikirjoitukseemme, jossa verrattiin karttojamme Googlen ja Applen kanssa, on ollut uskomattoman positiivinen. Taustatiimille on hienoa, että ihmiset näkevät ja arvostavat työtä ja vaivaa, jonka olemme panostaneet sovelluksen kokemuksen lisäämiseen. Se motivoi meitä jatkamaan tekniikkamme eteenpäin viemistä.

Tämän lisäksi meillä on vielä paljon ”vaikeita” ratkaistavia ongelmia. Jatkamme työskentelyä konepellin alla, ei vain siihen, että meillä olisi kaunein sovellus, jolla on paras käyttöliittymä, mutta kaikkein toiminnallisimpaan, tehokkaimpaan ja tarkkaan kuljetussovellukseen.

Haluatko pelata karttamme kanssa?
Voit saada Transitin ilmaiseksi App Storesta ja Google Playsta. Tai oppia lisää yrityksestä verkkosivuillamme.

Tuntuisitko vastaamasta tämän tyyppisiin haasteisiin elämiseen? Palkaamme!