On Wed, 9 Apr 1997, Jon Knight wrote:
> To me coverage.polygon seems to already provide the functionality of
> coverage.x.min, coverage.x.max, coverage.y.min, coverage.y.max, etc, in
> that it specifies a region.
Yes, but it's not so intuitive. In general I agree, but it's more
important to nail down the format, lat-long/long-lat, and direction (whether
the polygon is defining a closed area or its inverse). I know there's a
neat algorithm in the Web "imagemap" program for deciding if a point is
inside a polygon or not...
Also, I'm not sure what one is defining if the points are not coplanar.
Indeed a polygon could generalise a region
> to allow a 3d or 4d volume to be defined with something like:
>
> <meta name="DC.Coverage.polygon" content="[ 0.0 -0.2 0.15,
> 0.9 0.0 0.15,
> 0.0 0.0 0.15,
> 0.0 -0.2 -0.15,
> 0.9 0.0 -0.15,
> 0.0 0.0 -0.15,
> 0.0 0.0 -0.15 ]">
>
> (nicking the coordinate syntax un-ashamedly from OpenInventor/VRML)
In general I like the idea of defining a volume. I'm concerned that it
should be done right (mathematically correct) but I don't know how to
do it myself. In VRML, solids are not defined per se, but a set of convex
planar polygons (usually triangles) is defined, with (as I recall) a
defined direction and optional shapehints regarding which side of
the polygon is "inside" the shape (and therefore doesn't have to be lit).
VRML is written to be able to render surfaces, not do calculations on
volumes. If we want to define arbitrary volumes, it would be a good idea to
do it in such a way that one can easily
- determine if a given point is inside or outside the volume
- determine the intersection of two volumes (logical AND)
- determine the sum of two volumes (logical OR)
so that given something like a map of ozone levels in the
atmosphere, a software agent could quickly determine if a particular
point was included.
Andrew Daviel
|