Table of Contents

• 1. Introduction
• 2. Identifying a place - the DCMI Point scheme
• 3. Encoding DCMI Point
  • 3.1 DCSV encoding
  • 3.2 XML encoding
• 4. Examples
• 5. References

1. Introduction

Several methods are available to indicate a place. These include, but are not limited to:

• a name, normally defined in an identifiable enumeration such as a gazetteer or list of jurisdictional localities
• a unique geocode, such as a postal code
• the coordinates of a point, using geographic values or some well-defined projection and units
• a set of arcs or faces describing the polygon or polyhedron comprising the perimeter of the place
• the limits of a regular shaped container which encompasses the place, typically a rectangular box in two or three dimensions, using geographic values or some well-defined projection and units

The Dublin Core Metadata Element Set [DCMES] includes an element, Coverage, the value of which may contain an identifier for a place. If a name or geocode is used then the scheme from which that is selected determines valid values. However, there are no simple, commonly used, notations for the identifiers which use coordinates. Here we define DCMI Point, an identifier which specifies the coordinates of the point location of a place, and describe methods for encoding DCMI Point, as a profile of DCSV [DCSV], and using a fragment of XML [XML]. If an identifier corresponding to an extensive region is required, then DCMI Box [BOX] is available for rectangular regions.

2. Identifying a place - the DCMI Point scheme

We identify a place using a point location, described using coordinates in an identified cartesian system. The point may correspond to some place within an extensive region, such as the areal or volumetric centroid, but we do not specify the nature of the relationship in this document.

We define the following components to describe the point:

¹ All components are optional.
² Values are expressed as a text-string representing a number. Units should be included using conventional (SI) notation, unless the relevant units or zunits component is present. However, if units are given as part of any value, then for this component these override those given by units or zunits.
³ If this component is absent then the value is undefined. Processors performing numeric comparisons are recommended to set values corresponding to maximally inclusive matching, i.e. the location is a line if one coordinate is missing, and a plane if two are missing.
⁴ In this context the name is non-normative. In the case of a conflict, the place identified by the coordinate values takes precedence. The name is provided for user convenience only.

3. Encoding DCMI Point

The components of a DCMI Point identifier have no meaning when disaggregated, since in any particular instance it is the complete set which acts as the identifier. Thus, use of DCMI Point to identify a place requires that the components are linked together. For systems in which data is encoded using a limited character set, this is conveniently accomplished by packaging the components into a single text-string. Various serialisation syntaxes are available, including DCSV [DCSV] and XML [XML].

In normal usage, the unadorned token "DCMI Point" should be taken to refer to the encoding using DCSV.

3.1 DCSV encoding

Writing DCMI Point using DCSV notation is straightforward, using the component names defined above. A DCMI Point value appears as follows:

east=v1; north=v2; elevation=v3; units=v4; zunits=v5; projection=v6; name=v7                

All components are optional but may not be repeated, and the ordering is not significant.

3.2 XML encoding

DCMI Point may be written in XML. Given the flexibility of XML many alternative notations are possible. One form looks like this:

<Point projection="v6" name="v7">
  <east units="v4a">v1</east>
  <north units="v4b">v2</north>
  <elevation zunits="v5">v3</elevation>
</Point>

defined by the DTD fragment:

<!ELEMENT   Point     (east?,north?,elevation?)>
<!ATTLIST   Point       
      projection  CDATA    "geographic, height relative to mean-sea-level"
      name        CDATA    #IMPLIED >
<!ELEMENT   east        (#PCDATA)>
<!ATTLIST   east        units    CDATA "signed decimal degrees">
<!ELEMENT   north       (#PCDATA)>
<!ATTLIST   north       units    CDATA "signed decimal degrees">
<!ELEMENT   elevation   (#PCDATA)>
<!ATTLIST   elevation   zunits   CDATA "m">

The values here are equivalent to the values in the DCSV profile. Note that:

1. We have defined an XML element Point. Instances of this would occur within a complete XML document.
2. The content model for Point is a conventionally ordered (x,y,z) sequence of (optional) coordinate elements. This is a cleaner representation of the information required to specify the "point" structure than is possible in DCSV. All other components of DCMI Box occur as attributes
3. units and zunits are recorded in an XML attribute. Since these are associated directly with the local coordinate element, it is possible to express different components in different units if desired.

4. Examples

Perth, Western Australia:

name=Perth, W.A.; east=115.85717; north=-31.95301


<Point name="Perth, W.A.">
        <east>115.85717</east>
        <north>-31.95301</north>
</Point>

Bridgnorth, Shropshire, U.K.:

east=372000; north=293000; units=m; projection=U.K. National Grid

<Point projection="U.K. National Grid" name="Bridgnorth">
        <east units="m">372000</east>
        <north units="m">293000</north>
</Point>

The Greenwich Meridian:

east=0; 

<Point>
        <east>0</east>
</Point>

The highest point in Australia, illustrating the use of 3-D coordinates (and how flat Australia is):

east=148.26218; north=-36.45746; elevation=2228; name=Mt. Kosciusko

<Point name="Mt. Kosciusko">
        <east>148.26218</east>
        <north>-36.45746</north>
        <elevation>2228</elevation>
</Point>

5. References

[BOX]
S. Cox, 1999. DCMI Box Encoding Scheme- specification of the spatial limits of a place, and methods for encoding this in a text string http://purl.org/dc/documents/dcmi-box
[DCMES]
1999. Dublin Core Metadata Element Set, Version 1.1: Reference Description http://purl.oclc.org/dc/documents/rec-dces-19990702.htm
[DCMI]
Dublin Core Metadata Initiative, OCLC, Dublin Ohio. http://purl.org/dc/
[DCSV]
S. Cox, R. Iannella, 1999. A syntax for writing a list of labelled values in a text string http://purl.org/dc/documents/notes-cox-19990430.htm
[XML]
Extensible Markup Language http://www.w3.org/XML/