Make your own free website on Tripod.com
GIS8746 - Assignment #1, part A (questions 1-3)
 

[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!

Back to Contents