Some notes on the DC coverage element

Complex Spatial

Proposed:

Syntax

Coverage.Spatial.[Region|Void] [Scheme=<scheme>] [ x1 y1 [z1], x2 y2 [z2], ... yn [zn] ] | [x1 y1 R] | [x1 y1 z1 R]

Where exactly 2 values are specified, they are interpreted as x, y with no spatial extent (a point).
Where exactly 3 values are specified, they are interpreted as x, y, R.
Where exactly 4 values are specified, they are interpreted as x, y, z, R.
x, y, z are X, Y (and Z) coordinates in the current scheme. R is a radius value in the same scheme.

Where z values are not specified, the x,y pairs form an ordered set defining the edge of a polygon in an anticlockwise direction.
Where z values are specified, the region is defined as the minimum convex hull enclosing all x,yz triples.

Coverage.Spatial.Region and Coverage.Spatial.Void elements may be repeated. The coverage defined for the object is the sum of all Region elements minus the Void elements

If no scheme is specified:

The following abbreviations may be used:

In decimal and fractional notation, approximate precision of the data shall be indicated by the number of decimal places. In computation, some effort shall be made that this information is not lost.

If a UTM scheme is used, the zone number and hemisphere (N,S) shall be indicated in the scheme. Positions shall be defined as (Eastings, Northings, Elevation) in metres.

Computation

Where two-dimensional regions are defined, inclusion of a given point (X,Y) may be determined by a mathematical algorithm such as that in httpd "imagemap" by Eric Haines.

Where 3-dimensional regions are defined, an algorithm such as Bowyer-Watson may be used to generate the Delaunay Tessellation, and derive the convex hull of the given point set. Concave hulls which cannot be defined using an unordered point set may instead be defined using a void to produce the concave region.


A two-dimensional analog of the convex hull derivation from an unordered set of points. Here, the smallest convex polygon enclosing the points is constructed. In threee dimensions, the snmallest convex polyhedron is constructed.

Examples

We need lots of examples ...
The following coordinates are not all genuine:

A 50 metre circle around my office:
<meta name="DC.coverage.spatial.region" content="-123.384 49.10 50">
<meta name="DC.coverage.spatial.region" scheme="NAD27"
content="-123.382 49.410 50">

A more precise measurement:
<meta name="DC.coverage.spatial.region" scheme="NAD27"
content="-123.38194 49.40973 50.0">

<meta name="DC.coverage.spatial.region" scheme="UTM10N"
content="483233 5454797">

A 50 foot circle around my office:
<meta name="DC.coverage.spatial.region" scheme="NAD27"
content="49°14'44"N 123°13'49"W 50ft">

A 100 metre sphere around my office:
<meta name="DC.coverage.spatial.region" content="-123.3838 49.4094 65 100">
<meta name="DC.coverage.spatial.region" scheme="UTM10N"
content="483233 5454797 65 100">

My office building plan:
<meta name="DC.coverage.spatial.region" scheme="UTM10N"
content=" 483200 5454800, 483220 5454800, 483220 5454830, 483200 5454830, 483200 5454820, 483210 5454820, 483210 5454810, 483200 5454810 ">

My office building:
<meta name="DC.coverage.spatial.region" scheme="UTM10N"
content=" 483200 5454800 70, 483220 5454800 70, 483220 5454830 70, 483200 5454830 70, 483200 5454800 74, 483220 5454800 74, 483220 5454830 74, 483200 5454830 74 ">

<meta name="DC.coverage.spatial.void" scheme="UTM10N"
content=" 483200 5454810 70, 483210 5454810 70, 483220 5454820 70, 483200 5454820 70, 483200 5454810 74, 483210 5454810 74, 483220 5454820 74, 483200 5454820 74 ">

(defined using a void; the set of points is actually the Coordinate3 element from the VRML file)


<meta name="DC.coverage.spatial.region" scheme="UTM10N"
content=" 483200 5454800 70, 483220 5454800 70, 483220 5454810 70, 483200 5454810 70, 483200 5454800 74, 483220 5454800 74, 483220 5454810 74, 483200 5454810 74 ">

<meta name="DC.coverage.spatial.region" scheme="UTM10N"
content=" 483220 5454810 70, 483220 5454820 70, 483210 5454820 70, 483210 5454810 70, 483220 5454810 74, 483220 5454820 74, 483210 5454820 74, 483210 5454810 74 ">

<meta name="DC.coverage.spatial.region" scheme="UTM10N"
content=" 483220 5454820 70, 483220 5454830 70, 483200 5454830 70, 483200 5454820 70, 483220 5454820 74, 483220 5454830 74, 483200 5454830 74, 483200 5454820 74 ">

(defined using 3 convex regions)


A polygonal area.
<meta name="DC.coverage.spatial.region" content="1 1, 4 2, 5 4, 3 6, 2 3, 1 1">


A rectangle with a triangular and a circular void.
<meta name="DC.coverage.spatial.region" content="0 0, 7 0, 7 6, 0 6">
<meta name="DC.coverage.spatial.void" content="5 1.2, 6 1, 6 3">
<meta name="DC.coverage.spatial.void" content="3 2 1">


A square with a circular bite from one corner.
<meta name="DC.coverage.spatial.region" content="0 0, 3 0, 3 3, 0 3">
<meta name="DC.coverage.spatial.void" content="3 0 1">

Discussion

The purpose of the coverage element (or indeed all of DC), in my view, is to facilitate resource discovery by automated agents, yet allow the element to be entered by humans with as little ambiguity as possible. This means either specifying the format exactly, which is liable to lead to input errors, or specifying the format unambiguously and building agents smart enough to determine which scheme was being used.

In the case of complex shapes, specifying the format unambiguously is costly in terms of space, and therefore confusing to humans, because it becomes too large to comprehend at a glance. Therefore it is desirable to have the ordering and value of unqualified coordinates defined.

Ordering a set of coordinates which define a boundary is fairly intuitive for most people and therefore it is feasible to use an ordered set of points which permits concave shapes.

Defining a solid volume is less intuitive and requires the provision of not only vertex coordinates but also face sets. Using the convex hull approach permits a simpler definition of coordinates, while allowing many shapes such as cubes, pyramids (at arbitrary orientation) to be sepcified in one element. More complex elements may be built by using several convex regions or voids.

I believe that the conventions proposed above may be parsed unambiguously by an agent, providing that no typographical errors are made such as dropping commas.



Simple Spatial


<meta name="DC.coverage.placeName" content="British Columbia">

It might be nice to be able to select from a restricted set, e.g.
<meta name="DC.coverage.placeName" scheme="ISO3166-A3" content="GBR"> (Great Britain, c.f. UK, U.K., United Kingdom, England, the UK, etc. etc.)

GeoSpatial

It's getting a bit complex ...

Suggestions:

Self-documenting data

Use simple format. Where precision is not required, drop schema.
<meta name="DC.coverage.x" content="123d6.5W">
<meta name="DC.coverage.y" content="49d4.5N">
<meta name="DC.coverage.z" content="45m">
<meta name="DC.coverage.y" content="49d44'32"N">

How about ?
<meta name="DC.coverage.spatial" content="49d4.5N 123d6.5W 45m">
<meta name="DC.coverage.spatial" content="49d44'32"N 123d06'21W 120ft">
though I'll go along with x, y, z in the interests of getting something accomplished.


This is the kind of thing that someone might read from a GPS set, or a topo map. There is sufficient information to distinguish seconds from minutes, latitude from longitude, metres from feet. I think that if Web agents can deal with about four different date formats, that they should be able to deal with different, unambiguous, spatial formats.

Where precision is required, or the body in question is not the Earth, use a schema
<meta name="DC.coverage.y" scheme="UTM10N" content="5454818">
<meta name="DC.coverage.x" scheme="UTM10N" content="483282">
<meta name="DC.coverage.z" scheme="UTM10N" content="101"> (require metres)
<meta name="DC.coverage.x" scheme="WGS84" content="49.1462">

The instructions for using the schema may specify the format to be used. Note that lay users entering data ought to be able to discover the datum used (at least for recent material), but may not have access to translation software (such as PROJ.4).

Specifying Precision

If the fields are strings, not numbers, then one can give the precision implicitly. 49.01240 is more precise than 49.01. Otherwise, do we need some optional way to specify it, such as "49.01240/0.0001", or dc.coverage.x.precision. I'm not recommending it for general use, exactly...

What I want out of DC.coverage

References

Other References

A.Daviel