Development of a Data Framework for FSUTMS
The current version (4.2) of FSUTMS-Cube uses a mix of different file formats for its input and output data. For example, socioeconomic data are stored in dBase files, highway network data (loaded and unloaded) are stored in proprietary Voyager binary files, and most transit-related data and a number of lookup tables are stored in text files. Even within the same type of files, there exist different record formats. For example, a text file could be either fixed-width, comma-delimited, a combination of both, or in some other proprietary format. These files have not been designed for easy data editing, nor fast data access. Some files also lack a record header, thus, they rely on the user's familiarity with the record format. The data values in these files are also not constrained by any required data types, formats, or ranges and are thus susceptible to user input errors. In addition, the fact that these files exist as separate files not only leads to a lack of organization, but the files are also difficult to locate in a folder that holds a large number of other files. All of these shortcomings pose a challenge to especially novice users.
While the transition in FSUTMS-Cube for most of the input data for highway networks from the previous text-based files to the current dBase files represents a major improvement, the fact that dBase files are non-relational will make it more difficult to develop future applications that make use of the input and output data. In addition, the use of proprietary Voyager binary files (.NET and .MAT) also adds to the level of difficulty. As experienced first-hand by the proposed team in the development of the FSUTMS Standard Reporting Template, the existence of these different file formats significantly added to the development time and effort.
To overcome the shortcomings of the current file structure of FSUTMS-Cube, a database framework for FSUTMS is needed to standardize all of the input and output data in centralized relational databases. Although Version 5.0 of Cube Voyager will allow users to alternatively use an ArcMap-like network editor that works together with the industry-standard Geodatabase files, this alternative has so far been limited only to the highway network files. This means that the other files that Cube uses stay in their current file formats, some of which came from those of TRANPLAN.
As Citilabs plans to gradually phase out the VIPER network editor and its associated file formats, it is inevitable that FDOT will make the transition to the new GIS-based editor in the very near future. As such, the various FSUTMS models must also make the transition in terms of both the data file formats and the network editing interface. In addition, the proposed team is currently developing a master network for highway networks that will have an implication on the design of the database framework. The project is expected to be completed within a few months. All of this points to the fact that this may be the best time to develop a data framework for FSUTMS that will not only aim to overcome the current shortcomings, but will also facilitate future applications and developments. For example, the use of centralized relational databases will facilitate future migration to the server-based, enterprise databases that will allow easy data sharing within an organization. This migration will require significantly far less effort with the use of a database framework, as it will only involve the conversion of one database to another (e.g., SQL-Server).
The objectives of this project are:
- Design a data framework for FSUTMS that will be efficient and logical, and, thus, easy to maintain, understand, and apply.
- Develop framework templates for both spatial and non-spatial input and output data.
- Develop a data import tool for the database templates that will allow automated importation of existing input and output data files.