[kde-edu]: GSoC proposal: Marble routing
torsten.rahn at credativ.de
Fri Mar 21 11:30:54 CET 2008
I've seen that "routing suggestion" for Marble just yesterday.
While I of course like to see any suggestions that involves Marble I have my
doubts that Marble's code base is ready for a complex task such as routing.
But of course I like to see someone getting involved with Marble as a GSoC
project who already has contributed to KDE in the past.
IMHO there need to be steps taken before we can actually think of routing. So
right now I don't see something as complicated as routing getting implemented
in a useful way. But maybe I'm wrong and you could convince me that there
exists a strategy with a useful outcome. Be aware that there are also other
interesting things that could be implemented into Marble which would get
Marble well-prepared for routing: like e.g. working on a generic vector-tile
renderer that could also be used for rendering OSM data (that would enable us
to properly render the route and maybe even combine this in a proper way with
node calculations). I consider the latter alone already a huge task which
would benefit Marble greatly.
That being said I love the "routing" idea of course and I think that it's one
of Marble's most important subprojects and aims that would need to get done
On Friday 21 March 2008 01:32:36 Alex Merry wrote:
> 1: Routing Algorithm
Do you have any prior experience with this topic?
> be used). Care would need to be taken with regards to
> memory consumption in the OSM file case, as planet.osm is
> in the region of 60Gb!
> When using an internet link, data should be downloaded as and
> when the routing algorithm requires it. Naturally, the
This is of course one of the hard topics that would need to get dealt with.
So how would you tackle this? Did you make any estimations about how much data
would need to get stored on the client side to calculate the route? Would
that contain the full worldwide "node-model" down to street resolution? Would
the data necessary to calculate things need to get downloaded as tiles /
Be aware that Marble's philosophy is to provide everything seamlessly so
downloading a single 1-GB file isn't an option.
How do you plan to calculate which tiles/chunks you need to use?
How does the node-model get compiled and where does it get stored, so Marble
can fetch it?
> The algorithm implementation should probably return a list
> of nodes, two for each way - where the way is entered and
> where it is left.
Another problem I see is that Marble doesn't even have a good geographical
search yet :-/
> 2. Route Projection
> When using the Mapnik OpenStreetMap projection,
One of the problems with this is that the tiles that currently get provided
via Mapnik OSM aren't suitable for usage with Marble (they are using Mercator
projection which is a bad choice for a virtual globe). So we need to create
our own tiles in equirectangular projection.
> it should
> be possible to simply render the route onto the map, using
> the data returned from the routing algorithm, in much the
> same way that Mapnik might render a way - by drawing lines
> between each node and the following one on the route.
Drawing lines that way hasn't been implemented in Marble so far (but it's
likely to exist once GSoC starts).
I personally would actually rather like to see vector rendering be implemented
> 3. User Interface
> However, simply typing in a place name (such as a street name)
> should be possible as well.
I fear a good search for Marble alone would make a GSoC project (although a
possibly and admittedly boring one).
> I would expect to spend most time (over half of the project
> time) on the first part of the project: implementing the
> algorithm and data extraction. Rendering the route and
> generating the directions should be the next most
> time-consuming parts, with the user interface relatively
> straightforward to add.
How much time do you think you'll have available for this kind of project per
week? Given that you are a dedicated KDE hacker I could imagine that you'd be
able to spend more than others. However I still have my doubts that you'll
have enough time to implement the things suggested in a proper clean way.
I think we should strip this project down to something more realistic while
declaring everything that probably doesn't fit into the time frame optional.
Tel.: 0 21 61 - 46 43 - 192
credativ GmbH, HRB Mönchengladbach 12080
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz
More information about the kde-edu