If we opt for "tiled", VPF forces us to support primitive identifiers which are only unique within a tile. This in turn is strongly suggestive of separate files for each tile, which is what the DCW does. Big problem. In fact, two big problems. A two-part identifier, consisting of tile id and number-within-tile is much more complex, both in concept and in actual lines of code to implement it. And it's slower – which is what I thought we were trying to avoid.
For example, take the case of an edge primitive which has a reference to a neighbouring edge. This table compares the processing involved in two cases: one where the edge identifier (let us refer to it as x) is unique only within a tile and requires a tile number (t) to be appended to make a reference which is unique across the whole database; and one where the edge identifier (y say) is unique on its own.
|
|
|
| Convert the tile number, t, into a file name (which requires a look-up file – and may on its own be quite time-consuming) | |
| The file name, which is in the form N\J\13, is passed to the operating system which separates the components and looks first for a directory named N | |
| It then searches for a subdirectory within N called J | |
| Search for 13 within J | |
| Search for EDG within 13; open this file and pass it to the application program | |
| Application program retrieves record number x | Application program retrieves record number y |
It can be seen that all but the last step is unnecessary overhead, because the application program still has to find the specified record number within the new file – and the process of opening a new file won't have made this any quicker than it would have been if the records for all tiles were held in a single file.
An added penalty of the file-per-tile method is that some tiles contain few primitives, perhaps requiring as little as 1k bytes – but the minimum allocation is 32k bytes, so there is quite a lot of wasted space.
back to Vector Product Format and the Digital Chart of the World