The aim of the ‘Smart Ticket’ project is to develop a prototype navigation system for a transport network. In this project, the London Underground (or a section of it) will be used as the network, but the system developed will be able to be used for any such network. The system is to be able to provide routes across the network to ticket machines, navigational devices, and to users of the WWW. It must be possible for nodes (stations) and lines on the network to be closed, and so have the system develop alternative routes across the network in real time.

To realise the specification, a suite of programs will be developed. For the main route-finding system, a client-server model has been chosen. The server will contain the route-finding engine, and the code required to communicate with clients across the Internet. It will be designed to run on POSIX compliant operating systems. The machine running the server will also hold the transport network data. Clients for end-users will be developed in Java to allow their deployment on the variety of machines required by the specification. Tools for administration of the system will also be developed, but their implementation has not yet been decided, although it is likely that these will follow a similar model of a cross-platform client that will communicate with the server system.

The main body of the project splits easily into the client and server. The server itself contains network server code (for TCP or UDP communication), and a route-finding engine. Because the client and network server sections are very closely linked it was decided that they should be developed by the same person. I am developing these sections. The route-finding engine is being written by my partner. This division means that, provided a set of function prototypes supported by the engine are decided upon, the work of each individual can remain unconnected.

Development of the administration tools is as yet unplanned, but it is likely that I will write the user-interface and network code with my partner writing the code that interprets the information for use by the route-finding engine. This way, the administration programs build upon what we will have programmed for the core of the project.

We have developed a specification for the interface provided by the route-finding engine, and for the representation of routes. This has allowed us both to progress with our assigned sections.

I have written a complete skeleton of both client and server. The server provides TCP connections for multiple simultaneous clients on two ports (one for users, the other for administrators). It passes route requests to a dummy engine that returns a test pattern. It is fully functional, but requires error handling code to be developed.

The Java client is also fully functional, but with few features implemented. It will display a map, and read a node definition file from a web server. It then allows the user to specify a route, which it passes to the TCP network code which communicates with the server. Again, error handling code is required, as is a more flexible user interface.