[Roadster] Status & Roadmap
jeff at jgarrett.org
Sat Sep 8 06:12:36 PDT 2007
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
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
./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):
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
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
That said, I can still see a lot of things to do. Here's something of a
- 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
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
- 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
- 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:
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
* * *
Please let me know what you think!
More information about the roadster