Proposal to define common resources for OpenGIS Location Services

Spatial information is getting ever more prominent o the web. As envisioned by the Open Geospatial Consortium (OGC) a spatial strand has been woven in to the web. However, the buildup of the geospatial web takes place with scarce utilization of OGC standard s only. One reason might be of architectural nature . Many successful web services follow the paradigm of Repr esentational State Transfer (REST). OGC has recentl y turned towards discussing RESTful OpenGIS Web Servi c s. OpenGIS Location Services (OpenLS) have not been approached in that context. Thus, we propose t o d fine common resources for OpenLS that can be ex pos d by RESTful Web Services. Spatial information is getting ever more prominent o the web. As envisioned by [McKee 1999] a spatial strand has been woven into the web. However , th buildup of the geospatial web currently takes place with only very scarce utilization of OG C standards. While institutional spatial data infrastructure ini tiatives driven mainly by geospatial experts heavil y rely on OGC standards , most of the successful applications offering geos patial content on the web do not. Examples include Google Maps, MSN maps, Yahoo Maps and geo-tagged flickr photos or Wikipedia articles. 2 Table 1 makes three points drawing upon the case o f fulfilling a simple spatial task geocoding street addresses – through widely used Application Programmer Interfaces (APIs) on the web: First, multiple interfaces to the same fun ctio ality exist. This strongly feels like history repeating – a similar situation had been prevalent in the late 1990s ([OGC 2003], [Schmitz 2006]) and had led to OGC publishing the Web Map Service speci fication ([OGC 2001]) . Second, none of those interfaces has been defined by OGC, even though two OGC standards would have been applicable: Gazetteer Service (WFS-G) ([Fitzke & Atkinson 2006] ) and OpenGIS Location Services (OpenLS) Location Utility Service ([OGC 2005]). 3 Third, all corporations offering these interfaces are members of OGC, but do, however, not adhere to its standard s. Table 1 Multiple interfaces to geocoding functional ity on the web Google http://maps.google.com/maps/geo?q=1600+Amphitheatre+Parkway,+Mountain+Vie w,+CA&output=xml&key=xyz Yahoo http://local.yahooapis.com/MapsService/V1/geocode?appid=xyz&location=701+First +Ave,Sunnyvale,CA MSN http://dev.virtualearth.net/services/v1/geocodeservice/geocodeservice.asmx/Geoco de?count=&query=%22new%20york%22&landmark=&addressLine=&locality=&postal Town=&adminDistrict=&district=&postalCode=&countryRegion=&mapBounds=%223 7.44869658591038,%20-115.06805419921876,%2036.41686211530031,%20117.12799072265626%22&currentLocation=&curLocAccuracy=&entityTypes=&rankB y=&culture=%22en-us%22&format=json&rid=xyz 1 Examples include the Infrastructure for Spatial Information in Europe (INSPIRE) or the Canadian Spatial Data Infrastructure GeoConnections 2 http://maps.google.com, http://maps.live.com, http://maps.yahoo.com, http://flickr.com 3 Having two open standards/interfaces for the same functionality defined by a single standards body speaks for itself in this context. A table conveying the very same message of multiple non-OGC interfaces defined by OGC members for the same functionality could easily have been c ompiled for the cases of finding points of interest near a certain location, reverse geocoding or calcu lating routes. They constitute the core bulding blocks of Location-Based Services (LBS). Thus, furt he rationale will focus on interfaces for this service category. Within the OpenLS initiative seve ral services have been defined within this category ([OGC 2005]). Why is it that this readily available OGC standard has not been implemented in the real-life web applications introduced above? To analyze this in d etail is future work. One reason seems to be the bulkiness and the high-level of complexity inherent to he OpenLS specification and OGC standards in general. It can partly be accounted for by the long -term process of consensus finding between a large group of geospatial experts. Still, the API for the Yahoo! Geocoder ([Yahoo 2008]) is explained in one simple webpage whereas the OpenLS specification ([O GC 2005]) is a document of 165 pages. Even though the latter offers way more options, it docum ents the different outcomes produced by the web (simple) and the geospatial (complex) communities r espectively. Yet another reason seems to be of architectural nat ure. Many successful web services follow a Resource-Oriented architecture (ROA) ([Richardson & Ruby 2007]) as opposed to a Service-oriented architecture (SOA) that has guided currently availa ble OGC interfaces ([Lieberman 2003]). It is worth to take a closer look at ROA and the underlying arc hite tural style for distributed hypermedia systems called Representational State Transfer (REST). REST ‘has guided the design and development of the architecture of the modern Web’ ([Fielding 2000]). The core concepts of ROAs are obviously resources, their addresses (URIs), their representa tio s and the links between them. Core properties include addressability of resources, statelessness, connectedness and use of a uniform interface (in t he case of Web applications this is HTTP). Adhering to these principles is expected to lead to enhanced scalability, flexibility and simplicity, i.e. tappi ng the full potential of the Web. 4 Web Services that do are referred to as RESTful. OGC and the wider geospatial community have recentl y turned towards discussing RESTful OpenGIS® Web Services. This has happened both inter nally ([Reed 2006], [Cappelaere et al. 2007], [Uslaender 2007], [Turner 2008]) and externally ([M azzetti & Nativi 2008], [Lucchi et al. 2008]). Even though the promise of REST also appears to add ress OpenLS’ requirements, they have not yet been approached in that context. Especially the lim ited bandwidth available on mobile devices and the large number of potential concurrent users make the cas for a scalable, flexible and simple interface (HTTP itself) to OpenLS. Thus, we propose to define common resources for Ope nLS that can be exposed by RESTful Web Services. A shared understanding of resources is an alogue to defining a common interface in a SOA. It allows for interoperability between different RESTf ul Web Services for LBS. The case of routing serves as a concluding example of how the OGC OpenL S Implementation Specification ([OGC 2005]) and the approach of defining common resources relat e. Comparing SOA and RESTful Web Services [Tilkov 2008 ] states that ‘you can basically express anything you like with both approaches’. Thus, it i s possible to express the functionality defined in the OpenLS interface specification as resources (Figure 1). 4 For an in-depth introduction to REST and ROA refer to [Richardson & Ruby 2007] (Ch. 4) HTTP Request GET /RESTfulOpenLS/routes/7.09+50.74/7.19+50.73/Fas test HTTP/1.1 ... HTTP Response HTTP/1.x 200 OK Content-Type: application/xml ... Figure 1: Expressing interfaces to routing function ality (a) service-oriented as defined in the OpenLS Specification and (b) as resources, i.e. resource-o riented (based on [Tilkov 2008], modified) Note that the service-oriented approach (a) only ex poses one resource, its service URL, and defines novel operations. The resource-oriented approach (b ) in contrast exposes a very high number of resources (one for each route) and relies on standa rd HTTP operations to retrieve and manipulate those. Working a more complete set of resources fro m the OpenLS Specification remains future work. A first step is the specification of an HTTP GET sy ntax for OpenLS partly building on the APIs in Table 1 that could be presented in a full paper. On e of the challenges is expressing given semantics with a simpler syntax. Figure 2 presents a HTTP request to a first prototy pical implementation of a RESTful Web Service addressing a route as a resource. One possible repr sentation of a route can be XML for Location Services as specified in the OpenLS Implementation Specification ([OGC 2005]). Others representations may be defined. Figure 2: Route request against a prototypical REST ful OpenLS Route Service Our implementation operates on OpenStreetMap 5 d ta and has been preliminarily realized as a simp le wrapper around existing OGC OpenLS-compliant softwa re ([Neis & Zipf 2008]). A similar approach has been taken by [Mazzetti & Nativi 2008]. It can be used to evaluate the feasibility of the presente d approach. 5 Refer to http://www.openstreetmap.org a) b) Interface Resource + GET + POST + PUT + DELETE /routes/{here}/{there} + GET: request route + POST: unused + PUT: unused + DELETE: unused RouteService