I've been thinking for a while about an application for mobile devices that knows rail, bus, ferry, and magical flying eagle timetables and stops. The idea is to be able to glance at a mobile device and see it say "hey you are at foobar, its 9pm, I guess you want to go home/to hotel, and here's how you can do it, how regularly that happens and the last time you could do it today".
Of course, n900 guys will want to just use a web service for this. But as mobile data costs kidneys in some parts of the world, I'm more inclined to choose a design that precaches the data when free wifi is available. This also plays well for travelling with roaming charges etc.
If you are travelling, then the machine should already know where you are staying and when, so it can direct you to the metro line of interest from where you are to get there. Again for travelling, being able to wangle a timeline to move "now" forward and see that the app can suggest reasonable options as it goes is also a good idea. You don't want to rely on it to suggest and then find you are late for the jet.
I'm thinking perhaps Qt/Soprano for this, but the exact RDF vocabulary for the bus, train, etc timetables is not jumping out at me. There are many adhoc designs I've thought about, like a series or RDF list of ical entries for each bus run, perhaps with each entry using geo84 or some other ICBM assocation method. If you know of a good RDFS for this, please let me know. I don't know when/if I'll get to hack on the code, but the itch to do so is unlikely to go away by itself.
15 comments:
MetrO has been doing that since 1997 for many smartphone platforms:
http://www.nanika.net/metro/
A new GPS-enabled version would be great. You can try and contact MetrO authors for collaoration.
I noticed that a while back, though the License is fairly explicit about the data files, and it doesn't appear to be open source as mentioned at the bottom of:
http://www.nanika.net/metro/MetroO-en.html
there is something like your idea for germany: it's called "DB Railnavigator" and uses trains, busses, ferries, walking ...
www.bahn.de/railnavigator
Same thing in Finland as well. Busses, trains, trams, and walking.
http://www.reittiopas.fi/en/
there is a really good plasmoid for this purpose:
http://www.kde-look.org/content/show.php/PublicTransport?content=106175
maybe you could contact the author and work together. he has already implemented geolocation.
by the way, great idea to fetch data whenever you can because internet is not that ubiquitous than people expect.a
@info: I noticed this nice plasmoid too :) Unfortunately it seems (currently) geared toward showing departure/arrival at a single station, rather than displaying single routes which might be interesting. Though it still makes sense to try to extend that plasmoid or at least try to collaborate for data collection.
I also noticed this:
http://metromap.antex.ru/
Which links to another Russian site with more metro connection data. The format seems simple enough so a Qt frontend shouldn't be too hard to create.
@Malvin & @jodyfanning: Thanks for the links, I'll check them out. The railvanigator could be very handy for my next trip to .de.
For the semantic part you could/shoud use tracker, so you qt apps can work on desktop and next maemo release too. Also in tracker you can find maemo location ontology, that provide class and property for describe places and routes.
@michele: I don't see the reason to use tracker here, all I want is an RDF store which Soprano handles. But I'll take a look at their "maemo location ontology" to see what parts I can use. At least we should both be compatible at the triples level.
@michele: I would actually advice against tracker. I believe it's SQL storage will in time turn out to be inferior to a proper RDF store like soprano, and as tracker and Nepomuk follow the same standard one can easily interchange them.
In time tracker in Meego will, I think, be replaced by Nepomuk, probably like some other gtk based stuff. If it ain't better, why keep it? Just to keep some ppl happy? I think at some point Meego will conclude it's smarter to connect to the larger Qt/KDE community and share as much infrastructure as possible. Or at least I hope they're smart enough to get that.
I'm not sure if this has been already referred to in this discussion, but I think a service described here could benefit from your GPS location.
The program would fire up the GPS to determine where you are and shoot out straight how to get to where you're going.
@jospoortvliet : your comment has nothing to do with the fact you are one of the leaders of KDE-Promo team, yes?
http://behindkde.org/people/jos/
@Madbob: sure I am. Doesn't change that one of the tracker developers told me the SQL solution they have isn't very flexible - they have to create specific tables and stuff for specific types of queries or it performs horrible. Technical details aren't my thing but it didn't sound good. On the other hand, soprano is specifically designed for tripplets and stuff, which sounds to me, technically, like a smarter solution.
Anyway, as long as tracker & Nepomuk have a proper dbus interface and use the same ontology (and they are working on both) it doesn't matter much what you use. If you decide to go low-level, soprano is DESIGNED for tripplets storage. SQL is not.
But I'd go with dbus so tracker & soprano can be changed anytime.
When it comes to the 'gtk stuff will be replaced', that's not sure of course but aside from sunk costs (which should be ignored) I can't think of a reason to keep something GTK in your stack over Qt if you're building on Qt - as long as they're otherwise equivalent. Both from a technical (memory/disk usage) and a social (connecting to a community) standpoint, it doesn't make sense.
Or should I not speak my mind because I'm involved with one side of this coin?
@jospoortvliet :
0) your first comment was just a blind shot against Tracker, but I can accept your semi-technical arguments in the second one ;-)
1) Tracker don't link GTK, only Glib
2) Glib still seems to stay on MeeGo platform, since Intel (the second big player with Nokia about MeeGo stuffs) push for his Clutter toolkit. Since it may do sense to load in memory a single stack, it will not happen. Try phone Nokia to convince them to break alliance with Intel...
3) Really... Soprano on mobile? Nokia itself push for Tracker's optimization for that kind of hardware platform, run some benchmark about resources usage and re-evaluate your arguments
@madbob:
first of all, tnx for the input & info, I might have an opinion but as I'm not that well versed in the technology behind it all, I appreciate information like yours ;-)
0) good :D
1+2) Ok. I don't think glib will go away anytime soon either... I don't know why clutter should stay, from my understanding qgraphicsview does the same, will be used anyway, and last time I read about it was ahead in terms of performance and features... But things might have changed over the last year in that regard.
3)I don't know about the performance differences between using SQL for tripplets vs Soprano - I just assume, based on what the tracker dev told me and the 'soprano is designed for tripplets' that soprano would offer better performance...
BTW, see my memory mapped backend to soprano. It doesn't need many resources to work on mobile devices.
FWIW, the tracker vs soprano thing is somewhat mute as I only need a data store which soprano provides just fine. The trick & fun part is getting SPARQL to evaluate quickly, which is a problem that everybody faces.
Post a Comment