To-do list for RoadMap

January 2009

This is a list of changes envisioned for future versions of RoadMap. 
Please feel free to contact the author(s) for more ideas.  Please
feel especially free to contact the author(s) with patches.  ;-)

 - Better OpenStreetMap support
   
   RoadMap began as a rendering engine for the US Census bureau Tiger maps,
   but it has now grown the ability to render OpenStreetMap data.  This
   OSM support deserves to be fleshed out in many ways.

 - New Tiger map format

   The census bureau has released data in its new shapefile format,
   which replaces the previous TIGER format.  We could begin
   implementing a new converter for that shapefile spec, or we could
   ignore further TIGER updates, and concentrate on OSM, since OSM now
   incorporates the TIGER maps.  If editing changes from the RoadMap
   editor branch could be incorporated, RoadMap could in theory even
   help contribute new OSM data.

 - Use checkbox widget in the menus and toolbars:

   Some menu and toolbar entries are of the "start & stop" kind.  Instead
   of having 2 entries it would be nice to use a single checkbox one. 
   Other entries are already toggles, but their state can't be determined
   visually.  In any case, RoadMap should be consistent (or at least clear)
   about whether or not the change will affect startup preferences.

 - More message formats, and message data -- users have requested
   that more types of data be available on-screen:
   
     - speed should be available all the time, not just when a
       route is active
     - course (bearing), altitude
     - elapsed, and projected "trip time".  moving time, idle
       (stopped) time.
     - distance traveled since program start
     - distance since route start
     - perhaps a shell escape, for getting data from external
       programs?
     -
   
   In addition message signs that are too long should wrap, rather than
   truncate.

   Much of this information could be put into a canned trip statistics
   screen, so it could all be made visible at once.  (Could such a screen
   be constructed from the roadmap_display() basics?  Would need to
   be able to create better-formatted output -- newlines, columns, etc.)

 - Add voice output for trip navigation.

   The flite voice should read the routepoint comments that currently
   appear on the screen.  Need to make the timing of the comments
   speed-sensitive, and figure out what to do with routepoints that don't
   have attached comments.  Probably if some routepoints do have comments,
   then we should ignore those that don't, otherwise we should give
   a directional indication since there are no "real" directions.

 - Key bindings should be rebindable by the user.
   
   This would make the UI fully customizable.  Some support for this
   appears in the roadmap_editor branch, but it's not complete.

 - Show GPS location
   
   There should be a way to easily display the current location.

 - Use GPS time and map's timezone
   
   The GPS receiver provides a reliable universal time as well as the
   current location.  This is all what RoadMap needs to show the correct
   local time.  (On the other hand, the user of the maps may not care about
   the time in the place being examined.  Picture a desktop user, at home. 
   In that case, all times should perhaps be local.)
   
     - Associate a timezone to each county.
     - 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:  this would cause a whole mess when replaying GPS
   logs, RoadMap would need to be root or have the set UID bit set and
   managing system setup is best left to system daemons.  In addition, gpsd
   is now synchronizing the system time, so don't mess with that subject..

 - Internationalization

   RoadMap has some initial i18n code.  It's not based on gettext().
   Before going further, we should revisit that decision, just in case
   we want to do it differently.  But in any case, we should make the
   entire program translatable, and add more languages.

 - Modular map format
   
   RoadMap map format is such today that all the information must be
   contained in a single file.  RoadMap should be able to display, and use,
   data from multiple county files.  The benefits are that one can come
   with his own additional information (such as railroad tracks) without
   modifying the existing maps or making them larger.  In addition the
   current set of maps could be cut in two (separating the street shapes
   from the street names) to lower the amount of data mapped by RoadMap
   when displaying the map on the screen (especially when zoomed out). 
   Essentially, layers could be assigned to each of the split-up county
   files.

 - Modular map rendering
   
   The RoadMap map rendering code should be made more modular so that a new
   type of data can be defined, associated with a plugin to implement the
   rendering code.

 - Track more than one GPS source
   
   RoadMap should allow the user to track alternate GPS sources as defined
   by the user (like GpsDrive's friendsd).

 - Navigation
   
   While the TIGER data doesn't have the necessary data to make navigation
   with RoadMap feasible currently, other datasets do, and the
   roadmap_editor branch has proven that it can be done.  OpenStreetMap is
   starting to work with TIGER maps, and perhaps that work can be used as a
   shared resource for adding the necessary meta-data.

   A precursor to this work would be to make the roadmap plugin API
   match the roadmap_editor plugin API (again).  (Some progress has
   been made on this.)

 - Places
   
   Work was begun to add "places" support (i.e.  landmark) names to the
   RoadMap database.  This should be finished.

 - Interface with address book applications
   
   RoadMap should be able to interface with address book databases to get
   street addresses from there.  Instead of specifying a destination
   address, one would provide the name of a person.

 - Cross-platform widgets
   
   While the current home-grown widgets work pretty well, it's probably
   time to implement a version of the RoadMap API in something like
   WxWidgets.  If this were successful, and the extra cost of such a widget
   set weren't too great, then over time we could switch to it exclusively.

 - Speed-sensitive zoom

   While moving, there should be a mode where the zoom and 3D
   horizon value are adjusted dynamically, to give longer range at
   higher speeds.


