[Bowdoin Computer Science]

CS 350 Spring 2004:Projects

Project 2: Terrain Simplification

Due: April 15

The goal of this project is to develop a tool for terrain simplification. This tool will allow the user to load a grid, convert it to a triangulation, run the simplification routine, and visualize the resulting simplified triangulation.

Interface: The interface is open-ended. One possibility is to have a loadgrid command that loads a grid, converts it to a triangulation and displays it; an approximation command approx that approximates the current triangulation within a specified error threshold and displays it; and a save command saveTIN that writes the current approximated triangulation to a file (You do not need to implement a saveTIN command, but it may be useful to look at your output for debugging purposes; if you implement it pick a simple format for storing a triangulation on file; you do not need to write a function to load a triangulation from file). For instance:

lynx20: > makeitsimple
makeitsimple> loadgrid set1.asc
..Loading set1.asc
makeitsimple> approx  set1.asc 3
..Approximating set1.asc with error threshold e=3
makeitsimple> saveTIN set1.TIN-3
makeitsimple> exit
lynx20: > 

Grid simplification: In the first project you used a simple heuristic for implementing resolution on grids: for a given r, you replaced every subgrid of r by r points with its 4 corner points; in other words, starting from the entire grid, you dropped all points (i,j) in the grid such that either i or j is not a multiple of r; or, equivalently, starting from the 4 corners of the grid, you added all points (i,j) in the grid such that i and j are both multiple of r. This is a primitive implementation of two standard approaches to terrain simplification: decimation and refinement.

Read these papers carefully and understand the effect of the optimizations and the analysis of the running time. Then pick one method (decimation or refinement) and implement two versions of it: a brute-force one, and an improved one. For the first version, keep it simple: Remember, the first goal is to have a simplification algorithm that runs. The second goal will be to speed it up. You will not have time to do all the optimizations described in the articles above; but you will have to do something to speed it up. To compare the two procedures you will time each of them on the sample datasets and plot the running time as function of dataset size.

To optimize an algorithm is a bit of an art. Not always what is optimal in theory will be fast in practice..however understanding the theory is essential. One rule of thumb to use is: if 80% of the total running time is spent in routine A then optimize routine A first.

For this project you need to work in teams of two people. The goal is to think more systematically about the structure of the project before starting the programming. Of course this means that you will end up doing less coding and more thinking (..is that good or bad?).

Useful links:

What to turn in: Each team will turn in a tar file with the project sources and a brief writeup summarizing the method you chose (decimation or refinement), the difference between the unoptimized and optimized algorithms, and a table with the running times of your two algorithms on the sample datasets. To time a program make sure nobody else is using the machine and do not run any other process while the program is running.

Project demo: At the project demo we will time the optimized programs. The fastest one will be the winner. There will be prizes (suggestions welcome!)