C1PA 2005 XX International Symposium. 26 September-01 October. 2005, Torino, Italy, 
610 
3.THE CARTOGRAPHIC DATA 
3.1 The mapping engine: Mapserver 
both traditional formats such as ESRI shapefilc both spatially 
enabled database tables, such as Postgres-Postgis Server or 
ESRI ArcSDE, or others, can be achieved via OGR. 
The chosen software to deliver cartographic information to the 
web is the University of Minnesota Mapserver. 
MapServer is an Open Source development environment used to 
build spatially-enabled internet applications; it is not a full- 
featured GIS system, but excels at rendering spatial data (maps, 
images, and vector data) suitable for the Web. It was originally 
developed by the University of Minnesota (UMN) for ForNet 
project in cooperation with NASA and the Minnesota 
Department of Natural Resources (MNDNR). Beyond browsing 
GIS data, it allows the creation of "geographic image maps", in 
other words maps that can direct users towards the content. For 
example, the Minnesota DNR Recreation Compass provides 
users with more than 10,000 web pages, reports and maps via a 
single application. The same application serves as a "map 
engine" for other portions of the site, providing spatial context 
where needed. Its main features include: 
• Advanced cartographic output 
• Scale dependent feature drawing and application 
execution 
• Feature labeling including label collision mediation 
• Fully customizable, template driven output 
• TrueType fonts 
• Map element automation (scalebar, reference map, 
and legend) 
• Thematic mapping using logical- or regular 
expression-based classes 
• Support for popular scripting and development 
environments: PHP, Python, Perl, Ruby, Java, and C# 
• Cross-platform support: Linux, Windows, Mac OS X, 
Solaris, (and more) 
• Map projection support * On-the-fly map projection 
with thousands of projections through the Proj.4 
library. 
Many factors were taken into account when choosing the Web 
mapping software: the first was the possibility of using 
preconstituted useful functions; the second one was the 
possibility of personalizing the software, to solve problems 
connected to the project. What is usually called an API 
(Application Programming Interface) was needed in order to 
interface with the software. The last factor was the economic 
aspect of the project. It was necessary to reduce the construction 
costs because they can be an important factor, in particular in 
cultural conservation where sponsors are not so common, or 
funds are only available for limited periods of time or for 
specific projects. Choosing a commercial product also makes 
you dependant on the chosen solution: the terms and conditions 
of the software producer have to be accepted, and they do not 
always meet the users’ requirements. The users are tied to the 
expensive software updating and new releases; everybody can 
surely recall the decision made by ESRI to stop supporting 
Avenue language, forcing thousands of users to rewrite their 
applications in Visual Basic for the new version of the GIS 
software. 
The Politecnico di Torino Geomatics group has already used 
this software in different research projects and have had the 
chance to appreciate its reliability; being an Open Source 
product, it also matched the P.I.C.A. philosophy and 
requirements: low developing and maintenance costs, many 
available functionalities, flexibility and freedom to integrate it 
in a customized application. 
The wide range of supported data formats was also highly 
appreciated; on the raster side almost all the used formats can be 
handled via GDAL libraries, whereas on the vector data side, 
3.2 The unique reference system problem 
The researches group needed cartographic products to map and 
study the culturally interesting territorial sites of the P.I.C.A. 
area. National Cartographic systems maps were obviously 
initially used to georeference the information they had. In the 
early steps of the project the Italian working team started to 
develop a Gauss-Boaga based GIS project, whereas on the 
French side, the team developed a NTF Lambert II etendue one. 
The cooperation between the research groups to plan the 
documentation database structure had also to face the problem 
of different cartographic bases. 
As both National Cartographic systems have reliable conversion 
tools toward WGS84, and considering recent INTERREG II 
choices in the production of border excursion maps, and that 
GPS surveys would have been widely used in the subsequent 
project phases, the cartographic team suggested choosing 
WGS84 as the P.I.C.A. reference system. 
On the Italian side the IGM 2 Verto2 software was used in the 
conversion process, whereas on the French side, commercial 
GIS tools were being used. 
<r I* ** r 4f •** r r r r r MT ** *r 
Figure 6. The UTM zones involved in the P.I.C.A. project 
A dummy projection system was used to display cartographic 
maps on the Web: WGS84 geographic coordinates were 
projected using a fictitious UTM zone (between UTM zone 31 - 
32) with a 6° longitude central meridian. All these 
transformations were made using software procedures based on 
Hirvonen formulas on the Geometry column of the Postgres - 
Postgis Database. This was possible as this spatially enabled 
Database uses the Well-Known Text (WKT) formats to store 
geometric information. 
3.3 The data 
In the project, the geometric data are fundamental key, P.I.C.A. 
project couldn’t exist without; there was a considerable amount 
and different kinds of spatial data and these will increase as the 
project itself develops; they are made up of: 
Istituto Geografico Militare, one of the main Italian 
Cartographic Institutes