[for assignment instructions,
click here]
1. Point, vector-to-raster (POINTRAS module)
a) i) For contents
of ASCII point file, click here.
ii)
For snapshot of final raster image & point layer, click here.
b)
IDRISI vector point files consist of a row containing the
point's "ID" number and the number of points associated with that "ID"
number (1 point per ID), shown in pink
in 1.(a)(i) above. Immediately following this row are the X,Y co-ordinates
of that point, shown in white
in 1.(a)(i) above. This 2-row pattern is repeated for each point.
Thus, for the image in 1.(a)(ii), a total of 18 rows of data are required.
The last row (19th, in this case) always consists of "0,0",
as IDRISI's "end-of-file" indicator.
Generally, when the X or Y co-ordinate is a fraction (eg: 3.27), choosing the correct pixel is straightforward, as the co-ordinate places this point within a pixel, not on its edge. In the case of X=3.27, the 4th pixel would be chosen, for example, since it is beyond pixel 3, but not far enough to be in pixel 5.
However, when the co-ordinate is an integer (ie: the co-ordinate is between pixels), IDRISI must make a decision. For any raster software, if X=3, choosing pixel 3 is no more correct or incorrect than pixel 4. After all, the zone covered by pixel 3 is no closer to the vector point, X=3, than the zone covered by pixel 4. Nonetheless, a convention must be decided upon and adhered to by the vector-to-raster conversion engine.
In this case, it appears
that IDRISI uses the following convention for integer point co-ordinates:
* in the X
direction, the pixel to the RIGHT of the point is chosen;
* in the Y
direction, the pixel BELOW the point is chosen.
(NOTE: the extents
specified in the INITIAL module must be sufficiently large to accommodate
this methodology; otherwise, a "wrap-around" effect occurs, as was the
case for points
3 and 4 below. The "wrap-around" would
not have occurred had the "Number of columns" in the "Reference Parameters"
panel of INITIAL been set to 7 rather than 6. However, the grid in
the handout implies a limit of 6 columns. "Wrap-around", then, was
unavoidable.)
One other convention of IDRISI must be considered. While IDRISI's column numbering system runs left-to-right, its row numbering runs top-to-bottom, like a spreadsheet. As well, the first column is "0", not "1", and the first row is "0".
Given these conventions,
following is a description of how each point was rasterised from the vector
data.:
Point 1: X=0.5 ---> column 0,
Y=6.0 ---> row 0
Point 2: X=3.0 ---> column 3,
Y=6.0 ---> row 0
Point 3: X=6.0 ---> column 6,
Y=5.5 ---> row 0 ...
...but since there is no 6th column, IDRISI does a "wrap-around", (like
hitting "return" on a typewriter), and, thus, the pixels are:
---> column 0, ---> row 1
Point 4: X=6.0 ---> column 6,
Y=3.0 ---> row 3 ...
...but since there is no 6th column, IDRISI does a "wrap-around", (like
hitting "return" on a typewriter), and, thus, the pixels are:
---> column 0, ---> row 4
Point 5: X=3.0 ---> column 3,
Y=3.0 ---> row 3
Point 6: X=0.5 ---> column 0,
Y=3.0 ---> row 3
Point 7: X=0.2 ---> column 0,
Y=0.2 ---> row 5
Point 8: X=0.8 ---> column 0,
Y=0.8 ---> row 5 ...
...since this is exactly the same pixel as that of point 7, it
over-writes that of point 7. Thus, the "id" value of "7" no longer
exists in the image database (confirmed by running HISTO); it is
replaced by "8".
Point 9: X=3.0 ---> column 3,
Y=0.5 ---> row 5
2. Line, vector-to-raster (LINERAS module)
a) i) For contents
of ASCII line file, click here.
ii)
For snapshot of final raster image & line layer, click here.
b)
IDRISI vector line files, like point files, consist of a
row containing the line's "ID" number and the number of vertices associated
with that "ID" number (many vertices per ID are possible), shown in pink
in 2.(a)(i) above. Immediately following this row are the X,Y co-ordinates
of the vertices, shown in white
in 2.(a)(i) above, a separate row for each vertex. Thus, for the
image in 2.(a)(ii), a total of 8 rows of data are required (the beginning
of the line is vertex 1, the end is vertex 8). The last row (9th,
in this case) always consists of "0,0", as IDRISI's "end-of-file"
indicator.
As with point data, fractional
line-vector co-ordinates present straightforward pixel choices. Integer
co-ordinates, though, again require that IDRISI adopt a certain convention.
It appears that IDRISI uses the following convention for integer line co-ordinates:
* in the X
direction, the pixel to the RIGHT of the point is chosen;
* in the Y
direction, the pixel BELOW the point is chosen.
Without going into the same
line-by-line detail as in 1.(b) above, one can generally observe that the
problem occurs again, when extents are insufficient; in this case, in both
columns and rows. However, the "wrap-around" does not seem to occur.
Vertices 1 and 2 require pixels at row 6 ("below"), which, of course, doesn't
exist, since only 6 rows were specified in the "Reference Parameters" panel
of INITIAL, not 7. However, the lack of the 7th column for the 3rd
vertex (X=6.0, Y=2.0), did not cause a "wrap-around" such that the pixel
at column 0, row 0 was chosen.
For interest's sake, another
ASCII file was created, this time with co-ordinates
slightly altered so that the extents (6x6) would be sufficient. In
the resulting image, the entire line is now rasterised,
demonstrating that a significant improvement in image-conversion can be
effected with small changes in the values of the co-ordinates.
3. Polygon, vector-to-raster (POLYRAS module)
a) i) For contents
of ASCII line file, click here.
ii)
For snapshot of final raster image & line layer, click here.
b)
IDRISI vector polygon files, like line files, consist of
a row containing the polygon's "ID" number and the number of vertices associated
with that "ID" number (many vertices per ID are possible), shown in pink
in 3.(a)(i) above. Immediately following this row are the X,Y co-ordinates
of the vertices, shown in white
in 3.(a)(i) above, a separate row for each vertex. The last pair
of co-ordinates must be identical to the first pair, in order to "close
the box", as it were. Thus, for the image in 3.(a)(ii), a total of
5 rows of data are required (the beginning of the polygon is vertex 1,
the end is vertex 5, and they are one and the same), even though there
are only 4 corners to the polygon. The last row (6th, in this case)
always
consists of "0,0", as IDRISI's "end-of-file" indicator.
Unlike point or line data, polygon data are treated under an entirely different, and somewhat simpler convention. IDRISI simply chooses pixels that are completely within the polygon. Thus, while vertices 1 (X=0.9, Y=0.8) and 2 (X=5.0, Y=0.8) are within the pixels on row 5 and, where they point or line data, row 5's pixel would be chosen, they are not in the case of polygon data since row 5 is not completely within the polygon. So whether a polygon-vector co-ordinate is within a pixel (fractional value) or on its edge (integer value), IDRISI simply determines if that pixel is completely contained by the vector polygon itself, not needing to make a "left/right" or "above/below" decision.
Your comments on this assignment are welcome!
