Skip to content

Planner.js Roadmap

Jump to bottom
Harm Delva edited this page Aug 5, 2019 · 9 revisions

1. Profile CSA implementation with unrestricted walking

We have an implementation of earliest arrival CSA that uses published precomputed footpaths as described in http://hdelva.be/articles/decentralized-footpaths/ to achieve unrestricted walking. The profile algorithm needs to be updated to properly use these footpaths as well. The main difference is that two stops are no longer necessarily directly connected - but footpaths can be chained together to estimate the walking distance between any pair of stops. This chaining together part is what's still missing from the CSA profile implementation.

1.1 Find pareto criteria

The paper only consider travel time and legs in a journey, but we can probably do more. I think Google Maps for example considers walking time and travel times. Perhaps we could also think about connection frequencies, connection reliability, ...

2. Dynamically download routable tiles

The current implementation download all the tiles in the bounding box that spans the begin and end location. This can lead to suboptimal results. Brussels-Ypres for example are roughly on the same latitude, so that a thin long strip of tiles is downloaded. This strip does not contain the area around Ghent, which is (probably) the fastest route.

We should download additional tiles each time the pathfinding algorithm has reached a tile's boundary node. Related to this:

  • We should try implementing a bidirectional Dijkstra so that we download less tiles.
  • Don't download the entire tile unless we have to. We should be able to plug in the results from our State of the Map contribution here.

3. Improve architecture

Some things we want to achieve:

  • Better handling of profiles. How does a component know which profile to use? How does switching of profiles work?
  • How do we export more kinds of route planners? Let's say we want to add a one-to-many planner on the road network, how do we expose it?
  • Generalized interface for prefetching, possibly based on location data.
  • Inject a pareto criterion function?
  • Create an event channel module, let Planner and any other module push its events there.

Things to do:

  • Create a schematic overview of all the components and how they interact.
  • Figure out why the AsyncIterators misbehave until we wait for them.
  • Identify a component that can do the orchestration of the other components.
    • Perhaps this can create an immutable Context object that other components can read.
    • Somehow adjust the CSA implementations to use this component for the transfers.
  • Give each entity one purpose and replace all data-only interfaces with actual classes. Move all domain-logic in there.
  • No cyclic dependencies, get as close to a layer design as possible. Make sure each individual dependency makes sense. Passing weird arguments because some other dependency 4 layers down needs it is an indication of bad control flow.

As a side effect of all this, we should also have a good amount of documentation for internal development! This should be almost enough for people familiar with the project to know how the code base is organized.

4. Give directions

Just returning a list of nodes to walk from/to isn't very user friendly, we should improve the output format so that we have turn-by-turn directions.

4.1 Fill in the footpaths

5. Documentation

If we want the data sets and the planner.js project to get used, we'll need to make things as accessible as possible.

  • Add meaningful comments to the code base where needed.
  • We'll need to explain what advantages linked data fragments have over existing APIs they know and love.
    • Scalability and a level playing field for service providers, flexibility and anonymity for the users
  • We should also give some examples of what it can do.
  • We should create a 'cook book' with examples of how to build upon the existing functionality.
    • Running them through the steps of adding an extra public transport service
    • How to add a different kind of road planner
    • How to create their own derived data and use the results
    • ...
  • We should give a high-level description of the code base. Which services interact with which services, which libraries we use, ...
  • Publishing the function signatures and all the rest is arguably the least important. Once people get to this stage they can easily look at the code itself.

6. Turn restrictions

Very important for obvious reasons, but not trivial to implement. The standard approaches require too much memory, so we'll need to get creative.

7. Make the bundle smaller

It is over 460 kb right now, we need to do better. https://timkadlec.com/remembers/2019-01-09-the-ethics-of-performance/

8. (Reverse) Geocoding

Being able to route between coordinates is interesting of course, but nobody will use our product if users can't query from address to address. Preferably we should also include points of interest as well, so that people can query routes to specific restaurants, office buildings, ...

9. Become truly multi-modal

We should try to avoid all hard-coded restrictions on which modes of transportation are combined. We already have vehicle profiles, we should add user profiles that describe when the user has access to that vehicle. Some examples of routes we should aim to support:

  • Walk from your current location to a station; Take the train to another station; Ride your bike home
  • Drive your car to this parking; Take public transportation to the city center
  • Take your train to a station; Use a bike sharing service to get from the station to your destination

We may need to predict the availability of some resources to achieve this (parking space, available bikes, ...).

10. Find an efficient way to read Linked Open Data

The default JSON-LD parser was way too slow to actually use, so we're just interpreting it as JSON now. This means there are too many string constants in the code now, which might backfire at some point. We should look into either other JSON-LD librariers (the streaming parser) or different formats (turtle maybe).

11. More data

We could add more defining features to planner.js if we add more datasets. Things that come to mind: air quality, elevation, road safety and points of interest.

12. Branch out

Quoting Bernstein and Noy:

The real test in such work is convincing our peers from other communities (not semwebbers) that we have indeed made a contributions. Researchers outside of the semantic web community will not really care whether or not we used a particular technology. But can we publish our paper in a conference outside of our field that deals with the problem area. For instance, can we publish our improvements to the movie recommendations in the ACM RecSys conference? Will researchers in that field care? If we improved the performance, they sure will!

Some things that come to mind:

  • Geography: Mobility scores are a hot topic right now. People complained that opaque one-size-fits-all metrics such as https://mobiscore.omgeving.vlaanderen.be/ lacked nuance. We can probably do better by letting people define what's important to them. Proximity to highways is irrelevant to people who intend to cycle everywhere. We could give this a real estate or job portal spin as well; I live/work at X, so is Y a good place to work/place if I want to take public transportation?
    • This was a hot research topic a few years ago as well. We could reach out to http://www.idm.ugent.be/ and see what they think.
    • Government services that do public planning might also be interested, could we help them find areas that are hard to read by some people?
  • Tourism: Even with the perfect planner.js implementation, we probably won't match their quality of service because of all the data the likes of Google are sitting on. But there's still an untapped market of lost tourists. It would be really cool if we could create route planners that can answer things like "which museums are within 20 minutes of this place"; basically helping tourists plan their itineraries.
    • The Italian government is publishing data about their cultural heritage as linked data (http://wit.istc.cnr.it/arco/index.php?lang=en), which might be interesting for us.
    • Find a points of interest dataset. Do we at Ghent University or elsewhere in imec have a digital humanities department that could use planner.js to disseminate their work?
  • Make it accessible: We shouldn't just target developers. Lots of non-technical people seem interested in what it can do, so we should indulge them.

Clone this wiki locally