Traveling Salesman / News: Recent posts

With the new MultiTargetDijkstraRouter we can now
navigate to not only a node but to the any of a set of nodes.
This is required for adding "route to nearest gas-station/toilet/public phone/...".

Yes, we are still improving the seach-functionality.

Now you can use different national shortcuts
like "rd." for "road" and other things like "Kaiser Joseph strasse" to find the "Kaiser-Joseph-Straße".
Name-handling, comparison and normalization ae now
handled by a central helper and no longer re-implemented in each DataSet-implementation.

Once OpenStreetMap agrees on a schema to save
house-numbers and national borders they will make
our address-search complete.

The "AddressDBPlaceFinder" is now improved and debugged (With new unit-tests).

It now knows about suburbs and can index as well as search them and augment the result of a SimplePlaceFinder with suburbs and city-names to
make the result more usable.

Instead of 100x"mainstreet" you now get
"mainstreet, CityA"
"mainstreet, CityB(Suburb1)"
"mainstreet, CityB(Suburb2)",...

Today we started the AddressDBPlaceFinder.
It allowes searching for "house-number in street in zipcode+city" by building a local hsqldb
that indexes the downloaded maps.
It is not very complete but will allow much besser searching while offline once it is.

Today we introduced a new interface IExtendedPlaceFinder that all PlaceFinder-plugins can implement to show that they know about addresses.
The PlaceFinderPanel already recognizes it and now allowes to search for streets inside cities.
The INetPlaceFinder is the first finder to implement the interface.

Changes:
* much faster map-storage
* editing visible area in josm works
* map-tiles are cached locally

After trying MySQL and HSQLDB and not being
satisfied with the speed of both,
I replaced the Databases with the new "FileTileDataSe"t as the new default-data-set.
It is a data-storage backed by indexed files
that span the area of one tile-id.
Currently it is slow for name-queries and queries for an id (e.g. getNode(nodeID)) and on inserts.
All three can be improved with additional indexes
and delayed writes at a later time.

Today I added support for a new plugin-type
IRouteMetric.
We have 2 simple implementations to optimize for
* shortest path and
* fastest path.
A new metric is planned, that takes actual travel-times collected by the driver himself or other drivers to give better travel-times.

You can now start Traveling-Salesman via
Webstart with just one click:
http://travelingsales.sourceforge.net/ts.jnlp

========
Changes to Traveling Salesman 0.5

* contains HSQLDB
* starts as a fully self-contained application
* more messages ar3e localized
* major speed-improvements due to new libosm
* added menu with debug-tools
* minor bug-fixes and improvements everywhere
* binary-jar is now signed... read more

After the longawaited release of Travleing-Salesman 0.4
and LibOSM/OsmNavigation 2.2.0 we found the time
to update the wiki and document the plugins we currently have.

Now we have a first working version
of DBDataSet accessing an unmodified
OSM-Mysql-Database (created by Osmosis).

This enables us to route on maps that are
no longer constrained by the memory of the system.

To prepare for adding Database-support
we had to do some major refactoring.
We can no longer rely on having all data
in memory.
Thus a CachingDataSet was introduced and
the IDataSet-interface created.
DataSet has been renamed to MemoryDataSet.

The SVN-version of LibOSMNavigation will
now re-calulate the route every time
you get too far off.
It will stop a running calculation if the
location changes while calculating to start
over again and the threshold is configurable.

I just did the first tests where TS had to
route, navigate while "driving", show the correct
instructions and re-calculate the route
after I took a "wrong turn".
...it works! :)

Traveling-Salesman is now feature-complete enough to
undergo first test-drives where it is to
perform real in-car- navigation.
It does not look pretty yet,
it is prepared for a lot of features that are still to come and
it is not well debugged yet.
But it has all the features required to
start performing it's basic task and is
thus no longer incomplete alpha-code but
has reached a first BETA -state. :)... read more

Much of the management-code from Traveling-Salesman
has now been refactored into a single class
"NavigationManager" in OsmRouting.
It does not suffer from the limitations of the
simple implementation in TS.
* > 1 target-point to route to
* parallel computation of the sub-routed if multiple target-points are used
* navigation can start at the GPS-location
* prepared for re-compuration if the driver takes a wrong turn
* keep track of the current routing-step we are at by listening to gps-updates.... read more

Today I added support for relations in LibOSM.
The support is fairly basic in that they can be stored in a DataSet and retieved/removed but
will this will be extended later.
(Like: getting all relations for a node or way or relation.)

The map-renderer that uses the pre-rendered slippymap-tiles has now been fixed.
The tiles are corretly aligned.
Everything is cleaned, it falls back to
the simplePaintVisitor to render the
roads.
This will open up the way to reducing memory-
footprint by not holding everything that needs
to be rendered in memory but only the roads
that we can actually navigate on.
(No woods, power-lines, tram-lines, ...)

The wiki has seen some updates.
Especially about the configation- and plugin- framework in LibOSM providung you with everything from config-file and plugin-infrastructure to a ready-to-use config-dialog.

The SVN-version now:
* marks the current position (will be used once GPS is in place)
* marks the position of the next driving-maneuver
* gives directions with "left" "righ" "keep left" "turn around", "hard right",...
* has a lot of map-drawing-bugs fixed

Today we could finally test the new Versions against the OpenStreetMap-server and release them to the public.
LibOSM2.0 is named 2 because with the OSM0.5-API it is not incompatible with the 1.x-releases.
Traveling-Salesman and osmnavigation made some huge improvements are will go to beta shortly (after some missing features are added).

The refactoring to the new 0.5-API of OpenStreetMap,
that shall go live on 6/7.10.2007 is complete.
Everything compiles and _should_ work.
The problem is that the osm-server we get our
test-data from produces error-messages, so
we cannot yet test our changes.

On the 6th/7th of october (projectes date)
OpenStreetMap will switch over to API-version 0.5
(see http://wiki.openstreetmap.org/index.php/OSM_Protocol_Version_0.5\)

This means we will have to speed up our switch to
the new version and new features will be added after that is done.

Today the second plugin-class was added.
The PlaceFinderPanel can now utilize
IPlaceFinder-plugins.
A trivial name-compare already exists and a
plugin using the OSM-namefinder is in progress.

I just added a simple Plugin-Infrastructure and
made the Routing-Algorithms configurable as plugins.

A plugin must implement a given interface and have a no-arguments-constructor. A setting named "plugin.useImpl." + unqualifiedInterfaceClassName can be set to the full qualified name of the class to instanciate.