Web Coverage and Georreferenced Image Service for the Spatial Data Infrastructure of the Republic of Cuba and Applications

WEB COVERAGE AND GEORREFERENCED IMAGE SERVICE FOR THE SPATIAL DATA INFRASTRUCTURE OF THE REPUBLIC OF CUBA AND APPLICATIONS

Author and co-autors

Eng. José Luis Capote Fernández, M.Sc. Eng. Rafael Cruz Iglesias, Grad. Guillermo González Suárez, Grad. Osmani Herrera González, Tech. Liset Becerra Lugones

Affiliation

GEOCUBA Enterprise Group

Contact:

[email protected]

ABSTRACT

At the present time it is difficult the access to the geographical information, including satellite images and digital models of phenomenons of different types. These difficulties include the high cost in the acquisition, the great size of the information that hinders the transport and the distribution, and the lack of knowledge of the sources of that information. Due to this in many occasions the space variables are not considered resulting in non appropriate decisions. To give solution to this problem it is necessary to coordinate from a government level all the actions with respect to not only facilitating the access to these data but also the publication and the compartment of the same ones. In Cuba the Spatial Data Infrastructure of the Republic of Cuba (IDERC) takes charge of these functions.

In the frame of the IDERC has been developed a group of technologies guided to allow the access shared to the geographical information in an Internet environment. Based on the existence of a Internet Map Server that allow the publication of information in vectorial format other new potentialities are included oriented to the manipulation of raster data and the publication of these as images as well as to the publication of cosmic images.

Several projects of investigation about some of the specifications emitted by the OpenGIS consortium have been developed . Also was implemented the specification of the format GeoTIFF. This previous work allowed the creation of a service of images in format GeoTIFF for Internet using the specification 1.0.0 of Internet map servers. A web coverage service was implemented based on the specification 1.0.0 that it allows to serve raster data, and the specification Portrayal Coverage Service that allows the visualization of coverage data like images applying predetermined classifications and other ones defined by the user. In this work we present technical elements of the development of these technologies and of the interaction among them.

Examples of applications are shown that make use of these technologies guided to different addresses and developed by different institutions what will surely have a considerable impact in the quality of the taking of decisions.

INTRODUCCION

The rapid prosperity of Internet and the increment of the connectivity among computers at global level has provoked the necessity of a search of informative technologies that allow to take advantage of these communication facilities. The use of the information distributed in the net to give solutions related with a specific topic provides an incredible advance in terms of administration of the knowledge. And if to the use of information based on the traditional data types we join the one based on geospatial data we can obtain a new vision of the problems and a new spectrum of solutions.

The use of spatial information has experienced a peak in the last years. The development of new survey methods based on the remote perception has given a great impulse to this thematic. In Cuba is broadly diffused the use of air and satellites images to carry out surveys of different nature that can go from cartography generation to environmental studies.

These images take a previous process to their use that includes processes of improvement, georectification and georeferenciation to eliminate some deformations and to adjust it to a spatial reference system. During some years this process was carried out and its results were the obtained image and a file or document with the parameters of this image.

The format GeoTIFF eliminates this separation between the image and its parameters when inserting in the same one a group of labels that contain them. The specification GeoTIFF is made over the format TIFF in the version 6 and it doesn't contradict for anything to the same one. It admits compression for different methods and monochrome, gray scale and true color images.

For the possibilities before described this format is broadly used to store georreferenced images. The enterprise group GEOCUBA as results of previous investigation projects have an implementation of this format. This implementation allows to visualize images GeoTIFF in all its resolution variants. They have been carried out tests with GeoTIFF emitted by different applications used to generate them.

The Internet map servers don't only allow to publish maps of certain projects. They can also be used to share images among the different participants of an investigation without necessity of duplicating the same one or of overloading the net opening up from a remote location an image of great size. It also avoids an administrator of projects the work of to maintain updated the participants every time that are renewed the images.

In the frame of the IDERC has been developed and collected a group of technologies guided to allow the access shared to the geographical information in an Internet environment. Based on the existence of a Internet Map Server that allow the publication of information in vectorial format other new potentialities are included oriented to the manipulation of raster data and the publication of these as images as well as to the publication of cosmic images. Also a Web Coverage Server and a Web Portrayal Server is provided to allow the creation of on line clasiffications of theese data and the visualization of theese.

In the frame of the IDERC has been developed and collected a group of technologies guided to allow the access shared to the geographical information in an Internet environment. Based on the existence of a Internet Map Server that allow the publication of information in vectorial format other new potentialities are included oriented to the manipulation of raster data and the publication of these as images as well as to the publication of cosmic images. Also a Web Coverage Server and a Web Portrayal Server is provided to allow the "on line" classification and visualization of these data.

DEVELOPMENT 1. GEOTIFF FORMAT.

Elements of the specification

The format TIFF has become one of the formats of files more popular raster in the world. But TIFF is limited in cartographic applications because there is not an openly available stable structure to cover the geographical information that at the moment exists in the public domain.

Some private solutions exist to store cartographic information in the labels of the files TIFF. Intergraph has developed a group of geographical labels for the TIFF that at the present time they conform a robust and mature implementation, but it is only usable in its applications. The same thing happens to ESRI and Island Graphics that possess limited own geographical solutions to applications you specify to their software architectures. Many companies GIS, supplying of data raster, and their clients have requested to the companies responsible for the supply and the exploitation of these geographical images a platform standard interoperable for the support of geographical images in format TIFF. This way the images could originate from platforms of images satelitales and air, paper maps and the result of geographical analysis. The images TIFF that are supported by the specification of Intergraph will be read and positioned correctly in any system GIS that this new standard called GEOTIFF supports.

The saving to the users and suppliers of data raster and of software of exploitation it is potentially significant. With the platform GEOTIFF, the companies can stop of spending excessive resources of support development to anyone and all the formats proprietors that have been invented. The suppliers of data will be able to produce images at a lower and quicker cost. The final users will have the developed software advantage them to exploit the transparency of the labels of the format GEOTIFF. And the most important, the same image raster TIFF that can be read and modified in an ambient GIS it can be equally exploded in another ambient GIS without requirements of duplicity of files or of operations of caring / to export.

The specification GEOTIFF defines a group of labels to describe all the geographical information associated with an image TIFF originated from systems of satellite images, air pictures and scanned maps, digital models of elevation or as the result of a geographical analysis. Their objective is to facilitate a means to link an image raster to a model of the well-known space or map projection, and to describe these projections.

The format GEOTIFF fulfills totally the specification TIFF 6.0 and its extension doesn't go in any sense against the same one, neither it limits the reach of the data raster supported by TIFF.

GEOTIFF uses a small group of reserved labels TIFF to store a wide range of georeferenced information, supplying to the systems of coordinated geographical and projected of the data that are needed. The projections include UTM, US State Mourns and National Grids besides the projections base as they are they Traverse Mercator, Lambert and others. No information is stored in private structures, or another mechanism that hides information to the software reader of TIFF.

GEOTIFF uses an approach "MetaTag" (GeoKey) to code dozens of elements of information in only 6 labels, taking the advantage of the format of representation of data TIFF, independent of the platform, to avoid exchange difficulties among platforms. These keys are designed in parallel form to the standard labels TIFF, and they follow the discipline very closely TIFF in their structure and design. New keys can be defined chord to the necessities that are needed inside the mark of current work and without requiring the location of new labels in the standard TIFF.

It also uses numeric codes to describe the projection types, coordinated systems, datums, ellipsoids, etc. These codes are derived of the compiled list EPSG of Petrotecnical Open Software Corporation" (POSC), and the mechanisms to add new international projections, datums and ellipsoids have been established.

The content of the information GEOTIFF is designed to be compatible with the approximate of decomposition of data used by the Infrastructure of space data (NSDI) of the committee of geographical data of the United States (FGDC).

As GEOTIFF it provides of a mark of robust work to specify a wide class of projected systems of coordinates, it is also completely expandable allowing the storage of internal private information. However keeping in mind that this standard arises of the necessity of avoiding multiple systems code proprietors they don't seek advice private implementations.

EPSG database and the GEOTIFF format:

The European Petroleum Survey Group (EPSG) was formed in 1986. It comprises specialist surveyors, geodesists and cartographers from European Oil Companies. Meetings are held twice yearly to discuss survey and positioning topics within those areas of oil industry business where cooperation is generally agreed to be mutually beneficial.

The geodesic group of it maintains a database relacional of geodesic parameters. He encourages of helping to the companies members of this group and those that need of this information disseminating their information, it has contributed to increase the efficiency and the quality in this type of services at global level.

This geodesic group of EPSG maintains and it publishes a group of parameters of systems of coordinated and descriptions of transformations of coordinated. The code used in these databases has been included as part of the specifications of the exchange format GeoTIFF.

GEOTIFF specification implementation

The implementation of the Format was carried out using Delphi and in its design it inherited of the class TBitmap that is implemented in the unit Graphics. Leaving of her was implemented the specification TIFF in their version 6 obtaining the class TTIFFImage and inheriting of her, incorporating the specification GEOTIFF and making use of the database EPSG was obtained the class TGEOTIFFImage that allows to visualize images in this format.

Bitmap

Imagen TIFF

Imagen GeoTIFF Base de Datos EPSG

Validation application.

To validate the obtained implementation of the format GeoTIFF an application to visualize georeferenced images in this format was developed. This application uses the object GeoTIFF in the same way that could make it any other application. They were only given basic facilities of zoom and pan, and the possibility of superimposing to the image a file DXF in vectorial format for validate. In the status bar of the application the coordinates of the image are shown in píxel and in map coordinates.

It was added to the application a panel for the visualization of the data of the projection that is shown next:

Test were carried out loading GeoTIFF images created with ENVI 3.5, the results were satisfactory and it is shown an example of it next:

 Image of United States that is provided as example in the application Geomedia of Intergraph. This image in the Albers Equal Area projection. The projection coordinates that are shown in the state bar as the parameters of the projection were confronted with ENVI and the software proprietor for their validation and they were correct.

 In the picture is shown an aerial photo from Key Santa Maria. This photo is georectified and georeferenced in Lambert “CubaNorte” projection (epsg:2085). Over the image is superimposed a layer of Cuban keys in the 1:250 000 scale.

2. MAPS SERVERS

There are two profiles about the internet map publish. The first one includes those where the data is rendering in the client side using some vector web format like SVG or VML. The second profile uses internet map servers wish carry out the work of rendering and filter the data of interest. In that way a web map visor can be a image HTML control in a web page.

So that a Web maps visor works, its have to be interconnected a series of maps servers through the use of common protocols if these are in a Intranet, Extranet or Internet scenario.

A Map Server can do three things. It can:

Produce a map (as a picture, as a series of graphical elements, or as a packaged set of geographic feature data), Answer basic queries about the content of the map, and Tell other programs what maps it can produce and which of those can be queried further.

A standard web browser can ask a Map Server to do these things just by submitting requests in the form of Uniform Resource Locators (URLs). The content of such URLs depends on which of the three tasks is requested.

Due to the type of information that moves between client and server, the form in that this it is packed and looking for the form of using other terms that give a better idea of the problem, the OpenGIS specifications defined 3 cases: Picture case, Graphic Elements case and Data case.

Picture Case: What travels across the Internet in response to a client’s request is essentially a picture of a map, such as a GIF, JPEG or PNG image constructed by a Map Server.

Graphic Elements Case: What travels between the web server and the client is a packaged set of individual elements, typically already in a projected reference system, and with already defined symbolization for geographic features. SVG and WebCGM are the most used graphic element formats.

Data Case: Provides the ability to send geographic feature data from the server to the client. In WMT Phase I, experiments with the use of XML as the data encoding language resulted in a draft OGC Recommendation for "Geographic Markup Language," an encoding of Open GIS Simple Features in XML.

Our maps server implements the first one for his simplicity, security and documentation. Picture Case it can be something as simple as an application HTML that contains a Form where one of their input controls is a Image that make the requests to the map server and to visualize the map that this it returns.

3. IMPLEMENTED MAPS SERVER A maps service was developed to operate in server operative systems like Windows NT, 2000, XP. Maps Server was developed using as programming tool Borland Delphi 5 for his facilities in the implementation of servers, as much CGI as ISAPI.

It presents the basic facilities of a Maps server because it implements the interfaces proposed for OpenGIS. It also presents a group of interfaces designed to extend the use from maps server to the creation and publication of thematic maps.

3.1 Maps Server basic interfaces

A Maps Server should expose three interfaces: Capabilities, Map and FeatureInfo, at least both first they are obligatory in the process of obtaining a Map and the third although it is optional have great importance when developing Geographical Information Systems based on Web.

Capabilities Interface

Capabilities interface is required in a maps server. It is designed to provide that interfaces support the Maps server, that maps layers it can serve, formats and other details.

A Maps server should always implement this interface. Internally a Map Server can choose among generating an answer dynamically to Capabilities or simply to return a file XML with the answer.

Parameters Description http://server_address/path/script? Server URL prefix WMTVER=1.0.0 Request Version REQUEST=capabilities Request Name Specific parameters

The answer should be in form of XML, which should be validated against a Definition Type Document (DTD) that is published under the name of Capabilities.dtd.

A Capabilities request

http://server_name/scripts/mapserver.exe?request=capabilities

give a XML as a result with the possibilities of the Maps server including the listing of layers and data.

Map Interface

This interface is required and it is designed to provide to the clients of the Maps Server of maps images.

Parameters Description http://server_address/path/mapserver? Server URL prefix. WMTVER=1.0.0 Request Version. REQUEST=map Request Name. LAYERS=layer_list Comma-separated list of Layers. STYLES=style_list Comma-separated list of Drawing styles. SRS=srs_identifier Spatial Reference System. BBOX=xmin,ymin,xmax,ymax Bounding box. WIDTH=output_width Image Width in pixels. HEIGHT=output_height Image Height in pixels. FORMAT=output_format Map Format. TRANSPARENT=true_or_false Transparency. FALSE default BGCOLOR=color_value Background Color. 0xFFFFFF default EXCEPTIONS=exception_format Exceptions Format; INIMAGE default Vendor-specific parameters

The result to an Map interface request of a Maps Server should offer in the format described by the field FORMAT, otherwise the corresponding exception should be generated.

A Map request:

http://server_name/Scripts/mapserver.exe?request=map&Layers=Districts &Styles=$FF0000&BBox=591965.099,236413.574,629594.849,281773.036& Format=GIF&width=300&height=200&SRS= EPSG:4326

offer as result an image in GIF format.

FeatureInfo interface

FeatureInfo interface is designed to provide more information to the clients of a Map Server of the on the elements in the maps that were requested of previous maps. Basically the interface offers a client the possibility to specify on what pixel is asking, what layer(s) should request, and in what format the information should be returned.

Parameters Description http://server_address/path / mapserver? Server URL prefix WMTVER=1.0.0 Request Version REQUEST=feature_info Request Name < map request copy > Partial copy of the Map request parameters that generated the map for which information is desired. QUERY_LAYERS=layer_list Comma-separated list of one or more layers to be queried. INFO_FORMAT=output_format Return format of feature information (MIME type). FEATURE_COUNT=number Number of features about which to return information(default=1). X=pixel_column X coordinate in pixels of feature (measured from upper left corner=0) Y=pixel_row Y coordinate in pixels of feature (measured from upper left corner=0) Specific parameters

To provide a non-state protocol, the demand of the Map is one of the parts of an FeatureInfo request. The main use of FeatureInfo is that an user sees the result of an Map request and on that map he chooses a point to get more information.

A FeatureInfo request

http://server_name/Scripts/mapserver.exe?request=feature_info&Layers= Districts&Styles=,&BBox=591965.099,236413.574,629594.849,281773.036& Format=GIF&width=300&height=200&QUERY_LAYERS=Districts&X=253&Y=183

offer as a result the information of the objects consulted for the layers LAYERS in the X,Y coordinated in format XML. In the picture below is shown a web page visualizing a aerial photo o Key Santa Maria and other vector information. These information or maps are provided by the implemented map server with GeoTIFF support.

4. WEB COVERAGE SERVER

The Web Coverage Service (WCS) supports electronic interchange of geospatial data as "coverages" – that is, digital geospatial information representing space-varying phenomena. A WCS provides access to potentially detailed and rich sets of geospatial information, in forms that are useful for client-side rendering, multi-valued coverages, and input into scientific models and other clients. The WCS may be compared to the OGC Web Map Service (WMS) and the Web Feature Service (WFS); like them it allows clients to choose portions of a server's information holdings based on spatial constraints and other criteria. Unlike WMS (OGC document 01-068r3), which filters and portrays spatial data to return static maps (rendered as pictures by the server), the Web Coverage Service provides available data together with their detailed descriptions; allows complex queries against these data; and returns data with its original semantics (instead of pictures) which can be interpreted, extrapolated, etc. -- and not just portrayed. Unlike WFS (OGC Document 02-058), which returns discrete geospatial features, the Web Coverage Service returns representations of space-varying phenomena that relate a spatio-temporal domain to a (possibly multidimensional) range of properties.

The Web Coverage Service provides three operations: GetCapabilities, GetCoverage, and DescribeCoverage. The GetCapabilities operation returns an XML document describing the service and brief descriptions of the data collections from which clients may request coverages. Clients would generally run the GetCapabilities operation and cache its result for use throughout a session, or reuse it for multiple sessions. If GetCapabilities cannot return descriptions of its available data, that information must be available from a separate source, such as an image catalog.

The DescribeCoverage operation lets clients request a full description of one or more coverages served by a particular WCS server. The server responds with an XML document that fully describes the identified coverages.

The GetCoverage operation of a Web Coverage Service is normally run after GetCapabilities and DescribeCoverage replies have shown what requests are allowed and what data are available. The GetCoverage operation returns a coverage (that is, values or properties of a set of geographic locations), bundled in a well-known coverage format. Its syntax and semantics bear some resemblance to the WMS GetMap and WFS GetFeature requests, but several extensions support the retrieval of coverages rather than static maps or discrete features.

5. COVERAGE PORTRAYAL SERVICE

The Coverage Portrayal Service defines a standard interface for producing visual pictures from coverage data. CPS extends the WMS interface and uses the Styled Layer Descriptor (SLD) language to support rendering of WCS coverages. In addition to request parameters, which serve to qualify the request action, additional information has to be provided to the CPS for it to be able to do its work. SLD is used to express additional information about:

1. where to get the coverage that the client is interested in, 2. what part or parts of the coverage data to work with, and 3. what the client wants the CPS to do with that data.

Consequently, the CPS integrates into the OGC architecture by implementing two standard OGC interfaces, the WMS interface and the WCS interface.

The Coverage Portrayal Service implemented expands the possibilities of applications to develop in the frame of the Spatial Data Infrastructure or our country. Many WMS and WCS can be connected using it.

6. STYLED LAYER DESCRIPTOR

The importance of the visual portrayal of geographic data cannot be overemphasized. The skill that goes into portraying data (whether it be geographic or tabular) is what transforms raw information into an explanatory or decision-support tool. Exisst the need for geospatial consumers to control the visual portrayal of the data with which they work.

The current OpenGIS Web Map Service (WMS) specification supports the ability for an information provider to specify very basic styling options by advertising a preset collection of visual portrayals for each available data set. However, while a WMS currently can provide the user with a choice of style options, the WMS can only tell the user the name of each style. It cannot tell the user what portrayal will look like on the map. More importantly, the user has no way of defining their own styling rules. The ability for a human or machine client to define these rules requires a styling language that the client and server can both understand. Defining this language, called the StyledLayerDescriptor (SLD), is the main focus of this paper, and it can be used to portray the output of Web Map Servers, Web Feature Servers and Web Coverage Servers. In many cases, however, the client needs some information about the data residing on the remote server before he, she or it can make a sensible request. This led to the definition of new operations for the OGC services in addition to the definition of the styling language.

There are two basic ways to style a data set. The simplest one is to color all features the same way. For example, one can imagine a layer advertised by a WMS as “hydrography” consisting of lines (rivers and streams) and polygons (lakes, ponds, oceans, etc.). A user might want to tell the server to color the insides of all polygons in a light blue, and color the boundaries of all polygons and all lines in a darker blue. This type of styling requires no knowledge of the attributes or “feature types” of the underlying data, only a language with which to describe these styles. This requirement is addressed by the FeatureTypeStyle element in the SLD document.

A more complicated requirement is to style features of the data differently depending on some attribute. For example, in a roads data set, style highways with a three-pixel red line; style four-lane roads in a two-pixel black line; and style two-lane roads in a one-pixel black line. Accomplishing this requires the user to be able to find out what attribute of the data set represents the road type. WMS already has an optional operation that fulfils this need, called DescribeLayer. This operation returns the feature types of the layer or layers specified in the request, and the attributes can be discovered with the DescribeFeatureType operation of a WFS interface.

The use of Styled Layer Descriptor was used first to create thematic maps over vector cartography published in the Spatial Data Infrastructure, a sample application is shown in the site of the Cuban Spatial Data Infrastructure for create dynamic thematic maps using the census data. This service together with other like the Web Coverage Service and the Web Portrayal Service allow to create raster maps on line classifying raster data available in the net.

The picture above is a demonstration of how all this services are chained to obtain a desired result. A Web Coverage Server serve the coverage row data of elevation the data is classified using classes defined using the Styled Layer Descriptor specification and after is portrayal in the Web Portrayal Service. Then we can overlay other layers like, as shown in the picture, hydrography to obtain an interesting map.

The availability and the use of these spatial services in the frame of the Spatial Data Infrastructure of the Republic of Cuba will have a high positive impact in the quality of the analysis and solutions found.

CONCLUSIONS

1. The study of the open solutions is highly profitable because a global tendency exists in the network toward these products in other spheres.

2. The investigative work carried out previously to this relative project about OpenGIS specifications was of great utility for our implementations.

3. It is available a basic service platform of raster data that fulfills the OpenGIS specifications for Internet environments, this platform is widely used in the Spatial Data Infrastructure of the Republic of Cuba.

4. It is available in internet the services that allow to classify raster data on line.

BIBLIOGRAPHY

1. ADOBE SYSTEMS INCORPORATED (2000): SVG, Scalable Vector Graphics, Release notes, (2000.06.25) 2. HTML 4.01 Specification. W3C Recommendation 24 December 1999

3. Borland Delphi 6.0, 7.0. Programmer Guide.

4. GSDI, The SDI CookBook, Version 1, 2000

5. Inside Windows 2000, Third Edition

6. Microsoft Corporation, Microsoft Developer Network, Abril-2003.

7. Open GIS Consortium, Inc., OpenGIS Web Map Server Interface Implementation Specification Revision 1.0.0, 2000

8. Open GIS Consortium, Inc., OpenGIS Geography Markup Language Implementation Specification Revision 2.0, 2001

9. Open GIS Consortium, Inc., OpenGIS Catalog Interface Implementation Specification Revision 1.0, 2000

10. Open GIS Consortium, Inc., OpenGIS Styled Layer Descriptor (Draft Implementation Specification) Revision 0.7.0, 2001

11. Open GIS Consortium, Inc., OpenGIS Web Feature Server Implementation Specification Revision 0.0.14, 2001

12. Open GIS Consortium, Inc., Grid Coverage Implementation Specification Revision 1.00, 2001

13. Open GIS Consortium, Inc., OpenGIS(tm) Service Architecture, Version 4.2, 2001.

14. Open GIS Consortium, Inc., The Coverage Type and its Subtypes, Version 4.0, 2001.

15. GSDI, The SDI Cookbook, Version 1.0. 2000.

16. Mastering Delphi 6.