This version:
http://fabl.net/lib/geography/map/1.1/revision1.html
Revision 1[1]
Status: experimental
Previous Version: http://www.mapbureau.com/rdfmap1.0/revision2.html
Chris Goad, September 2004
cg@mapbureau.com
This specification is brief and simple because it treats only the connections between things and geography. It does not involve itself in describing the things themselves, nor describing the geometry of their earthly forms, but only in making statements of the form "this thing has that geometry on the earth", or "this map covers that area on the earth". This way of doing things allows indepedent evolution and reuse of the related vocabularies, such as RDFGeom for geometry.
WGS84 Geo is an even simpler vocabulary for defining geographical locations of RDF resources. It defines classes SpatialThing and Point, and properties lat (latitude), long (longitude), and alt (altitude). Applications that only require assigment of point locations to resources in wgs84 latitude/longitude coordinates should use the simpler Geo vocabulary. RDFMap supports assigning more complex geometry, use of other datums and cartographic projections, and descriptions of maps.
Due to the composability of RDF vocabularies, RDFMap and WGS84 Geo can be freely intermixed in RDF documents, and it is intended that applications that support RDFMap include support for WGS84 Geo as well - allowing the simplest facts to be expressed in the simplest way.
RDFMap is compliant with the recommendations for RSS 1.0 modules.
Here is an RDFMap file containing one RSS item.
<?xml version="1.0" encoding="iso-8859-1"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:map="http://fabl.net/vocabularies/geography/map/1.1/"
xmlns:geom="http://fabl.net/vocabularies/geometry/1.1/"
xmlns:geom2d="http://fabl.net/vocabularies/geometry2d/1.1/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"
xmlns:rss="http://purl.org/rss/1.0/"
>
<rss:item about="http://www.el.com/to/astoria/">
<dc:coverage>
<geom2d:Point>
<map:srs resource=
"http://fabl.net/vocabularies/geography/SRSCatalog/wgs84"/>
<geom:x>-123.817</geom:x>
<geom:y>46.183</geom:y>
</geom2d:Point>
</dc:coverage>
</rss:item>
</rdf:RDF>
This RDF signifies that the specified RSS item pertains to a particular point on the earth's surface, namely the point in the WGS84 spatial reference system with x (longitude) equal to -123.817, and y (latitude) equal to 46.183. See below for details about the srs (spatial reference system) property.
Note that dc:coverage is defined as follows in http://dublincore.org/documents/2003/02/04/dces/:
"Coverage will typically include spatial location (a place name or geographic coordinates), ..."
So, in this example, the RDFMap vocabulary was only needed to specify a spatial reference system for a point; other vocabularies did the rest of the work.
While dc:coverage is adequate to define the simplest geographical property of a thing - its location - additional vocabulary is needed to cover other basic relationships between things and geometry.
Now, here is the list of properties and classes making up RDFMap. The names "boundedBy", "edgeOf", "centerLineOf", and "srs" appear in the GML specification with similar meanings.
An Open GIS standard for defining spatial reference systems is available. However, the specification (and the subject matter which it formalizes) is complex, and the great majority of applications can be served adequately by the use of standard names for the commonly used projections. As part of this specification, we designate the URI
http://fabl.net/vocabularies/geography/SRSCatalog
as the parent beneath which SRSs are named. The most commonly used SRS's can be specified via their EPSG (European Petroleum Survey Group) codes. The SRS with EPSG code <N> is named "epsg<N>". (A listing of EPSG codes can be found at http://www.inovagis.org/giserver/epsg.asp.) For example,
http://fabl.net/vocabularies/geography/SRSCatalog/epsg32610
denotes UTM zone 10N, the universal transverse mercator zone for points in the northern hemisphere between 120 and 126 degrees west longitude (eg San Francisco). The UTM projections are suitable for maps that cover areas of up to a few hundred miles on a side (except at latitudes near the poles). We also specify that UTM zone <N> is designated by "utm<N>n", or "utm<N>s" for the northern and southern hemispheres, respectively (eg utm10n for the zone which includes San Francisco), and that "wgs84" denotes the WGS84 datum.
Programmers who use RDFMap will rarely have any need to understand the intricate details of these spatial reference systems, but will sometimes need access to a library of functions for transforming points between them. End users of systems based on RDFMap normally won't need to concern themselves with spatial reference systems at all.
The srs property can be applied to such geometric entities as Points and Boxes, with the effect that the coordinates of the entities in question are to be interpreted as points on the earth under the specified projection. The example appearing above illustrates this.
Following SVG terminology, the map is visualized as a viewport onto an infinite two-dimensional surface called the "canvas". Most maps will also have an srs property, which specifies the datum and projection used for representing points on the earth that are depicted by the map. Determining the point on a map corresponding to a point on the earth is a matter of first computing its coordinates in the SRS of the map, and then perfoming an affine transformation (scaling and offset) to render the point in canvas coordinates. For projections whose axes approximately align with lines of longitude and latitude, the x coordinate is taken to mean longitude and y latitude. The output of the affine transformation is in a right-handed coordinate system with x pointing to the right and y up. (Most graphics applications need to flip y before display, since screen coordinates usually have y pointing down).
The affine transformation is described by the following properties:
RDFMap can be used in conjunction with either RSS 1.0 or RSS 2.0 (but not RSS 0.9*). RSS 1.0 is an RDF vocabulary, so assigning RDFMap properties to RSS 1.0 resources presents no obstacle. RSS 2.0 allows inclusion of elements not defined in the RSS 2.0 specification, as long as those elements are defined in namespaces. RDFMap properties may be asserted of RSS 2.0 channels or items simply by including the relevant property elements. Here is a legal RSS 2.0 fragment of this kind:
<item>
<description>In golden gate park</description>
<dc:coverage>
<geom:Point>
<map:srs rdf:resource=
"http://fabl.net/vocabularies/geography/SRSCatalog/utm10n"/>
<geom:x>545806</geom:x>
<geom:y>4180610</geom:y>
</geom:Point>
</dc:coverage>
<pubDate>Wed, 31 Jul 2002 17:07 +0000</pubDate>
</item>
In either RSS 1.0 or RSS 2.0, a channel can be assigned a map:useMap property which specifies how its items are to be mapped. As illustrated more than once above, each item or channel may have a dc:coverage property belonging to a geometric class such as geom2d:Point indicating the geometry that should be displayed when that item is mapped.
It is common for RSS items to have other properties that are relevant to mapping. For example, the dc:type property may specify the category of entity described by an item. The map implementation is free to exploit this category information in defining map layers.
The following convention is a part of this specification: whenever a container of some kind is assigned an srs (resp. canvas), its contents are to use that srs (resp. canvas) as the default. For example, if a channel is assigned an srs, then its items may be assigned locations which fail to specify srss individually. Then, the srs of the channel is used to interpret these locations.
These techniques are illustrated by Blogmapper, an application which uses RDFMap and RSS to map the contents of weblogs.
Here's an example of an RDFMap file that describes a map of Astoria, Oregon.