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:[EMAIL PROTECTED]:/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 _______________________________________________ roadster mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/roadster
