[Roadster] Status & Roadmap

[Jeff Garrett]

Hello to All!

I now have CVS access for Roadster.  Well, actually, I got it the week
before Labor Day, but I went away for a bit.  OK, so here's my question:
what do *you* want from Roadster?  What would *you* use it for?

* * *

Before I start describing my personal wishlist, I'll give a bit of a
status update.  Now that I have CVS commit access, I've gone ahead and
committed the following patches to Roadster CVS:

- Remove the MySQL embedded server (#12135)
  It doesn't exist in MySQL 5.0.  This does mean you will have to run
  your own MySQL server, or have access to one.  Minimal configuration
  support is added for the DB connection parameters.
- Replace memchunks with the slice allocator (#12136)
  Memchunks are deprecated in GLib, so this allows compilation without
  passing --enable-deprecated.  It should also have a speed boost,
  but this is not verified.
- Cities are TIGER places, not primary county subdivisions (#12137)
  At least in the most recent TIGER files, some large counties have
  primary subdivisions much larger than cities.  For example, Dallas
  Co, TX has 4 primary subdivisions with names such as
  "Southwest" [Dallas Co] each consisting of multiple cities.  It
  turns out that the cities are only listed correctly as places and
  as economic places, so we instead use places.
- TIGER/Line files are checked for wrong case (#12134)
  The most recent TIGER files are named in uppercase, and the import
  specifically checked for names in lowercase.  Now it checks for
  the right case.
- About box doesn't point to the wiki (#12173)
  It pointed to an old website.
- Bugfix for Mac OS/X compilation
  http://lists.freedesktop.org/archives/roadster/2006-February/000136.html
  Using __unused for parameter names is bad because it's reserved.  On
  OS/X this is defined in a system header, and results in the
  preprocessor basically removing our parameter name.

This should make it easier to get your feet wet.  You can simply do:
  export CVSROOT=:pserver:anoncvs at cvs.cairographics.org:/cvs/cairo
  cvs login ; cvs -z3 co roadster
  cd roadster
  ./autogen.sh ; make ; make install

Now roadster uses MySQL, so you have to configure connection parameters
(#12321).  Keep in mind that these are only used for the actual
connection.  After roadster is connected to the MySQL server, it
attempts to create a database called 'roadster' if it doesn't exist and
uses that one.  That is, the 'database' connection parameter is used
only for connecting to the server, not using that database (#12320).

To specify the connection parameters (#12322), create the directory
~/.roadster and edit the file ~/.roadster/roadster.conf.  Put in it
(substitute your actual values):
  [mysql]
  host = $host
  user = $user
  password = $password
  database = $database

If you skip this step, or if you don't specify all of the parameters,
roadster will use the defaults (local host, local user, no password, no
database name).

Now you'll need to import mapping data.  To do that you'll need to find
out your county FIPS code, and download a file from the Census Bureau
website (#12319).  The roadster wiki has links to a list of FIPS codes
as well as to the CB website.  You can start roadster, go to Debug >
Import Map Data... and select the ZIP file from the Census Bureau.

Now you are ready to begin!  Go to the search box in the upper right,
put in a street name, and press enter (#12323).

* * *

OK, so everybody please go try it out!  I've updated the wiki's
instructions to reflect the patches as well.

I haven't managed to update the wiki by git yet, and I'm not sure how to
upload screenshots otherwise, so that will have to wait (#12324).  Also,
I don't yet know about where I can put a git repository.  Personally,
I'd much rather use git (#12325).

There are definitely a few other things that I will add to the wiki when
I get time (#12326, #12327, #12328, #12329, #12330, #12333).

* * *

But enough of that.  What do *you* want roadster to do?

There are plenty of ideas on the mailing list archive, and on the
wayback archive of the old wiki, and I have my own ideas.  But what do
the people who are still around think?  What would you do with roadster?

Here's what I think.  First of all, I would rather give preference to
developing features at the moment, and to developing something of a user
base.  There are a number of non-user-facing changes that need to be
made, but they can be made in the background, and along the way.

For my own personal use, it would be something like an offline google
maps ('pizza near here').  The POI support and POI sharing would
therefore be a priority.  Of course it could be better than even an
online google maps since I have some discretion in whose POI sets I
import.

That said, I can still see a lot of things to do.  Here's something of a
list:

- POI support & sharing
  Well, for starters, the location edit window doesn't work (#12334).
  Not sure what else needs to be done as far as the basic POI support.

  Regarding sharing, there were various methods mentioned previously,
  but one I didn't see was XMPP pubsub (#12335).  This seems to me
  ideally suited.  Subscribe to your friend's pubsub feed for good
  restaurants...  Obviously locations also need to be exported in some
  sort of file format, probably something like GML (#12336).

  With the flat file, one should be able to email or IM a POI or POI
  set (#12350).  Note that one also should be able to share POIs
  with upstream so that other users can benefit (#12351).  Maybe
  XMPP is best for this.

- Work on rendering
  There are a few things that can be done here.  To start with the
  basics, stable label positioning would be nice (#12337).  Then you
  can drag with labels enabled and they won't fly all over the
  place.  :)

  Also there are labels that end up curving in on themselves --
  making it very hard to read (#12338).

  Also in the default style, the road labels look too 'big' at
  certain zoom levels, i.e. the font size is too big, or they
  should just not be displayed (#12339).

  Likewise, currently labels are always abbreviated, such as King
  Dr, even when there is more than enough room to write out the name
  fully, such as King Drive (#12340).

  In addition, we could have glyphs for highway labels (#12341).

  Also, in profiling, it appears that a fair amount of time is
  spent in the map_draw_gdk functions.  There may be ways to
  speed this up, but even better would be to have a rendered
  tile cache (#12342).  Currently there is no caching in place
  in the post-render path.  This would allow us to use the 'good'
  (i.e. cairo) tiles even when dragging and would eliminate the
  gdk time sink.  It could be disk-based for long term use.  You'd
  rarely have to render the area around your own home... :)

- map_hittest optimization
  The second highest profiling offender is the map_hittest stuff.
  There should be some fairly low hanging optimizations available
  here (#12343).

- Printing (#12352)

- Database abstraction / other databases
  There are places in the code that have explicit database queries
  and which are not very database independent.  Obviously, most of
  the database stuff should be moved away from the rest of the code,
  so as to make it fairly easy to change (#12344).

  An SQLite database backend would be nice and have zero
  configuration (#12321).  It'd also make it easy to prepackage
  the TIGER data (#12345).

  Some people would probably appreciate postgres/postgis support but
  I don't think that's an immediate concern (#12346).

- Routing / Navigating (#12192)
  This is fairly self-evident.  One could also ask for speech support
  through festival (#12347).  One needs one-way street knowledge for
  this (#12349).

- OpenStreetMap support (#12348)
  We should be able to read their data, and serve as an OSM editor.
  They currently use JOSM, a specialized Java app, but we could also
  do this.  It would give us more data too...  Note that the OSM
  data includes the one-way street data.

- Turn it into libroadster (#12353)
  Lower level 'map this' library.  Desktop apps can link to it in
  order to allow mapping (e.g. Evolution shows not only addresses
  but map snippets).

  Note that this is something like what mapnik does (except mapnik
  appears to be general enough that you may have to do some work with
  the data).  Also mapnik is written in C++, and uses AGG.  The
  C/Cairo/Gtk+ probably will fit better in our world, but we may
  be able to steal ideas.

  It should also be noted in this situation, that Roadster is
  currently GPL.  If we were to library-ize it, it should probably
  move to LGPL (there are few contributors, so if they agree, there
  would be no issue).  Note that mapnik is LGPL.  AGG recently
  switched to GPL, so mapnik has an older in-tree version of AGG
  under a BSD-ish license.

- Alternatively, provide mapping *service* (#12354)
  In this scenario, other applications would ask (over D-Bus, say)
  for a map and we'd draw it for them.  It appears that geoclue
  (hosted on fd.o) is working on this sort of setup.

- Other data sets (#12355)
  Most other data is available in shapefile (e.g. GeoBase is), so
  we should probably support that.  The OGR library (of GDAL)says
  it supports shapefile and TIGER in addition to tons more, so that
  seems like a good dependency to add.

Now, I didn't list everything.  There are some other things still on:
http://web.archive.org/web/20060615151333/cairographics.org/Roadster_2fWishList

And we can also look at "competitors", such as TMRS, roadnav, gpsdrive,
mapnik, openstreetmap, etc. to see what exactly is needed in this niche.

* * *

I've also thought about the logistics of releases, and in the interest
of project growth, I'd rather release often and focus on user visible
features right now.  The roadster source currently says the version is
at 0.2.9, but the screenshots are labeled up to 0.3.9.  So I think I'll
start with 0.5.0 to avoid any confusion.  I'll attempt to stick to a
monthly release schedule for a little while.  Expect my first release,
0.5.0, on Oct. 8.  What is in that release of course depends on what
responses I get from this mail... :)  But I would like it to be at least
minimally usable by ordinary people (e.g., not having to find out your
FIPS code).

* * *

Please let me know what you think!

- Jeff