This is a (definitely incomplete) list of features/improvements for gpsdrive.
This file helps us keep track of what can be done and who is interested in doing it.
Everyone is invited to catch one of the tasks and start development.

Currently Worked on for Release gpsdrive-2.10pre5:
--------------------------------------------------
- Vektor Maps with Mapnik and Data from OSM
   - Integration of lib-mapnik (loom)
   - Creating osm-data-mapnik debian Package (tweety)
   - remove QT-Dependency
- POI Management (d.s.e)
   - gpx import
- Cleaning Up the debian package Content; merge with DebianGIS's version
    at http://svn.debian.org/wsvn/pkg-grass/packages/gpsdrive/trunk/debian/


Ideas for gpsdrive improvement: (unassigned, unrated)
-----------------------------------------------------
- Documentation:
    - writing lots of useful comments to the existing code.
	- Writing/improving man Pages
	- Translate man Pages
	- Translate in Programm Text (translate in the po/*.po Files)
    - writing and correcting text for the FAQ/man pages
    - Better "hacking" documentation (e.g. documentation describing how to generate
      a "GpsDrive-compliant" raster map from outside of GpsDrive, clear
      documentation on the size and shape of custom icons, etc.).
    - Help translate the gettext strings (po-Files) in to your native language

- Makefiles/Distribution:
	- include generation of icon Directory while installing gpsdrive
	- update the distribution dependant Files (debian, suse, ...)

- Modularising:
	- Put every drawing layer into a seperate sourcefile.
	- moving configuration Data into a structure (already started)
	- moving actual settings into another structure (already started)
	- move more stuff from gpsdrive.c into meaningful standalone Files
		examples:
		- poi.{c,h}
		- gps_handling.{c.h}
		- icons.{c.h}

- Autosave Tracks periodically
	- started: savetrack was seperated and got 
	  option to save only actual Track an not track_ALL.sav

- Finding and correcting Bugs in the existing Code.
   Bug/wish tracker: http://sourceforge.net/tracker/?group_id=148048

- make the code more error resistant

- Changing User Interface:
	- move to setup menu:
		save Track
	- rewrite the UI using glade-2 (see above)
	- Keyboard shortcuts for all menu items

- Point and measure Mode: Show the lat/lon of a point you clicked on. 
  Click an another point and then show the distance and bearing
  between those two points. Or update continuously from the mouse
  position and display lat/lon+range/bearing in lower status bar.

- write routines to import gps Tracks (GPX) into the Database. The difficulty
  here is to classify the Data and find corresponding tracks and merge 
  them together (use gpsbabel filters?). Also to find gaps in the tracks and
  split them at this point (<trk> and <trkseg> in GPX).

- make gpsdrive compile inside eclipse.
  should work

- refactor the variable names inside gpsdrive.

- write an interface to use functions like gpsbabel gpstrans from inside
  gpsdrive. note gpstrans is abandonware these days, better to use
  "gardump" program for Garmin wpt/trk/rte up/download? Actually gpsbabel
  does those functions these days.

- Move part of the user interface to a Pulldown menu.

- Track writing: User option to automatically cull points which are
  closer than 1-5m (eg when you are stopped for a few minutes).
  Gpsbabel has some filters for this stuff.

- add an Mode for Displaying position under the cursor and measure distances
  Do as a tooltip or in a status bar?

- add support for moving the map with the cursor keys if in POS-Mode
  Add support for middle-click to recenter image, or middle-drag to pan.

- Correct/complete/add-new translations in the po Files

- Store poi-type-specific information in a separate poi_extra table
  (e.g. macaddr, wep, etc. for wlan entries; classification, features, pricing,
  rooms, etc. for hotels, etc.).
  GpsDrive would only need to access the basic data in the core poi table for
  search and display of pois, but when a poi is clicked, the additional data
  can be displayed formatted in a (pop-up) window.
  Also external programs could make use of the extra data.

- Devise a "standard" set of tables for OpenGIS data (lines, polygons, etc) 
  which can be drawn atop the existing raster maps if desired (or used to
  populate a "blank" raster map.)  Someone could work up an import routine
  from the US Census Bureau "TIGER/Line[1]" data, import from Shapefiles, etc.
  [1] http://www.census.gov/geo/www/tiger/tiger2003/tgr2003.html  There's
	  actually supposed to be a new release of this data sometime this month as
 	  well.  I personally have a sloppily-done but functional script that generates
	  GPSDrive raster maps by rendering TIGER/Line "Type 1" (roads) data atop
	  the satellite photo data at various scales.  I'll share it with anyone
	  that wants it, if they promise not to laugh in my face at my really slovenly
	  code.
  Don't reinvent the wheel here, use a simple ascii format* or better yet
  use GDAL's OGR to read/write simple features.
   [*] see GRASS GIS's standard ascii vector format from v.in.ascii man page.

  [2] http://geonames.usgs.gov/geonames/stategaz/index.html  I have a script 
	  to import these into GPSDrive's waypoint table (as modified by myself - see
	  the suggestion about added fields...), and a start on custom waypoint icons
	  for a few of the types.  Eventually I hope to have waypoint icons for all of
	  them.  I'll share these if anyone wants them, too.  Note that the GNIS also
	  has a link to "Foreign" (relative to the U.S.) names: I haven't looked too
	  deeply into these yet, but the files do have a different structure than the
	  GNIS datafiles last time I looked.  However, they should be pretty easy to
	  reconcile with the GNIS waypoint types and write an import script for.  That's
	  on my "to do" list sometime soon, and would give non-U.S. people a possibly
	  useful source for some geographic waypoints.

- HOWEVER...split map fetching out into external programs.  Even simply having
  a field in the configuration to supply program names which get run (with 
  environment variables for lat, lon, altitude, etc. set appropriately by
  GPSDrive when it calls them.)  Anyone with the time, talent, and inclination
  to do so can then easily contribute independent "fetch a map" programs for
  various purposes, in whatever programming language they prefer, without
  needing to mess with the core of GPSDrive itself.  No doubt some horrible, 
  horrible person would make an expedia download program to replace the 
  "built-in" function and thus allow people to commit the terrible sin of 
  robbing Bill Gates of an uncountably-small fraction of a penny of profit by
  downloading maps without permission once again, but what can you do? :-)

- ADD SUPPORT FOR UTM PROJECTION MAPS!  Possibly remove the "street" and "topo"
  distinctions and instead have selections for UTM, ORTHO(?), and LATLON,
  perhaps?
  I've been trying for some time now to find out what projection the
  Expedia(tm) maps are in, so that I can use gdalwarp to convert UTM maps
  that will work correctly as "street"-type maps, but nobody seems to know.
  Best guess I've heard so far is that they are an "Orthographic" projection.
  FWIW, Google Maps uses a spherical mercator.
  Better yet would be to outsource the problem to the PROJ.4 software, then
  you are not just limited to using lat/lon and UTM.

- Improve Kismet connection robustness.  GpsDrive still locks up for me
  if Kismet dies while GpsDrive is connected to it.  Even better, add a
  "check for Kismet" button and allow GpsDrive to connect to Kismet
  AFTER being started - or to re-connect if Kismet gets stopped and restarted.

- A function to overlay raster data atop the existing displayed map - for 
  example if I find a way to fetch weather radar data while driving around, 
  maybe I could have GpsDrive draw the weather activity atop the current
  map, so I can tell if I'm going to outrun the storm...
  Data often comes in "grib" format.

- Implement direct GPX support
  - replace way.txt by way.gpx (or remove this file completely)
  - support import of POIs/Waypoints in gpx format

-----------------------------------------------------------------------------
D.S.E <d.s.e@sordidmusic.com>

my personal TODO-List (for after the pre4 release) :-)

- make POIs editable
- make displayed map draggable with mouse
- cleanup units handling; only metric units should be used internally

-----------------------------------------------------------------------------
Koji <koji@e-mail.jp>

- making 2.10pre2's ja.po. 

- Tokyo maps:
  This URL contain the position (deg/mm/ss), map scale(1/7000) and 
  map size(1280x1024). And a lot of scales can be obtained.
  This is very convenient for me. :-) Only one probrem is not WGS84 position,
  this positioning is named "Tokyo". So I need excange the position. :-(

  http://www.mapion.co.jp/c/f?el=139/36/45.600&scl=70000&size=1280,1024&uc=1&grp=MapionBB&nl=35/31/36.300

-----------------------------------------------------------------------------

Old (has to be checked):
------------------------

Command line switch to set gpsd hostname and port for remote control.
   -complete?  "-B, --gpsd-server=<SERVER>"

Add load of trackings (i.e. stored in the GPS and converted with a nice
 perl script anyone will write).
 -See gpsbabel/gardump import above.

Servermode to display different positions provided over Internet
server.
 -use gpsd's gpsfake?

render maps in greyscale
 -why? nightmode? OLPC high-contrast screen?
