I think a scan iterator should
A. iterate over all integer coordinates strictly contained within the shape;
B. not necessarily iterate over all the boundary points; and
C. iterate such that the iteration over the union of two shapes yields
exactly the same bag of points as the union of iterations over the two
shapes. (Bag to make sure points aren't repeated.)
This yields to something similar to the common scan conversion
routines in graphics. Coordinates are then treated as points and not
areas. The concept of a "point on the border" is welldefined, but not
trivial. (C) implies a partitioning.
I think the frustrations about a point being on the boundary comes
often comes from not posing the problem correctly, in the following
sense. Suppose you have a rectange (0,0)(5,5) defining a region, and
you want all the pixels in that rectangle. You want the points (0,x),
(x,0), (x,5) and (5,x) to be included in the bag. Then, given the
conditions above, simply define your region as
(0.5,0.5)(5.5,5.5). Boundary pixel issue solved. (Or, if you don't
want the boundary, define the region as (0.5,0.5)(4.5,4.5).)
I think the graphics scan conversion meaning works well. In the cases
it doesn't seem to, I think begin explicit about what you want from
the boundary solves the problems.
A nice thing about using this definition of scan conversion is that
the graphics community has already developed fast and robust
algorithms that handle all the corner cases.
Amitha.
