Space & Time - Programming GPS and OpenStreetMap Applications with Java - page 53

and, with the vision in mind, they should be saved for the actual roll-out
of the application.
Additional features and TODOs. We list some of the additional ideas one
might want to add to the bare-bones implementation.
ˆ The GPS unit is a virtual GPS device. What if we want to replace
it with a real GPS device (on a smart phone)? In order to do this,
a GPS interface should be extracted from the GPSunit . Note that the
interface should not include methods to set time and place, since this
is done by the device itself.
ˆ Replaying a GPS trace is useful. Yet looking at the overall vision,
there are many more use cases for coordinating objects. Every (simu-
lated) object should have ways to start, pause, and stop a trace. For
example, in the case of a car accident, it is useful to be able to replay
a complete scenario. A ROApp could record the motion of all par-
ticipating ROs and use this data to analyze the scenario. Fast/slow,
forward/backward, and pause methods could be used to implement
the type of buttons found, for example, on any DVD player.
ˆ For methods to be used internally by an RO, a proximity Trigger
would be helpful. With this trigger, the journey of a car can be
automated until it comes to an area where auto navigation reaches
its limits and the car has to be driven interactively.
ˆ A programmer could implement an XML validation and analysis of
GPS traces: Do the timestamps make sense? Are they aligned in a
sequential positive direction?
ˆ A live trace could become really large over a unit's lifetime. How long
does a lifetime last? For plausibility reasons, a ROApp might record
all of its ROs' motions, while they are participating in a scenario. As
in many online community games, a player can logoff from a scenario,
save its current status, and shutdown.
Therefor a trace management should be implemented to allow each
RO to flush its trace to the file system and reload it at a later time.
The RO user (or operator) should be able to specify a time span
to regularly store the current trace and, vice-versa, to put it back
together.
Externally the client communicating with the RO should be able to
say \Give me your trace between two time stamps, t 1 and t 2 ." Then,
the ROApp server could compare the trace to the one recorded for
the RO and check them against the scenario rules.