 |
| Trajectory data editing tool |
The trajectory data editing tool was one of the deliverables of a project, called Query Processing for moving objects on Road Networks, funded by Electronics and Telecommunications Research Institute, back in 2004. Internally, our team named the primary system as MODB.NET (Moving Object DataBase .NET). The project aimed to develop a database management system for moving objects on road networks. From a development phase to the utilization phase, data acquisition was challenging. For the data acquisition, two approaches were made: synthetic data generation and real data collection.
At that time, open data about moving objects were rare. So, we had to collect all data by ourselves, taking buses and taxis in Busan, South Korea. For the real data collection, I developed a location tracking program in Java on PDAs equipped with GPS. Unlike today, receiving GPS streaming data required serial-port communication. Besides, I had to handle raw GPS messages, learning specification of National Marine Electronics Association (NMEA) messages. One of the challenges was the low accuracy of the data collected by GPS. The error was so severe that we could not use without data preprocessing. I implemented a map-matching algorithm based on the literature [1]. Unfortunately, the quality of the results was not good enough to make use of them. That was the motivation to create the trajectory data editing tool.
The primary goal is to convert raw GPS data to locations on the road network. Its major functions are
- To browser maps: zoom in/out, panning,
- To convert coordinates from WGS84 to Korean 1985 Korea Central/East Belt,
- To select/translate/delete trajectories,
- To split a trajectory into parts, and
- To match locations onto maps with different algorithms.
Trajectories, especially taxi data, included multip trips, and we needed to split them for multiple purposes. The tool was supposed to facilitate quality control of data leading to the non-functional requirements including
- Ease of use, and
- Efficient visualization.
Compared to data size nowadays, data I handled at that time was not that big though, still computing power wasn't that strong neither. Thus, to efficiently plot all points and lines was the critical non-functional requirement. To accelerate, I introduced a double-buffering technique with multilayers. Rather than updating canvas, I managed layers separately, checking whether an update is needed to reduce the unnecessary overhead from redrawing all segments.
As an undergraduate in computer engineering, it was an exciting project beyond a simple course project. Yet, I was a kid who loves building blocks from scratch.
[1] Quddus, M.A., Ochieng, W.Y., Zhao, L. and Noland, R.B., 2003. A general map matching algorithm for transport telematics applications. GPS solutions, 7(3), pp.157-167.