GeoRDF

An RDF compatible profile for geo information (points, lines and polygons)

Implementation

ChrisGoad's suggestion for how GeoRDF as a flexible standard might be presented (in principle all the software projects in the informal ecology would have to implement both a simpler and a more complex profile...):

a vocab with three profiles, might emerge from
our discussions: 1) a point profile/vocab (== the current rdfig geo), 2) a
polyline/polygon profile/vocab (same in content as Mikel's geo:polygon or geoRSS,
but perhaps with a point sequence option added), and 3) something along the
general lines of rdfgeom.

Points

RDFIG defined a simple vocabulary for expressing points on the earth in WGS84 form.

http://www.w3.org/2003/01/geo/

 <geo:Point>
   <geo:lat>51.4</geo:lat>
   <geo:long>-0.02</geo:long>
 </geo:Point>

OR

 <geo:lat_long>51.4,-0.02</geo:lat_long>

Lines and Polygons

'simple' profile

Mikel's extension of the geo schema for [mapufacture] uses lists of comma-separated lat,long pair values to describe both lines and polygons.

http://brainoff.com/worldkit/doc/polygon.php

 <geo:line>50,-0.2,100 54,3,442 59,2.56,0</geo:line>
 <geo:polygon>30,-120 30,-100 20,-100 30,-120</geo:polygon>

However the standard GML representation, and the "Well Known Text" representation used in SQL based geometry storage, has a list of space-separated points, marked by commas: the inverse of the WorldKit formulation.

 e.g.  <geo:line>50 -0.2, 54 3, 59 2.56</geo:line>
 or <geo:line>50 -0.2 100, 54 3 442, 59 2.56 0</geo:line>

It could be left to the consumer to 'guess' which format was being used, but the case of lists of 3-dimensional points would make it more complex to infer. If the WKT form was 'standardised' on, some consumers, specifically WorldKit, would have to be able to support both and 'guess' but this would be preferable to asking the world to do it...

'complex' profile

Chris Goad's more complex formulation uses an rdf:Seq to express a list of points that are a line, a polyline or a polygon. It also separates abstract geometry from geospatial representations.

http://fabl.net/lib/geometry/1.1/revision1.html

Here are a few details:

The vocabularies RDFGeom, and its 2d companion, RDFGeom2d, provide an RDF framework that is extensible via subclassing to all kinds of geometric data, although the class hierarchy is currently only sparsely populated. The class hierarchy is loosely based on the geometric part of SVG.

Since lines, curves, and transformations are geometric, not specifically geographical, notions, RDFGeom and RDFGeom2d formulate geometry without reference to any particular application. Properties that connect geometry to intended interpretations are asserted by application-specific vocabularies. For example, under the stipulation that geo:where (transplanted from georss) takes values interpreted in wgs84:

 <geo:SpatialThing rdf:about="http://example.org/places/us/oregon/astoria">
   <geo:where> 
      <geom2d:Point><geom:x>-123.82</geom:x><geom:y>46.18</geom:y></geom2d:Point>
   </geo:where>
 </geo:SpatialThing>

In contrast to the coordinate-string approach of the simple profile, RDFGeom points appear as separate resources within sequences, illustrated by this example. The result is more verbose than the coordinate-string approach, but allows properties (including, eg, descriptions and topological relations) to be asserted of individual points - a crucial attribute for many applications (consider annotated GPX tracks).

Question: wouldn't it be better to transpose the geometric class hierarchy from GML 3.1 into RDF? (See these notes on the relationship between RDF and GML.) Yes, perhaps. But there is still a place for a geometric profile at RDFGeom's scale, requiring a dozen rather than a hundred pages of exposition, but covering enough territory beyond the simple profile to handle routine GIS applications.

Solids

It could be desirable to include a description of solids, possibly as a series of polygons which are faces:

 <geom:shape>
   <geom:face>
     <geom:polygon>
   </geom:face>
 etc.

Spatial Queries

One can represent spatial queries (places / things meeting certain criteria near a point) using either profile; the simple one as part of a HTTP GET request; the more complex one as the contents of a URI POSTed to a query service.

[bbox] has a HTTP based spatial query interface returning RDF of aggregated things that will support this query method and it would be nice to include a simple spec like this as a parcel with suggestions for and implementations of a vocabulary.

Prior Art

The GeoInfo page has a lot of references to material gathered around the time we came up with the Geo vocabulary to express point information in WGS84.

Chris Goad came up with an RDF geometry vocabulary which is used inside Fabl / RDFMapper http://mapbureau.com/ http://www.mapbureau.com/gml/index.html http://fabl.net/lib/geometry/1.1/index.html

Mikel Maron coined geo:line and geo:polygon predicates, which are just comma separated lists of lat-lon pairs. worldKit docs on geo:line, geo:polygon

Also, defined a way to specify lat/long within the content of an XML element (like <description> in RSS, or <dc:subject> in del.icio.us, flickr), for users without access to the structure of machine readable output. http://brainoff.com/worldkit/doc/rss.php#within

MortenFrederiksen's work on expressing geometry in RDF using bits of cyc http://dk.space.frot.org/ (where else?)