rapport_final
Document Sample


Rapport de stage
Développement d'un prototype WebGIS sur un lieu d'étude martien
présenté à
Ralph Girard
Agence Spatiale Canadienne
Technologies Spatiales
Charges Utiles Spatiales
par
Maxime Phaneuf
Université de Sherbrooke
Département de géomatique appliquée
22 août 2008
Introduction
Analog missions can be described as " terrestrial desert sites that provide
excellent and affordable environments in which to carry out scientific research
relevant to the exploration of the Moon and Mars1 ". There is such a site in
northern Canada. Located on Devon Island in Nunavut, the Haughton impact
crater is 23 kilometers is diameter and was formed 39 millions years ago. This
island is composed of Paleozoic shale and siltstone. When the impact occurred,
the shale and siltstone were peeled back to expose the bedrock underneath.
Also, the isolation of analog sites provides researchers with the chance to
simulate the remoteness of space exploration. It helps scientists determine how
explorers can optimized their limited supplies and time in these remote areas
where it is impossible to bring all sorts of equipments.
At latitude 79° north, the temperature is below the freezing point for most of the
year. This low temperature causes slow-growing vegetation limited vegetation
and this leads to very little weathering. For this reason, Haughton crater retains
many geological features that many other low-latitude craters lose.
Haughton's geology and climatology share many resemblances with Mars. In
fact, it is the region on Earth that shares the most similarities with this planet. For
this reason, scientists working there have named it "Mars on Earth". For
example, the center of Haughton crater contains breccia permeated with
permafrost, thus creating a close analog to what may be expected on a Martian
crater.
The Canadian Space Agency is intensively doing researches there to help
scientists interpret data obtain from Mars from robotic probes and robotic surface
missions.
After this type of data has been obtained from analog sites or from the Moon or
Mars and has been analyzed, it often stays on the shelves, waiting to be used. In
fact, those data could be used to produce some sort of maps for scientists to use
for future projects. Also, multiple types of data can be seen simultaneously on a
map.
For that to happen some operations must be made on them and diverse software
must be used. This is where geomatics comes in.
1
http://www.nasa.gov/centers/ames/research/technology-onepagers/moonmars.html
Geomatics and GIS
Definition
Geomatics is a fairly new science. It is the discipline that gathers, stores,
analyzes, processes, visualizes and delivers geographical data. This type of data
means that it is spatially referenced, so it has geographic coordinates and could
also be projected through a projection.
There are different ways to obtain geographical data:
Aerial photography;
Remote sensing images;
Field survey;
Scans of already existing documents, such as cadastral maps or
topographical maps.
If obtained data do not possess geographical or projected coordinates, it can be
georeferenced through already spatially referenced data or ground control points
often obtained from GPS.
Processing, analysis and visualizing steps are often done through software called
geographical information systems (GIS). Those are tools that allow manipulation
and organization of spatially referenced data. They can also help produce maps
and plans.
There are two basic types of geographical data representation:
Raster: Raster data is in fact an image, comprised of multiples pixels. The
value of each individual pixel represents something. Examples of raster
data:
o Remote sensing imagery
o Aerial photography
o Scanned maps
o Derived information from remote sensing imagery:
Digital elevation models (DEM)
Various indexes such as NDVI, LAI, etc.
Vectors: It is comprised of lines or arc, defined by a beginning and an end,
which meet at nodes. It is an abstraction of the real world, where
positional data is represented in the form of coordinates. There are three
basic types of vector data:
o Points: Points represent zero-dimensional geographical features:
wells, peak elevations, etc. They are also used to represent
features at a very large scale. For example, a city on the world map
would be a point.
o Lines: Lines represent one-dimensional geographical features:
rivers, roads, borders, etc.
o Polygons: Polygons represent two-dimensional geographical
features that cover a lot of ground, such as lakes, countries, etc.
It is those two types of data that are used in GIS.
Representation of a raster Representation of vectors
Figure 1: Representations of a raster and vector data
On the vectors image, three layers of data are present: well, river and lake. A
layer of data is a dataset that is saved in the same file. So, different layers of
data are dataset not save in the same file.
Web applications
For years, like every other software, private companies developed GIS. The most
well known is ESRI, who developed the ArcGis products. But, as years went on,
users needed more specific GIS. So, some began developing open-source GIS.
Open-source software must respect different criteria established by the Open
Source Initiative, such as:
Accessibility to the product's source
Free redistribution possibility
Derived works possibility
The vast majority of open-source GIS were software users needed to install on
their own computer. As years went on, some online GIS (WebGIS) appeared.
The most well known currently is Google Maps. But, even though open-source
GIS and WebGIS are great initiatives by developers, a big problem occurred: the
non-interoperability of those geographic software.
To counter that, the Open Geospatial Consortium (OGC) was founded in 1994. It
is an international organization dedicated to open software in geomatics. More
than 300 commercial, governmental, and educational organisms are part of the
OGC. Their principal objectives are:
Promote the use of open-source software
Synchronize the use of geographic information technologies with norms
and standards
Ensure cooperation between users and developers
Involve the whole community in the process of interoperability
Supply a platform of exchanges to promote similar development.
To achieve this, the OGC has developed some specifications. Here are some
that involve WebGIS, because this is the core of this project.
Web Mapping Service (WMS)
WMS allows the creation of maps with dataset from different data servers. It
returns an image that can be seen on screen. The format of this map can be
JPEG, GIF, PNG or another image format. So, WMS does not return the actual
data, but an image of the data. Three operations are possible through WMS:
GetCapabilities: Returns the accepted parameters, the content of the
service and the metadata of the WMS server.
GetMap: Returns the image of the data with parameters entered by the
user.
GetFeatureInfo: Returns information about an object on the map.
WMS are called through a web browser, by submitting information in the Uniform
Resource Locator (URL) bar. A URL address of a WMS looks like this:
http://host/path?{name=value&} where name=value& matches a list of already
implemented parameters:
Version: The number version of the WMS protocol.
Service: The name of the wanted standard (WMS).
Request: One of the three possible operations named above.
Format: The output format of the image.
BBOX: The spatial extent of the map.
Width: The width of the map in pixels.
Height: The height of the map in pixels.
Layers: List of the desired layers.
SRS: The wanted projection system.
Here is an example of a WMS URL:
http://67.205.74.208/cgi-bin/mapserv?map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/mars_iau49918.map&request=getMap&SERVICE=WMS&VERSION=1.1.1&REQUE
ST=GetMap&BBOX=-165.910000,-6.116460,-
107.344000,55.193900&SRS=EPSG:49918&WIDTH=608&HEIGHT=637&LAYERS=geologie&S
TYLES=&FORMAT=image/png&TRANSPARENT=TRUE
The resulting file can be opened with a web browser.
Web Feature Service (WFS)
It provides an interface allowing requests for geographical features using
platform independent calls. It can be compared as the source code behind a
map, whereas WMS only returns an image that cannot be edited or analyzed.
WFS defines interfaces for describing data manipulation operations of
geographic features. Actually, instead of returning an image of the date, it returns
the actual data.
Get or query features based on spatial or non-spatial attributes.
Create a new feature.
Delete a feature.
Update a feature.
There are two types of WFS. The basic one can only query or get features, while
the transactional WFS (T-WFS) can create, delete or update a feature.
WFS describes discovery, query or data transformation operations. The user
generates a request and posts it to a web feature server using HTTP. The server
then executes the requests. There are two ways to encode the parameters of
WFS requests:
Through XML/GML
Through Keyword-value pairs (like WMS)
Here is an example of a XML file describing a WFS request:
<wfs:GetFeature service="WFS" version="1.0.0" xmlns:wfs="http://www.opengis.net/wfs"
xmlns:topp="http://www.openplans.org/topp">
<wfs:Query typeName="topp:states"/>
</wfs:GetFeature>
Web Coverage Service (WCS)
WCS provides an interface allowing requests for geographical coverages using
independent platform calls. Coverages are digital geospatial information
representing space varying phenomena, such as:
Series of points, like locations of samples
Regular grid of pixels or points
Set of Thiessen polygons
Set of triangular irregular network (TIN)
DEMs
Like WMS and WFS, it allows client to choose a portion of a server's information
based on spatial constraints and other criteria. Unlike WMS, it returns data with
its original semantics instead of images. Unlike WFS, which returns discrete
geographic features, it returns coverages representing space-varying
phenomena.
Three operations are possible:
GetCapabilities: Returns the accepted parameters, the content of the
service and the metadata of the WCS server.
DescribeCoverage: Returns a complete description form one or a lot of
returned coverages.
GetCoverage: Returns a coverage.
Like WFS, there are two ways to encode the parameters, either through
XML/GML or HTTP request.
Web Processing Service (WPS)
WPS is designed to standardize the way GIS calculations are made available on
the Internet. It can describe any calculation (process) including all inputs and
outputs and trigger its execution. Three operations are possible:
GetCapabilities: Returns service-level metadata
DescribeProcess: Returns a description of a process, including its inputs
and outputs.
Execute: Returns the output of a process.
Like WFS and WCS, there are two ways to encore the parameters, either
through XML/GML or HTTP request.
For each of the above specifications, metadata must be defined in order to
respect the OGC recommendations. Some of these metadata will be presented
in section 5.
Styled Layer Descriptor (SLD)
SLD is used to describe the appearance of a map. It can describe either vector or
raster data. It is encode as a XML schema.
Geospatial architecture
First of all, a web server is needed. It will accept HTTP requests from users and
respond accordingly. The choice of the web server will be explained in section 5.
Also, a database is needed. It will be use to store geographical data as well as
non-geographical data. The objective of a database it to regroup at the same
place all necessary data. There are various choices of databases on the market.
Some of them do not accept geographical data, so they cannot be used for this
type of project. Others do not handle large process like WPS requests, so they
should be set aside. Also, some do not support large amount of data. So, the
criteria to choose the right database for this project are:
Handling of geographical data
Handling of large process
Handling of large amount of data
The choice of the database will be explained in section 5.
When one wants to publish geographical data on the Internet, a cartographic
server is needed. It will be installed on a web server, and will be the medium
between the database and the visualizing tool. The choice of the cartographic
server will be explained in section 5.
After requesting a cartographic server, one must have at his disposition a
visualizing tool. Two types of tool are available:
A web client integrated in a website, such as Ka-Map, OpenLayers,
GeoMoose, etc.
A GIS software, such as QGIS, GvSIG, uDIG, etc.
Web clients are popular because a simple web browser enables users to have
access to the GIS functionalities. Users don't need to install software on their
computer to actually see the map. Also, since web clients are installed on the
web server, the developers do the updates. So, there is no need for users to do
the updates themselves and they always have access to the most recent version.
GIS software need to be installed on a computer before they can be used. One of
the advantages of GIS software is that the user can have access to data on a
web server, but he can also overlap his own data. Also, users can develop some
modules for analysis in the GIS.
For the project, this is not really a choice. The two must be considered. So, a
web client must be developed. The choice of the web client will be explained in
section 5.
Like it is said above, OGC has a lot of web services. As standards, they avoid the
imposition of a tool and allow the user to use what he wants, either a web client
or a GIS. They do not need to be all implemented on a web server. So, the
choice of chosen OGC web services will be explained in section 5.
Planetary applications
There are already other planetary GIS or planetary WEBGIS.
JMARS
First of all, the Mars Space Flight Facility at Arizona State University developed a
planetary GIS called JMARS. It is Java based and several NASA missions, such
as Mars Reconnaissance Orbiter and Mars Odyssey, use it for mission planning
and scientific data analysis. It can simultaneously display multiple dataset, such
as THEMIS VIS and IR, TES, MOC, MOLA and IRTM. Before it can be used, it
must be installed on one's computer. However, it is free of use. Here is the look
of JMARS:
Figure 2: JMARS interface
PIGWAD
Planetary Interactive GIS on the Web Analyzable Database (PIGWAD) is a web
based GIS of multiple planets and different natural satellites. The United States
Geological Survey (USGS) astrogeology team developed it. As stated on their
website, the mission statements are:
Produce a web-based, user-friendly interface aimed at the planetary
research community that will support GIS graphical, statistical and spatial
tools for analyses of planetary data
Create planetary GIS databases consisting of peer-reviewed digital
geologic maps, feature maps, topography, and remote-sensing data
Support and encourage the use of GIS in planetary research including
geospatial open standards.
For each planet or natural satellite, three types of GIS are available for users:
beginner, intermediate and advanced. The complexity level increases as the user
GIS knowledge increases, but it becomes more complete. A lot more options are
available to the user as the difficulty level increases.
No installments are required, because this is a WEBGIS. The user just need to
go to the website and access the GIS he wants.
Here is a look of the advanced user Mars map:
Figure 3: Advanced WebGIS, PIGWAD
MAP-A-PLANET
Map-a-planet is another project developed by the USGS astrogeology team. Like
PIGWAD, users have a choice between different planets and natural satellites.
Nevertheless, there are differences between the two. They do not use the same
web client technology. PIGWAD uses Maplicity for its advanced GIS, while Map-
a-planet uses Mapmaker. Also, PIGWAD offers GIS where one can add different
dataset. Map-a-planet only shows one mosaic at a time: users cannot add other
dataset to the current map, but it offers the choice to download the current
image. PIGWAD specializes in vector date, while Map-a-planet offers much more
remote sensing images.
Here is a look of the Mars Merged Color Basemap from Map-A-Planet:
Figure 4: Map-A-Planet interface
Exogeomatics problem (planetary geomatics)
There are two major problems with exogeomatics:
Projection of celestial objects
The wide range of planetary data and the size of those files.
Projection of celestial objects
A map projection is any method used to represent the Earth or any other
spherical objects onto a plane. From a mathematical point of view, it is function
that establishes a link between a spherical object and a plane:
and where:
x and y are plane coordinates, is the longitude, is the latitude and f1 and f2
are functions that transforms longitude and latitude into plane coordinates.
An ellipsoid is needed. It needs to be representative of the real Earth surface. It
is also necessary to position this ellipsoid compared to the real Earth surface.
This way, it will be possible to have longitude and latitude coordinates. After the
ellipsoid and datum have been chosen, it is possible to apply a projection. There
are various types of projections:
Cylindrical projection: The ellipsoid is projected on a cylinder.
Conical projection: The ellipsoid is projected on a cone.
Azimuthal projection: The ellipsoid is projected on a plane that is tangent
to any point on this ellipsoid. Those points are often the poles.
Unique projection: The ellipsoid is not projected on a plane, cylinder or
cone.
The European Petroleum Survey Group (EPSG) has developed norms for all
Earth projections and coordinate systems definition. A numeric code is
associated with each one of them. For example, EPSG:4326 represents the
WGS84 ellipsoid, and EPSG:32611 represents UTM zone 11 North, WGS84.
The OGC's WMS standard uses EPSG codes to define Earth projections and
coordinates systems. Since it is accepted by the OGC, EPSG codes are
implemented in every GIS software.
But, there is a problem with planetary projections and coordinate systems. Even
though scientists already know planets or natural satellites ellipsoids, projections
and coordinates systems parameters, no accepted standards are defining them.
The International Astronomical Union (IAU) has proposed codes to define them,
but it is not yet accepted by the OGC. Their codes work in the same way as
EPSG, but instead the prefix is IAU2000.
Since there are no accepted standards for planetary projections and coordinates
systems, no open-source GIS software developers implement the IAU2000
codes in their product. This causes a major problem in planetary GIS.
If one wants to see a map of Mars through a WMS request with the
IAU2000:XXXXX projection, the HTTP request could look like this:
http://67.205.74.208/cgi-bin/mapserv?map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/mars_iau49918.map&request=getMap&SERVICE=WMS&VERSION=1.1.1&REQUE
ST=GetMap&BBOX=-165.910000,-6.116460,-
107.344000,55.193900&SRS=IAU2000:49918&WIDTH=608&HEIGHT=637&LAYERS=geologie&
STYLES=&FORMAT=image/png&TRANSPARENT=TRUE
The problem is the SRS=IAU2000:49918. Since cartographic servers are not
implemented to work with IAU2000 codes, they return an error to the user saying
that this projection does not exist.
Some WEBGIS have their own solution to this problem, but for each WEBGIS
that exist, there could be a solution. So, right now, it is really hard to display
multiple WMS planetary data from multiple sources on a WEBGIS. Some ways to
bypass this problem will be discussed in section 6.
Wide range of planetary data and the size of those files
It is possible to find multiple planetary dataset over the Internet. Here is a
summarized list of websites offering this type of data:
Planetary Data System (PDS): http://pds.nasa.gov/
JMARS: http://jmars.asu.edu/data/
OnMars: http://onmars.jpl.nasa.gov/ It's a Mars WMS server.
HiRISE images: http://hirise.lpl.arizona.edu/katalogos.php
MOLA: http://mola.gsfc.nasa.gov/images.html
PIGWAD: http://webgis.wr.usgs.gov/pigwad/down/index.html
Map-A-Planet: http://www.mapaplanet.org/
PIGWAD WMS server:
http://webgis.wr.usgs.gov/wmsconnector/com.esri.wms.Esrimap/Mars_general_image?re
quest=getcapabilities&service=WMS
Map-a-planet WMS server: http://www.mapaplanet.com/explorer-
bin/imageMaker.cgi?map=Mars&request=GetCapabilities&version=1.3.0
PIGWAD WMS server, Mars craters:
http://webgis.wr.usgs.gov/wmsconnector/com.esri.wms.Esrimap/Mars_crater_image
PIGWAD WMS server, Mars geology:
http://webgis.wr.usgs.gov/wmsconnector/com.esri.wms.Esrimap/Mars_geolo
gy_image?request=getcapabilities&version=1.1.1&service=WMS
There is a lot of dataset available for downloading. The problem lies with the size
of some of those data.
This is the case of HiRISE images. HiRISE is a camera onboard Mars
Reconnaissance Orbiter. It has a spatial resolution of 0.3 meter per pixel. Red
color images have 20,048 pixels wide (6 km wide for an orbit of 300 km) and
blue-green and near infrared have 4,048 pixels wide (1.2km). HiRISE onboard
computer reads out these lines in time with the orbiter's ground speed, meaning
the images are potentially unlimited in size. However, the computer limits images
to 28Gb. An uncompressed image could have a size of 28Gb, but when they are
transmitted, they are compressed with a typical maximum size of 11.2Gb.
After being processed, those images are available to download on HiRISE
website. Their format is JPEG2000. This format is a wavelet-based image
compression and could be lossless or lossy. Despite the fact that JPEG2000
compresses HiRISE images a lot, they still possess a big memory size. It is not
rare to find on the HiRISE website images that surpass the 1 Gb size.
So, if a developer offers the choice to display images with very large size, like
HiRISE images, he must be sure the size of those files will not affect their own
display and loading time. Some tests were made to find the best way to display
big size images like HiRISE on a WEBGIS. The results will be presented in
section 6.
Project presentation
The goal of this project is to develop a WebGIS prototype. The studied site will
be Mars, more specifically the Phoenix landing site. Some objectives result from
this ultimate goal:
Short-term objectives (6 months):
Develop an architecture that is able to receive a planetary WebGIS.
Test the feasibility of a planetary WebGIS.
Implement basic applications.
Middle-term objectives (1 - 2 years):
Develop functional analog sites and planetary WebGIS.
Put the WebGIS online so the non-scientific public can benefit from it.
Give the CSA scientists a WebGIS tool to display the data they have
collected.
Long-term objectives (2 years and more):
Develop a WPS server, so CSA scientists can do the processing of their
own data.
Make the CSA a leader in analog sites and planetary GIS.
A planetary site was chosen because CSA wanted to address the problem of
planetary projections and coordinate systems. The Phoenix landing site was
chosen as the studied site because it has recently successfully landed on Mars,
and CSA is a part of this Martian mission. Canada's contribution in this space
mission is the development and construction of the meteorological station
onboard Phoenix.
Data used
Here is an exhaustive list of data used and that can be displayed on the
prototype WEBGIS and their source:
Geologic map of the Olympus Mons region, USGS,
http://webgis.wr.usgs.gov/pigwad/down/mars_geology.htm#I-2327
Footprints of HiRISE images, USGS/NASA,
ftp://ftpflag.wr.usgs.gov/dist/pigpen/mars/hirise/footprints
HiRISE image, Arizona State University, PSP_008426_2595_RED, in
JPEG2000 format
Tiles of this HiRISE images (for testing the HiRISE images)
Images of MDIM2.1 (Viking image mosaic), USGS,
http://astrogeology.usgs.gov/Projects/MDIM21/#Download
Mola Hillshade, USGS,
ftp://ftpflag.wr.usgs.gov/dist/pigpen/mars/geology/NPlains_geology_SIM28
88_2005.zip
Graticule 30°x30°, USGS,
ftp://ftpflag.wr.usgs.gov/dist/pigpen/mars/geology/NPlains_geology_SIM28
88_2005.zip
Functionalities
Some functionalities were requested, while some others were simply added by
the initiative of the developer. Here is the list of the functionalities that are
implemented in the WEBGIS:
DEM viewer
Database query system
Database search system
Link to the Phoenix meteorological data
Save the current view in multiple formats
Zoom system
Legend
Reference image
All of those functionalities will be presented in section 7.
Problems
Two major problems need to be addressed:
Projection of celestial objects
Display of large size file, like an HiRISE image
Other minor problems were encountered, but since they were only details
throughout the project, they will not be talked about in this report.
Proposed architecture of the WebGIS
In this section, the proposed architecture will be presented, along with libraries
and OGC specifications used and data format present in the WebGIS.
First of all, all of the software used in this project is open-source. A lot of
advantages derived from this type of software.
For each open-source software, there is a large community that is there to help
users and developers, and to present the added functionalities they developed.
Functionalities can be easily implemented since the source code is free and can
be modified. The only thing is that this specific functionality must be presented to
the community so it can benefit from it.
Another advantage is that most of this software is free of charge, so that one can
download it and begin using it immediately, without paying anything.
So, for this project, the cost of software was 0$. The only thing that costs
something is the rental of a dedicated web server.
Operating system
For this project, all of the software runs under a Linux operating system. It is a
free software. Like any other open-source software, the source code can be
modified, used and redistributed by anyone. It is predominantly known for its use
in servers.
For this project, the CentOS distribution of Linux is used. A Linux distribution
consists of a Linux operating system and a collection of applications. CentOS is
used because it already has installed plug-ins about users management. So, it is
a good Linux distribution for a web server.
Web server
The web server used for this project is an Apache HTTP server. It supports a lot
of features; many implemented as compiled modules, which extend the core
functionality. These can range from server-side programming language support
to authentification scheme.
Apache is primarily used to serve both static and dynamic web pages. Many web
applications are designed expecting the environment and features that Apache
provides.
This Apache server is dedicated, and is rented from iWeb2.
Geospatial database
A geospatial database is a database designed to store, query, and manipulate
geographic data. For this project, the geospatial database used is PostGIS. It is
the geospatial extension of the PostGreSQL object-relational database. The
following schema is a part of a PostGIS table:
Figure 5: Example of a table in PostGIS
2
http://fr.iweb.com/?gclid=CMnHmsjZjZUCFRKLxwody1etfw
In a conventional database, the first eight columns (gid to pshade) are
conventional. They represent attributes while a line is an entry in the database.
For example, in figure 5, a line or a tuple represent a geological polygon, while
columns represent attributes of this polygon. The particularity of a geospatial
database is the declaration of another attribute describing the geometry of the
tuple. In this case, this attribute is called "the_geom.". The geometry could be a
point, a line, a polygon or derived geometries coming from those three.
In a PostGIS table, the geometry attribute is written in hexadecimal, so the
geometry type is not explicit. By using a SQL query, it is possible to see the value
of this attribute in normal text:
select astext(the_geom)
from olympus
where gid = 1
The result of this query will return the value of the_geom from the tuple where gid
is 1, in the Olympus table:
Figure 6: Result from a SQL query
So, the first tuple of Olympus table is a multipolygon. The coordinates can also
be seen.
The projections and spatial reference system of those geometries are saved in
another table in the database.
Cartographic server
For this project, the cartographic server is MapServer. It is an open-source
development environment for building spatially-enabled internet applications,
such as a WebGIS. It can run as a CGI program or via MapScript, which
supports several programming language. The University of Minnesota developed
it for NASA, which needed a way to make its satellite imagery available to the
large public. It supports OGC standards, including WMS and WFS. It works really
well with the PostGIS database.
MapServer is a CGI executable that is placed in the inactive part of a web server.
When a request is sent to MapServer, it uses the information in the HTTP
request (like a WMS request) and the configuration file included (a MapFile) to
render an image of the wanted map. This image can be viewed in a web
browser.
A mapfile is the basic configuration mechanism for MapServer. It defines the
relationship between objects, points Mapserver to where data are located and
defines how things are to be drawn.
Mapfile are built with multiple different objects that need to be declared in order
to configure Mapserver. It possesses a hierarchic organization, based on those
objects within a main object, the MAP object.
The MAP object defines the general map parameters. Here is some frequent
parameters found in the MAP object:
Extent: It is the spatial extent of the map to be created.
ImageType: It is the output image format to be created. The value of this
parameter must match the name of a user defined or internally generated
of an OUTPUTFORMAT object.
Name: It is the prefix attached to the map, scalebar, and legend filenames
created.
Shapepath: It is the path of the directory holding the shapefiles.
Size: Size in pixels of the output image.
Status: It means if the map is active or not.
Units: It is the units of the map coordinates.
Different objects that have their own parameters can be declared in the MAP
object. Here is a list of those objects and their most important parameters:
WEB: It defines how a web interface will operate.
Imagepath: It is the path to the temporary directory for writing temporary files
and images.
ImageURL: It is the URL that will take the web browser to ImagePath to get
the images.
Metadata: It allows arbitrary data to be stored as name value pairs. Example :
METADATA
title "My layer title"
author "Me!"
END
PROJECTION: It defines the coordinate system to display the data. Here are
three different examples of a projection object:
PROJECTION
"+proj=stere +lat_0=90 +x_0=0 +y_0=0 +a=3376200.0 +b=3376200.0 +k=1"
END
PROJECTION
"proj=utm"
"ellps=GRS80"
"datum=NAD83" PROJECTION
"zone=15" "init=epsg:26915"
"units=m" END
"north"
"no_defs"
END
Table 1: Examples of projection declaration in a mapfile
OUTPUTFORMAT: It defines how output image formats are defined.
Name: The name to use in the IMAGETYPE parameter in the MAP object.
Driver: It is the name of the driver to use to generate this output format.
Imagemode: It selects the imagemode in which the output is generated.
o PC256: Pseudocolored result up to 256 colors.
o RGB: Render in 24 bits red/green/blue mode.
o RGBA: Render in 32 bits red/green/blue/alpha mode. The alpha mode
is the transparency.
o BYTE: Render raw 8 bit data.
o INT16: Render raw 16 bits signed pixel values.
o FLOAT32: Render raw 32bit floating point pixel values.
Mimetype: Provide the mime type to be used when returning results over the
web.
Extension: The extension to use when creating files of this format.
Transparent: It indicates if transparency should be allowed for this format.
FormatOption: It provides a format specific options.
REREFENCE: It defines how a reference map should be created.
Color: It is the color in which the reference map box should be.
Extent: It is the spatial extent of the reference map.
Image: It is the image to use for the reference map.
Size: It is the size, in pixels, of the reference map.
LEGEND: It defines how a legend is built.
Position: It is the position of the legend.
SCALEBAR: It defines how a scalebar is built.
Intervals: It is the number of intervals to break the scalebar into.
Position: It is the position of the scalebar.
Size: It is the size, in pixels, of the scalebar.
Units: It is the output of the scale units.
LAYER: It describes layers used to make up a map.
Classitem: It is the item name in the attribute table to use for a class lookups.
This parameter is used with the CLASS object when one wants to work with a
specific value of an attribute.
Data: It is the name of the spatial data to process. It is relative to the
shapepath parameter in the MAP object.
Group: It is the name of the group this layer belongs to. It is used to be able to
turn on and off group layers through the legend.
Metadata: It allows arbitrary data to be stored as name value pairs.
Name: It is the short name of this layer.
o Type: It specifies how the data should be drawn. The possible values
for this parameter are: point, line, polygon, raster, circle, annotation,
query and chart.
o Units: It is the units of the layer.
CLASS: It defines thematic classes for a given layer.
Color: It is the color to use to draw features.
Expression: It is the value to evaluate in the attribute named by the
CLASSITEM object. An example will follow.
Name: It is the name to use in legend for this class.
Outlinecolor: It is the outline color of polygons of this class.
To illustrate the use of the CLASSITEM object and the CLASS object, let's
assume the following is a part of a mapfile:
LAYER
NAME geologie
GROUP Geo_mars2
TYPE polygon
DATA "i-2327_g_dd.shp"
STATUS on
CLASSITEM "uname"
CLASS
NAME 'AHtm'
EXPRESSION "AHtm"
COLOR 22 222 112
OUTLINECOLOR 22 222 112
END
END
This layer is named geologie, and comes from the shapefile i-2327_g_dd. In this
shapefile, there is an attribute called uname. This is the CLASSITEM. A value of
this attribute is Ahtm. This is the EXPRESSION. So, every polygon of this
shapefile that has a value of Ahtm for the attribute uname will have a RGB color
of 22 222 112.
Multiple mapfiles could be created within Mapserver. The user will only specify
which mapfile he wants to use in the HTTP request with the keyword
map=name_of_the_mapfile. The extension of a mapfile is .map.
It is important to know that each mapfile object must be close with the keyword
END.
All mapfiles created for this project are presented in the appendix.
Web Client
The web client chosen for this project is Ka-Map3. Ominiverdi4, a group of Italian
programmers, developed it. A large community is present for this web client. It is
developed in php for the server-side operations and in javascript for the client-
side operations. Its goal is to provide a Javascript API for developing highly
interactive WebGIS interfaces using features available in modern web browsers.
Ka-Map is developed to work with Mapserver. So, if a WEBGIS with a ka-map
client is accessed, it will use the information contained in the appropriate mapfile
to create the map. Mapfiles that a Ka-Map client can use must be declared in the
configuration file of Ka-Map.
Query and search system
There are three useful functionalities specific to Ka-Map. First of all, there are
implemented query and search systems. For the query functionality, when the
user clicks on a geographic feature, it is possible to see information about it in a
predefined box. For the search functionality, there is a text box to enter
keywords. Those keywords will be searched within all geographic features in the
attribute already predefined within the mapfile. There are also some parameters
that need to be determined in order to make the query and search functionalities
work.
METADATA
3
http://ka-map.maptools.org/
4
http://www.ominiverdi.org/
"queryable" "true"
"SEARCHFIELD" "UNAME"
"fields" 'UNAME:Description'
END
For each layer of information the developer wants to be queryable, he must
declare those three metadata parameters in the correspondent LAYER object.
"Queryable" means if this layer is queryable or not. The "fields" parameter is the
name of the attribute in which the query will be made. In this case, the queried
attribute is UNAME, and in the predefined box this attribute name will appear as
'Description'. Also, the "SEARCHFIELD" is the same thing as "fields" but for the
search functionality. It is the attribute that will be searched when a search is
triggered.
Tiles
One of the nicest Ka-Map functionality is the tiling. Since the map is in fact an
image (jpeg, png or gif), the display or the loading can be long. To counter this, it
is possible to create image tiles of the map. A tile is a small part of the image and
all tiles together form the image. Here is a visual example:
Figure 7: Non tiled and tiled images
The left image is non tiled, while the other is tiled. If someone applied a zoom in
on the left image, it will be totally loaded, even if it is not totally seen. For the tiled
image, if the same zoom is applied, only the seen tiled will be loaded. This way,
the load and display time is less long.
The size of the tiles in Ka-Map is 256 pixels by default, but it can be changed.
Nevertheless, it is suggested to leave it like that, because bigger tiles are longer
to load, and there are too much tiles to load if they are too small.
Pre-caching
Another useful functionality is the pre-caching system. It is a script that pre-
generate image tiles for all maps (mapfiles) present in the Ka-Map configuration
file. If tiles have not been created, each time a user goes to visit the WebGIS for
the first time, every tiles must first be created in the temporary folder. So, the
loading and display time is long. But if all maps are pre-cached, the time is less
long.
So, because of those three functionalities, the Ka-Map web client was chosen for
this project.
Librairies
PROJ4
In this project, different libraries were used. The PROJ4 library does the
management of the Earth projections and coordinate systems within Mapserver
and PostGIS. In this library, the EPSG:4326 is defined this way:
+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs
The goal is to describe every parameter of a particular projection or coordinate
system. PROJ4 already contains the definition for EPSG:4326, so it is not
necessary to describe the sphere radius. For a planetary projection or coordinate
system, nothing is implemented, so it is necessary to describe all parameters:
+proj=longlat +a=1737400 +b=1737400 +no_defs
In this example, the spheroid is a sphere with major (+a) and minor (+b) axis of 1
737 400 meters and the coordinate system is in longitude/latitude.
So, it is possible to use PROJ4 for planetary projections or coordinate systems.
GDAL
The Geospatial Data Abstraction Library (GDAL) is a library for raster geospatial
data formats. It is built with various command line utilities for raster translation
and processing. MapServer uses this library to write and read multiple raster
formats.
A list for supported formats can be found here:
http://www.gdal.org/formats_list.html
OGR
The OGR library is part of GDAL. It does the same thing as GDAL, but for vector
datasets. It can read and sometimes write numerous vector file formats. Since its
part of GDAL, it comes with Mapserver.
A list of supported vector file formats can be found here:
http://www.gdal.org/ogr/ogr_formats.html
DIFFERENT FORMATS
In this project, various file formats were used. Here is a list of all of them:
Raster formats:
JPEG2000: It is a lossless or lossy compression, using a wavelet
transformation. The extension is .jp2.
GeoTIFF: It is a public domain metadata standard, which allows
georeferencing information to be embedded within a TIFF file. The
extension is .tif.
GIF: It is an 8-bit per pixel image format and has come into widespread
usage on the World Wide Web due to its portability. In this project, it is
used as the output image format of maps in MapServer.
Vector formats:
Shapefile: It is a geospatial vector format for GIS software. It was
developed by ESRI as an open specification for data interoperability
among GIS software. A shapefile is a collection of files with ".shp" ".shx"
and ".dbf" extensions.
PostGIS data: The vector data is contained within this geospatial
database, as said in section 5.3.
Implemented OGC specifications
Only the WMS specification has been taken into account for this project. That
means that a user will be able to request specific data from this project server,
and will be returned as an image format.
Problems resolution
The definition of planetary projections and coordinate systems
Like it has been said in section 3.2, there are no accepted standards for
planetary projections and coordinate systems. The IAU2000 standard has been
created to define those, but it is not accepted by the OGC yet. Because of that,
GIS developers do not implement the IAU2000 codes. Nonetheless, planetary
projections and coordinate systems can be implemented in the PROJ4 library, as
can be seen in section 5.5.
So, how can one use planetary projections or coordinate systems in a WMS
request? Three solutions will be presented to solve this major problem.
The first solution to counter this problem is to modify the Mapserver code to
make them accept IAU2000 requests. This solution would be the best as a long-
term solution, only if IAU2000 would be accepted by the OGC. Since it is not the
case as of now, no developer is ready to update the Mapserver code.
Also, that solution would also mean updating the PROJ4 library to add the
IAU2000 codes.
Modifying Mapserver and PROJ4 to make them accept IAU2000 codes through
WMS requests is a really big task. So this is not a short-term option since the
OGC has not accepted IAU2000 codes yet.
The second solution would be to define, in the PROJ4 library, new EPSG codes
that would define IAU2000 codes. For example, IAU2000:49900 has these
properties:
GEOGCS["Mars 2000", DATUM["D_Mars_2000",
SPHEROID["Mars_2000_IAU_IAG",
3396190.0, 169.89444722361179]], PRIMEM["Greenwich", 0],
UNIT["Decimal_Degree",
0.0174532925199433]]
It is a Martian coordinate system with the Mars 2000 datum. In PROJ4, we only
have to define a new EPSG code, EPSG:49900, that contains the exact same
parameters as IAU2000:49900. Also, the parameters of this datum need to be
added to PROJ4.
So if a user wants to have a map in the IAU2000:49900 coordinate system, the
SRS parameter in the WMS request would be:
SRS=EPSG:49900
The problem with that solution is that it is not interoperable. Two different
planetary WebGIS could have two different EPSG codes for IAU2000:49900.
Users can become really confused about what EPSG codes to use for each
WebGIS. Also, it doesn't respect the OGC recommendations because the newly
created EPSG codes do not define Earth projections or coordinate systems.
This solution has not been implemented.
The third solution is the one that has been accepted and implemented. Each time
a WMS request is sent to Mapserver, it analyses it, and creates the map
according to the parameters in the request. So, the idea of this solution is to
modify the request before Mapserver can analyze it. If a IAU2000 code is
present, it is important to change it to a EPSG code. For example, this request:
http://67.205.74.208/cgi-bin/mapserv?map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/mars_iau49918.map&request=getMap&SERVICE=WMS&VERSION
=1.1.1&REQUEST=GetMap&BBOX=-165.910000,-6.116460,-
107.344000,55.193900&SRS=IAU2000:49918&WIDTH=608&HEIGHT=637&LAY
ERS=geologie&STYLES=&FORMAT=image/png&TRANSPARENT=TRUE
would become:
http://67.205.74.208/cgi-bin/mapserv?map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/mars_iau49918.map&request=getMap&SERVICE=WMS&VERSION
=1.1.1&REQUEST=GetMap&BBOX=-165.910000,-6.116460,-
107.344000,55.193900&SRS=EPSG:49918&WIDTH=608&HEIGHT=637&LAYE
RS=geologie&STYLES=&FORMAT=image/png&TRANSPARENT=TRUE
This way, Mapserver will receive a WMS request containing an EPSG code
instead of a IAU2000 code.
Usually, a Mapserver script called mapserv receives the WMS request, analyses
it, and produces the map according to the parameters. So, the goal is to write
another script that is called before mapserv, and changes the IAU2000 code to
an EPSG code in the request. After that, the newly created WMS request is sent
to mapserv and the map can be created. For example, let's call this new script
planetserv. This WMS request is sent to it:
http://67.205.74.208/cgi-bin/planetserv?map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/mars_iau49918.map&request=getMap&SERVICE=WMS&VERSION
=1.1.1&REQUEST=GetMap&BBOX=-165.910000,-6.116460,-
107.344000,55.193900&SRS=IAU2000:49918&WIDTH=608&HEIGHT=637&LAY
ERS=geologie&STYLES=&FORMAT=image/png&TRANSPARENT=TRUE
After the IAU2000 has been changed to EPSG in planetserv, the new request is
sent to mapserv:
http://67.205.74.208/cgi-bin/mapserv?map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/mars_iau49918.map&request=getMap&SERVICE=WMS&VERSION
=1.1.1&REQUEST=GetMap&BBOX=-165.910000,-6.116460,-
107.344000,55.193900&SRS=EPSG:49918&WIDTH=608&HEIGHT=637&LAYE
RS=geologie&STYLES=&FORMAT=image/png&TRANSPARENT=TRUE
Also, it is important to define every IAU2000 codes that can be used in the
PROJ4 library.
This solution was chosen over the two others, because of its simplicity.
Management of large size data files
As said in section 3, some planetary raster data are very large. The pixel size of
those images is really small, so there are a lot of them in an image. Also, the
radiometric resolution for those raster data is often bigger than 8 bits/pixel, so the
gigabits mark is often exceeded. In fact, it's not rare to see a HiRISE image (30
cm/pixel) with a size of 2 Gbits, even when compressed.
This size is so big, the loading and display time can really be long. To solve this
problem, two solutions were tested:
Use the JPEG2000 file format
Use tiles of a large raster file
For the first solution, no process is needed. The only thing to do is to add the
JPEG2000 image to the mapfile:
LAYER
NAME test_jp2
DATA PSP_008559_1405_RED.JP2
STATUS off
TYPE raster
END
For the second solution, there are some operations to do beforehand. First of all,
the large raster file format must be tiled. To do this, the GDAL utility
gdal_retile.py is used. It creates tiles for a given image. Some necessary
parameters must be declared in this utility:
-targetDir: It is the directory where the tiles will be created.
-of: It is the output format of the tiles.
-ps: It is the size, in pixels, of the output tiles.
-tileIndex: It is the name of the shapefile created containing the result tiles.
-levels: It is the number of pyramids levels to build.
Three different sizes of tiles were created: 256x256, 512x512 and 1000x1000.
The outpout format selected is GeoTIFF. For each of the sizes, a different
directory was created: tmp_1000 for the 1000x1000 tiles, tmp_512 for the
512_512 tiles and tmp_256 for the 256x256 tile. Also, for each size, 7 different
levels of pyramid were created.
A tileindex can be defined as a shapefile that ties together several dataset into a
single layer. Here is an example of what is a tileindex.
Figure 8: Tileindex shapefile
The image above is a shapefile. Each of the polygons in this shapefile represents
a section (tile) of an image, which is formed with all of those different sections.
The attribute table linked to that shapefile is:
Table 2: Tileindex attribute table
Each row of this attribute table represents a tile in the shapefile. The second
column, IMAGE, indicates the location of the actual tile. So, by using each row
and the second column, it is possible to reconstruct the original image by putting
each tile at the right place.
After the creation of this tileindex, it must be declared in the mapfile.
LAYER
GROUP mdim_mosaik
NAME mdim21
STATUS off
TILEINDEX "mola_mosaik.shp"
TILEITEM "IMAGE"
PROJECTION
"init=epsg:4326"
TYPE raster
END
The TILEINDEX parameter defines the shapefile containing the actual index, and
TILEITEM is that attribute that represents the location of the tiles.
Like this, each time a user does a WMS request of the mdim21 layer, the
TILEINDEX will put together all the tiles to construct the actual image.
It is also possible to use the different levels of pyramid to a particular zoom level.
For example, if the developer wants to associate the last level of the pyramid with
the global view of the map, he needs to declare it in the mapfile:
LAYER
NAME "HiRISE_6_512"
GROUP "tile_hirise"
STATUS off
TYPE RASTER
TILEINDEX "tileHirise6.shp"
TILEITEM "location"
MINSCALE 1000001
MAXSCALE 40000001
END
When it is declared like that, the "HiRISE_6_512" layer, represented by the
"tileHirise6.shp" tileindex, will only be seen between 1:40 000 001 and 1:1 000
001 scales. The developers must be sure that every possible scale level is
declared in the mapfile. If it is not the case, there could be no image appearing at
that particular zoom level.
Now, for the actual test of the loading and display time of a JPEG2000 file format
and GeoTIFF tiles of 256, 512 and 1000 pixels, a python script was created.
This script creates different threads accessing the JPEG2000 or the tiles, and
calculates the loading and display time. In other words, it creates a number of
virtual users accessing those images at the same time, at a different zoom level,
and calculates the loading and display time.
The controlled variable for the test were the number of users accessing the
images, and the zoom level. The output of the script is the average loading and
display time of the images for all the users. Here are the results of the test:
Jpeg 2000
70
60
50
40
time (s)
30
20
10
0
8 50
7 12
6 11
5 10
9
4 8
3 7
zoom levels 2 6
5 number of users
1 4
0 3
2
1
Zoom levels 0 1 2 3 4 5 6 7 8
Chart 1: Jpeg2000 display and loading time
Tif 1000
100
90
80
70
60
50 tim e (s)
40
30
20
10
050
11
8 9
6 7
4 5
num ber of users
2 3
zoom levels
0 1
Zoom levels 0 1 2 3 4 5 6 7 8
Chart 2: 1000 x 1000 tiles display and loading time
Tif 512
100
90
80
70
60
time (s) 50
40
30 50
20 10
10
7
0 number of users
8 4
7
6
5 4
3 1
zoom levels 2
1
0
Zoom levels 0 1 2 3 4 5 6 7 8
Chart 3: 512 x 512 tiles display and loading time
zoom
user Data 0 1 2 3 4 5 6 7 8
1
time_jpeg2000 1.072 2.593 6.288 16.904 10.924 13.027 14.4409 9.684 7.0199
time_tif_1000 2.552 32.646 12.256 5.768 1.832 3.625 3.704 5.138 0.82
time_tif_512 23.382 73.052 21.439 7.811 8.651 4.065 4.445 4.154 2.642
2
time_jpeg2000 2.518 8.702 16.708 18.921 13.544 18.631 16.959 10.278 10.409
time_tif_1000 9.168 34.037 9.683 3.034 3.274 3.61 9.177 7.445 3.86
time_tif_512 38.348 84.163 39.279 11.255 3.86 8.121 6.994 4.916 4.331
3
time_jpeg2000 2.574 6.065 11.442 23.172 17.778 19.75 15.906 16.153 11.716
time_tif_1000 14.407 31.824 12.01 12.934 5.611 9.129 5.307 7.13 3.675
time_tif_512 52.26 136.635 51.128 16.92 13.168 9.456 9.333 6.812 5.628
4
time_jpeg2000 3.4172 9.214 17.092 22.917 22.366 18.744 16.313 13.086 12.342
time_tif_1000 10.131 21.319 10.893 5.455 4.386 5.282 4.614 3.29 2.04
time_tif_512 56.476 209.837 60.893 15.601 12.319 10.404 4.807 2.911 3.304
5
time_jpeg2000 5.956 9.767 19.283 27.783 32.941 24.224 19.852 15.079 14.418
time_tif_1000 10.56 26.867 18.271 9.457 6.184 13.495 4.704 4.798 4.708
time_tif_512 72.943 220.903 83.968 21.101 10.482 7.35 3.961 4.708 3.456
6
time_jpeg2000 4.254 7.405 18.611 22.346 19.343 20.397 20.04 18.065 11.567
time_tif_1000 27.539 59.84 24.241 8.253 12.659 9.446 6.921 5.816 3.713
time_tif_512 85.822 299.373 87.833 31.588 17.391 12.799 6.128 5.49 2.994
7
time_jpeg2000 4.573 10.842 15.786 21.034 23.201 21.314 23.098 17.828 18.509
time_tif_1000 12.396 43.285 14.685 13.79 10.317 10.973 8.955 7.113 5.908
time_tif_512 76.563 300 107.265 22.137 15.205 12.111 8.308 10.373 6.782
8
time_jpeg2000 4.688 9 15.673 26.687 24.147 24.782 18.629 15.645 14.066
time_tif_1000 14.75 50.373 27.03 18.894 15.593 16.438 13.935 8.481 5.799
time_tif_512 79.399 300 119.006 28.46 13.592 9.311 8.028 5.515 4.27
9
time_jpeg2000 5.372 7.99 10.418 12.385 11.707 11.245 12.742 7.105 7.07
time_tif_1000 13.434 42.511 25.646 20.909 18.021 15.066 16.71 12.18 7.724
time_tif_512 74.872 300 142.467 41.172 23.738 16.027 13.13 10.694 6.48
10
time_jpeg2000 3.07 6.06 9.01 16.614 14.697 16.977 11.269 11.857 7.819
time_tif_1000 17.363 58.182 31.331 27.013 25.753 20.259 16.671 10.804 9.795
time_tif_512 101.841 300 151.208 39.095 13.959 11.416 11.935 6.464 5.017
11
time_jpeg2000 2.672 6.289 11.687 20.313 17.264 17.016 16.65 6.438 10.729
time_tif_1000 19.088 48.459 34.478 23.768 18.101 26.82 23.071 15.738 13.324
time_tif_512 101.182 300 148.886 43.817 14.921 10.471 13.066 8.607 12.372
12
time_jpeg2000 3.728 8.219 15.734 22.119 20.057 21.216 26.773 14.083 13.746
time_tif_1000 59.012 153.419 40.512 18.102 21.292 22.957 21.689 18.322 10.949
time_tif_512 111.873 300 190.358 49.198 29.867 21.13 16.432 13.291 9.728
50
time_jpeg2000 11.376 23.55 44.946 63.988 62.582 61.066 60.753 39.903 35.241
time_tif_1000 60.37 286.931 77.292 37.855 42.602 43.434 42.607 32.192 23.366
time_tif_512 300 300 300 300 223.586 54.654 52.422 41.9 28.444
Table 3: Loading and display time result
All images used for the test can be seen in the appendix.
This test was conducted to see which image format was the fastest in term of
display and loading time, depending on a zoom level and a number of users.
As it is possible to see in the charts and the table, the JPEG2000 format is the
fastest for the first three (0 to 2) zoom levels, for any number of users. Since the
first three levels of zoom are global view of the image, the tiled images (512 or
1000) need to load every tile or a really large amount of tiles. This is why it is so
long for them for the first three zoom levels. So, 1000x1000 and 512x512 tiles
are not an option for global views of a large size image.
For the rest of the zoom levels, the 1000x1000 tiles seem to be the fastest
option. For example, if 50 users wanted to access the JPEG2000 image at a
zoom level of 8 (very precise), it would take 35 second, while the 1000 x 1000
tiles would take 23 seconds. The 512x512 tiles are also a good solution for the
last 4 zoom levels. Those zoom levels are very precise, so not a lot of 1000 x
1000 or 512 x 512 tiles need to be loaded. So, the loading time is reduced.
The 512 x 512 tiles is not a solution for a low zoom level (0 to 5). There are too
many tiles to load, so the time is really long. It would discourage any users
attempting to see the images.
The amount of users influences the loading time. If the amount of users is high,
the time will be long, and vice-versa.
The 256 x 256 tiles were not used because the loading time was really too long.
To display a large size file image, the following solution would be the best
according to the previous result:
Zoom level 0: JPEG2000
Zoom level 1: JPEG2000
Zoom level 2: JPEG2000
Zoom level 3: 1000 x 1000 tiles
Zoom level 4: 1000 x 1000 tiles
Zoom level 5: 1000 x 1000 or 512 x 512 tiles
Zoom level 6: 1000 x 1000 or 512 x 512 tiles
Zoom level 7: 1000 x 1000 or 512 x 512 tiles
Zoom level 8: 1000 x 1000 or 512 x 512 tiles
Martian WebGIS presentation
This section will be, at the same time, a visual presentation of the WebGIS and a
tutorial.
The front page of the Martian WebGIS looks like
this:
Figure 9: WebGIS interface
There are four distinct sections:
1. The first section, surrounded by a red rectangle, is the control section.
This is where the user can zoom and pan the map, save the map in a
wanted output format, query and search the map and choose the actual
map.
2. The second section, surrounded by a green rectangle, is the keymap
reference. The little rectangle inside represents the actual extent of the
map.
3. The third section, surrounded by a blue rectangle, is the search and query
results. Each time a user does a query or a search, the results can be
found there.
4. The fourth section, surrounded by a brown rectangle, is the legend and
the scale of the map.
5. The actual map is in the background. Right now, the only layer seen is the
HiRISE footprints. Other layers will be presented throughout this tutorial.
Toolbar
First of all, the first section could be called the tools section. Without it, it would
be impossible to navigate the map.
Figure 10: Toolbar
This section can be divided in 11 parts:
1. With this dropdown menu box, the user can choose between several maps. In
this case, the map currently selected is Mars.
2. With this button, it is possible to query a layer. The results will be returned in
search and query box.
For example, if a user queries this particular polygon (the one surrounded by a
green line), which is part of the layer of the geology of Mons Olympus:
Figure 11: Queried polygon and result
The result of the query will appear in the box search and query result. In this
case, this polygon represents a region where HAL geology is present. The button
with the magnifying lens in the search result box allows a zoom to the specified
feature.
3. This button allows the user to pan the map in any direction.
Figure 12: Before the pan
As it is possible to see, only a part of the Mons Olympus can be seen. But after
panning the map, all of the Mons Olympus geology is seen:
Figure 13: After the pan
So, the pan is a movement of the map, without zooming it.
4. The print button lets the user saves the actual map into a specified output
format. When it is clicked, this window appears:
Figure 14: Output format choice window
The user has to choose between those five output formats to save the present
view of the map.
5. This lens is used to zoom out. If a user wants to zoom out of this view:
Figure 15: Before the zoom out
The resulting view would be this:
Figure 16: After the zoom out
6. Those rectangular buttons are intermediate zoom levels. A little button means
a global view, while a bigger button means a more precise view. Those zoom
levels are already defined in the Ka-Map configuration file.
7. This lens is used to zoom in. If a user wants to zoom in this view:
Figure 17: Before the zoom in
The resulting view will be:
Figure 18: After the zoom in
8. This button represents a rubber zoom. The users defines a rectangle:
Figure 19: Before the rubber zoom
and the zoom in will be applied on it:
Figure 20: After the rubber zoom
9. When this button is clicked, it brings back the global centered view. If this is
the actual view:
Figure 21: Before the global view
and the button is clicked:
Figure 22: Global view
10. The link to this view button creates a link to a particular view. For example,
the default link to the WebGIS is: http://67.205.74.208/~mphaneuf/gis/ka-
map/htdocs/index_overlay.html. If someone wants to have a link to this
particular view:
Figure 23: Link to this view
He clicks the link to this view button, and a new URL address will be in the
address bar: http://67.205.74.208/~mphaneuf/gis/ka-
map/htdocs/index_overlay.html?map=Mars&cps=-
136.12670182902474,31.311284398315124,7500000&layers=Geo_mars2,Hirise
2.
11. The search text zone and button lets a user search the searchable layers, by
entering keywords. For example, if a user enters 'olympus' as a keyword, the
result of the search will appear in the search result box:
Figure 24: Result of the search 'olympus'
It is possible to zoom to a specified feature by clicking the zoom to button in this
box.
Keymap reference
For the second section, which is the keymap reference, it is possible to move the
little red rectangle inside of it to pan the map. For example, here is the global
centered view, with the little red rectangle in the middle of the keymap reference:
Figure 25: Keymap reference before zoom
When this rectangle is moved, the map view also moves, and also changes
shape depending of the zoom level:
Figure 26: Keymap reference after zoom
The third section, which is the search and query result box, has already been
explained in XXX and XXX.
Legend
Finally, the fourth section is the scalebar and the legend.
Figure 27: Legend and scalebar
In the legend, checkboxes are present. When checked, the corresponding layer
will be on, and vice-versa. For example, if the Geo_mars2 (Olympus geology)
checkbox is unchecked, this layer will not appear in the map. If checked, it will
appear.
Also, a light and a dark button appear alongside each other. The light button
decreases the corresponding layer opacity, while the dark one increases it. Here
is an example of a translucent layer versus a darker one:
Figure 28: Translucent layer
Figure 29: Dark layer
The plus button is to make the symbology of a layer appear. Here is the
symbology of the Olympus geology:
Figure 30: Symbology of Olympus geology
When the same button is clicked again, the symbology disappears.
Finally, the little up and down arrow is to change the order of the layers. When as
up arrow is clicked, the corresponding layer goes up a level. If it is the case, this
particular layer will appear above all layers that are below it in the order. For
example, before the up arrow of the geology layer is clicked, the HiRISE
footprints are at a higher level in the order, so they appear above the geology:
Figure 31: Layers level
But, if the HiRISE footprints goes down a level:
Figure 32: Layers level
The footprints are not visible, even though this layer is turned on. This is because
the geology is at a higher level.
Added functionalities
Two other functionalities were added in the WebGIS:
DEM viewer
Website with Phoenix climatic data
DEM viewer
A DEM viewer was added to the WebGIS. With it, it is possible to see the 3D
representation of the relief. It was developed with different options as a Java
applet:
Rotate the orbit of the DEM
Rotate the XY plane
Change the scale of the DEM
Move the DEM
Get the height of a pixel
As of now, only a DEM of a Mars mountain can be seen. Others could be added
to the list of viewable DEMs from Mars.
Here is an example of the DEM viewer, with the height of a pixel:
Figure 33: DEM viewer
Phoenix Website
This functionality works as a hyperlink in the WebGIS, that redirects the user to
the Phoenix climatic data website.
Figure 34: Phoenix climatic website boxes
If the mouse cursor passes over the red dot labeled "Climatic data from Phoenix"
in this black rectangle:
Figure 35: XML overlay button
A box with a link to the Phoenix climatic data website will automatically appear,
just under the keymap reference:
Figure 36: Hyperlink to Phoenix climatic data website
The labeled red dot actually comes from a XML file. In Ka-Map, it is possible to
make appear on the map a XML file containing an ID, coordinates and a label.
This file must look like these:
<?php
header("Content-Type: text/xml");
header("Cache-Control: no-store, no-cache, must-revalidate");
echo '<?xml version="1.0" encoding="UTF-8"?>'
?>
<overlay>
<point x="-124.5" y="68.5" id="climate info" collision='true'
col_radius='16'>
<label>Climatic data from Phoenix</label>
<symbol shape="bullet" size="10" opacity="1" color="#FF0000" />
</point>
</overlay>
Since the file is a .php format, the first section is necessary. It declares that the
second section will be XML language. This second section is the declaration of
the labeled red dot on the map. In the point bracket, three parameters are
important: the X and Y are the coordinates, while id is the identifier of this point.
The content of the label bracket is that text that appears on the map. The symbol
bracket defines the style of the feature that will appear on the map. In this case, it
is a red bullet of size 10.
Finally, this file needs to be declared in the Ka-Map code so that it can appear in
the map. The advantage of using a XML file instead of creating a layer in the
mapfile is that it can be easily modified and it can lead to a hyperlink, like in this
project.
The labeled red dot will always appear in this position, because it is the landing
site of Phoenix.
When the hyperlink is clicked, the website will appear:
Figure 37: Phoenix climatic data website
The center image is the landing site of Phoenix. It has been downloaded from the
University of Arizona HiRISE website. The red arrow represents the wind
direction. As of now, it only points in that direction, since no solution was found to
make it point the right wind direction. On the top right, a dropdown menu offers
the choice to choose the day from which a user wants to know the climatic data.
Figure 38: Day selection
When the user selects a day, he has to click to make the climatic data appear at
the bottom of the website, in this table:
Figure 39: Empty table
If, for example, the user chooses to see the day 1 data, here is what the table
would look like:
Figure 40: Full table
To make all of this work, a PHP code was written. It connects to the PostGIS
database, and fetch all the climatic data associated with the day selected by the
user. The code is available in the appendix.
Recommendations
Here is a short list of recommendations to upgrade the WebGIS and to make the
CSA a leader in this domain:
Create a team of experts in geomatics and IT to implement a geomatics
structure in CSA. This way, every CSA scientist will be able to make use
of all the collected data. This structure should be developed with open-
source software.
Implement other OGC specifications, such as WFS, WCS and WPS.
Develop a specialization in analog sites WebGIS, since a lot of CSA
scientists works are based on those places.
Promote the use of geomatics via their WebGIS and advertising on their
website.
Develop an international cooperation with other space agencies in the field
of geomatics. Every space agencies should learn from the forces of the
others.
With those recommendations, CSA could become a real leader in the field of
geomatics.
Conclusion
This project is a good example of the potential of a GIS structure in a space
agency. Even though only a prototype has been developed up to this point, some
functionalities are useful for scientists or general users: the query and search
system, the user-friendly interface, the DEM viewer and the Phoenix climatic data
website.
Also, like it has been demonstrated in the text, it is possible to use planetary
projections or coordinate systems in a WebGIS. The best format to use for large
size file has also been resolved. So, those two situations are no longer problems
to the development of a WebGIS.
Finally, developing such a structure is no longer a financial problem: all software
used during the course of this project are open-source. So, the development cost
of a GIS structure for an institution such as the CSA would only be a small
percentage of all the advantages it would bring to the scientists and the
community.
Appendix X: Images use for the test
Zoom 0
Zoom 1
Zoom 2
Zoom 3
Zoom 4
Zoom 5
Zoom 6
Zoom 7
Zoom 8
Appendix X: Script of the Phoenix climatic data website
<?php
// Connecting, selecting database
$dbconn = pg_connect("host=localhost dbname=meteo_mars user=mphaneuf password=spacegis")
//connecte a la bd
or die('Could not connect: ' . pg_last_error());
$test=$_GET["jour"]; //va chercher la valeur soumise par le form plus bas
$results = pg_exec($dbconn, " SELECT * FROM meteo"); //execute la requete (si requete
trop complexe, creer des vues
$sol = pg_exec($dbconn, "SELECT id_meteo FROM meteo");
$row = pg_fetch_all_columns($sol);
//fonction pour obtenir la bonne journee -- verifie si le jour entrer par user = un jour
ID, si oui retourne info de cette journee
if ($test != false) {
for ($tr=0; $tr < pg_numrows($sol); $tr++) {
$str = strcmp($test,$row[$tr]);
if ($str == 0) {
$id_jour = $tr;
}
}
}
if ($test != false) { //si $test a été soumis alors effectue la recherche des variables
ci-dessous pour toute la table, selon le id_jour selectionne
for ($lt = 0; $lt < pg_numrows($results); $lt++) {
$jour = pg_result($results, $id_jour, 0);
$temp_max = pg_result($results, $id_jour, 1);
$wind = pg_result($results, $id_jour, 2);
$pres = pg_result($results, $id_jour, 3);
$temp_min = pg_result($results, $id_jour, 4);
$w_direct = pg_result($results, $id_jour, 5);
$visib = pg_result($results, $id_jour, 6);
$descr = pg_result($results, $id_jour, 7);
}
}
?>
<html>
<head>
<title>Climatic report, sol <?=$test?>, Mars</title>
<style type="text/css">
img.vent {position:absolute; bottom:50%; left:50%;z-index:6}
img.phoenix {position:relative;z-index:5; left:6%; border: medium
double #336600}
body{background-color: #669966}
div.image {position:absolute;top:7%;left:5%}
table.table {position:relative; left:22%; background-color:#336600}
div.legend{position:absolute;z-index:7; top:7%}
div.hyperlinks{position:absolute; top:7%; right:1%}
table.meteo{background-color: #336600}
#tr_meteo{background-color: #669933; color:#FFFFCC}
#tr_meteo1{background-color: #339900; color:#FFFFCC}
#h{color:#FFFFCC}
form.day_select{position:absolute; top:2%; left:70%}
#mysubmit { background-color: #669933; font-size: 75%; padding:
10px; font-weight: bold; }
</style>
</head>
<body>
<h1 id='h'>Climatic data from Phoenix : Sol <?=$test?></h1>
<form class = "day_select"> <!-- le form sert a soumettre a la page la
bonne journée -->
<input id="mysubmit" type="submit" value="Select the day you
want:"></input>
<select name="jour">
<?
for ($lt = 0; $lt < pg_numrows($results); $lt++) { //pour toutes
les colonnes
$id = pg_result($results, $lt, 0); //va chercher tous les
id(journee) disponibles
?>
<option value=<?=$id?>>Sol <?=$id?></option> <!-- tous les
options ont la meme value, qui sera retorune lors que le input plus haut sera appuye -->
<?
}
?>
</select>
</form>
<div class='hyperlinks'>
<p>
<a href='http://www.space.gc.ca/asc/index.html'.>
<img class ='csa' border= "0" alt= "Return to CSA
website" width="75" height="75" src="http://67.205.74.208/~mphaneuf/gis/ka-
map/htdocs/XMLOverlay/csalogo.png">
</a>
</p>
<p>
<a href='http://67.205.74.208/'>Return to <br> the CSA
WebGIS</a>
</p>
</div>
<div class='image'>
<p>
<img class ='phoenix'
src="http://67.205.74.208/~mphaneuf/cgi-bin/images_mars/phoenix_land.jpg"
width="1000" height="800">
</p>
<p>
<img class='vent'
src="http://67.205.74.208/~mphaneuf/gis/ka-map/htdocs/XMLOverlay/fleche_vent.png"
width="30" height="100">
</p>
<table bordercolor = '#336633' class='table' border="3">
<tr id="tr_meteo">
<th>Sol</th>
<th>Wind Speed</th>
<th>Wind Direction</th>
<th>Min Temp.</th>
<th>Max Temp.</th>
<th>Pressure</th>
<th>Visibility</th>
<th>Description</th>
</tr>
<tr id="tr_meteo1">
<td id='td'><?=$jour?></td>
<td id='td'><?=$wind?> km/h</td>
<td id='td'><?=$w_direct?></td>
<td id='td'><?=$temp_min?>°C</td>
<td id='td'><?=$temp_max?>°C</td>
<td id='td'><?=$pres?> millibars</td>
<td id='td'><?=$visib?></td>
<td id='td'><?=$descr?></td>
</tr>
</table>
</div>
<div class='legend'>
<table bordercolor = '#336633' class='meteo' border='1'>
<tr id="tr_meteo">
<th>Legend</th>
</tr>
<tr id='tr_meteo1'>
<td><img class='imglegend' src
="http://67.205.74.208/~mphaneuf/gis/ka-map/htdocs/XMLOverlay/fleche_vent_legend.gif"
align="middle" width="100" height="160"> </td>
</tr>
</div>
</body>
</html>
Appendix X: Python script for testing the loading and display time
# Test program for time access of high scale images (HIRISE)
# Jul 22 2008
# Mickael Germain - Maxime Phaneuf
from URLThread import ImURLThread
import threading
import time
from PIL import Image
import cStringIO
import urllib
#dictionnary definition
jpeg2000 = { "zoom0": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/usr/local/apache/htdocs/test_time/test_jp2.map&mapext=-
6144201.5+-2339088.25+-6110645+-2305531.75&mapsize=600+600&layers=test_jp2",
"zoom1": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/usr/local/apache/htdocs/test_time/test_jp2.map&mapext=-
6135616.301961603+-2331063.260642738+-6118838.051961603+-
2314285.010642738&mapsize=600+600&layers=test_jp2",
"zoom2": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/usr/local/apache/htdocs/test_time/test_jp2.map&mapext=-
6131267.682074291+-2327106.7868322204+-6122878.557074291+-
2318717.6618322204&mapsize=600+600&layers=test_jp2",
"zoom3": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/usr/local/apache/htdocs/test_time/test_jp2.map&mapext=-
6129149.392998748+-2325072.529058848+-6124954.830498748+-
2320877.966558848&mapsize=600+600&layers=test_jp2",
"zoom4": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/usr/local/apache/htdocs/test_time/test_jp2.map&mapext=-
6128069.240635434+-2324069.40538919+-6125971.959385434+-
2321972.12413919&mapsize=600+600&layers=test_jp2",
"zoom5": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/usr/local/apache/htdocs/test_time/test_jp2.map&mapext=-
6127529.1644537775+-2323571.3448586185+-6126480.5238287775+-
2322522.7042336185&mapsize=600+600&layers=test_jp2",
"zoom6": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/usr/local/apache/htdocs/test_time/test_jp2.map&mapext=-
6127262.627667206+-2323320.563941204+-6126738.307354706+-
2322796.243628704&mapsize=600+600&layers=test_jp2",
"zoom7": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/usr/local/apache/htdocs/test_time/test_jp2.map&mapext=-
6127127.608621792+-2323194.2981564323+-6126865.448465542+-
2322932.1380001823&mapsize=600+600&layers=test_jp2",
"zoom8": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/usr/local/apache/htdocs/test_time/test_jp2.map&mapext=-
6127100.392336206+-2323171.4585011676+-6126888.725783839+-
2322959.791948801&mapsize=600+600&layers=test_jp2"}
tif_1000 = { "zoom0": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/1000_tif.map&mapext=53.2675+-39.535+53.832499999999996+-
38.97&mapsize=600+600&layers=test_jp2",
"zoom1": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/1000_tif.map&mapext=53.41299457429048+-39.3989378130217+53.69549457429048+-
39.116437813021705&mapsize=600+600&layers=test_jp2",
"zoom2": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/1000_tif.map&mapext=53.485270242070115+-
39.33090671953256+53.626520242070114+-39.18965671953256&mapsize=600+600&layers=test_jp2",
"zoom3": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/1000_tif.map&mapext=53.521408075959926+-
39.296419553422375+53.59203307595993+-39.22579455342237&mapsize=600+600&layers=test_jp2",
"zoom4": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/1000_tif.map&mapext=53.53947699290484+-39.27929387520869+53.57478949290484+-
39.24398137520868&mapsize=600+600&layers=test_jp2",
"zoom5": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/1000_tif.map&mapext=53.548511451377294+-
39.27073103610184+53.566167701377296+-39.25307478610184&mapsize=600+600&layers=test_jp2",
"zoom6": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/1000_tif.map&mapext=53.55302868061352+-
39.266449616548414+53.561856805613516+-
39.25762149154842&mapsize=600+600&layers=test_jp2",
"zoom7": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/1000_tif.map&mapext=53.55525781902128+-39.26429416866653+53.55967188152128+-
39.25988010616653&mapsize=600+600&layers=test_jp2",
"zoom8": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/1000_tif.map&mapext=53.556298011007925+-
39.26332029815317+53.55869801100792+-
39.260920298153174&mapsize=600+600&layers=test_jp2",}
tif_512 = { "zoom0": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/512_tif.map&mapext=53.2675+-39.535+53.832499999999996+-
38.97&mapsize=600+600&layers=test_jp2",
"zoom1": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/512_tif.map&mapext=53.41299457429048+-39.3989378130217+53.69549457429048+-
39.116437813021705&mapsize=600+600&layers=test_jp2",
"zoom2": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/512_tif.map&mapext=53.485270242070115+-
39.33090671953256+53.626520242070114+-39.18965671953256&mapsize=600+600&layers=test_jp2",
"zoom3": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/512_tif.map&mapext=53.521408075959926+-
39.296419553422375+53.59203307595993+-39.22579455342237&mapsize=600+600&layers=test_jp2",
"zoom4": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/512_tif.map&mapext=53.53947699290484+-39.27929387520869+53.57478949290484+-
39.24398137520868&mapsize=600+600&layers=test_jp2",
"zoom5": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/512_tif.map&mapext=53.548511451377294+-
39.27073103610184+53.566167701377296+-39.25307478610184&mapsize=600+600&layers=test_jp2",
"zoom6": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/512_tif.map&mapext=53.55302868061352+-
39.266449616548414+53.561856805613516+-
39.25762149154842&mapsize=600+600&layers=test_jp2",
"zoom7": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/512_tif.map&mapext=53.55525781902128+-39.26429416866653+53.55967188152128+-
39.25988010616653&mapsize=600+600&layers=test_jp2",
"zoom8": "http://67.205.74.208/cgi-
bin/fwmapserv?mode=map&map=/home/mphaneuf/public_html/cgi-
bin/mapfiles/512_tif.map&mapext=53.556298011007925+-39.26332029815317+53.55869801100792+-
39.260920298153174&mapsize=600+600&layers=test_jp2",}
#main program
allTimeValue = list()
def main():
nbUser = raw_input( "Number of users :\n" )
nbUser = int(nbUser)
numZoom = raw_input( "Zoom level (0, 1 , 2, 3, 4, 5, 6, 7, 8):\n")
numZoom = int(numZoom)
#threadName = raw_input( "jpeg2000, tif_1000 or tif_512 \n")
for i in range(1,nbUser+1):
exec("user%d = ImURLThread( 'client:%d', jpeg2000['zoom%d'], 'im_client%d.gif',
%d, %d)"%(i,i,numZoom,i,nbUser,i))
for i in range(1,nbUser+1):
exec("user%d.start()"%i)
class ImURLThread( threading.Thread ):
"""Subclasss of threading.Thread"""
def __init__( self, threadName, link, fileName, nbUser, currentUser):
"""Initialize thread, set sleep time, print data"""
threading.Thread.__init__( self, name = threadName )
self.threadName = threadName
self.link = link
self.fileName = fileName
self.nbUser = nbUser
self.currentUser = currentUser
self.timeValue = 0
self.allTimeValue = allTimeValue
print "Name: %s;" % ( self.getName())
def run( self ):
print "%s started"%self.threadName
tic = time.time()
file = urllib.urlopen(self.link)
im = cStringIO.StringIO(file.read()) # constructs a StringIO holding the image
img = Image.open(im)
tac = time.time()
#img.save(self.fileName)
self.timeValue = tac-tic
self.allTimeValue = allTimeValue.append(self.timeValue)
print allTimeValue
self.average = float(sum(allTimeValue)) / len(allTimeValue)
print "La moyenne est: %s"% (self.average)
#print "Time %s : %f"%(self.threadName,tac-tic)
del img
print "Operation %s End \n"%(self.threadName)
main()
Appendix X: Mapfiles
Mars Map
#
# Start of map file
#
# $Id: gmap75.map,v 1.24 2004/03/02 00:30:03 fredrock Exp $
#
MAP
NAME MARS_v1
STATUS on
SIZE 1000 800 #a ne pas mettre en commentaire pour faire fonctionner légende
IMAGETYPE gif
SYMBOLSET "/home/mphaneuf/public_html/gis/fusion/gmap-ms46/etc/symbols.sym"
EXTENT -180 -90 180 90
UNITS dd
SHAPEPATH "/home/mphaneuf/public_html/cgi-bin/shapefiles/"
IMAGECOLOR 255 255 255
FONTSET "/home/mphaneuf/public_html/cgi-bin/etc/fonts.txt"
#
# Start of web interface definition
#
WEB
#MINSCALE 10000
#MAXSCALE 50000000
#
# On Windows systems, /tmp and /tmp/ms_tmp/ should be created at the root
# of the drive where the .MAP file resides.
#
IMAGEPATH "/usr/local/apache/htdocs/ka-map/htdocs/tmp/"
IMAGEURL "/ka-map/tmp/"
METADATA
"version" "1.1.1"
"max_extents" "-180 -90 180 90"
"wms_title" "ASC Mars Server" ##required
"wms_onlineresource" "http://67.205.74.208/cgi-
bin/mapserv?map=/home/mphaneuf/public_html/cgi-bin/mapfiles/mars_v1.map&" ##required
"wms_srs" "EPSG:4326" ##recommended
END
# LOG "/tmp/kacache/Mars_log.log"
END
OUTPUTFORMAT
NAME jpeg
DRIVER "GD/JPEG"
MIMETYPE "image/jpeg"
IMAGEMODE RGB
EXTENSION "jpeg"
#TRANSPARENT on
FORMATOPTION "quality=100"
END
#OUTPUTFORMAT
#NAME png24
#DRIVER "GD/PNG"
#MIMETYPE "image/png"
#IMAGEMODE rgba
#EXTENSION "png"
#TRANSPARENT on
#FORMATOPTION "TRANSPARENT=ON"
#END
#OUTPUTFORMAT
#NAME png
#DRIVER "GD/PNG"
#MIMETYPE "image/png"
#IMAGEMODE rgba
#EXTENSION "png"
#TRANSPARENT on
#FORMATOPTION "TRANSPARENT=ON"
#END
OUTPUTFORMAT
NAME gif
DRIVER "GD/GIF"
MIMETYPE "image/gif"
IMAGEMODE PC256
EXTENSION "gif"
FORMATOPTION "TRANSPARENT=ON"
END
OUTPUTFORMAT
NAME gtiff
DRIVER "GDAL/GTiff"
MIMETYPE "image/tiff"
IMAGEMODE rgba
EXTENSION "tif"
FORMATOPTION "TRANSPARENT=ON"
END
PROJECTION
"init=epsg:4326"
END
REFERENCE
IMAGE /home/mphaneuf/public_html/gis/fusion/gmap-
ms46/htdocs/images/Mars_general_image.gif
EXTENT -180 -90 180 90
STATUS ON
COLOR -1 -1 -1
OUTLINECOLOR 255 0 0
SIZE 120 90
END
LEGEND
TRANSPARENT true
END
SCALEBAR
TRANSPARENT true
END
#LAYER
#GROUP tile
#NAME MDIM
#STATUS OFF
#CONNECTIONTYPE OGR
#TILEINDEX "mdim21_footprint.shp"
#TILEITEM "IMAGE"
#TYPE raster
#END
LAYER
GROUP Mosaik
NAME img_fond
TYPE raster
DATA Mars_Color_MDIM_1
STATUS off
CONNECTION
"http://webgis.wr.usgs.gov/wmsconnector/com.esri.wms.Esrimap/Mars_general_image?"
CONNECTIONTYPE wms
PROJECTION
"init=epsg:4326"
END
METADATA
"DESCRIPTION" "mars"
"tile_source" "auto"
"redraw_interval" "60"
"refresh_interval" "10"
"wms_srs" "EPSG:4326"
"wms_name" "Mars_Color_MDIM_1"
"wms_onlineresource"
"http://webgis.wr.usgs.gov/wmsconnector/com.esri.wms.Esrimap/Mars_general_image?"
"wms_format" "image/gif"
"wms_server_version" "1.1.1"
"wms_style" "visual"
"wms_group_title" "Mosaik"
"wms_title" "img_fond"
END
END
LAYER
GROUP mdim_mosaik
NAME mdim21
STATUS off
TILEINDEX "mola_mosaik.shp"
TILEITEM "IMAGE"
PROJECTION
"init=epsg:4326"
END
METADATA
"imageformat" "gif"
"wms_title" "ASC Mars Server"
"tranparent" "on"
"tilesource" "auto"
"wms_group_title" "test"
"wms_srs" "epsg:4326"
END
TYPE raster
END
LAYER
NAME geologie
GROUP Geo_mars2
#CONNECTIONTYPE postgis
#CONNECTION "user=mphaneuf password=spacegis dbname=geologie host=localhost"
TYPE polygon
#DATA "the_geom from olympus"
DATA "i-2327_g_dd.shp"
STATUS on
CLASSITEM "uname"
TEMPLATE "ttt.html"
#PROJECTION
#"init=epsg:4326"
#END
METADATA
"queryable" "true"
"SEARCHFIELD" "UNAME"
"fields" 'UNAME:Description'
"tranparent" "on"
"tile_source" "auto"
"wms_title" "ASC Mars Server"
"wms_group_title" "Geo_mars2"
#"rgbcolor" "50,123,43"
END
CLASS
NAME 'AHtm'
EXPRESSION "AHtm"
COLOR 22 222 112
OUTLINECOLOR 22 222 112
END
CLASS
NAME 'AHosc'
EXPRESSION "AHosc"
COLOR 33 233 133
OUTLINECOLOR 33 233 133
END
CLASS
NAME 'Aa1'
EXPRESSION "Aa1"
COLOR 50 0 0
OUTLINECOLOR 50 0 0
END
CLASS
NAME 'Aa3'
EXPRESSION "Aa3"
COLOR 0 50 0
OUTLINECOLOR 0 50 0
END
CLASS
NAME 'Aab'
EXPRESSION "Aab"
COLOR 1 101 201
OUTLINECOLOR 1 101 201
END
CLASS
NAME 'Aah'
EXPRESSION "Aah"
COLOR 34 189 23
OUTLINECOLOR 34 189 23
END
CLASS
NAME 'Aam'
EXPRESSION "Aam"
COLOR 0 0 50
OUTLINECOLOR 0 0 50
END
CLASS
NAME 'Aar'
EXPRESSION "Aar"
COLOR 43 1 200
OUTLINECOLOR 43 1 200
END
CLASS
NAME 'Aas'
EXPRESSION "Aas"
COLOR 100 0 0
OUTLINECOLOR 100 0 0
END
CLASS
NAME 'Acf'
EXPRESSION "Acf"
COLOR 0 100 0
OUTLINECOLOR 0 100 0
END
CLASS
NAME 'Amp'
EXPRESSION "Amp"
COLOR 209 9 59
OUTLINECOLOR 209 9 59
END
CLASS
NAME 'Amr'
EXPRESSION "Amr"
COLOR 12 212 121
OUTLINECOLOR 12 212 121
END
CLASS
NAME 'Ams'
EXPRESSION "Ams"
COLOR 0 0 100
OUTLINECOLOR 0 0 100
END
CLASS
NAME 'Aoal'
EXPRESSION "Aoal"
COLOR 150 0 0
OUTLINECOLOR 150 0 0
END
CLASS
NAME 'Aoama'
EXPRESSION "Aoama"
COLOR 0 150 0
OUTLINECOLOR 0 150 0
END
CLASS
NAME 'Aoamb'
EXPRESSION "Aoamb"
COLOR 0 0 150
OUTLINECOLOR 0 0 150
END
CLASS
NAME 'Aoamc'
EXPRESSION "Aoamc"
COLOR 200 0 0
OUTLINECOLOR 200 0 0
END
CLASS
NAME 'Aoamd'
EXPRESSION "Aoamd"
COLOR 0 200 0
OUTLINECOLOR 0 200 0
END
CLASS
NAME 'Aoame'
EXPRESSION "Aoame"
COLOR 44 4 204
OUTLINECOLOR 44 4 204
END
CLASS
NAME 'Aoau'
EXPRESSION "Aoau"
COLOR 100 200 71
OUTLINECOLOR 100 200 71
END
CLASS
NAME 'Aoav'
EXPRESSION "Aoav"
COLOR 0 0 200
OUTLINECOLOR 0 0 200
END
CLASS
NAME 'Aoc1'
EXPRESSION "Aoc1"
COLOR 50 100 64
OUTLINECOLOR 50 100 64
END
CLASS
NAME 'Aoc2'
EXPRESSION "Aoc2"
COLOR 251 100 64
OUTLINECOLOR 251 100 64
END
CLASS
NAME 'Aoc3'
EXPRESSION "Aoc3"
COLOR 25 64 100
OUTLINECOLOR 25 64 100
END
CLASS
NAME 'Aop'
EXPRESSION "Aop"
COLOR 250 0 0
OUTLINECOLOR 250 0 0
END
CLASS
NAME 'Aos1'
EXPRESSION "Aos1"
COLOR 99 199 88
OUTLINECOLOR 99 199 88
END
CLASS
NAME 'Aos2'
EXPRESSION "Aos2"
COLOR 50 34 11
OUTLINECOLOR 50 34 11
END
CLASS
NAME 'Aos3'
EXPRESSION "Aos3"
COLOR 0 250 0
OUTLINECOLOR 0 250 0
END
CLASS
NAME 'Aos4'
EXPRESSION "Aos4"
COLOR 77 141 61
OUTLINECOLOR 77 141 61
END
CLASS
NAME 'Atm'
EXPRESSION "Atm"
COLOR 111 11 211
OUTLINECOLOR 111 11 211
END
CLASS
NAME 'Hal'
EXPRESSION "Hal"
COLOR 0 0 250
OUTLINECOLOR 0 0 250
END
CLASS
NAME 'Hf'
EXPRESSION "Hf"
COLOR 184 2 200
OUTLINECOLOR 184 2 200
END
CLASS
NAME 'Hhf'
EXPRESSION "Hhf"
COLOR 50 50 0
OUTLINECOLOR 50 50 0
END
CLASS
NAME 'Hhh'
EXPRESSION "Hhh"
COLOR 50 0 50
OUTLINECOLOR 50 0 50
END
CLASS
NAME 'Hhp'
EXPRESSION "Hhp"
COLOR 0 50 50
OUTLINECOLOR 0 50 50
END
CLASS
NAME 'Naf'
EXPRESSION "Naf"
COLOR 100 0 50
OUTLINECOLOR 100 0 50
END
CLASS
NAME 'Nam'
EXPRESSION "Nam"
COLOR 50 100 50
OUTLINECOLOR 50 100 50
END
CLASS
NAME 'Nap'
EXPRESSION "Nap"
COLOR 100 0 100
OUTLINECOLOR 100 0 100
END
CLASS
NAME 'ca'
EXPRESSION "ca"
COLOR 50 75 100
OUTLINECOLOR 50 75 100
END
CLASS
NAME 'cb'
EXPRESSION "cb"
COLOR 50 100 75
OUTLINECOLOR 50 100 75
END
CLASS
NAME 'cc'
EXPRESSION "cc"
COLOR 75 50 100
OUTLINECOLOR 75 50 100
END
CLASS
NAME 'cd'
EXPRESSION "cd"
COLOR 75 100 50
OUTLINECOLOR 75 100 50
END
CLASS
NAME 'HNosc'
EXPRESSION "HNosc"
COLOR 25 125 225
OUTLINECOLOR 25 125 225
END
END
LAYER
NAME empreintes
GROUP Hirise2
TYPE polygon
#CONNECTIONTYPE postgis
#CONNECTION "user=mphaneuf password=spacegis dbname=hirise host=localhost"
#DATA "the_geom from footprint"
DATA "HiRISE_PDS_footprints_20070916.shp"
STATUS default
TEMPLATE "ttt.html"
#PROJECTION
#"init=epsg:4326"
#END
METADATA
"queryable" "true"
"SEARCHFIELD" "RATION_DES"
"fields" 'RATION_DES:Description'
"tranparent" "on"
"tile_source" "auto"
"wms_title" "ASC Mars Server"
"wms_group_title" "Hirise2"
"wms_srs" "EPSG:4326"
"rgbcolor" "50,123,43"
END
CLASS
NAME footprint
STYLE
COLOR 56 124 216
OUTLINECOLOR 100 150 200
END
END
END
LAYER
NAME labels
GROUP Labels
TYPE annotation
DATA HiRISE_PDS_footprints_20070916
STATUS off
LABELITEM "RATION_DES"
METADATA
"wms_group_title" "labels"
"wms_srs" "epsg:4326"
"wms_title" "Labels"
END
PROJECTION
"init=epsg:4326"
END
CLASS
NAME labels_Hirise
STYLE
COLOR 56 124 216
OUTLINECOLOR 100 150 200
END
LABEL
TYPE truetype
FONT "sans-bold-italic"
ANTIALIAS true
SIZE 6
MINSIZE 4
MAXSIZE 8
POSITION cc
OFFSET 0 0
COLOR 0 0 0
#BACKGROUNDCOLOR 255 255 255
END
END
END
#ce système de tuiles fonctionne (pour la transparence)
#affiche image hirise
LAYER
GROUP test_jp2
NAME hirise_tile
STATUS off
TILEINDEX "mdim21_footprint_dd_Erase.shp"
TILEITEM "IMAGE"
PROJECTION
"init=epsg:4326"
END
METADATA
"imageformat" "gif"
"wms_title" "ASC Mars Server"
"tranparent" "on"
"tilesource" "auto"
"wms_srs" "epsg:4326"
"wms_group_title" "hirise_tile"
END
TYPE raster
END
#----------test for tile = 512 pixel, geotiff--------------#
LAYER
NAME "HiRISE_1_512"
GROUP "tile_hirise"
STATUS off
TYPE RASTER
TILEINDEX "tileHirise1.shp"
TILEITEM "location"
MINSCALE 10000
MAXSCALE 50000
METADATA
"wms_srs" "epsg:4326"
"wms_group_title" "tile_hirise"
"wms_title" "HiRISE_1_512"
END
END
LAYER
NAME "HiRISE_2_512"
GROUP "tile_hirise"
STATUS OFF
TYPE RASTER
TILEINDEX "tileHirise2.shp"
TILEITEM "location"
MINSCALE 50000
MAXSCALE 125000
METADATA
"wms_srs" "epsg:4326"
"wms_group_title" "tile_hirise"
"wms_title" "HiRISE_2_512"
END
END
LAYER
NAME "HiRISE_3_512"
GROUP "tile_hirise"
STATUS off
TYPE RASTER
TILEINDEX "tileHirise3.shp"
TILEITEM "location"
MINSCALE 125000
MAXSCALE 250000
METADATA
"wms_srs" "epsg:4326"
"wms_group_title" "tile_hirise"
"wms_title" "HiRISE_3_512"
END
END
LAYER
NAME "HiRISE_4_512"
GROUP "tile_hirise"
STATUS OFF
TYPE RASTER
TILEINDEX "tileHirise4.shp"
TILEITEM "location"
MINSCALE 250000
MAXSCALE 500000
METADATA
"wms_srs" "epsg:4326"
"wms_group_title" "tile_hirise"
"wms_title" "HiRISE_4_512"
END
END
LAYER
NAME "HiRISE_5_512"
GROUP "tile_hirise"
STATUS OFF
TYPE RASTER
TILEINDEX "tileHirise5.shp"
TILEITEM "location"
MINSCALE 500000
MAXSCALE 1000000
METADATA
"wms_srs" "epsg:4326"
"wms_group_title" "tile_hirise"
"wms_title" "HiRISE_5_512"
END
END
LAYER
NAME "HiRISE_6_512"
GROUP "tile_hirise"
STATUS off
TYPE RASTER
TILEINDEX "tileHirise6.shp"
TILEITEM "location"
MINSCALE 1000001
MAXSCALE 40000001
METADATA
"wms_srs" "epsg:4326"
"wms_group_title" "tile_hirise"
"wms_title" "HiRISE_6_512"
END
END
LAYER
NAME "HiRISE_512"
GROUP "tile_hirise"
STATUS off
TYPE RASTER
TILEINDEX "tileHirise.shp"
TILEITEM "location"
MINSCALE 0
MAXSCALE 10000
METADATA
"wms_srs" "epsg:4326"
"wms_group_title" "tile_hirise"
"wms_title" "HiRISE_512"
END
END
#---------------end of test 512 pixels------------------#
#----------test for tile = 256 pixel, geotiff--------------#
LAYER
NAME "HiRISE_1_256"
GROUP "tile_hirise256"
STATUS off
TYPE RASTER
TILEINDEX "tileIndex_256_1.shp"
TILEITEM "location"
MINSCALE 10000
MAXSCALE 50000
METADATA
"wms_group_title" "tile_hirise256"
"wms_srs" "epsg:4326"
"wms_title" "HiRISE_1_256"
END
END
LAYER
NAME "HiRISE_2_256"
GROUP "tile_hirise256"
STATUS OFF
TYPE RASTER
TILEINDEX "tileIndex_256_2.shp"
TILEITEM "location"
MINSCALE 50000
MAXSCALE 125000
METADATA
"wms_group_title" "tile_hirise256"
"wms_srs" "epsg:4326"
"wms_title" "HiRISE_2_256"
END
END
LAYER
NAME "HiRISE_3_256"
GROUP "tile_hirise256"
STATUS OFF
TYPE RASTER
TILEINDEX "tileIndex_256_3.shp"
TILEITEM "location"
MINSCALE 125000
MAXSCALE 250000
METADATA
"wms_group_title" "tile_hirise256"
"wms_srs" "epsg:4326"
"wms_title" "HiRISE_3_256"
END
END
LAYER
NAME "HiRISE_4_256"
GROUP "tile_hirise256"
STATUS OFF
TYPE RASTER
TILEINDEX "tileIndex_256_4.shp"
TILEITEM "location"
MINSCALE 250000
MAXSCALE 500000
METADATA
"wms_group_title" "tile_hirise256"
"wms_srs" "epsg:4326"
"wms_title" "HiRISE_4_256"
END
END
LAYER
NAME "HiRISE_5_256"
GROUP "tile_hirise256"
STATUS OFF
TYPE RASTER
TILEINDEX "tileIndex_256_5.shp"
TILEITEM "location"
MINSCALE 500000
MAXSCALE 1000000
METADATA
"wms_group_title" "tile_hirise256"
"wms_srs" "epsg:4326"
"wms_title" "HiRISE_5_256"
END
END
LAYER
NAME "HiRISE_6_256"
GROUP "tile_hirise256"
STATUS OFF
TYPE RASTER
TILEINDEX "tileIndex_256_6.shp"
TILEITEM "location"
MINSCALE 1000001
MAXSCALE 40000001
METADATA
"wms_group_title" "tile_hirise256"
"wms_srs" "epsg:4326"
"wms_title" "HiRISE_6_256"
"wms_extent" "53.000000,-39.600000,54.000000,-38.90"
END
END
LAYER
NAME "HiRISE_256"
GROUP "tile_hirise256"
STATUS off
TYPE RASTER
TILEINDEX "tileIndex_256.shp"
TILEITEM "location"
MINSCALE 0
MAXSCALE 10000
METADATA
"wms_group_title" "tile_hirise256"
"wms_srs" "epsg:4326"
"wms_title" "HiRISE_256"
END
END
#---------------end of test 512 pixels------------------#
#----------test for tile = 256 pixel, geotiff--------------#
LAYER
NAME "HiRISE_1_1000"
GROUP "tile_hirise1000"
STATUS OFF
TYPE RASTER
TILEINDEX "tileIndex_1000_1.shp"
TILEITEM "location"
MINSCALE 10000
MAXSCALE 50000
METADATA
"wms_group_title" "tile_hirise1000"
"wms_title" "HiRISE_1_1000"
"wms_srs" "epsg:4326"
END
END
LAYER
NAME "HiRISE_2_1000"
GROUP "tile_hirise1000"
STATUS OFF
TYPE RASTER
TILEINDEX "tileIndex_1000_2.shp"
TILEITEM "location"
MINSCALE 50000
MAXSCALE 125000
METADATA
"wms_group_title" "tile_hirise1000"
"wms_title" "HiRISE_2_1000"
"wms_srs" "epsg:4326"
END
END
LAYER
NAME "HiRISE_3_1000"
GROUP "tile_hirise1000"
STATUS OFF
TYPE RASTER
TILEINDEX "tileIndex_1000_3.shp"
TILEITEM "location"
MINSCALE 125000
MAXSCALE 250000
METADATA
"wms_group_title" "tile_hirise1000"
"wms_title" "HiRISE_3_1000"
"wms_srs" "epsg:4326"
END
END
LAYER
NAME "HiRISE_4_1000"
GROUP "tile_hirise1000"
STATUS OFF
TYPE RASTER
TILEINDEX "tileIndex_1000_4.shp"
TILEITEM "location"
MINSCALE 250000
MAXSCALE 500000
METADATA
"wms_group_title" "tile_hirise1000"
"wms_title" "HiRISE_4_1000"
"wms_srs" "epsg:4326"
END
END
LAYER
NAME "HiRISE_5_1000"
GROUP "tile_hirise1000"
STATUS OFF
TYPE RASTER
TILEINDEX "tileIndex_1000_5.shp"
TILEITEM "location"
MINSCALE 500000
MAXSCALE 1000000
METADATA
"wms_group_title" "tile_hirise1000"
"wms_title" "HiRISE_5_1000"
"wms_srs" "epsg:4326"
END
END
LAYER
NAME "HiRISE_6_1000"
GROUP "tile_hirise1000"
STATUS OFF
TYPE RASTER
TILEINDEX "tileIndex_1000_6.shp"
TILEITEM "location"
MINSCALE 1000001
MAXSCALE 40000001
METADATA
"wms_group_title" "tile_hirise1000"
"wms_title" "HiRISE_6_1000"
"wms_srs" "epsg:4326"
END
END
LAYER
NAME "HiRISE_1000"
GROUP "tile_hirise1000"
STATUS off
TYPE RASTER
TILEINDEX "tileIndex_1000.shp"
TILEITEM "location"
MINSCALE 0
MAXSCALE 10000
METADATA
"wms_group_title" "tile_hirise1000"
"wms_title" "HiRISE_1000"
"wms_srs" "epsg:4326"
END
END
END
Mars map with Mars polar projection
#
# Start of map file
#
# $Id: gmap75.map,v 1.24 2004/03/02 00:30:03 fredrock Exp $
#
MAP
NAME iau2000_49918
STATUS on
SIZE 1500 1300 #a ne pas mettre en commentaire pour faire fonctionner légende
IMAGETYPE gif
SYMBOLSET "/home/mphaneuf/public_html/gis/fusion/gmap-ms46/etc/symbols.sym"
EXTENT -6752685.06 -6752221.9668 6752221.9668 6752685.06
UNITS meters
SHAPEPATH "/home/mphaneuf/public_html/cgi-bin/shapefiles/"
IMAGECOLOR 255 255 255
FONTSET "/home/mphaneuf/public_html/cgi-bin/etc/fonts.txt"
#
# Start of web interface definition
#
WEB
#MINSCALE 10000
#MAXSCALE 50000000
#
# On Windows systems, /tmp and /tmp/ms_tmp/ should be created at the root
# of the drive where the .MAP file resides.
#
IMAGEPATH "/usr/local/apache/htdocs/ka-map/htdocs/tmp/"
IMAGEURL "/ka-map/tmp/"
METADATA
"version" "1.1.1"
"max_extents" "-6752685.06 -6752221.9668 6752221.9668 6752685.06"
"wms_title" "ASC Mars Server_iau2000" ##required
"wms_onlineresource" "http://67.205.74.208/cgi-
bin/mapserv?map=/home/mphaneuf/public_html/cgi-bin/mapfiles/mars_iau49918.map&"
##required
"wms_srs" "iau2000:49918" ##recommended
END
# LOG "/tmp/kacache/Mars_log.log"
END
OUTPUTFORMAT
NAME jpeg
DRIVER "GD/JPEG"
MIMETYPE "image/jpeg"
IMAGEMODE RGB
EXTENSION "jpeg"
#TRANSPARENT on
FORMATOPTION "quality=100"
END
OUTPUTFORMAT
NAME png24
DRIVER "GD/PNG"
MIMETYPE "image/png"
IMAGEMODE rgba
EXTENSION "png"
TRANSPARENT on
FORMATOPTION "TRANSPARENT=ON"
END
OUTPUTFORMAT
NAME png
DRIVER "GD/PNG"
MIMETYPE "image/png"
IMAGEMODE rgba
EXTENSION "png"
TRANSPARENT on
FORMATOPTION "TRANSPARENT=ON"
END
OUTPUTFORMAT
NAME gif
DRIVER "GD/GIF"
MIMETYPE "image/gif"
IMAGEMODE PC256
EXTENSION "gif"
FORMATOPTION "TRANSPARENT=ON"
END
OUTPUTFORMAT
NAME gtiff
DRIVER "GDAL/GTiff"
MIMETYPE "image/tiff"
IMAGEMODE rgba
EXTENSION "tif"
FORMATOPTION "TRANSPARENT=ON"
END
PROJECTION
"+proj=stere +lat_0=90 +x_0=0 +y_0=0 +a=3376200.0 +b=3376200.0 +k=1"
END
REFERENCE
IMAGE /home/mphaneuf/public_html/gis/fusion/gmap-
ms46/htdocs/images/Mars_general_image.gif
EXTENT -6752685.06 -6752221.9668 6752221.9668 6752685.06
STATUS ON
COLOR -1 -1 -1
OUTLINECOLOR 255 0 0
SIZE 120 90
END
LEGEND
TRANSPARENT true
END
SCALEBAR
TRANSPARENT true
END
LAYER
GROUP base_tiff
STATUS default
NAME "hillshade"
METADATA
"wms_title" "HillShade" ##required
"wms_srs" "IAU2000:49911"
"tile_source" "nocache"
END
TYPE raster
DATA "NPlains_geology_SIM2888_2005/Topography_bases/Hillshades/hillshade_mola.tif"
PROJECTION
"+proj=stere +lat_0=90 +x_0=0 +y_0=0 +a=3376200.0 +b=3376200.0 +k=1"
END
END
LAYER
GROUP Mosaik
NAME img_fond
TYPE raster
DATA Mars_Color_MDIM_1
STATUS off
CONNECTION
"http://webgis.wr.usgs.gov/wmsconnector/com.esri.wms.Esrimap/Mars_general_image?"
CONNECTIONTYPE wms
PROJECTION
"init=epsg:4326"
END
METADATA
"DESCRIPTION" "mars"
"tile_source" "nocache"
"redraw_interval" "60"
"refresh_interval" "10"
"wms_srs" "epsg:4326"
"wms_name" "Mars_Color_MDIM_1"
"wms_onlineresource"
"http://webgis.wr.usgs.gov/wmsconnector/com.esri.wms.Esrimap/Mars_general_image?"
"wms_format" "image/gif"
"wms_server_version" "1.1.1"
"wms_style" "visual"
"wms_group_title" "Mosaik"
"wms_title" "img_fond"
END
END
LAYER
NAME graticules
GROUP graticules
TYPE line
DATA "graticule30x30_np_meters.shp"
STATUS default
PROJECTION
"+proj=stere +lat_0=90 +x_0=0 +y_0=0 +a=3376200.0 +b=3376200.0 +k=1"
END
METADATA
"queryable" "false"
"tranparent" "on"
"tile_source" "auto"
"wms_title" "ASC Mars Server"
"wms_srs" "iau2000:49918"
"rgbcolor" "50,100,150"
END
CLASS
NAME gridsd
STYLE
COLOR 56 124 216
END
END
END
LAYER
NAME geologie
GROUP Geo_mars2
#CONNECTIONTYPE postgis
#CONNECTION "user=mphaneuf password=spacegis dbname=geologie host=localhost"
TYPE polygon
#DATA "the_geom from olympus"
DATA "geologie_proj.shp"
STATUS default
CLASSITEM "uname"
TEMPLATE "ttt.html"
PROJECTION
"+proj=stere +lat_0=90 +x_0=0 +y_0=0 +a=3376200.0 +b=3376200.0 +k=1"
END
METADATA
"queryable" "true"
"SEARCHFIELD" "uname"
"fields" 'uname:Description'
"tranparent" "on"
"tile_source" "auto"
"wms_title" "ASC Mars Server"
"wms_group_title" "Geo_mars2"
#"rgbcolor" "50,123,43"
END
CLASS
NAME 'AHtm'
EXPRESSION "AHtm"
COLOR 22 222 112
OUTLINECOLOR 22 222 112
END
CLASS
NAME 'AHosc'
EXPRESSION "AHosc"
COLOR 33 233 133
OUTLINECOLOR 33 233 133
END
CLASS
NAME 'Aa1'
EXPRESSION "Aa1"
COLOR 50 0 0
OUTLINECOLOR 50 0 0
END
CLASS
NAME 'Aa3'
EXPRESSION "Aa3"
COLOR 0 50 0
OUTLINECOLOR 0 50 0
END
CLASS
NAME 'Aab'
EXPRESSION "Aab"
COLOR 1 101 201
OUTLINECOLOR 1 101 201
END
CLASS
NAME 'Aah'
EXPRESSION "Aah"
COLOR 34 189 23
OUTLINECOLOR 34 189 23
END
CLASS
NAME 'Aam'
EXPRESSION "Aam"
COLOR 0 0 50
OUTLINECOLOR 0 0 50
END
CLASS
NAME 'Aar'
EXPRESSION "Aar"
COLOR 43 1 200
OUTLINECOLOR 43 1 200
END
CLASS
NAME 'Aas'
EXPRESSION "Aas"
COLOR 100 0 0
OUTLINECOLOR 100 0 0
END
CLASS
NAME 'Acf'
EXPRESSION "Acf"
COLOR 0 100 0
OUTLINECOLOR 0 100 0
END
CLASS
NAME 'Amp'
EXPRESSION "Amp"
COLOR 209 9 59
OUTLINECOLOR 209 9 59
END
CLASS
NAME 'Amr'
EXPRESSION "Amr"
COLOR 12 212 121
OUTLINECOLOR 12 212 121
END
CLASS
NAME 'Ams'
EXPRESSION "Ams"
COLOR 0 0 100
OUTLINECOLOR 0 0 100
END
CLASS
NAME 'Aoal'
EXPRESSION "Aoal"
COLOR 150 0 0
OUTLINECOLOR 150 0 0
END
CLASS
NAME 'Aoama'
EXPRESSION "Aoama"
COLOR 0 150 0
OUTLINECOLOR 0 150 0
END
CLASS
NAME 'Aoamb'
EXPRESSION "Aoamb"
COLOR 0 0 150
OUTLINECOLOR 0 0 150
END
CLASS
NAME 'Aoamc'
EXPRESSION "Aoamc"
COLOR 200 0 0
OUTLINECOLOR 200 0 0
END
CLASS
NAME 'Aoamd'
EXPRESSION "Aoamd"
COLOR 0 200 0
OUTLINECOLOR 0 200 0
END
CLASS
NAME 'Aoame'
EXPRESSION "Aoame"
COLOR 44 4 204
OUTLINECOLOR 44 4 204
END
CLASS
NAME 'Aoau'
EXPRESSION "Aoau"
COLOR 100 200 71
OUTLINECOLOR 100 200 71
END
CLASS
NAME 'Aoav'
EXPRESSION "Aoav"
COLOR 0 0 200
OUTLINECOLOR 0 0 200
END
CLASS
NAME 'Aoc1'
EXPRESSION "Aoc1"
COLOR 50 100 64
OUTLINECOLOR 50 100 64
END
CLASS
NAME 'Aoc2'
EXPRESSION "Aoc2"
COLOR 251 100 64
OUTLINECOLOR 251 100 64
END
CLASS
NAME 'Aoc3'
EXPRESSION "Aoc3"
COLOR 25 64 100
OUTLINECOLOR 25 64 100
END
CLASS
NAME 'Aop'
EXPRESSION "Aop"
COLOR 250 0 0
OUTLINECOLOR 250 0 0
END
CLASS
NAME 'Aos1'
EXPRESSION "Aos1"
COLOR 99 199 88
OUTLINECOLOR 99 199 88
END
CLASS
NAME 'Aos2'
EXPRESSION "Aos2"
COLOR 50 34 11
OUTLINECOLOR 50 34 11
END
CLASS
NAME 'Aos3'
EXPRESSION "Aos3"
COLOR 0 250 0
OUTLINECOLOR 0 250 0
END
CLASS
NAME 'Aos4'
EXPRESSION "Aos4"
COLOR 77 141 61
OUTLINECOLOR 77 141 61
END
CLASS
NAME 'Atm'
EXPRESSION "Atm"
COLOR 111 11 211
OUTLINECOLOR 111 11 211
END
CLASS
NAME 'Hal'
EXPRESSION "Hal"
COLOR 0 0 250
OUTLINECOLOR 0 0 250
END
CLASS
NAME 'Hf'
EXPRESSION "Hf"
COLOR 184 2 200
OUTLINECOLOR 184 2 200
END
CLASS
NAME 'Hhf'
EXPRESSION "Hhf"
COLOR 50 50 0
OUTLINECOLOR 50 50 0
END
CLASS
NAME 'Hhh'
EXPRESSION "Hhh"
COLOR 50 0 50
OUTLINECOLOR 50 0 50
END
CLASS
NAME 'Hhp'
EXPRESSION "Hhp"
COLOR 0 50 50
OUTLINECOLOR 0 50 50
END
CLASS
NAME 'Naf'
EXPRESSION "Naf"
COLOR 100 0 50
OUTLINECOLOR 100 0 50
END
CLASS
NAME 'Nam'
EXPRESSION "Nam"
COLOR 50 100 50
OUTLINECOLOR 50 100 50
END
CLASS
NAME 'Nap'
EXPRESSION "Nap"
COLOR 100 0 100
OUTLINECOLOR 100 0 100
END
CLASS
NAME 'ca'
EXPRESSION "ca"
COLOR 50 75 100
OUTLINECOLOR 50 75 100
END
CLASS
NAME 'cb'
EXPRESSION "cb"
COLOR 50 100 75
OUTLINECOLOR 50 100 75
END
CLASS
NAME 'cc'
EXPRESSION "cc"
COLOR 75 50 100
OUTLINECOLOR 75 50 100
END
CLASS
NAME 'cd'
EXPRESSION "cd"
COLOR 75 100 50
OUTLINECOLOR 75 100 50
END
CLASS
NAME 'HNosc'
EXPRESSION "HNosc"
COLOR 25 125 225
OUTLINECOLOR 25 125 225
END
END
LAYER
NAME empreintes
GROUP Hirise2
TYPE polygon
#CONNECTIONTYPE postgis
#CONNECTION "user=mphaneuf password=spacegis dbname=hirise host=localhost"
#DATA "the_geom from footprint"
DATA "hirise_foot_proj.shp"
STATUS default
TEMPLATE "ttt.html"
PROJECTION
"+proj=stere +lat_0=90 +x_0=0 +y_0=0 +a=3376200.0 +b=3376200.0 +k=1"
END
METADATA
"queryable" "true"
"SEARCHFIELD" "ration_des"
"fields" 'ration_des:Description'
"tranparent" "on"
"tile_source" "auto"
"wms_title" "ASC Mars Server"
"wms_group_title" "Hirise2"
"rgbcolor" "50,123,43"
END
CLASS
NAME footprint
STYLE
COLOR 56 124 216
OUTLINECOLOR 100 150 200
END
END
END
LAYER
NAME labels
GROUP Labels
TYPE annotation
DATA HiRISE_PDS_footprints_20070916
STATUS off
LABELITEM "RATION_DES"
METADATA
"wms_group_title" "labels"
"wms_srs" "iau2000:49918 EPSG:4326"
"wms_title" "Labels"
END
PROJECTION
"init=epsg:4326"
END
CLASS
NAME labels_Hirise
STYLE
COLOR 56 124 216
OUTLINECOLOR 100 150 200
END
LABEL
TYPE truetype
FONT "sans-bold-italic"
ANTIALIAS true
SIZE 6
MINSIZE 4
MAXSIZE 8
POSITION cc
OFFSET 0 0
COLOR 0 0 0
#BACKGROUNDCOLOR 255 255 255
END
END
END
#ce système de tuiles fonctionne (pour la transparence)
#LAYER
#GROUP test
#NAME tuiles
#STATUS OFF
#TILEINDEX "mdim21_footprint_dd.shp"
#TILEITEM "IMAGE"
#PROJECTION
#"+proj=stere +lat_0=90 +x_0=0 +y_0=0 +a=3376200.0 +b=3376200.0
+k=1"
#END
#METADATA
#"imageformat" "gif"
#"wms_title" "ASC Mars Server"
#"tranparent" "on"
#"tilesource" "auto"
#"wms_group_title" "test"
#"wms_srs" "iau2000:49918 EPSG:4326"
#END
#TYPE raster
#END
#affiche image hirise
LAYER
GROUP test_jp2
NAME hirise_tile
STATUS OFF
TILEINDEX "mdim21_footprint_dd_Erase.shp"
TILEITEM "IMAGE"
PROJECTION
"init=epsg:4326"
END
METADATA
"imageformat" "gif"
"wms_title" "ASC Mars Server"
"tranparent" "on"
"tilesource" "auto"
"wms_srs" "iau2000:49918 EPSG:4326"
"wms_group_title" "hirise_tile"
END
TYPE raster
END
END
Test for 1000 x 1000 tiles
MAP
NAME MARS_1000
STATUS on
SIZE 1000 800 #a ne pas mettre en commentaire pour faire fonctionner légende
IMAGETYPE gif
SYMBOLSET "/home/mphaneuf/public_html/gis/fusion/gmap-ms46/etc/symbols.sym"
EXTENT 53.000000 -39.600000 54.000000 -38.90
UNITS dd
SHAPEPATH "/home/mphaneuf/public_html/cgi-bin/shapefiles/"
IMAGECOLOR 255 255 255
FONTSET "/home/mphaneuf/public_html/cgi-bin/etc/fonts.txt"
WEB
MINSCALE 100
MAXSCALE 1550000
#
# On Windows systems, /tmp and /tmp/ms_tmp/ should be created at the root
# of the drive where the .MAP file resides.
#
IMAGEPATH "/usr/local/apache/htdocs/ka-map/htdocs/tmp/"
IMAGEURL "/ka-map/tmp/"
METADATA
"version" "1.1.1"
"max_extents" "-180 -90 180 90"
"wms_title" "ASC Mars Server" ##required
"wms_onlineresource" "http://67.205.74.208/cgi-
bin/mapserv?map=/home/mphaneuf/public_html/cgi-bin/mapfiles/mars_v1.map&" ##required
"wms_srs" "EPSG:4326" ##recommended
END
# LOG "/tmp/kacache/Mars_log.log"
END
PROJECTION
"init=epsg:4326"
END
OUTPUTFORMAT
NAME gif
DRIVER "GD/GIF"
MIMETYPE "image/gif"
IMAGEMODE PC256
EXTENSION "gif"
FORMATOPTION "TRANSPARENT=ON"
END
REFERENCE
IMAGE /home/mphaneuf/public_html/gis/fusion/gmap-
ms46/htdocs/images/Mars_general_image.gif
EXTENT -180 -90 180 90
STATUS ON
COLOR -1 -1 -1
OUTLINECOLOR 255 0 0
SIZE 120 90
END
LEGEND
TRANSPARENT true
END
SCALEBAR
TRANSPARENT true
END
LAYER
NAME "HiRISE_1_1000"
GROUP "tile_hirise1000"
STATUS default
TYPE RASTER
TILEINDEX "tileIndex_1000_1.shp"
TILEITEM "location"
MINSCALE 221432
MAXSCALE 442860
METADATA
"wms_group_title" "tile_hirise1000"
"wms_title" "HiRISE_1_1000"
"wms_srs" "epsg:4326"
END
END
LAYER
NAME "HiRISE_2_1000"
GROUP "tile_hirise1000"
STATUS default
TYPE RASTER
TILEINDEX "tileIndex_1000_2.shp"
TILEITEM "location"
MINSCALE 442860
MAXSCALE 664288
METADATA
"wms_group_title" "tile_hirise1000"
"wms_title" "HiRISE_2_1000"
"wms_srs" "epsg:4326"
END
END
LAYER
NAME "HiRISE_3_1000"
GROUP "tile_hirise1000"
STATUS default
TYPE RASTER
TILEINDEX "tileIndex_1000_3.shp"
TILEITEM "location"
MINSCALE 664288
MAXSCALE 885716
METADATA
"wms_group_title" "tile_hirise1000"
"wms_title" "HiRISE_3_1000"
"wms_srs" "epsg:4326"
END
END
LAYER
NAME "HiRISE_4_1000"
GROUP "tile_hirise1000"
STATUS default
TYPE RASTER
TILEINDEX "tileIndex_1000_4.shp"
TILEITEM "location"
MINSCALE 885716
MAXSCALE 1107144
METADATA
"wms_group_title" "tile_hirise1000"
"wms_title" "HiRISE_4_1000"
"wms_srs" "epsg:4326"
END
END
LAYER
NAME "HiRISE_5_1000"
GROUP "tile_hirise1000"
STATUS default
TYPE RASTER
TILEINDEX "tileIndex_1000_5.shp"
TILEITEM "location"
MINSCALE 1107144
MAXSCALE 1328572
METADATA
"wms_group_title" "tile_hirise1000"
"wms_title" "HiRISE_5_1000"
"wms_srs" "epsg:4326"
END
END
LAYER
NAME "HiRISE_6_1000"
GROUP "tile_hirise1000"
STATUS default
TYPE raster
TILEINDEX "tileIndex_1000_6.shp"
TILEITEM "location"
MINSCALE 1328572
MAXSCALE 1550000
METADATA
"wms_group_title" "tile_hirise1000"
"wms_title" "HiRISE_6_1000"
"wms_srs" "epsg:4326"
END
END
LAYER
NAME "HiRISE_1000"
GROUP "tile_hirise1000"
STATUS default
TYPE RASTER
TILEINDEX "tileIndex_1000.shp"
TILEITEM "location"
MINSCALE 50
MAXSCALE 221432
METADATA
"wms_group_title" "tile_hirise1000"
"wms_title" "HiRISE_1000"
"wms_srs" "epsg:4326"
END
END
END
Test with 512 x 512 tiles
MAP
NAME MARS_512
STATUS on
SIZE 1000 800 #a ne pas mettre en commentaire pour faire fonctionner légende
IMAGETYPE gif
SYMBOLSET "/home/mphaneuf/public_html/gis/fusion/gmap-ms46/etc/symbols.sym"
EXTENT 53.000000 -39.600000 54.000000 -38.90
UNITS dd
SHAPEPATH "/home/mphaneuf/public_html/cgi-bin/shapefiles/"
IMAGECOLOR 255 255 255
FONTSET "/home/mphaneuf/public_html/cgi-bin/etc/fonts.txt"
WEB
MINSCALE 100
MAXSCALE 1550000
#
# On Windows systems, /tmp and /tmp/ms_tmp/ should be created at the root
# of the drive where the .MAP file resides.
#
IMAGEPATH "/usr/local/apache/htdocs/ka-map/htdocs/tmp/"
IMAGEURL "/ka-map/tmp/"
METADATA
"version" "1.1.1"
"max_extents" "-180 -90 180 90"
"wms_title" "ASC Mars Server" ##required
"wms_onlineresource" "http://67.205.74.208/cgi-
bin/mapserv?map=/home/mphaneuf/public_html/cgi-bin/mapfiles/mars_v1.map&" ##required
"wms_srs" "EPSG:4326" ##recommended
END
# LOG "/tmp/kacache/Mars_log.log"
END
PROJECTION
"init=epsg:4326"
END
OUTPUTFORMAT
NAME gif
DRIVER "GD/GIF"
MIMETYPE "image/gif"
IMAGEMODE PC256
EXTENSION "gif"
FORMATOPTION "TRANSPARENT=ON"
END
REFERENCE
IMAGE /home/mphaneuf/public_html/gis/fusion/gmap-
ms46/htdocs/images/Mars_general_image.gif
EXTENT -180 -90 180 90
STATUS ON
COLOR -1 -1 -1
OUTLINECOLOR 255 0 0
SIZE 120 90
END
LEGEND
TRANSPARENT true
END
SCALEBAR
TRANSPARENT true
END
LAYER
NAME "HiRISE_1_512"
GROUP "tile_hirise"
STATUS default
TYPE RASTER
TILEINDEX "tileHirise1.shp"
TILEITEM "location"
MINSCALE 221432
MAXSCALE 442860
METADATA
"wms_srs" "epsg:4326"
"wms_group_title" "tile_hirise"
"wms_title" "HiRISE_1_512"
END
END
LAYER
NAME "HiRISE_2_512"
GROUP "tile_hirise"
STATUS default
TYPE RASTER
TILEINDEX "tileHirise2.shp"
TILEITEM "location"
MINSCALE 442860
MAXSCALE 664288
METADATA
"wms_srs" "epsg:4326"
"wms_group_title" "tile_hirise"
"wms_title" "HiRISE_2_512"
END
END
LAYER
NAME "HiRISE_3_512"
GROUP "tile_hirise"
STATUS default
TYPE RASTER
TILEINDEX "tileHirise3.shp"
TILEITEM "location"
MINSCALE 664288
MAXSCALE 885716
METADATA
"wms_srs" "epsg:4326"
"wms_group_title" "tile_hirise"
"wms_title" "HiRISE_3_512"
END
END
LAYER
NAME "HiRISE_4_512"
GROUP "tile_hirise"
STATUS default
TYPE RASTER
TILEINDEX "tileHirise4.shp"
TILEITEM "location"
MINSCALE 885716
MAXSCALE 1107144
METADATA
"wms_srs" "epsg:4326"
"wms_group_title" "tile_hirise"
"wms_title" "HiRISE_4_512"
END
END
LAYER
NAME "HiRISE_5_512"
GROUP "tile_hirise"
STATUS default
TYPE RASTER
TILEINDEX "tileHirise5.shp"
TILEITEM "location"
MINSCALE 1107144
MAXSCALE 1328572
METADATA
"wms_srs" "epsg:4326"
"wms_group_title" "tile_hirise"
"wms_title" "HiRISE_5_512"
END
END
LAYER
NAME "HiRISE_6_512"
GROUP "tile_hirise"
STATUS default
TYPE RASTER
TILEINDEX "tileHirise6.shp"
TILEITEM "location"
MINSCALE 1328572
MAXSCALE 1550000
METADATA
"wms_srs" "epsg:4326"
"wms_group_title" "tile_hirise"
"wms_title" "HiRISE_6_512"
END
END
LAYER
NAME "HiRISE_512"
GROUP "tile_hirise"
STATUS default
TYPE RASTER
TILEINDEX "tileHirise.shp"
TILEITEM "location"
MINSCALE 50
MAXSCALE 221432
METADATA
"wms_srs" "epsg:4326"
"wms_group_title" "tile_hirise"
"wms_title" "HiRISE_512"
END
END
END
Test with JPEG2000 image
MAP
NAME MARS
STATUS on
SIZE 600 600
IMAGETYPE gif
EXTENT -6132851.25 -2339088.25 -6121995.25 -2305531.75
UNITS meters
SHAPEPATH "/home/mphaneuf/public_html/cgi-bin/shapefiles/"
IMAGECOLOR 255 255 255
WEB
#MINSCALE 10000
#MAXSCALE 50000000
#
# On Windows systems, /tmp and /tmp/ms_tmp/ should be created at the root
# of the drive where the .MAP file resides.
#
IMAGEPATH "/usr/local/apache/htdocs/ka-map/htdocs/tmp/"
IMAGEURL "/ka-map/tmp/"
END
# PROJECTION
# "+proj=eqc +lat_ts=-35 +lon_0=180 +x_0=0 +y_0=0 +a=3389574.3490888
+b=3389574.3490888 +units=m +no_defs"
# END
LEGEND
TRANSPARENT true
END
SCALEBAR
TRANSPARENT true
END
LAYER
NAME test_jp2
DATA PSP_008559_1405_RED.JP2
STATUS off
TYPE raster
END
END
Appendix X: Folders and content
Get documents about "