Webbased Visualization, Fall 2001, Yap

Homework 1

DUE: October 8, 2001 THIS IS A REVISED VERSION OF hw1, BASED ON HINDSIGHT!

INTRODUCTION

We begin with visualization of 2-D vector data. In 2-D, vector data basically consists of points, lines and polygons. In this exercise, we do not have polygons: our data are a set of pairwise disjoint polygonal lines. Please visit the TIGER Resources Page under our visualization project home. Here you will find a collection of text files created by Yunyue Zhu, one for each state of the US. These files are derived from the TIGER data set (we will hear more about them in this course). Each file stores the boundaries of counties of a states. The files are line-based:

The first two lines gives the coordinates of two extreme points of the bounding box for the state. Point coordinates are in (Latitude, Longitude).
Each of the remaining lines represents a single polygonal line, given by a sequence of points. These lines happen to be x-monotone, but you need not concern yourself with this property for now.

This homework will write some programs to visualize these files. This is somewhat similar to Case Study 2.4 in the TextBook (p.75). But our input files have a slightly different format.

OBJECTIVES

To construct OpenGL/GLUT programs which read and display the above files, and also to interact with the data through GUI interfaces. We will assume C++ but you can use C if you prefer. Officially, we use either g++ or gcc compiler. We proceed in several progressive stages. In each stage, you must produce a working program which will be based on the previous stages. We also want to write these programs so that they can be reusable for future projects and homeworks. All these programs (which must be named hw1a.cc, hw1b.cc, etc) should be compiled and run through suitable targets in a single Makefile.

Stage A: Write a program named hw1a.cc that reads the above files and displays the data directly in a screen window that is 640x480.
Stage B: We give the user some feedback. First, we draw suitably chosen latitude/longitude lines in the viewport. See notes in the Tiger page. These lines must be labeled appropriately. Second, we display each monotone polygonal line in a randonly selection color.
Stage C: We next want the ability to pan and zoom. Panning is achieved by moving the right mouse button while holding down the right button. Zooming in and out are achieved by clicking the "i" and "o" keys, respectively. Your screen window should display three non-overlapping subwindows: (1) Viewing Subwindow: this displays a portion of the overall image. This should be as big as possible. (2) Navigation Subwindow: about 100x100 pixels that shows two rectangles: one rectangle is as large as possible, indicating the bounding box of the input data. The second rectangle is the position of the Viewing Subwindow within this bounding box. (3) Zoom Subwindow: a slider showing the current zoom level (the maximum and minimum zoom should be computed). Make sure that the maximum zoom in is sufficient for me to see all the detailed points. IMPORTANT: we may need to revise the solution for placing long/lat grid lines. A "static solution" will not do. When I zoom in, at each level of zoom I should be able to see at least two latitude and 2 longitude grid lines (but the numbers should also depend on aspect ratio of window).
Stage D: We refine the notion of ``lines'' in the above description of our file format. The straightforward meaning of these lines are as physical lines: they are maximal sequences of ascii characters in the file that does not include <CR> or <LF> or <EOF>. There are two conventions for separating physical lines: either a single <CR> or a <CR><LF> sequence. They are roughly the conventions in the Unix or Windows world, respectively. Your program should work for either convention. Note that these characters are not considered part of the line. But we want to re-interpret ``lines'' to mean logical lines which are constructed from one or more physical lines by taking into account three special classes of characters:
1. comment character '#': when encountered, the rest of the current physical line is discarded.
2. continuation character '\': when encountered, the rest of current line is ignored, but it also signals that the next physical line is part of the current logical line.
3. white space characters: these are spaces and tabs. A consecutive sequence of such spaces are replaced by a single space character.
Modify your previous program so that you accept physical lines. We want you to construct ``reusable components''. Therefore, you should write two files, ``logicalLines.h'' and ``logicalLines.cc''.

SUBMITTING HOMEWORK

These should be nicely packaged as a tarfile, and sent to us via email by 12 midnite of the due date. Making this tarfile should be a target of your Makefile (e.g., "make tar"). I should be able to compile hw1a.cc by saying "make 1a", and to run it by saying "make run1a". Please do not deviate from these name conventions! We do not want to second guess how to compile and test your programs. Be sure to follow all explicit instructions! Every program file should be accompanied by some high level explanations of what classes and methods are in the program, and how they are used. If it depends on other files or programs, this should be stated! You should also comment your code when appropriate. You should organize the programs so that you can reuse this homework in the future. All these issues are graded!

HINTS

Stage A: We suggest that you download the New Jersey data set to begin with, since this is relatively small but it is a state that is meaningful for us. For the OpenGL information, read sections 3.1, 3.2 of [Hill], to understand the concepts of world coordinates vs. screen coordinates, the difference between ``world window'' and ``viewport'' (and screen window). Routines from p.87-88 may be freely used.
Your program will need to determine the bounding box of the input data, and construct a viewport within your screen window so that there is no distortion in the data. See [Hill, Sect.3.2.2, p.92].
Stage B: Examples of writing text on the screen is given by our rotate.cc example.
Stage C: The use of subwindows is illustrated in our rotate.c program. We suggest the use of double buffering for the zooming and panning redisplays. Read [Hill, p.93]
Stage D: Be sure to include <ctypes.h> that has useful functions such as isspace(char c) for processing text.