RoadMap - a street navigation system using the US Census maps and GPS
---------------------------------------------------------------------

                              T O   D O


Accurate local time

   The GPS receiver provides a reliable universal time and the current
   location. This is all what RoadMap needs to show the correct local time:
   
   - associate a timezone to each state (problem: a few states have county
   dependent timezones--we may have to add the timezone field to counties).
   
   - when showing a particular location on the map, display the local time
   for this location.
   
   - show estimated time of arrival in the destination's timezone.
   
   One might think of setting the UNIX time and system timezone, but that
   would be a bad idea:
   1- this would cause a whole mess when replaying GPS logs.
   2- RoadMap would need to be root or have the set UID bit set.
   3- managing system setup is best left to system daemons.
   
Multiple tracking

   As of today, RoadMap can track one GPS source.

   RoadMap should allow the user to track alternate GPS sources as defined by
   the user (like GpsDrive's friendsd ?).
   
Submaps & Plugins

   The RoadMap format is flexible (additional tables could be added), except
   for that fact that it is monolythic: one single file per county, no plugins
   to handle additional tables that not originally planned in RoadMap.

   The result is that one must decide what is visible when generating the
   1.7 Gbyte map set. Any change means regenerating the whole thing. This
   is not friendly..

   In addition, when zooming out to display several states, the RoadMap
   performances go down in a linear fashion, until the Linux disk cache
   is saturated. Then the performances are disk-bound (and dismal..).

   The goal is to remove any hardcoded knowledge of line categories (street,
   freeway, shore, river, lake, etc..), to make the code able to gather lines
   from various extension map files and to allow the creation of plugins to
   handle new kind of map tables.

   This would also allow the physical isolation of features according to
   their declutter level (for example one extension file type for freeways
   and borders--load all the US freeway without taking too much space or
   even saturating the disk cache).

   Plugins should be flexible enough to allow for the gathering of data
   from other sources (database, web servers, etc..). This would allow for
   the mix of permanent features (roads, rivers, lakes, etc..) and dynamic
   information (traffic jams ? :-).

Address book:

   Add an interface with a plugin program to gather addresses from an existing
   address database. Make it a separate plugin to allow for the support of
   different database formats (selectable as a preference).

   The address database planned for support in the future is the one from
   the GPE project.

Routing:

   Make a plugin program to compute a route from the current location to the
   selected destination. make it a separate plugin to (1) keep the UI active
   while the route is selected, (2) not loose everything if the route program
   crashes or loop forever, and (3) allow people to implement their own
   (I guess there will be a lot of arbitrary choices to be made there).

   The main issue with any routing logic is that the US Census Bureau's data
   does not provide any one-way information. Considering the risk of taking
   the wrong way, any routing based on the US Census Bureau TIGER files has
   been postponed.
