[ gpsdrive ] External program interfacing with gpsdrive

stan stan.distortion at gmail.com
Mon Aug 25 05:15:31 AKDT 2008


> the easiest thing first to do, would be creating a route in the existing
> route functionality with a route point for every turning direction. most of
> the needed icons should already be there, and composing a text from your
> routing data shouldn't be too difficult.
To be honest, I had never used the route planner and hadn't even thought of 
it, yes that would be the best place for it :) I'll have a look in there and 
see how to work it.

> yes, we definitely have to work on the database.
> the problem is, it is more or less the database providing information for
> the mapnik rendering, so we can't change any of the existing tables without
> risking to break the rendering. BUT we can add tables and indexes as we
> need, I think.
I found out the hard way that the osm2pgsql app wont tolerate any interfering 
with it's tables. So far I'm using a separate set of tables in the same 
database for the routing and osm2pgsql is happy with that. The trouble at the 
mo is the different data formats, it's tricky to join something from the mapnik 
tables with something from the routing tables but I'm slowly getting these 
kind of issues ironed out. It's almost certain the osm data will be duplicated 
in the 2 sets of tables, changing the layout too much would break the 
functions of one or the other, but duplication can be kept to a minimum once 
the tables are speaking the same language and adding a text search index will 
be fairly simple after that.
The question of adding extra columns for different transport types or using the 
same data with different functions makes a big difference, I'm going with extra 
columns for now as the extra functions would make it very slow for older 
systems and almost unusable on embedded systems. What are the plans for 
gpsdrive with floating point operations and similar at the moment?
cheers



More information about the GPSdrive mailing list