Abstract
— Today, the discovery and sharing of geospatial information over the Web presents some difficulties which have not yet been solved. News distribution through website content was simplified by the use of Really Simple Syndication (RSS) and Atom syndication formats. This paper exposes an extension of Atom to redistribute references to geospatial information in a Spatial Data Infrastructure distributed environment. A geospatial client can save the status of the application and share this status with other users that need to deal with the same information and use different client vendor products in an interoperable way. The extensibility of the Atom format was essential to define a format that could be used in RSS enabled web browser, Mass Market map viewers and emerging geospatial enable integrated clients that support Open Geospatial Consortium (OGC) services. The status exchange between a web client application and Geographic Information System desktop solution is demonstrated.
Index Terms—Geospatial, web services, XML, syndication,
map, interoperability
I. INTRODUCTION
HE geospatial generation represents a component of the constant flow of information over the Internet. In the past, geospatial information was only produced by the National Map Agencies. Today, the proliferation of Geospatial Information System (GIS) applications, web Mass Market portals and frameworks (such as Google maps) and Volunteer Geographic Information (VGI) [1], are contributing significantly to diversify the use and even the creation of the geospatial information. The information is no longer collected and stored in monolithic and closed GIS’s but made available in a distributed environment that is more heterogeneous and diverse. Standards organizations such the Open Geospatial Consortium (OGC) are making a considerable effort to increase interoperability between different systems by specifying protocols and data
Manuscript received December 28, 2012. This work was supported in
part by the European Commission through the FP7- 265178- GeoViQua (ENV.2010.4.1.2-2), a grant to the Consolidated Research Groups given by the Catalan Government (2009 SGR 1511) and the OGC in the OWS9. Xavier Pons is recipient of an ICREA Acadèmia Excellence in Research grant (2011-2015).
Dr. Joan Masó is with the CREAF, Universitat Autònoma de Barcelona, 08193 Bellaterra (Cerdanyola del Vallès), Spain (phone: +34-93-5181312; fax: +34-+34-93-5181312; e-mail: joan.maso@uab.cat).
Paula Diaz is with City University of Hong Kong (e-mail: puala.diaz@uab.cat).
Anna Riverola is with the CREAF, 08193 Bellaterra (Cerdanyola del Vallès), Spain (e-mail: joan.maso@uab.cat).
Dr. Xavier Pons is with Universitat Autònoma de Barcelona, 08193 Bellaterra (Cerdanyola del Vallès), Spain (e-mail: xavier.pons@uab.cat).
encodings for geospatial data discovery and access [2]. A result of this effort is a set of service standards for data discovery (such as the Catalogue Service for the Web: CSW [3]), view (such as the Web Map Service WMS [4] and Web Map Tile Service, WMTS [5]) and access (such as the Web Coverage Service: WCS [6]). Nevertheless, the discovery and data access is still complicated, and thus many actions need to be taken to improve this situation [2]. In the analysis of a geospatial problem, several datasets (also called layers) covering the region of interest are overlaid and combined together, new information is derived and the results are presented in the form of a composed map. The distribution of this map can be done in several ways. One is by simply generating a digital printing in GeoPDF format [7], which then can be distributed and easily printed on paper. This is a popular approach to deal with emergency disaster response data, where priority is given to speed and ease of distribution rather than on the format of the data. The nature of the GeoPDF format prevents the further use of the information gathered and even its latter processing and analysis. Another possibility is to encapsulate all the data in a single file and in a reasonably popular format such us netCDF or HDF [8], or in a popular database file such as GeoPackage (based on SQLite). This has the advantage of sending the real information, which can then be used off-line, but the disadvantage of resulting in big files that become disconnected from the producer services and are limited to the region and purpose of the application. The alternative discussed in this paper is the generation of an interoperable OWS Context document. Just a small document is transmitted with links to external services and to information used; furthermore, this file is also able to contain limited amounts of embedded information.
Somehow, the proposal of this work is a way to advertise a combination of multiple geospatial content layers into a single document. This approach shares several similarities with the internet syndication formats such as RSS and Atom. In fact, the relation between syndication formats and geospatial content has been suggested in previous papers. Geospatial information can be extracted from RSS feeds [9][10], feeds are generated from map based application [11], which are used to lower the entry barrier or a non geospatial clients based on flexible RESTful services [12]. In [13] feeds are used as an output format in geospatial catalogues implementing OpenSearch queries. In [14] feeds are used to expose results of geoprocessing.
T
Exchanging the Status between Clients of
Geospatial Web Services and GIS applications
using Atom
In fact, in 2005 OGC released a standard for sharing map compositions that linked to WMS maps called Web Map Context (WMC) [15] [16]. This standard defines an XML encoding for saving the status (the context) of a WMS client, which later can be used to recover the status. It is able to save WMS URL entry points, the parameters needed to obtain each layer on a map composition as well as the size of the screen in pixels among other metadata. The standard also proposed the possibility of saving references to these XML files in another file that acts as a very simple catalogue of WMC documents.
Since the first version of the WMS, OGC Web Services (OWS) have been diversified and several service standards are now available for different tasks. Some integrated clients are able to dialog with some of these services and present the data to the user. The possibility to extent WMC to other services was noted in the WMC document and, in fact, some work was already done by some authors. WMC was combined with Web Processing Services and map services [17] [18] and WMC was extended to support WFS services in a previous interoperability experiment [19] [20].
This paper describes the conceptual model behind an emerging standard called OWS Context, and on how Atom can be adapted and extended as an encoding for context. It is inspired in WMC but supports in-line and referenced information coming from files and OGC standards. This work has been done by the OWS Context Standards Working Group from the OGC, the standard candidate is now under public comments period. Comments will be reviewed and incorporated in it and it is foreseen to be completed and approved by summer 2013. This paper also includes the description of different implementations for desktop and web applications that are able to interchange the status between them in an interoperable way. This work has been conducted in the OWS9 interoperability experiment organized by the OGC during the past 9 months.
II.OWSCONTEXT CONCEPTUAL MODEL
Conceptually, OWS Context is a list of metadata on a collection of resources. What makes it singular is that resources are geospatial, so OWS Context has to incorporate the ability to express the temporal geospatial scope of these resources. Additionally, clients can present the information not just as a list but also as a single overlaid map (see Fig 1). The model defines the structure of a document that has a generic section defining overarching metadata about a collection or resources. In this metadata we have common entries such as title, abstract, author, etc., but also specific entries about the geometrical and temporal area of interest. It also collects specifics on the application that generated the context document and, in case that the context document was visualized as an overlaid map, the size of the window used to display it. The later is useful to calculate the scale of the map when the information is presented in a bird’s eye vertical classical view. This is not the only possible representation of the data, since other oblique and world view representations have become popularized by the virtual globes interface and the Google Earth application [21].
The model [22] also defines the particularities of each resource included in the context, emphasizing the geospatial and temporal extend and the scale range in which the layer would be visualized. The content of each resource can be described at 2 levels. The first level can be interpreted by common clients that are able to deal with text and screen resolution images. The second level allows geospatial data to be included by referencing an OGC service or by including direct content.
OGC services provide a web interface for encoding requests to data in a Key and Value Pair (KVP) HTTP GET request, as a HTTP POST request that encodes the request in an XML document transmitted in the body of the message and as an HTTP POST request that encapsulates a SOAP message. Recently, OGC has also incorporated more RESTful interfaces. Conceptually, all this requests can be embedded in a resource offering element by defining an operation that includes both the elements needed for the request and the content returned by a previous execution of the OGC services request.
An alternative for the offering element is to include direct static content that can be a reference to a geospatial file (such as a GML or a SHP file), or even to embed the data directly into the context document in a supported textual or XML encoding.
Geospatial data is usually decoupled from the styling information but there is still an important aspect for data portrayal. When the data is rendered in the screen, colors, patterns, icons, etc., are added to the data to make it understandable to the final user. Context resources can incorporate a Style Layer Description file by referencing it or by embedding it in the context file.
A complete list of elements that composes the OWS Context document conceptual model is included in a UML class model (see Fig 2).
The conceptual model can be implemented in different encodings. This paper presents the Atom encoding and some implementation of it. A JSON encoding is foreseen for the future, making JavaScript based web client implementation easier.
III. OWSCONTEXT ATOMENCODING
IETF RFC 4287 defines the Atom Syndication Format as an XML file. The XML document starts with a <feed> root element that contains generic metadata and a list of <entry> defining the items exposed by the feed. The primary use case for Atom is the syndication of Web content such as weblogs and news headlines to Web sites as well as directly to user agents [23], but nothing prevents to use it for different purposes. In the OWS Context XML Encoding [24] the Atom structure has been adapted and the <feed> and <entry> elements and attributes are mapped to the context document concepts. Each entry represents a layer of geospatial information provided by a service or encoded in a file.
The Atom specification has been extended to include the geospatial extent. Geographically Encoded Objects for RSS (GeoRSS) [25], has been selected for that purpose, as it is a standard for encoding location as part of a Web feed. The name "GeoRSS" is derived from RSS, another well known web feed and syndication format, but can be equally applied to Atom. In GeoRSS, location content consists of geographical points, lines, polygons of interest and boxes. GeoRSS feeds are designed to be consumed by geographic software such as map viewers. This way, Google Maps and Bing Maps are able to represent GeoRSS feeds as points or lines over the base map. Currently, there are two levels of GeoRSS. The GeoRSS Simple is a very lightweight format that supports basic geometries (point, line, box and polygon) and it covers the typical simple use cases for encoding locations. GeoRSS GML is a formal OGC GML Application Profile, and supports a greater range of features than GeoRSS Simple. OWS Context encoded in Atom includes a geoss:where element in the general feed and in the atom:entry to define the extent of the feed or the entry. It is expected that most applications will use the element gml:Envelope to describe the bounding box of an entry (see Fig 3) but it could also be done by a more complex gml:Polygon.
<georss:where>
<gml:Envelope srsName="EPSG:4328"
srsDimension="2">
<gml:lowerCorner>-90 -180
</gml:lowerCorner>
<gml:upperCorner>90 180
</gml:upperCorner>
</gml:Envelope>
</georss:where>
Fig 3. GeoRSS encoding example
Note that, in OWS Context, GeoRSS is not intended to fully encode the geometry of the geospatial content of an <atom:entry>. To do that two options were examined: to include the geospatial content in the <atom:content> entry and to include the geospatial content in a new section. After some tests with feed readers, we saw that the inclusion of geospatial content in the <atom:content> confuses readers or they simply choose to ignore it. We did not find any current Atom reader that was able to make use of geospatial content from the atom:content element. For that reason, the final decision was to create a new element called <owc:offering>, which is able to include any geospatial content in an independent complex element that will be ignored by common Atom readers. The OWS Context standard recommends populating the <atom:content> with a textual content that helps Atom readers to better present information for the entry.
The added <owc:offering> element is defined in a way that can store specific request to OGC service binding or direct content for the resource. Most of the OGC services have a URL entry point and it can be requested providing values to a series of parameters that filters the server information to an amount of data reasonable to be transmitted in a single client-server interaction. When these parameters can be included in the service entry point URL in a KVP notation, they are included in a href attribute of an <owc:operation> element (see Fig 4). Alternatively many OGC services define an XML encoding for requests that can be encoded in XML notation and added in a <owc:payload> element.
<owc:offering
code="http://www.opengis.net/spec/owc/1.0/conf/ato
m/wms">
<owc:operation code="GetMap" method="GET"
type="image/jpeg" href="http://www.opengis.uab.cat/cgi-bin/SatCat/MiraMon.cgi?SERVICE=WMS&VERSION=1.1 .1&REQUEST=GetMap&SRS=EPSG:23031&BBOX= 355000,4539000,475000,4619000&WIDTH=600&HE IGHT=400&LAYERS=TotCatalunyaED50&FORMAT=im age/jpeg&STYLES=opti_fals&TIME=2011-03"/> </owc:offering>
Fig 4. OWS Context offering for a WMS service request class OWSContext Core Model
Context
+ specReference :URI + language :CharacterString + id :CharacterString + title :CharacterString + abstract :CharacterString [0..1] + updateDate :CharacterString [0..1] + author :CharacterString [0..1] + publisher :CharacterString [0..1] + rights :CharacterString [0..1] + areaOfInterest :GM_Envelope [0..*] + timeIntervalOfInterest :TM_GeometricPrimitive [0..*] + keyword :CharacterString [0..*] + extension :Any [0..*]
Resource
+ id :CharacterString + title :CharacterString [0..1] + abstract :CharacterString [0..1] + updatedDate :TM_Date [0..1] + author :CharacterString [0..*] + publisher :CharacterString [0..1] + rights :CharacterString [0..1] + geospatialExtent :GM_Envelope + temporalExtent :TM_GeometricPrimitive [0..*] + preview :URI
+ easilyExploitableContent :URI [0..*] + active :Boolean + keyword :CharacterString [0..*] + minScaleDenominator :double [0..1] + maxScaleDenominator :double [0..1] + folder :CharacterString [0..1] + extension :Any [0..*]
Operation
+ operationCode :CharacterString + operationMethod :CharacterString + type :CharacterString + requestURI :URI + payload :Content [0..1] + result :Content [0..1] + extension :Any [0..*]
Offering
+ offeringCode :URI + content :Content [0..*] + extension :Any [0..*]
Style
+ name :CharacterString + title :CharacterString + abstract :CharacterString [0..1] + default :Boolean [0..1] + legendURL :URI [0..1] + content :Content [0..1] + extension :Any [0..*] «FeatureType»
MD_Metadata
Creator
+ extension :Any [0..*]
CreatorApplication
+ title :CharacterString [0..1] + uri :URI [0..1] + version :CharacterString [0..1] + extension :Any [0..*]
CreatorDisplay
+ pixelWidth :Integer [0..1] + pixelHeight :Integer [0..1] + mmPerPixel :double [0..1] + extension :Any [0..*] «DataType»
Content
+ type :CharacterString + URL :URI [0..1] + content :Any [0..1] + extension :Any [0..*] +contextMetadata
0..*
+resourceMetadata 0..*
+resource 0..* {ordered} 1 +creator 1 1 +creatorApplication 0..1 1 +creatorDisplay 0..1 1 +offering 0..* 1 +operation 0..* 1 +styleSet 0..* 1
Alternatively, an offering can include direct content in the form of a href reference to a geospatial data file or embedded in some form of XML notation such as GML or KML (see Fig 5).
<owc:offering
code="http://www.opengis.net/spec/owc/1.0/req/atom
/gml">
<owc:content type="application/gml+xml">
<Annotation gml:id="AN_01">
<annotates>
<gml:Point gml:id="PT_02">
<gml:pos>430100.0
4582700.0</gml:pos>
</gml:Point>
</annotates>
</Annotation>
</owc:content>
</owc:offering>
Fig 5. OWS Context offering inline content in GML form
Finally, some extra metadata related to the entries can be included directly by using some of the 15 elements that the Dublin Core defines [26] or it can be included as an ISO 19115 metadata document [27] reference (see Fig 6).
<link rel="via" type="application/xml"
href="http://www.opengis.uab.cat/metadata/Cat_2011
0301.xml" title="XML 19115 metadata for 2010301"/>
Fig 6. OWS Context offering reference to an ISO 19115 metadata document
IV. OWSCONTEXT APPLICATION
Since OWS Context has been designed as an Atom extension, it is possible to see the document in common applications where Atom documents are valid. Some Internet browsers are able to present the document as a list of items with title, abstract, time, description and download features (see Fig 7).
Fig 7. OWS Context document shown in the Internet Explorer browser
The use of GeoRSS in Atom and the embedded KML and GML content allows the same document to be interpreted by Google Maps (and in Bing Maps with limitations) as a list of items that have the extent, and in some cases the actual content, represented in a dynamic map (see Fig 7).
Fig 8. OWS Context document shown in Google Maps. WMS entry is represented by a rectangle and GML embedded content is shown as
geometries
Since the OWS Context Atom encoding is an XML and the references to the services are included as full URLs, we have develop an XSL Transformation (XSLT) to convert the Atom feed into an HTML5 document that shows the exact status of the client view window that saved the context document. To accomplish so, we use the width and height of the client window, and the extent of the view in world (geographic) coordinates in order to calculate the scale of the map. Then, we can mix elements in world coordinates (such as GML annotations in the XIMA profile included in a chapter of the GMLJP2 standard [28]) with elements in pixel coordinates (such as WMS maps, WMTS tiles and direct SVG content). The result is an overlaid map with a legend that activates and deactivates individual items (see Fig 9). The XSL document is just 180 lines long.
Fig 9. OWS Context document that includes a link to a XSL document that Internet Explorer applies before showing the result
is able to select the specific layers to be added to the current view (see Fig 10).
Fig 10. A map browser build with JavaScript is presenting a context document for content selection
The possibility to store direct links to content in OWS Context is particularly interesting for GIS desktop solutions. This paper also presents the development made in the MiraMon desktop GIS solution [29] to include initial support for standard OWS Context (see Fig 11). Additionally, MiraMon software is able to deal either with local files, web services as well as database connections. As in any other GIS solution, MiraMon team designed its own file for storing and sharing the status of a GIS session that is called MiraMon map (MMM). The new OWS Context format is now adopted as a way to migrate the current MMM map project file to an OWS interoperable format that can be shared with other future applications implementing OWS Context. The extensibility of the format makes it possible to map concepts in the MMM to current OWS Context elements (such as titles, data links, extent, etc.) and to generate new elements that are able to include all extra content not currently covered by OWS Context. Different aspects of the different level of OWS Context usage, comparison with WMC standard and validation methods are collected in a OWS9 Engineering Report [30]. That report also describes the potential of OWS Context to combine other OGC standards such as CSW catalogue responses and as a way to share Web Processing Service (WPS) [31] requests and results.
Fig 11. MiraMon software showing the same OWS Context document presented in figure 8
V.CONCLUSIONS
OGC services are a solid ground for geospatial distributed content, but discovery an access problems persists. The need for easy discovery can be solved by using generic Internet standards that can be understood by generic clients and web crawlers. The Atom format extensibility has been proved ideal for creating a new format, which helps to advertize dynamic maps composed by distributed geospatial services calls over the Internet. The OWS Context document also serves to save the status of a map client and recover the geospatial context later, being able to replace the project files in GIS desktop applications while remaining compatible with integrated web map clients.
REFERENCES
[1] Coleman D.J, Georgiadou Y, Labonte J., “Volunteered Geographic Information: the nature and motivation of producers”, International Journal of Spatial Data Infrastructures Research, Vol 4, 2009. http://ijsdir.jrc.ec.europa.eu/index.php/ijsdir/article/viewFile/140/223 [2] Percivall G., “The application of open standards to enhance the
interoperability of geoscience information”, International Journal of Digital Earth, Volume 3, Issue S1, , pages 14 – 30, April 2010. http://gisandscience.com/2010/08/13/the-application-of-open-standards-to-enhance-the-interoperability-of-geoscience-information/ [3] Nebert D., Whiteside A., Vretanos P., “OpenGIS Catalogue Service
Implementation Specification”, Open Geospatial Consortium Inc.
OGC 07-006r1, 2007. portal.opengeospatial.org/files/?artifact_id=20555
[4] de la Beaujardiere J., “OpenGIS® Web Map Server Implementation Specification”, Open Geospatial Consortium Inc., OGC 06-042,
Version: 1.3.0., 2006. https://docs.google.com/viewer?a=v&q=cache:y5_DvxzfTBYJ:portal.
opengeospatial.org/files/?artifact_id%3D14416+%E2%80%9COpen GIS%C2%AE+Web+Map+Server+Implementation+Specification%E 2%80%9D,&hl=ca&gl=es&pid=bl&srcid=ADGEESjlWuBMZ1caT2
1khu6z- dSk8c0E9Jk3_24kDhTyUsxObaRYhWcWiT24Erz3UWshG1-C6dGrVn0UzQDGEIxFWEFsH7WvvWuuC4lHb35tl3zzO2rSCBTX kv2JvMYyP0rMAbfXiJbI&sig=AHIEtbTjkQvsyKekSN2gIEqYQw-CqOozNA
[5] Masó J., Pomakis K. and Julià N., “OpenGIS® Web Map Tile Service Implementation Standard”, Open Geospatial Consortium Inc. 2010-04-06. OGC 07-057r7. Version 1.0.0., 2010. https://docs.google.com/viewer?a=v&q=cache:a0enjKlR86EJ:portal.o pengeospatial.org/files/?artifact_id%3D32484%26version%3D2+Ope nGIS%C2%AE+Web+Map+Tile+Service+Implementation+Standard &hl=ca&gl=es&pid=bl&srcid=ADGEEShlbuP0NJQM9C8KUQk1Zs A7ywKXk8V8kiWD0rcbPEYs5wAxlqrkbiMl0Nrb3X11g24qYCWC bX26lG2bQr5HwFqSALRtfpWL9aBqUyzN_hwnYSYQnH4tINjaJ7u vGvnEFKL_VuLk&sig=AHIEtbSRCIWrf1YNorlWXNz_Hi8jkV3lzg [6] Baumann P., “OGC WCS 2.0 Interface Standard – Core”, Open Geospatial Consortium Inc., OGC 09-110r3, Version 2.0.0., 2010. https://portal.opengeospatial.org/files/?artifact_id=45404
[7] Masó J., Pons X., Zabala A., “Tuning the second-generation SDI: theoretical aspects and real use cases”, International Journal of Geographical Information, Vol. 26 (6), pp 983-1014, 2011. http://www.tandfonline.com/doi/abs/10.1080/13658816.2011.620570 [8] Cervantes D., “Using GIS to Create an Interactive GeoPDF Mapbook
for the Big Island of Hawaii”, PHD thesis, 2009. http://www.nwmissouri.edu/library/theses/cervantesdanielle/final_the sis.pdf
[9] Cammack R.G., “Open Content Web Mapping Service: A Really Simple Syndication (RSS) Approach Location Based Services and TeleCartography”, Lecture Notes in Geoinformation and Cartography 2007, pp 417-431, 2007. http://link.springer.com/chapter/10.1007%2F978-3-540-36728-4_30 [10] Wick M, Becker T, 2007 Enhancing RSS Feeds with Extracted
Geospatial Information for Further Processing and Visualization. The Geospatial Web. Advanced Information and Knowledge Processing 2007, pp 105-115
[12] Mazzetti P., Nativi S. and Caron J., “RESTful implementation of geospatial services for Earth and Space Science applications”,
International Journal of Digital Earth, Vol. 2, Supplement 1, 2009. 40-61, 2009. http://openwetware.org/images/4/4f/REST-Mazzetti.pdf [13] Núñez-Redó M., Díaz L., Gil J., González D., Huerta J., “Discovery
and Integration of Web 2.0 Content into Geospatial Information Infrastructures: A Use Case in Wild Fire Monitoring, Availability, Reliability and Security for Business, Enterprise and Health Information Systems”, Lecture Notes in Computer Science, Vol. 6908, pp 50-68, 2011. http://dl.acm.org/citation.cfm?id=2033980
[14] Müller M., Kadner D., Bernard L., “Moving Code–Sharing Geospatial Computation Logic on the Web. Multidisciplinary Research on Geographical Information in Europe and Beyond”, Proceedings of the AGILE'2012 International Conference on Geographic Information Science, Avignon, April, 24-27, 2012. ISBN: 978-90-816960-0-5 Editors: Jérôme Gensel, Didier Josselin and Danny Vandenbroucke, 2012. http://agile.gis.geo.tu-dresden.de/web/Conference_Paper/CDs/AGILE%202012/proceedings
/papers/Paper_Mueller_Moving_Code-Sharing_Geospatial_Computation_Logic_on_the_Web_2012.pdf [15] Sonnet J., “Web Map Context Documents”, Open Geospatial
Consortium Inc., OGC 05-005, Version: 1.1.0., 2005. https://docs.google.com/viewer?a=v&q=cache:uhKfzGXhOUoJ:porta l.opengeospatial.org/files/?artifact_id%3D1306+Sonnet+J.,+%E2%80 %9CWeb+Map+Context+Documents&hl=ca&gl=es&pid=bl&srcid= ADGEESiAtCnDanGtsT1Fnd6X8QUmeUDlEEDaj8rOO8H_no63n-
mUMF_-EC- 4k21W9rxzgDTlkbGvd9lOXgF5B1Kxmofz1900jCAzIGsmzTC-94R8dLr2pYFrsmFQfVoWQvDlWHxWKf5r&sig=AHIEtbSel4RlXg ZR5UwOxvDno9PiTRiYxw
[16] Manso-Callejo M.A., Manrique-Sancho M.T., Abad-Power P., “WMS Integrator: continuous access to neighboring WMS”, 13th
Agile International Conference on Geographic Information Science, Portugal, 2010. http://agile.gis.geo.tu-dresden.de/web/Conference_Paper/CDs/AGILE%202010/PosterAbstr acts_PDF/109_DOC.pdf
[17] Sai M., Minruo L., Weichang D., “Service Composition for GIS”,
IEEE Congress on Services 2008 - Part I, 2008. http://dl.acm.org/citation.cfm?id=1439005
[18] Smolders, S., Alegre, C., Gianfranceschi, S., Gilles, M., Resch, B. & Everding, T., “GENESIS Employing Web Processing Services and Sensor Web Technology for Environmental Management”, 14th AGILE International Conference on Graphic Information Science, Utrecht, (NL), 2011. http://gisandscience.com/2011/07/13/genesis- employing-web-processing-services-and-sensor-web-technology-for-environmental-management/
[19] Döllner J. and Hagedorn B., “Integrating Urban GIS, CAD, and BIM Data By Service-Based Virtual 3D City-Models”, Urban and Regional Data Management – Coors, Rumor, Fendel & Zlatanova (eds) (c) 2008 Taylor & Francis Group, London ISBN 970-0-415-44059-2 pp -157-170, 2007. http://www.hpi.uni-potsdam.de/doellner/publications/year/2007/869/DH07.html [20] Cote P., “OGC Web Services Architecture for CAD GIS and BIM,
Interoperability program report”, Open Geospatial Consortium Inc., OGC 07-023r2 Version 1.0., 2007. https://docs.google.com/viewer?a=v&q=cache:yQzmho9dHQsJ:portal .opengeospatial.org/files/?artifact_id%3D21622+OGC+Web+Service s+Architecture+for+CAD+GIS+and+BIM&hl=ca&gl=es&pid=bl&sr
cid=ADGEESgf3GVcu-iorZIHm5ZDane_E8viMgzD6wIxtntyXkv6lcCp6KkSalJ0rf2d31gzjuv rdwb2pNL06I7miyWlQc2Lv0PwGtkU-JixMSN7n08wTQj-Dq7vbR5gsz1Oka5zXG8F3Q24&sig=AHIEtbSgkRSxpIIZbOXrwa_ ZHKtS9rna3Q
[21] Butler D., “Virtual globes - the web wide world”, Nature, 439, 776– 778, 2006.
[22] Brackin R. and Gonçalves P., “OGC OWS Context Conceptual Model Specification”, Open Geospatial Consortium Inc., OGC 12-080, In preparation.
[23] Nottingham M., and Sayre R., “The Atom Syndication Format” IRTF
RFC 4287, 2005. http://webcache.googleusercontent.com/search?q=cache:_YGYknUk
GNEJ:www.cs.odu.edu/~mln/teaching/cs791-s08/%3Fmethod%3DgetElement%26element%3D~week8~Cartledge Northern.ppt+Nottingham+M.,+and+Sayre+R.,+%E2%80%9CThe+A tom+Syndication+Format%E2%80%9D&cd=5&hl=ca&ct=clnk&gl= es
[24] Brackin R.. and Gonçalves P., “OGC OWS Context ATOM Encoding Specification”, Open Geospatial Consortium Inc., OGC 12-084. In
preparation, 2012.
https://portal.opengeospatial.org/files/?artifact_id=51861
[25] Maron M., “GeoRSS: Geographically Encoded Objects for RSS Feeds”, Proc. of XTech, 2006.
[26] ISO 15836:2009 Information and documentation -- The Dublin Core metadata element set
[27] ISO 19115:2003 Geographic information – Metadata
[28] Kyle M., Burggraf D., Forde S., Lake R., “GML in JPEG 2000 for Geographic Imagery (GMLJP2) Encoding Specification”, Open Geospatial Consortium Inc. OGC 05-047r3. Version: 1.0.0, 2006. portal.opengeospatial.org/files/?artifact_id=13252
[29] Pons, X., “Manual of MiraMon. Geographic information system and remote sensing software”. Bellaterra: Centre de Recerca Ecològica i Aplicacions Forestals (CREAF) ISBN: 84-931323-5-7, 2004. [30] Masó J., “OGC OWS-9 - OWS Context evaluation IP Engineering
Report”, Open Geospatial Consortium Inc., OGC 12-105, 2012. [31] Schut P., “OGC Web Processing Service (WPS)”, Version 1.0.0,
