October 2007
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. ;-)
RoadMap began as a rendering engine for the US Census bureau Tiger maps, but it's clear that it can be more useful than that. There is now shapefile support, and other early work has been done for postgis and shpmp support, but the RoadMap database itself is still strongly US-centric -- all of the maps (even for the rest of the world) must be given fake US county identifiers. Work has been done to outline the problem, but no work has been done to implement a solution as yet.
The census bureau has published its spec for the new shapefile format which will replace the existing tiger format in the future. When a sample map becomes available, we should begin implementing a new converter for that shapefile spec. This would also be a good time to address other current issues, such as the polygon shape point issue, placenames, perhaps others.
Currently, the only font capable of appearing in different sizes on the screen at once is the primitive internal "linefont". Some work has been done to add better font control for QT, but nothing has been done for the other desktop toolkits.
The error messages are logged on the standard output, and to individual dialog boxes. Standard output isn't very useful in a GUI app, and the dialog boxes can multiply much too fast with recurring errors. Some sort of an "error log" window would be a good compromise. (One issue is fonts: should be big enough to be readable in a car.)
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.
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.)
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.
This would make the UI fully customizable. Some support for this appears in the roadmap_editor branch, but it's not complete.
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.
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.)
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..
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.
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.
RoadMap should allow the user to track alternate GPS sources as defined by the user (like GpsDrive's friendsd).
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).
Work was begun to add "places" support (i.e. landmark) names to the RoadMap database. This should be finished.
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.
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.
While moving, there should be a mode where the zoom and 3D horizon value are adjusted dynamically, to give longer range at higher speeds.