RoadMap: Todo List

This page lists the changes planned for the future versions of RoadMap. Please feel free to contact the author for more ideas.

When the developments on RoadMap 1.0 are complete, a 1.1 development branch will be started, with the highest priority given to some needed changes to the map format. The criteria for starting the 1.1 branch is actually the compatibility with the existing maps: RoadMap will stay at the 1.0 level as long as the format of the maps has not changed.

This means there will be no map provided for the 1.1 branch, considering their unstable nature. The 1.0 branch will be maintained as the "stable" branch. Some of the changes above may still find their way in the stable branch, as long as the map compatibility is maintained. It may take some time before the development branch appears on the web site.

When the 1.1 code will stabilize, a new 1.2 stable branch will be created and a 1.3 development branch will be started anew, and so on.

(The changes believed to break compatibility with RoadMap 1.0 are marked with a "[1.1]" sign.)

Here is the detail description of the changes planned so far:

• Error messages on screen. The error messages are logged on the standard output. This is bad when RoadMap is started from a menu, since there is no way the user could read the message. Errors should be shown on the screen. It would be nice to have a log window for all messages, error or not. One issue is fonts: should be big enough to be readable in a car.
• 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.
• Show GPS location and speed. The speed shows on RoadMap, but not on RoadGps. The location shows on none. There should be a way to show the location, at least in RoadGps.
• Show when the GPS source is not available. RoadMap gives no feedback regarding its connection to the GPS source. The feedback should be somewhat graphical (an icon?) and not a dialog (in a car?).
• Show the waypoints names on the screen (next to the waypoint). This would be controlled by an on/off button and key (Z?).
• Show the X and Y scales of the map in a way that does not obscure the map.
• More natural street naming. RoadMap requires the street names to be entered using the US Census Bureau's own conventions (ST for streets, AVE for avenues and so on..). It would be more friendly to authorize some alternate conventions (such as AV for avenues), or even plain words. The idea would be to let the user set a list of aliases for each USCB acronym. These aliases would be stored in a text file loaded either from the user's environment, or else from the shared one.
• [1.1] 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:
  • 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..
• [1.1] 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).
• [1.1] 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).
• 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.