> 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
_______________________________________________
GPSdrive mailing list
GPSdrive@???
http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive
(text/plain)