Space Time Alarm ClockMaster Thesis Proposal

Student: Adrian C. PrelipceanSupervisor: Takeshi ShirabeCo-supervisor: Falko Schmid

AG242X GeoinformaticsKTH Royal Institute of Technology

School of Architecture and Built Environment Department of Geoinformatics

Outline

The presentation’s agenda consists of:1. Introduction2. Statement of the problem3. Motivation4. Methodology5. Time schedule6. Acknowledgments

Introduction

Do we still use alarm clocks?

Introduction

Do we still use alarm clocks?Of course we do!

Introduction

Why do we still use alarm clocks?1. To perform activities without worrying about the

time2. To get a sense (control) of time3. To synchronize our schedule with that of others4. As a reminder5. To wake up :-)

The problem

Current problems with alarm clocks:1. An event, E, is characterized by its time of

occurrence, t2. When events imply traveling to other locations,

people usually: a. approximate the travel time which results in under-

or overestimationb. use other devices to get there which may imply

further difficulties (e.g., cost, privacy issues, etc.)

Motivation

There are several opportunities:1. Almost everybody uses a type of alarm clock2. Provide a smarter alternative to using multiple

devices3. When scheduling an alarm for an event, the

temporal aspect should be accompanied by the spatial one

4. New alternatives to classical step-by-step navigation

Methodology

User Interaction: ● Get user input (arrival time, destination) ● Communicate useful information to the user

Network Analysis: ● The network subset that can be reached by the

user in a given time frame

Methodology

Navigation: ● Aid the user in reaching an unknown destination● Aid the user in exploring her options

Map-matching variation:● What is the current location inside the network

Methodology

Architecture and integration: ● Provide the needed functionality while integrating it

in the OpenScienceMap context ● Make the implementation available to the (scientific)

community by open-sourcing it● Provide the needed functionality in a context and

implementation agnostic environment

Time schedule

Estimated time for most important operations: - familiarize with the OpenScienceMap environment (3 weeks) - literature review of relevant papers (3 weeks)- prototype implementation and tests (4 weeks) - fixing reported bugs (1 week)- writing the thesis (4 weeks)- thesis revisions (2 weeks)

Acknowledgments

Institutions:1. KTH Royal Institute of Technology

○ Department of GeoinformaticsContact: Takeshi Shirabe <shirabe@kth.se>

2. Universität Bremen○ Cognitive Systems (CoSy)○ Open Science Map (OSciM)Contact: Falko Schmid <schmid@informatik.uni-bremen.de>

Q&AAdrian C. Prelipcean <acpr@kth.se>