Home

What is GeoIRI?

GeoIRI is an experimental implementation of a URI/IRI space meant to denote arbitrary geometries, in arbitrary coordinate reference systems, by resolvable HTTP URI/IRIs.

This work builds upon the pioneering approach adopted by Ian Davis for the PlaceTime GeoPoint URI Space service (no longer operational), where two-dimensional points in the WGS84 datum are encoded directly in the relevant URI, which is then resolved to different representations based on HTTP content negotiation.

For instance, the following PlaceTime.com URI

http://placetime.com/geopoint/wgs84/X0Y0

denotes point with 0° of latitude (Y0) and 0° of longitude (X0) in the WGS84 datum.

Before going in the details of how GeoIRI is implemented, I would like to stress that GeoIRI is meant to give a working example of how to denote geometries by resolvable URIs, and not to propose the best solution for this.

The GeoIRI Syntax

The idea is to denote geometries by using HTTP URI/IRIs encoded based on the following pattern:

*/id/geometry/<CRS>/<string-encoded geometry>

whereas the corresponding description resources (i.e., the description/encoding of geometries) are denoted by the following URI/IRIs pattern:

*/doc/geometry/<CRS>/<string-encoded geometry>[.<file extension>]

The different components of the URI patterns above are as follows:

CRS

It denotes the coordinate reference system, expressed by a number corresponding to the EPSG SRID. E.g., value 4326 will denote EPSG:4326 = WGS84.

string-encoded geometry

It denotes a geometry encoded in the Well-Known Text (WKT) format. Spaces in the WKT string can be either %-encoded (i.e., replaced with %20) or replaced with char “_” (underscore). E.g.: the WKT string POINT(0 0) will be encoded either as POINT(0%200) or as POINT(0_0).

file extension

It explicitly denotes the specific requested geometry encoding. If omitted, the returned encoding is determined by HTTP content negotiation.

For instance, the following (fake) URI

http://some.site/geoiri/id/geometry/4326/point(0_40)

denotes point with 40° of latitude and 0° of longitude (point(0_40)) in the WGS84 datum (4326).

Limitations

Using a WKT string to encode a geometry in a URI cannot of course work for too complex geometries (as a polygon with hundreds of vertices), since this will result in an HTTP 414 error (“Request-URI Too Long”).

In such a case, a number of solutions might be devised. For instance, the service may replace such WKT string with a fixed-length hash value, and store the mapping temporarily. Alternatively, the service may give the user the ability to assign a “name” to such geometry, and store the mapping persistently, for future re-uses. Of course, in both cases the URI will not carry any longer information about the geometry which can be directly used by an agent without resolving the URI itself.

Anyway, as said earlier, the purpose of GeoIRI is more to give a working example of how to denote geometries by resolvable HTTP URIs, rather than proposing the best solution for this.

Similarly, the URI patterns proposed above are simply an example of how to organise such URIs.

Supported Encodings

Currently, GeoIRI can resolve geometry URIs to one of the following encodings:

Format	Content type	Extension
HTML	text/html	.html
RDF/XML	application/rdf+xml	.rdf
JSON-LD	application/ld+json	.jsonld
N3	text/n3	.n3
Turtle	text/turtle	.ttl
N-Triples	application/n-triples	.nt
WKT	text/plain	.txt
GML	application/gml+xml	.gml
GeoJSON	application/vnd.geo+json	.json
KML	application/vnd.google-earth.kml+xml	.kml

The RDF representation

Since there is currently no “de facto” standard way for representing geometries in RDF, the basic idea is to include any of the most used encodings. Thanks to this, an agent able to understand only a specific subset of the available representation, will be able to find them, and ignore the rest.

More precisely, GeoIRI supports the following RDF representations of a geometry:

• as GML and WKT literals, as per the GeoSPARQL specifications.
• by using the W3C Lat/Long vocabulary (for points only).
• by using the schema.org vocabulary (in particular, by using classes schema:GeoCoordinates and schema:GeoShape).

In addition to this, if the geometry is a point, the RDF representation also includes:

• the corresponding URI encoded by using thegeo URI scheme (see RFC 5870)
• the corresponding URI at PlaceTime.com
• the corresponding URI at geohash.org

All the above representations are linked together by using the owl:sameAs property.

The above statements are finally included in an RDF template based on the one used at reference.data.gov.uk. More precisely, the description of a geometry is represented as a prv:DataItem, and it is linked to all its available distributions—i.e., its different representations/encodings.

Complete examples of RDF representation (serialised as RDF/XML), are available in the examples/ folder, included in the GeoIRI distribution. E.g., see:

http://some.site/geoiri/id/geometry/4326/point(0_0).rdf

Underlying technologies

PostGIS

Used to generate the WKT, GML, GeoJSON, and KML encodings of the geometry, as well as the geohash.org URI.

PHP conNeg library

Used to manage HTTP content negotiation.

EasyRDF + ML/JSON-LD

Used to generate the N3, Turtle, N-Triples, and JSON-LD RDF serialisations.