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 ..Bye. 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.
The two papers below provide a detailed description of these two approaces and a discussion of possible optimization and their effect on the worst-case and expected running time:
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
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
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
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?).
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!)