LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
27.12.2005
Road map for InfoCoSM Describing the system
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
CONTENTS
CONTENTS 2
INTRODUCTION 5
1 ENVIRONMENTAL ISSUES AND TRADE-OFF AT STAKE IN THE AREA 7
1.1 General characteristics 7 1.2 Environmental problems 8 1.2.1 Surface and coastal water quality 8 1.2.2 Waste management 9 1.2.3 Soil pollution 11 1.2.4 Recreational areas 12 1.2.5 Air pollution 12 1.3 Environmental priorities 14 1.3.1 Kronstadt municipality 14 1.3.2 St. Petersburg City Committee for Environment Protection 14 1.4 Conclusions 15
2 DESCRIPTION OF TARGET USER 16
2.1 General user profiles 16 2.2 Kronstadt as project pilot user 16 2.2.1 Functions supporting organisation goals and objectives 16 2.2.2 Basic features already made available to user 17 2.2.3 Technology available to access and view the information 17 2.2.4 Needs of information 17 2.3 Conclusion 18
3 DATA PROVIDERS AND DATA SETS 19
3.1 Data providers 19 3.2 Data sets 20 3.3 Limitation in the use of information 20 3.4 Conclusions 21
4 TOP-LEVEL OBJECTS 21
4.1 Required and optional elements of a GIS database schema 22 4.2 Description of top-level objects 22 4.3 The data dictionary 23 4.4 The schema 24 4.4.1 Tables and relationships 24 4.4.2 Schema example. 24 4.5 Conclusion 29
2
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
5 SELECT GEOGRAPHIC REPRESENTATION 31
5.1 Coordinate reference system and projections 31 5.2 Working with points and locations 31 5.3 Geographical dataset formats 32 5.4 Resolution and minimum mapping units 32 5.5 Grids 33 5.6 Language and conventions for naming files and attributes 33 5.7 Map extends 33 5.8 Report & map templates 34 5.8.1 Map templates 34 5.8.2 Reports templates 34 5.9 Metadata 35 5.10 Geoservices 35 5.11 Quality and quality control 35
6 METADATA 35
6.1 ISO 19115:2003 Geographic information – Metadata 36 6.2 6.2 ISO 19139 – A schema for implementing 36 6.3 GML 37
7 PROPOSED INFORMATION STRUCTURE 39
7.1 Structure of the information 39 7.2 Content of the information 39 7.2.1 Information Products 39 7.2.2 Themes 40 7.2.3 Supporting Documentation 40 7.3 Organizational functions 40 7.3.1 Restrictions in accessing web services 40 7.3.2 User management 40 7.3.3 Database managers 41 7.3.4 Maintenance & Back-up 41 7.4 General requirements for the client applications 41 7.4.1 Browser interface 41 7.4.2 Other client applications 42
8 OPTIONS 42
8.1 The project Infrastructure for spatial information in Europe (INSPIRE) 42 8.2 Raster servers 43 8.3 RaveGeo streaming vector technology 43 8.3.1 What it takes 44 8.3.2 RaveGeo ArcGIS Plugin 45
CONCLUSION: PUTTING IT TOGETHER 46
REFERENCES 47
3
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
List of Annexes
Annexe I: St. Petersburg administrative divisions 49 Annexe II: Information Resources available by the Committee 50 Annexe III: Top-level Objects 55 Annexe IV: Data Dictionary and Schema 56 Annexe V: Code conversion table 57 Annexe VI: Example of a grid used by the EEA 58
4
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
INTRODUCTION St. Petersburg is the second largest city in Russia with a population of 5 million, and the biggest city on the Baltic Sea. The overall objective of the InfoCoSM project (www.in-foeco.ru), run by the Committee for Nature Use, Environmental Protection and Ecological Safety of St. Petersburg Administration (further, the Committee) is to develop a GIS servic able to provide environmental information for users.
This information strategy intends to give essentials in the development of the InfoCosm information system. Therefore, certain aspects will appear obvious to certain, maybe even too simplistic. We believe however that the combination of all steps proposed hereafter make this document valuable and useful in giving visibility to project's developpement: this is why it can be refer to also as a road map.
All these steps are likely to be taken when developing the GIS services and it is tremendously important that they are understood not only by the specialists in charge of developing the system, but also by those ordering and financing it, i.e. all deciders involved in the decision-making process who can have few to none understandings of what a GIS service is and how it should be managed. The information strategy may be rather seen as a checklist, so that various alternatives for organising the data and distributing it will be considered and not forgotten.
What are the needs? Kronstadt has been chosen as a pilote case-study and therefore environmental problems have been enumerated and described in the in the very first part of the report to understant the Environmental issues and trade-off at stake in the area [page 7]. In particular, several interviews have been conducted with representatives of the Committee and Kronstadt District in order to describe Environmental priorities [page 13]
The Description of target user [page 14] has been made following a visit to Kronstadt administration to better understand the functions supported by the organisation, as well as the source of information already made available to user, the technology currently used to access and view the information, and the needs of information the project should address. Parallel, information resources made available by Data providers [page 17] have been rapidely investigated. Currently the Committee can be seen, at the level of the project, as the unique data provider. Since 1992, the Committee has been gathering a considerable amount of data, a part only of which will be used for the project.
Therefore, one of the first task to undertake is to choose among all available information the most pertinent top-level objects [page 19], to describe them into data dictionaries, and to schematise their relationships best suited to produce the requested information. The production of information will be the most efficient if it sacrifies to a minimum standardisation: geographic representation has to be selected and standardised [page 27]. Such procedures guaranty the compatibility and comparability of data sets
5
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
produced over time, as well as it provides to the information produced a certain homogeneity.
One of the pillar of the project is the development of a solid Metadata information system [page 31]. Many reasons for that: the huge amount of information already stored in Committee's premises should be easily searched and access by Committee's staff; also in a changing environment, metadata remains the memory of the system, something that keeps information about data and that may be consulted at any time. At last, metadata will represent the only visible part of Committee's resources for the public browsing the information system. Metadata will allow them identifying information available at the Committee to ground their request.
Beside metadata, the information system will offer other information products [page 34]: reports, maps & graphs, environmental indicators, and geographic data (for those who are granted access). In the frame of the project, this information will be developed for the priority topics identified in Kronstadt.
The final objective of the all project is to use state-of-the-art technologies and methodologies – not just any fresh ideas thrown up, but those accepted, tested, and used, and those that have a future also. In that sense it is recommended to use established standards (metadata XML, GML, other national and/or international standards). Setting the scene in its general requirements, we must keep the access to information as simple and as fruitful as possible for the user: the final objective is the satisfaction of the user, not the one of the developer of the system.
For any question concerning this report, please contact: Arto Vuorela
6
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
1 ENVIRONMENTAL ISSUES AND TRADE-OFF AT STAKE IN THE AREA
Existing economic statistics, semi-structured interviews with key stakeholders, and detail case studies of selected economic entities have been used to prepare an overview of economic and environmental issues in Kronstadt district. This review allows to target information policy on the most relevant environmental issues and therefore to target the information delivered.
1.1 General characteristics
The city of Kronstadt is located on Kotlin island in the Gulf of Finland at a distance of 24 kilometres from St. Petersburg; Kronstadt district is one of the suburban district of St. Petersburg city. The area of the district is 15 km2 of which 145 hectares of greens. The number of inhabitants in Kronstadt amounts to 44,1 thousand, with a birth rate of 6,3‰ and a mortality rate of 16.2‰.
The densely urban area occupies 170 hectares with a population density of about 720 inhabitants per hectares. A particular territory in the south-west of the island belongs to the Marine factory1 and the arsenal; also an important part of the urban area belongs to military organisations.
The labour population amounts to 6.3 thousand people; distribution per type of employment is shown in Illustration 1, page 7. The monthly average income of workers is RUR 1,551, making a maximum average of RUR 2,008 in housing services, and a minimum average of RUR 1,117 in small business and retail.
The industry comprises shipreparation facilities, storage and maintenance of ammunitions, sewing machine factory, four food processing plants (a bakery, two meat processing plants, and a dairy).
From a sanitary point if view, the average situation of the district does not differ much of this of the city. Adults and children pathologies are almost the same: respiratory diseases, infectious diseases, and skin diseases.
High level of children diseases is said to be linked to soil pollution. Soil pollution is particularly high in the central part of Illustration 1: Kronstadt civil the city, in the former dump site, and in population employment per sector of the south-west. Lead, copper, and zinc activity are the most common pollutants. A direct link between the level of soil pollution and the risk of anomaly at birth, diseases affecting the digestive system, skin and nervous system diseases, have been established. This allowed mapping area where there is a significant impact on health.
7
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
To ameliorate the sanitary state of the city of Kronstadt, the municipality is encouraging the industry located in the centre of the urban area either to move in the outskirts or to change their production to a less toxic or less dangerous one. Several examples have been brought, including one transport company that moves to city's suburbs and one diary factory that modified its production and stopped using ammoniac. Co-operation with the military sector is necessary not only in the harbour but also in the city centre, because there is a storage for dangerous materials to be moved to South-East, and a boiler house that should be closed.
1.2 Environmental problems
The main ecological problems of Kronstadt city have been listed as the following:
1. Pollution of surface water and coastal water of the Gulf of Finland; 2. Waste management (of which civilian, industrial and military-class wastes); 3. Soil pollution; 4. Recreational areas (of which green areas and beaches); 5. Air pollution (including stationary and mobile sources).
1.2.1 Surface and coastal water quality
The water reservoir of the Neva bay in the Gulf of Finland is used as a source of drinking water supply and also as a recreation area. Control over water quality is conducted at three sampling stations: one located at the pumping station and two others on the beach.
According to the result of the monitoring water quality is slowly degrading if considering concentrations of iron, manganese, aluminium, ammoniac, chloro- organic compounds, as well as pH, and content of micro-organisms.
For the last three years, the city of Kronstadt is partly securing water supply form groundwater2 that allows to guaranty its quality, especially concerning bacteriological contamination. Among the 430 samples taken in 2001, only 0.69% did not meet the standards.
Approximately 10,000 m3 of untreated sewage are discharged to the Gulf of Finland through 50 channels or so, coming principally from the industry, and containing hydrocarbons, suspended solids, heavy metals, phosphorus, nitrogen, sulphates in concentrations exceeding several times the admissible ones.
Almost all the sewage channels belong to the Ministry of defence and are located in the historic part of the city; following, their connection to the municipal waste water collector is difficult and costly. Moreover, the municipality does not have any possibility to treat more sewage.
Pollutants concentration around Kotlin island is significantly higher than in the rest of the Neva Bay, due in particular to the effect on streams that had the construction
8
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
of the dam. The bulk of the pollution is yet coming from St. Petersburg, where approximately 320 million cubic meters of sewage are discharged into the Gulf of Finland without any treatment. Also as mentioned earlier, sewage is discharged from Kronstadt as well, from approximately 50 industrial outlets. Also the big number of ships and vessels in harbours represent another source of pollution as most of them discharge their sewage directly to the port. Observations have shown that concentrations in sediments of Kronstadt harbour exceeds admissible concentrations by 370 times for mercury, 30 times for phenols, 8.4 times for hydrocarbons, and 6 times for chlorides. Soil pollution in berthing areas exceeds background concentrations by 107 times for hydrocarbons, 15 times for mercury, 4 times for copper, and twice for nickel, zinc, and copper.
A tanker refilling station is located not far from the island. In fact, 11 million tonnes of oil transit each year via St. Petersburg. They are transported by the Neva to St. Petersburg on barges that can carry between 4,000 and 8,000 tonnes of oil. More than 4,000 of them enter each year the Gulf of Finland to transport their oil to the refilling station. There, bigger sea tanker are filling their reservoirs and transport it to Rotterdam. During replenishment, tankers are usually discharging ballast water and the Committee is conducting monitoring, particularly biological monitoring to identify alien species. Kronstadt has not been touched by these phenomena yet.
Distance from St Petersburg creates particular difficulties in liquidation of marine pollution by hydrocarbons, especially in winter time. In St. Petersburg, emergency services may be ready in 2-3 hours, but it took them the same time only to cover the distance from St Petersburg to Kronstadt. Six hours would be then necessary to reach pollution spot that reduces effectiveness of measures taken, especially in bad weather conditions. In 2004, a particular programme was conducted thanks to the collaboration with Hamburg City. One ship is now based permanently on Kotlin Island and is ready for intervention. Oil-spill problem is actual: first, because of the fleet standing in Kronstadt and, second, because of oil tankers refilling not far from the island in the Gulf of Finland. Oil spills have been frequent in the past few years. The creation of an emergency service in Kronstadt allowed to reduce operative time to 1 or 3 hours.
Kronstadt is equipped with a water treatment plant especially dedicated to the treatment of diluted hydrocarbons; this could allow treating effluent from Kronstadt ships and vessels, but the plant requires modernisation.
1.2.2 Waste management
1.2.2.1 Civilian and industrial-class wastes
Nowadays municipal solid waste is transported to Novoselki waste dump located at a distance of 40 km from Kronstadt; waste transport generates significant costs. In the past few years, the degradation of living conditions in military areas favoured environmental hazardous behaviour as burning domestic waste on the area itself, that worsens air quality. The municipality of Kronstadt conducted an inventory of
9
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
domestic and industrial waste sources and different solutions for waste management are foreseen, but no decision has been yet made.
Two sources of toxic waste have been registered: the Marine factory and Arsenal; these factories are evacuating waste to the Krasny Bor toxic waste dump. In 2005, 8,000 tube lamps (containing mercury) have been collected. It seems like there is no organized collection for other problematic municipality wastes like car batteries. The Housing committee is controlling waste collect and treatment.
Illegal waste dumping is a major concern for the municipality. In 2004, 325 m3 of such rubbish has been cleaned, and 300 m3 in 2005. Though municipality try to keep control over illegal dumps, it seems rather difficult to say if cleaning goes quicker than waste is discharged. Certain places are really problematic, for example around the gardening areas; such areas should be monitored and cleaned more often. However, according to municipal representatives, the situation seems stabilised.
Since the middle of the XIX Century and until 1987, a domestic waste dump was in use on Kotlin; certain assertions let think that it has been use for dumping industrial waste products as well. The dump is located in close vicinity of the coastal zone and occupies an area of approximately five hectares.
Although the dump is now closed, its impact on the environment still persist as shown by soil sampling results in 1993-1997. It could represent a risk for marine environment due to its proximity from the Gulf of Finland and its high concentration in pollutants and toxic substances as arsenic cadmium and copper, as well as for cobalt, nickel, and mercury.
The former domestic dump is said to be a source of contamination by heavy metals able to reach surface and groundwater, or subject to dispersion by the wind. The absence of control in the past of the waste dumped may have resulted in discharge of radionuclide that may have migrated from outside the dump site. Also this site as been the only place for dumping waste for 280 years; taking into account the military status of the island, there is a high risk that toxic wastes have also been discharged. Monitoring has shown that lead, zinc, and copper are exceeding admissible concentrations in soils by 30 to 50 times, and nickel and chrome by 5 to 10 times. Mobile forms of lead and zinc represent 40% of over whole concentrations that facilitate contaminants leaching by precipitations and thus their migration. However, monitoring of coastal areas in vicinity of the dump does not show evidences of coastal water pollution. Mitigation measures would include the gathering of waste on an area as small as possible, its coverage and re-cultivation (plantation of herbal cover), and the construction of a water proof barrier (clay wall) between the dump and the coastal area; the cost of the project reaches one million dollars.
10
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
1.2.2.2 Military-class wastes
Until recently, 18 sunk vessels were inventoried, 26 others were in very bad condition and could sink at any time, and 10 more had ran aground; most of them belonged to the Russian navy. Number of abandoned ships and vessels was augmenting every year.
The district has achieved positive results however in removing these sunk boat. In 2004 only, twenty of them were removed, seventeen in 2005, and the remaining should be removed in 2006. Such action required the financial support of the Committee for environmental protection of the City and close collaboration with the military authorities that were conducting the works.
A major drawback in collecting such particular type of waste is that cutting of these ships for recycling metal is usually conducted without enough care to prevent pollution, that results in discharge of hydrocarbons contained in vessels' tankers.
Concrete measures are said to be taken for the protection of inhabitants and the environment from the risks linked to ammunition storage and dangerous chemicals located in military storage facilities. In particular, safety areas have been organised around ammunitions or toxic substances storages. This thematic is very particular and therefore falls out of the scope of the project.
1.2.3 Soil pollution
All the territory of the city has been monitored for heavy metal following a 200 per 200 meters, resulting in 317 samples. As a result, the average content of zinc exceeds ten times the permissible concentration limits, and six times for the copper, and is equal to permissible concentrations for the cadmium. Pollution of soil is on average comparable to the level found in St. Petersburg in general. Nevertheless, average concentrations hide strong variation of pollution levels between east and west of the territory, as the level of pollution by zinc is lower than the permissible concentrations in the west, it becomes representative extremely high in the east.
The pollution of Kotlin Island by zinc and copper significantly exceeds average city level. The main polluter is the industrial and military complex of the Russian navy, and the Marine factory.
The territory highly contaminated occupies 6% of the whole district's territory, and 10% of the industrial area located in the eastern part. Eighteen of the thirty-five radiologically contaminated sites are located on territories belonging to the navy.
Data concerning pollution of the territory by organic compounds are missing, though the military and industrial complex is certainly a source of pollution. According to the average level of pollution by chemical products, the district of Kronstadt occupies the th rank among the districts of the city. Nevertheless, if considering the eastern part only, this ranking shifts to the 3rd or 4th place.
11
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
1.2.4 Recreational areas
Beaches have been rebuilt in 1976-77 that resulted in the creation of 11,000 m2 of sandy areas with a water reservoir of approximatively 13 hectares and a deepness up to 3.5 meters. The beach is regularly open for swimming and answer all sanitary requirements, thought bacteriological pollution have been noticed from time to time.
At the moment, greens in the city are in a proportion of 50 m2 per inhabitants, a figure lower than in the past. A lot of trees are planted annually, but the oldest trees also have to be cut down. The balance is nowadays close to zero. In the 70’s, new residential areas were created on the East side of the city where the ring road is now being built. The inhabitants are afraid of the noise from the highway as the closest houses are in a distance of 200 meters from the road. First there were plans to plant a tree barrier, but the plans changed to go for noise walls. The administration would like to have more research on the possible impact of the road: 22 000 cars are estimated to pass the ring road daily. The ring road represents also a future air pollution source for the neighbouring habitations due to predominating west and south-west winds. This is why the plantation of trees on approximately 20 hectares is still seen by the municipality as a possible counter-measure. Generally speaking, the population of Kronstadt is concerned by the possible impact that could have the construction of the dam and of the ring-road on their quality of life.
In the frame of the general plan of St. Petersburg, the City plans to create a protected area in the western part of the Island with strict limitations on human activities, to protect fish spawning and bird nesting areas. This is however only a plan and no concrete measures have been yet taken.
1.2.5 Air pollution Air quality on the island of Kotlin is satisfactory compared to other parts of the city. This is due to dominating wind blowing from west and south-west and to the geographic isolation of the district, surrounded by marine environment: emissions from industry or transportation sources from other city's districts do not reach the island.
The main stationary sources of air pollution on the island are the Marine factory and coal-running boilers-houses belonging to the Ministry of defence. Beside boiler- houses running on natural gas (boilers from the city, the Marine factory, the Arsenal, and Vodokanal), there are 24 boilers running with coal that belong to the Ministry of Defence and that represents the main source of air pollution. The condition of these boilers is also not satisfactory as the equipment is over used and particular measures should be taken toward these sources of pollution in case of unfavourable environmental conditions.
A high environmental improvement priority is given for the coal burning units. On the other hand, their number has been reducing (by 50% in the past 15 years). And many are being transferred to use natural gas instead of coal.
12
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
Air pollution due to traffic increases together with the level of cars of the households. Although Kotlin is located on the track of city's ring road, its impact on air quality may be yet neglected as this part of the road is not yet completed; the situation should be monitored as it can change drastically with the development of the traffic.
The impact of air pollution is usually considered as satisfactory as the territory is well ventilated.
The Northwest Direction for Hydrometeorological Services does conduct monitoring neither of surface water nor of air quality. One automated air quality monitoring station managed by St. Petersburg administration is installed on the territory. Radiological monitoring is done only in one point located on Lenin prospect 36.
GosSanepidnazor is conducting monitoring of air quality in Kronstadt on one sampling point for which 17 parameters are sampled.
Year Nub. of Samples Of which exceeding AC 1997 346 7 1998 519 15 1999 596 4 2000 635 1 2001 673 1
Table 1: Dynamic of air pollution for the years 1997-2001 according to GosSanepidnazor
Air pollution is lowering for the last few years, first of all due to a decrease in industrial activities. Dust, phenol, formaldehyde, hydrogen chloride, and ethyl- benzene are usually found in concentrations exceeding admissible concentrations. According to the data of Sanepidnazor, air condition in Kronstadt is however one of the best in the city.
13
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
1.3 Environmental priorities
Both Kronstadt municipal officers and representatives of the Committee have been asked to describe what they consider to be environmental priorities in the area.
1.3.1 Kronstadt municipality
According to Kronstadt municipal civil officers interviewed, environmental issues and priorities of the island are as follows: 1. Pollution of air by small boiler houses running on coal and belonging to the Ministry of defence; their number has been divided by 2 during the last 15 years; the solution is to replace coal by natural gas. This requires a close collaboration with the Ministry of Defence; 2. Quality of surface water and water of the Gulf of Finland, principally due to discharges from St. Petersburg and military ships standing in the port; 3. Cleaning of channels that were used in the past either for defence purposes (Krontversky), either for transporting goods from the port (obvodny kanal); they need nowadays to be cleaned and deepened; 4. Discharge of untreated waste water from Kronstadt directly to the coastal sea, either untreated or unsatisfactory treated; this is mostly under the competencies of Vodokanal and of the Ministry of Defence; 5. Reduction of green areas of public use.
1.3.2 St. Petersburg City Committee for Environment Protection
The committee for environment protection formulates a very similar diagnosis of the situation. For the Committee, environmental priorities include:
Air pollution, first of all because pollution levels are expected to raise following the completion of St. Petersburg ring road as the highway lies at the south and south- west of Kronstadt, under dominating winds blowing toward the city. Pollutants released by the traffic could be dispersed up to 500 meters on each side of the highway and therefore augment air pollution pressure on certain part of the island. This segment of the ring road should be opened by 2008. As the cost of the project has doubled compared to what was foreseen, most of the mitigation measures (as planting trees along the road) have been abandoned.
However, and according to the Committee, questions related to air pollution may be of less importance for district administration, as it has very few possibility to influence the situation. Pollution levels may be taken into account when locating e.g. children educational organisation (schools, kindergarten, etc.) to make sure that the latter will not be affected by pollution.
Second priority is green areas for public use. All green areas will be inventoried and mapped in St. Petersburg city until the 1st January 2006 and will have an ecological passport, i.e. a document containing a lot of descriptive data. Starting from February 2006, the Committee should proceed with inventorying and mapping each tree.
14
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
The third priority is the level of soil pollution, including the problem of the former Kronstadt dump site. No monitoring have been made on the part of the pollution that could migrate. Only average data is available. The complete monitoring of soil quality will be available by the year 2006. Also the Committee is monitoring the water quality of the Neva mouth mostly to assess the impact of the work of the south-west waste water treatment plant that has been put into service in September this year. Monitoring is conducted on a monthly bases in 22 sampling points. Monitoring results are then compared to the results obtained by modelling pollutant transport in the Gulf of Finland. The question is still to know if Kronstadt needs this information?
Kronstadt will certainly and definitively be interested in such information layers as land use, and especially cadastrial data that is used to collect taxes on land use, to inventory and identify owner of parcels, green areas, the level of soil pollution that influences the price of the soil for investors as the higher the soil pollution the higher the rehabilitation costs will be.
Another example would be the coastal areas for public use as well as protected water reservoirs that should be cleaned from floating rubbish and wastes. Nobody knows actually the length of the coastal line that should be cleaned by Kronstadt and therefore the City budget can not be modified in accordance. Once the coastal areas have been determined and mapped, and knowing the average cost of cleaning, it becomes possible to estimate the total budget necessary to clean the coast. Another problem is related to cadastrial data and parcel ownership. Prior to conduct any rehabilitation measures, owners of the parcels should be identified as the budget of the city should be used to clean only the land belonging to the city.
1.4 Conclusions
With regard to the description of the environmental situation, the definition of environmental priorities is relatively straightforward, except when Kronstadt municipality pointed out surface water quality, while the Committee considered this priority mostly out of the scope of municipal interest except for inland water (channels).
15
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
2 DESCRIPTION OF TARGET USER
The information provided hereafter is coming from interviews of Committee's representatives as well as from the proceedings of the Second Steering Committee of the project, held in St. Petersburg on November 1st November 2005.
2.1 General user profiles
When purchasing the data, the Committee purchases also the rights to use it, but not to distribute it; such a restriction that is brought by data providers to almost all contracts. Therefore, the data can be used to fulfill the tasks of the Committee, but cannot be transferred to third parties. This explains why, municipalities, stakeholders, and the large public will have only a limited access to information resources. Only City Districts, i.e. territorial units under City's administration, may be granted a full access to data.
Full access to data will be granted to third parties only on contract basis, but there is no plan to provide information to advanced users using on-line information system.
2.2 Kronstadt as project pilot user
2.2.1 Functions supporting organisation goals and objectives
Basic functions of the district administration in term of environment protection and ecological safety are globally inherited from those of the Committee: informing and alerting. However, Kronstadt district administration lacks human and financial resources to face environmental problems. The only ecologist of the administration is neither specialist nor specialised, and deals with environmental problems among others.
As it appeared during the course of the discussion, deciders at district's level lack both the information and the technical knowledge to understand environmental issues. As a consequence, environmental problems are usually not considered at district's level, though they are likely to exist.
For the same reasons, the role of the district in environmental education is limited. Experiences working with schools have been reported, restricted however by the lack of educational materials. Successful actions show that positive results may be achieved when involving the District, e.g. for cleaning illegal waste dumps, collecting tube lamps, or removing shipwrecks.
16
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
2.2.2 Basic features already made available to user
The city has a centralized information system, AIS100 (Automated Information System), but it is not for environmental problems. AIS100 contains simplified maps, showing details of house and flats therein, and enabling search from the census data (e.g. number of inhabitants per building and some other cadastral information). A Computer Centre company is preparing and manually up-grading regularly the data on each working station using data on a CD.
The “Working Station of the District's Ecologist” worked out by the Regional GeoEcological Centre in 1997 is an ArcView 3.0 application, opening one of 3 themes. The first concerns heavy metal concentration in soils, based on a 1997 year measurement grid. There is no update plan. The second theme concerns the radiological situation. There is no ongoing monitoring, but it is usually done on request. The third and last theme concerns pollution by mercury that was meant for solving pollution cases. The information contained in the system is not used, first because it is out of date, and second because it does not answer disctrict's needs of information.
The waste management system3 is presently based on MS Excel tables. Previously another system was in use, 1S, but it has been judged too complicated to use and using Excel was preferred. The company collecting the waste is originally filling the information into special forms. Then the data is handled twice: once a month at District's level to compile information, and a second time every quarter at Housing Committee's level to compile information issued by all the districts of St. Petersburg city.
On the local server, there are search tools to find documents, telephone numbers, legal acts database (CODEX). News and documents are updated twice a week. The intranet seems to be a nicely working environment.
2.2.3 Technology available to access and view the information
Many civil servants have access neither to the intranet nor to the internet. Current administrative rules stipulate that there must be no direct access from the work station to the internet. District level network and the internet must be physically separated. There is only one PC with an internet connection located at the information and communication department. Reasons for such practices are not clear: are they to protect the administrative network from intrusion, or to limit civil servants' access to external network? Internet-based tools are however not likely to be adopted into wide use even if they were available.
Therefore, instead of building only a map server, used at the one and only PC in the city office, it is reasonable to think of building a mirror server, for which a subset of the data is prepared and separately transferred to (for example in night time or on external hard disks) to the city intranet. Incremental up-dates may be preferred to limit the amount of data to be transferred.
17
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
However, situation may evolve fast. In 2006, an intranet connecting all administrative bodies (including districts) is planned to be developed. Waste information system is also to be changed as a new programme should be introduced, but no details have been given on its functionalities.
2.2.4 Needs of information
Most of the new information is coming in paper form, and is nearly limited to the yearly state of the environment report. Most of the data is solely owned by the Committee and not reaching Kronstadt. At local level, information would be used for preparing annual work plans, for formulating local problems, and for grounding local requests toward City Council or Committees with solid information. Information would be needed also for coordinating the action of authorities locally. Removing sunk ships required from Kronstadt District to convince both the ministry of defence, who owned the ships, and the ministry of environment, who financed the operation. There are neither standard ways nor regular meetings or established procedures to take proposals to committees. Discussions have to be held with all relevant committees first, before gathering them together, freely. An active role of Kronstadt city is always needed in order to make things happening. Precise information would help defending local opinions against various other interests (e.g. military) or to obtain subsidies from the economic & development committee that allocate the budget.
At district level, the information provided by the Committee would be used for: 1. informing District's authority about information resources available in the Committee and on the way to receive them; 2. providing information to District's deciders on the state of the environment in order to take into account environment in the decision- making process; 3. supporting or justifying environmental projects of local significance; 4. managing specific environmental-related problems as e.g. illegal waste dumping, urban green areas, gardening areas management, etc. 5. informing Kronstadt's inhabitants on the state of the environment.
2.3 Conclusion
The basic functions of District's environmental specialist is to inform and alert local deciders on environmental problems, to conduct environmental project of local significance, and to inform the population.
The District however lacks both human and financial resources to conduct its tasks and has very few information to ground its decision. Technology is yet almost limited to the administration's intranet. Internet, due to specific limitations, is not usable.
18
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
When available, information would help defending local opinions against various other interests (e.g. military) or to obtain subsidies from the economic & development committee that allocate the budget. informing the population.
3 DATA PROVIDERS AND DATA SETS
3.1 Data providers
All information is aquired and centralised first by the Committee who has passed unlimited agreement with other committees and resulting in an exchange of data among administrative entities concerned. All other information is bought, from e.g. Sanepidnazor (four databases annually about quality of air, water, soil, and noise pollution), from the committee for statistics (six databases annually), and a very important database that concerns companies. Stringent requirement are given to producers and the Committee prefers buying and ordering the data in order to receive data with higher quality. Agreements are made on an annual bases and prices are revised annually.
19
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
In addition to the databases the Committee receives are buy, it produces its own information as a result of its routine activities or as subcontracted agreements (e.g. digitalisation). Another type of work is the maintenance of a normative database comprising approximately 86 sources of official norms that may be applied to the environment. Only for air quality, Russia has three different normative systems and therefore different admissible concentrations limits.
The cost of data management should be kept as a minimum to allow further development of the system to other districts and, especially, to keep the running costs as reasonable as possible. Unfortunately, certain districts have developed their own GIS in the past few years; some of them existing as unique exemplar without equivalent, and data format is too specific to allow compatibility with other GIS. In such a case, technical difficulties faced when exchanging data make the cost of data management too high. The Committee still need to prove, however, the advantages of the use of a centralised information system.
3.2 Data sets
Annually the Committee integrates up to twenty new databases in its information system, the total number of database should reach 300 by the end of 2005. Dataset available for the project and relevant to environmental priorities defined in 1.4, page 14, are listed in Annexe II, page 44. Note that data is already organised into logical set of features. The data is gathered by the Committee and updated regularly at interval depending on the data itself (continuously, monthly, quarterly, or annually). When up-dated new files are added to existing ones. Certain data historic exists back to 1992. However, the form of reporting has changed, or the structure of the files has evolved over time, also certain parameters are changing quickly that makes the whole dataset difficult to understand for a non-specialist or a novice. The databases may contain errors and the role of the Committee is also to check data consistency.
3.3 Limitation in the use of information
As already mentioned, the Committee is bying the rights to use the data, but not to distribute it; such a restriction is brought to almost all contracts on data acquisition. Therefore, the data can be used to fulfil the task of the Committee, but can not be fully and freely transferred to third parties.
Information is a product having a commercial value and St. Petersburg city will not give free access to the data it gathered on its own financial resources. The Committee itself has no rights to sale any data whatsoever: it can even not request payment for data extraction. Even if it could do so, the payment would be directed to the central budget and would not be available for the needs of the Committee.
20
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
The information system will not be used to provide information to advanced users. The latter should address the Committee in written and grounds their requests. As soon as rules are different for each user, contracts are concluded on a case-by-case basis, exposing the rights and duties of the parties. Access to the core data may be granted free of charge to students and researchers who may bring an independent expertise complementary to Committee's own investigations.
3.4 Conclusions
The Committee is the ultimate data provider for the project. All agreements with other data providers remain ”beyond the scene”. The number of dataset available is huge, still growing, and represents the best available resources. Data access an distribution is restricted due to its commercial value, at least for the data bought by the Committee. Therefore two type of users may be defined: the Committee itself and its branches (e.g. Kronstadt administration) whose staff may be granted access to the whole set of data, and and the rest of the world whose access shall be restricted.
4 TOP-LEVEL OBJECTS
A key task of building a GIS information system is to define top-level objects and to schematise their relationship through a database schema. At first, and at its simpliest, the schema consists in an arrangement of tables and the relashionships among them. At this stage, we may defined required and optional elements of a more complete database scheme. Unfortunately, without subset of data the demonstration will be limited to a few examples and general considerations.
21
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
4.1 Required and optional elements of a GIS database schema
A data dictionary that describes the content of the various tables in the database and a schema of tables and the relationships among them are the central elements at this stage. The all information system will contain in definitive much more than simply tables and a data dictionary, but the design of the tables and the relationship between them is at the core of the schema.
The way data available at the Committee and pertaining to our task is presented in Annexe II, page 44, does allow neither to see top-level objects nor to identify relationships among objects.
The first task will therefore to list top-level objects, to describe them into the data dictionary, and to illustrate their relationships.
4.2 Description of top-level objects
Top-level objects can be shortly defined as primary features or data from which other features or data are diverted, but which can not be themselves diverted from any other features or data. For example, if listing of resources under 01 -Physico-geographical characteristics of the territory, the layer of Surface water reservoirs (resources code 010401) can be seen as such top-level objects. The number, size, and location of each surface water body is factual; note however that some characteristics, as name or intended uses for example, are more conventional.
On the opposite, the Index of water pollution (resources code 010412) is not a top- level object as it depends from several others: the location of water quality monitoring stations, their number, the number of parameters measured, the frequency of the measurments, the methodology used for the calculation of the index, etc.
At last, certains parameters may be considered as top level objects or as derivated ones, depending on the accuracy of the observations, or on the needs of data users. For example, the recharge area of water reservoirs (resource code 010403) is not a top-level object as it depends from geological, soil, and relief characteristics (slopes and permeability essentially); however, if the area of the recharge is not likely to be modified, it can be treated as a top-level object to simplify. On the contrary, if the recharge area is rather small or submitted to strong anthropogenic impacts, changes in its characteristics should be monitored: evolution of the permeability of the surface, water extraction, dewatering, mining and quarrying works, etc. In this case, the recharge area is derivated from the parameters monitored.
22
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
A proposed list of top-level objects extracted from the Annexe II, page 44 and concerning water resources is presented in Annexe III, page 49. The number of datasets is reduced from 54 to 18.
4.3 The data dictionary
The data dictionary is a field-by-field description of each field in each table. At a minimum it must include the data type (e.g. numeric, text, data, image), the space it requires in the field (if appropriate for the data type), and a description of the data. Optionnally the data dictionary can contains domains and validation rules that explicitly defined allowed ranges for data and acceptable unique values for certain fields. For example, the data allowed in the field for the date a water permit began could be restricted to be only the date on which the form was filled out.
A data dictionary can be as simple as a table or a dozen of pages documents detailling all alternative values, codes, or abreviations an item can take. Example of a data dictionary is given in Annexe IV, page 50.
23
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
4.4 The schema
4.4.1 Tables and relationships
The schema is a diagram that shows the relationships among the various tables in the databases. The relationships between tables, called cardinality, can be one to one, one to many, or many to many.
A schema can include all level of details or, on the contrary, can be kept very simple. The bottom limit would be where the conceptors do not have the minimum information to build the architecture of the database, and the upper limit where the decidors loose control over what is being done. The right level of details is somewhere between these two limits.
The key issue in the schema design is that each table should represent a distinct class of objects and only information that relates to that type of object should be present in the table.
Detailling the relationship forces system conceptor to think about primary and foreign keys for the tables. A primary key in a table is a field that contains a unique identifier that is not duplicated for any feature in the table. Foreign keys are primary keys in other tables.
4.4.2 Schema example
We may think of an example where Kronstadt District would need a database to manage water intakes and water users, knowing what water reservoirs are used, where are the water intake points, by who they are used, what for, under what licences, and what agreements.
4.4.2.1 Step I: identify the possible classes of objects
The first step is to identify, among all available information, the one needed to build the database. Among the information resources owned by the Committee, and listed in Annexe II, page 44, we may identify the following objects pertinent to our task: • Surface water reservoirs (010401) • Points of water intakes (120301) • Characteristics of water intake from water reservoirs (010408) • Points of water intake (120301) • Characteristics of water intakes from surface water (120305) • Agreement on the use of water body (120305) • Licence on the use of water body (120306) • Address of long-term rent (120101) • Address of short-term rent (120102) • Real-estate (120103) • Characteristics of real estate (120104) • Juridical and physical persons as nature users (120110)
24
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
At this level two information sources seem confusing: the Characteristics of water intake from water reservoirs (010408) and the Characteristics of water intakes from surface water (120305). Having no precision on the data contained in these datasets, we will assume the characteristics of water intakes from water reservoirs and surface water may be grouped into the same table: Characteristics of water intake.
Another remark can be formulated concerning the Address of long-term rent (120101) and Address of short-term rent (120102). It seems a priori possible to simplify by adding a duration of the rent field and to merge the two tables into one Address of rent. Also possibly the Address of short-term or long-term rent should be part of the Characteristics of real estate (120104); the fact to keep this characteristic apart is questionable. We will consider the Address as an integral part of real-estate characteristics.
Remark: errors on the meaning of datasets or on the way they should be handled may occur. Such mistakes will be corrected by collaborating with the person who prepared the dataset or when compulsing the documentation related to that dataset (dictionnary or metadata).
Without subset of the data it is not possible in our particular case to check for the consistency of the classes within each object. All objects selected at this stage are top-level objects.
4.4.2.2 Step II: Sketch the relationship between the tables
In our example we have choosen to link tables in a particular – and somewhat artificial – way. In reality, these relationships are guided both by the objectives assigned to the database, and by the content fo each table. At that level, the cardinality is between objects is not considered, instead we will focus on how tables are related to each others.
For example, the Characteristics of water intake from water reservoirs (010408) may contain information proper to the water intake but not linked to its use (e.g. maximum water supply, type of pumps, organisation owning or serving the intake, etc.). In that case, the table 010408 will be connected only to the table Points of water intake (120301).
Another example could have seen in the Characteristics of water intake from water reservoirs (010408) a table containing information linked to water use (e.g. average water intake per user). In that case, the table 010408 would not be linked only to the Points of water intake (120301) table as in our example, but also to the Real- estate (120103) table.
25
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
Also in our example we have assumed that water users own licences, which are necessary to obtain agreements (and not the contrary); we also considered that these agreements concern water intakes rather than e.g. the real estate property or the water reservoir. The resulting schema is shown in Illustration 2, page 23.
4.4.2.3 Step III: Detail the relationships
Once the main relationships are established, we may detail the type of relationship, based on their cardinality.
Cardinality defines the numeric relationships between occurrences of the entities on either end of the relationship line. The values are zero, one, or many. The basic types of connectivity for relations are: one-to-one, one-to-many, and many-to- many.
• A one-to-one (1:1) relationship is when at most one instance of a entity A is associated with one instance of entity B. For example, A is the Points of water intake (120301) table and B is the Characteristics of water intakes (120305) table. In this case, for each instance of A (water intake) it exists one and only one instance of B (description); on the opposite, each description of B refers to one and only one water intake of A; • A one-to-many (1:N) relationships is when for one instance of entity A, there are zero, one, or many instances of entity B, but for one instance of entity B, there is only one instance of entity A. For example, A is the Surface water reservoirs (010401) table and B is the Points of water intakes (120301) table. In that case, for one instance of A (a water reservoir) there may be zero, one, or many instances of B (water intakes). On the opposite, for each instance of B there must be (mandatory) one and only one instance of A.
• A many-to-many (M:N) relationship, is when for one instance of entity A, there are zero, one, or many instances of entity B, and for one instance of entity B there are zero, one, or many instances of entity A. Consider the relationship between agreements and water intakes: we may suppose that each agreement concerns one or more water intakes (zero is excluded); on the opposite, each water intake can be the object of zero (e.g. if not used), one, or more agreements.
26
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
Illustration 2: Building the relationships between the tables
27
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
Many-to-many relationships cannot be directly translated to relational tables but instead must be transformed into two or more one-to-many relationships using associative entities called composite or link tables. Though these composite tables are very important to maintain the most complex of the relationships, they remain beyond the scene and will never been seen by users.
In our example, the following relationships may be detailed:
Surface water reservoirs (010401) and Points of water intakes (120301): there are from 0 to many points of water intake on a reservoir; on the opposite, for each water intake there is one and only one water reservoir (one mandatory-to-many relationship); Points of water intakes (120301) and Characteristics of water intakes from surface water (120305): characteristics are attached to each water intake; on the opposite, each water intake has its own characteristics. The relationship is here one-to-one; Points of water intakes (120301) and Real-estate (120103): each real estate property may have zero to many water intakes and each water intake may be used by zero or many real estate property. Keeping 0 as an option allows to account for situations where e.g. the water intake is momentaneously not used or, on the opposite, where the real estate property is not using any water intake. A link table will be required to describe this complex relationship; Real-estate (120103) and Characteristics of real estate (120104) is a one-to-one relationship; Real-estate (120103) and Juridical and physical persons as nature users (120110) is a many to many relationship: a nature user may owns zero to many real estate properties and a property may be owned by zero or many nature users. Here again a link table is necessary; Juridical and physical persons as nature users (120110) and Licence on the use of water body (120306): a nature user may have zero or many licenses on the use of water bodies; on the opposite a license may be delivered to one and only one nature user. This is a one-to-many relationship; Licence on the use of water body (120306) and Agreement on the use of water body (120305): each license may give the right to conclude zero or many agreements; on the opposite, one agreement may require at least one (mandatory) or many licences. The relationship is here many-to-many and will also require a link table; Agreement on the use of water body (120305) and Points of water intakes (120301): each agreement refers at least to one or many water intakes; on the opposite, a water intake may be concerned by zero or many agreements. The relationship is there again a many-to-many relationship.
The table relationship schema (also known as the Entity-Relationship Model) illustrates the resulting schema obtained in our example (see next page).
28
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
4.5 Conclusion
Our example is somewhat artificial as we do not have a subset of the data and we have to guess a lot on the possible content of one or another table. This could lead to surprising relationships for those who know the real content of each table! Nevertheless, this example illustrates quite well the principes and the result obtained. The schema presented in possesses at least two advantages: 1. it does not requires particular skills to be understood; 2. it may be the result of an initial work of identifying the tables and the relationships among them done by a group with nothing more than a large piece of paper and a marker.
To be effective, the schema must be simple enough to communicate to the end user the data structure required by the database, but yet detailed enough for the database designer to use it to create the physical structure.
Another example of a database schema, taken from a real case, is given in Annexe IV, page 50.
29
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
Illustration 3: The table relationship schema (also known as the Entity-Relationship Model)
30
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
5 SELECT GEOGRAPHIC REPRESENTATION
This part is all about standardising the procedures used to produce or publish information. As soon as the number of information resources and the amount of data grow, there becomes a strong need for stringent procedures to ● ameliorate productivity and lower costs, ●secure quality, ●enhance dataset consistency over time and topics. Guidelines and templates are needed at this time to be used internally by Committee's staff or by third parties working with or for the Committee. That's what we call standardising the production.
5.1 Coordinate reference system and projections Addressing coordinate systems and Projected coordinate system in use projection in Russia remains taboo but is in Russia (St. Petersburg) obviously unavoidable for who wants to work with GIS and greographic data. If the Pulkovo_1942_GK_Zone_5 Committee is using a particular projection Projection: Gauss_Kruger system, a prj-file should be produced to be False_Easting: 5500000.00000000 used in ArcGIS. False_Northing: 0.00000000 Central_Meridian: 27.00000000 In ArcGIS it is possible to copy such file to Scale_Factor: 1.00000000 the directory of projections. prj-files for the Latitude_Of_Origin: 0.00000000 most common projection(s) used by the Linear Unit: Meter (1.000000) Committee should be available to all Geographic coordinates system: Committee's data providers and customers. GCS_Pulkovo_1942 Datum:D_Pulkovo_1942 When placed in the correct directory, these Main meridian:0 projections will be available as an option under predefined projections in ArcGIS 9.x. The prj-files should be placed in: arcexe9x/Coordinate Systems/Projected Coordinate Systems/Continental/Europe.
5.2 Working with points and locations
The Committee receives and will receive more and more data in tabular form where the locations are georeferenced: e.g. point locations for cities, water quality stations, waste treatment sites, oil spill sites, etc. Incorrect positions or formatting in the files delivered to the Committee will later on cause unsolvable problems and unnecessary workload.
Degrees/minutes/seconds (DMS) are a unit of measure for describing latitude and longitude. However point data delivered in DMS format is not suitable for GIS systems. Therefore all point locations should always be delivered to the Committee in latitude/longitude decimal degrees (DD) and not in DMS format.
31
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
5.3 Geographical dataset formats
Defining preferred (or even compulsory) geographical datasets may preserve the Committee from handling numerous different file formats; this will also allow to harmonise user agent or client applications for viewing and working with the data.
ERDAS® imagine (IMG) and Geographic Tag Image File Format (GeoTIFF) are compatible with most GIS software. ERDAS IMG benefits from a high compression ratio without data loss, it supports any colour depth, and possesses a detailed header information.
The ESRI® Shape file (SHP) is certainly the most common vector file. It is compatible with most GIS software. Major drawbacks are that datasets having several types of shapes (feature classes) or several tables need more than one shape file/table file. Microsoft Access® Database (MDB) and dBASE5® (DBF) are both common table formats. Access may store multiple tables as a relational database. Both formats are widely accepted by all systems.
5.4 Resolution and minimum mapping units
Resolution refers to the detail with which a map depicts the location and shape of geographic features, like e.g. the smallest spacing between two display elements. The larger the map scale, the higher the possible resolution. As scale decreases, resolution diminishes and feature boundaries must be smoothed, simplified, or not shown at all; for example, small areas may have to be represented as points. In a raster, the resolution is
Resolution in meters at different scale (Source: EEA)
1:10 000 ca. 3 metres 1:50 000 ca. 15 metres 1:100 000 30–50 metres 1:1 million 300–500 metres
Minimum mapping unit
1:100 000: all areas smaller than 250 000 m2 (25 ha) eliminated 3 mill.: all areas smaller than 2 250 000 m2 (225 ha) eliminated 10 mill.: all areas smaller than 25 000 000 m2 (2 500 ha) eliminated 20 mill.: all areas smaller than 100 000 000 m2 (10 000 ha) eliminated
the area represented by each cell or pixel.
The minimum mapping unit is directly related to the scale and the resolution. It represents the smallest unit that can be drawn on the map.
32
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
Also, depending on the scale and precision, lines and vectors my be generalised using Arc/Info® Bendsimplify function; this will also noticeably reduce the size of the file.
5.5 Grids Grids may be used to georeference large-scale or diffuse phenomenon. In order to keep consistency and comparability among datasets, as well as to avoid misinterpretation, characteristics of the most frequently used grids should be published. An example of a sample of the 100 km ETRS-LAEA grid in use by the EEA is given in Annexe VI, page 52.
The use of grids requires obviously to fix grid position, size, and resolution, but also to define a systematic way to encode each cell. Coding is for identifying or referring to a unique cell.
EEA has developed a tool, known as EEA FishNet tool for ESRI ArcCatalog, to produce vector grid according to its standards. Grid can be produced in polygon (squares) or in line vector format. EEA grid coding system is automatically added to the produced grid as attributes. The tool is available from EIONET GIS page5.
ESRI ArcGIS Spatial Analyst extension allows creating raster grids, either clean and without no data, or based on other data sources.
5.6 Language and conventions for naming files and attributes
Both language interface and language of tables' attributes have to be addressed. They can be seen as independent problems, however, there is few meaning in translating the interface if the content displayed is not understandable and vice- versa.
Language interface should as a minimum be available in Russian. Taking into account the international dimension of St. Petersburg, an English interface is strongly advised. To avoid systematic translation of tables' attributes, codes and acronyms may be used if further linked to their lexical meaning through a conversion table. User interface will display only the lexical content in the proper language. The use of latin characters in codes and acronyms may also reduce the risk of cyrillic symbol encoding errors.
The use of codes and acronyms require the development of conversion tables to link codes and acronyms to their proper lexical content in each language. See Annexe V, page 51 for an example of a Canadian code conversion table between English and French.
5.7 Map extends Standard map extends may be defined to produce maps on a routine basis securing a minimum harmony and comparability between the maps produced. This require to
33
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
use a predefined map projection as discussed earlier (see Coordinate reference system and projections, page 27). If map extend, projection, and appearance are harmonised, it becomes possible to reuse and mix data from different productions, and to produce maps that fit reports' layouts.
Pre-defining extends of map is especially important considering the number of City's districts and all the possibilities to represent them.
5.8 Report & map templates
Harmonizing maps projection and extend may not be enough to improve information management productivity and visibility.
5.8.1 Map templates
Map templates are developed for standard map presentations in printed reports and Web applications. The use of templates simplifies map production as map extents, map projections, background features (e.g. district boundaries, water bodies, urban infrastructure), and colour schemes are predefined.
The objective is to obtain maps in reports and on the Web that appear harmonious, and to ease the final layout process as there is no need to reproduce manually common parts of the maps. It makes also possible to reuse and mix data from different productions.
The ArcGIS map template files (.mxt) are made with the use of lyr-files that define colour and symbol definitions; they allow to pre-defined graphic layout (colour/line size/font) for selected features that are frequently used on maps.
5.8.2 Reports templates
Report templates may be build similary to map templates. Desktop publishing tools allow achieving great results in producing on-line or downloadable information resources, and require a minimum computer skill from desktop users. Desktop- published information needs to go through a minimum quality-control procedures anyway.
Templates should carefully address the colour and graphics used for displaying thematic information. General rules of map semiology, such as using a maximum of seven different colours or a maximum of five densities of grey, should be respected. The help of professional designers may be required when developing documents' templates or guidelines.
34
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
5.9 Metadata Metadata have clearly their place in this list of conventions and standards, but considering their importance according to Committee's requirements, they are discussed in detail in the next section: 6-Metadata, page 31.
5.10 Geoservices
When considering the presentation made by Dmitry Frank-Kamenetsky during the Second Steering Committee of the project, there are yet very few web based information available in St. Petersburg. However, it could be a good practise to develop the Committee information system taking into account OpenGis standards and OGC Web Map Service specifications to secure future interroperability with other systems.
5.11 Quality and quality control
Datasets delivered by third parties to the Committee should meet all requirements stated above. In order to facilitate the preparation of the dataset and prevent rules infragment as early as possible, guidelines and recommendations should be published and distributed to data providers. Quality control procedures should be established at the Committee, comprising at a minimum a check-list and a person in charge of checking the datasets.
6 METADATA
A prerequisite for the effective use of geographic information at all levels of society is that the datasets are comprehensive and mutually interoperable, possess integrity in logical and technical terms and, above all, are readily available. To achieve interoperability common standards and recommendations need to be applied to the maintenance and management of geographic datasets in widespread use.
The efficient and effective use of geographic information depends on whether common standards and recommendations are applied to data compilation, data maintenance and information service. The standards should promote data sharing both on a national and international scale. In addition to recommendations pertaining specifically to geographic information, the management of data resources must also adhere to the principles governing and guiding the information society at large.
35
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
The set of national recommendations pertaining to geographic information need to be comprehensive and up-to-date with international standards (the ISO/EN 19100 series, Open GIS specifications etc.). (FNCGI 2004)
When forming a system for publishing the environmental data of St. Petersburg, Extensible Markup Language (XML) -based descriptions would be very good to produce for the existing data (W3C 2005). The Committee might also require such standards to be applied when new data is added into the service.
6.1 ISO 19115:2003 Geographic information – Metadata
ISO 19115:2003 is an international standard for defining the schema required for describing geographic information and services. The paper costs some 100 -200 euros. It can be bought from ISO (www.iso.org) or SFS (www.sfs.fi). See also http://grdc.bafg.de/servlet/is/2376/. The standard includes separate recommendations for vector and raster data. For aerial and satellite images, there are some recommendations available already, but mainly those are in an extension for imagery and gridded data, ISO 19115-2 (i.e. part 2), which is in the draft stage at the end of 2005 but planned to be available in 2006. Part 2 will broaden the meta information contents to include raster data as well.
The standard is rather large – it includes about 400 elements to describe GIS data. This means that it is not quickly adopted but takes some time. It is reasonable just to select those the Committee wants to use. There are various compulsory levels, and the minimum set includes about 20 obligatory elements to serve data directories. Data quality issues are not included in it.
6.2 ISO 19139 – A schema for implementing
It is important to understand that the actual implementation of ISO 19115 may vary. The standard only gives some frame of reference for metadata collection, and does not comment how it should be documented. It could be even just text files. But there are schemas available, defining the structure to enhance interoperability by providing a common specification for describing, validating and exchanging metadata about geographic datasets. The metadata dataset implementation specification ISO 19139 gives such schemes on how to document metadata, implemented with XML. The schemas are drafts, may be still updated, but will probably soon be official. These XML schemas implemented according to ISO 19115 can be downloaded from www.isotc211.org/schemas/2005/gmd/ or http://eden.ign.fr/xsd/isotc211. The file gmd.xsd uses metadataApplication.xsd, and metadataEntity.xsd is a good starting point. MD_Metadata is the root element for the whole structure.
Usually each country selects and translates something on its own language. In Finland, Riikka Henriksson from the Helsinki University of Technology has concentrated on the ISO 19115 standard, selected a certain subset of elements and defined terms in the local language to be used by the public administration; so
36
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
called JHS recommendations (Henriksson 2005a-d). Lassi Lehto of the Finnish Geodetic Institute has concentrated on the schema of ISO 19139 and used it rather directly for these selected elements.
In the Finnish implementation, some parts are still missing; for the functionality there may be certain features still coming, as well as for the quality definitions. But the relationship between the meta information standard and the schema already becomes quite clear, and the elements that have been considered by the JHS recommendations are already included.
The latest international presentations about the schedules of meetings can be seen at www.isotc211.org/present/. The status of Russian implementation of the ISO 19115 & ISO 19139 standards should be checked. Perhaps some field names have already been translated. Among the ISO/TC 211 members, the Russian Federation seems to be represented in the international activities by GOST R, Federal agency on technical regulating and metrology (www.gost.ru). They should be contacted.
If the translation would not be under preparation already, the same schema as in Finland could be used and the Russian interface could be defined. Perhaps there are some tricks in using Cyrillic alphabets within XML.
ESRI’s ArcCatalog can also be used to collect metadata and produce XML files that are in accordance with ISO 19115. Previously it did not fully support the schemas of ISO 19139 but was ESRI’s own but almost the same. Note that in the Metadata editor, at least the information about measured quality is incomplete (Lehto 2005). The XML schema implementation of metadata, defined in the standard 19139, will probably be broadened in the future to include also the contents being now modelled in 19115 Part 2 for raster data.
6.3 GML Geography Markup Language (GML) is a procedure, code or means to store the actual geographic information (not just the metadata) based on XML. GML was initiated by the Open Geospatial Consortium (OGC, see www.opengis.net/gml/) , and it is becoming an ISO standard. The page http://www.isotc211.org/schemas/2005/gml/base/ includes the GML version 3. The benefits and development of GML are also discussed on pages like http://xml.coverpages.org/geographyML.html.
GML is a general, open data transfer format. In the future it is likely to replace the separate file formats used by the providers. As XML is a text based format, it takes a lot of disk space. Therefore the possibilities for packing GML has been investigated and compared a lot. It is probable that instead of creating new concepts, the basic packing formats like Zip will be applied somehow. The file sizes will be about 5 % of the original.
37
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
Illustration 4: The Finnish Geodetic Institute has made a metadata editor (Lehto 2005). It is a good example how metadata can be fed in. URL of the application is http://geoinfo2.fgi.fi/metaeditor/. Each page can be used to define and save some more meta data, and the button of the last page creates the XML file for vector data. The file is in accordance with the schema.
GML is becoming more common and included in the software. ESRI and Intergraph already support GML read/write operations. The Open Source packages also support GML rather well already. In various countries, the utilisation level varies. For example the Ordnance Survey (the national mapping agency of Great Britain) supports only GML-based transfer of map data.
Already now, if you want to describe the scope or coverage of a dataset as a part of metadata, you have to apply geometry types that are in accordance with GML; if min & max limits are not enough, the defined polygon is GML-based (Lehto 2005).
38
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
7 PROPOSED INFORMATION STRUCTURE
Designing the information structure brings together all aspects enumerated so far. Among the users of Committee's information system, a minority of them will be users of geographic data, and even a smaller minority might have good computer skills. To be widely used the system should present information under different forms and formats, and should be easy to access and navigate.
7.1 Structure of the information
As stated in 3.4 Conclusions, page 19, only Committee's staff may be granted access to the core of the information system. All other users have restricted access. Information freely accessible is the so called ”thematic information” (e.g. derivated dataset) plus the metadata that is seen as a vitrine of all information available at the Committee. The metadata is the entry point to Committee core dataset: it serves for Committee's staff to identify and access the data, and for third parties to identify existing data before applying for an agreement granting them access (see 3.3 Limitation in the use of information, page 19).
The overall information may be structured around Information Products, Themes, and Supporting Documentation.
7.2 Content of the information
7.2.1 Information Products
Reports are all written documents produced by the Committee and that can be made publicly available. This concern in particular, but is not limited to, the annual State of the Environment Report.
Environmental indicator are defined as parameters or values that describe the state of the environment and its impact on human beings, ecosystems and materials, the pressures on the environment, the driving forces and the responses steering that system. Task 5 of the Project is dedicated to selecting and building environmental indicators.
Maps and graphs: 2D or 3D representations of phenomenon that illustrate either the dynamic of factors, their relationships, or their spatial distribution. The maps and graphs can be produce as routine procedure (e.g. regular reporting), or in response to particular situations.
Data: all products referred to as top-level objects or derivated datasets in 5-Select geographic representation, page 27. Except for minor exceptions, these data sets are likely not to be available to third party users.
39
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
7.2.2 Themes
The information system developed within the project is limited to environmental priorities identified for Kronstadt (refer to 1.4-Conclusions, page 14 for more details): • air pollution (both stationary and mobile sources); • surface water (of which coastal and inland waters); • recreational areas (both beaches and green areas); • soil pollution; • waste.
7.2.3 Supporting Documentation
Glossary: considering that the information system adresses a none specialised public, a glossary defining the main terms and their equivallent in English would certainly be helpful;
HOWTO: the first HowTo concerns the system itself: how to use it, retrieve information, forward requests or feed-back, etc. More HowTo can be developed, targeted to Committee staff stipulating how to use datasets, user agents, and other applications.
Software: this section contains links to downloadable client applications and user agents (GIS-related software, viewer, open-source office suite and software, web browser, etc) available for free.
Links: to other applications or information resources.
7.3 Organizational functions
7.3.1 Restrictions in accessing web services
Not all the staff from kronstadt District has an access to the internet, due to administrative restrictions brought to accessing web services. Instead, the personnel has access to intranet services that seem to be operational (see 2.2.3 Technology available to access and view the information, page 16). We may consider mirroring a subset of the actual database into the intranet. This can be done regularly, at night, and using incremental update to avoid overloading the system.
7.3.2 User management
Databases store critical information but perform no processing. Committee staff will use client applications to perform information queries, modifications, additions, and deletions. In order for an application to access a database a user account and password should be established. Security is established through user's access level and ID/password to gain access to the application. This user account should only permit those functions required by the application instead of a broad administrator user account.
40
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
There must be a systematic way of controlling and managing the official user agreements. The manager will have to deal with forgotten passwords and other broken legs.
7.3.3 Database managers
Database managers are key-persons performing routine maintenance of the database, enhancing security, and granting access rights. The Committee should have at least two of them permanently available, equally competent, and well trained.
7.3.4 Maintenance & Back-up
The primary risk associated with data and programme is the inability to recover systems, applications, and data in case of a disaster or other disruptive event. This can be caused by incomplete or sporadic performance of back-up procedures, unreliable back-up media, or the inability to access off-site back-up material. Written standards should document backup methodologies, delineate responsibilities of personnel, and ensure timely and appropriate measures.
A backup server should be considered, so that two servers are available for the end user (not visible for him/her but seen as one data source) to avoid service disruption and facilitate maintenance operations.
We must consider bringing new versions from the databases for the server. A centralized collection and display of databases is possible with ArcSDE. In the Finnish Digiroad, there are 3 databases, Oracle etc. They are brought together, but it is a rather heavy system.
7.4 General requirements for the client applications
7.4.1 Browser interface
Browser interface have the advantage to be almost pre-installed on all computers and available for all platforms (Windows, Mac, and Linux). ESRI provides viewer for inter-net-based products. However, these viewer do not allow to modify the content of the information displayed.
Even if complementary download /upload capabilities may be added somewhere else in the system, they offer few possibilities for the agent to interact with the information provided.
However, for most of the users the simplicity will be a key-criteria, and for the general users just visiting the site there should be no special requirements (downloading or installing pluggins), otherwise they are not going to stay there for long.
41
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
7.4.2 Other client applications
If downloading data is permitted for District's users, they will need client application to view or manipulate the data off-line. Despite the use of ArcGIS suite, other applications may be used.
ESRI proposes ArcExplorer and ArcReader:
√ ArcReader is a free, easy-to-use mapping application that allows users to view, explore, and print maps and globes; √ ArcExplorer is a lightweight GIS data viewer, freely available, which offers an easy way to perform a variety of basic GIS functions, including display, query, and data retrieval applications. It can be used on its own with local data sets or as a client to Internet data and map servers.
Open-sources products are also available: QGIS (all platforms), GRASS (Linux):
√ Quantum GIS (QGIS) is a user friendly Open Source Geographic Information System (GIS) that runs on Linux, Unix, Mac OSX, and Windows. QGIS supports vector, raster, and database formats. QGIS is licensed under the GNU Public License; √ GRASS is a Geographic Information System (GIS) used for geospatial data management and analysis, image processing, graphics/maps production, spatial modeling, and visualization. GRASS is currently used in academic and commercial settings around the world, as well as by many governmental agencies and environmental consulting companies. Primarly developed for Linux platforms, it is available for Windows with Cygwin.
Note that Kronstadt district has a ArcView 3.x version that may be used to view or modified the information delivered.
8 OPTIONS
8.1 The project Infrastructure for spatial information in Europe (INSPIRE)
A project Infrastructure for spatial information in Europe (INSPIRE) has been started to enhance common policy preparation, implementation and follow-up by improving the accessibility of useful, homogenous and qualified geographic information in Europe. The homepage of the project is www.ec-gis.org/inspire/. The concrete aim is to prepare rules and general laws to support the accessibility of geographic information and the development of European geographic information infrastructure. The original INSPIRE directive proposal (EC 2004) has been followed by member states’ political understanding in the council on July 24th, 2005. Several updates were made, concerning e.g. data publicity, service fees and principles of data sharing within official use. The commission has been positive about the parliament's suggestions, except those weakening the principles of free
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
accessibility of information. Since EU parliament, council and commission have no final understanding, the proposal will go through the second handling in 2006.
The commission has continued the preparation of implementation rules included in the directive proposal, according to the agreed work programme by arranging preparation groups. Specialist groups and their supportive networks aim to prepare the preliminary implementation rule proposals within about a year. For commenting and participation, there have been organised networks (Spatial Data Interest Communities, SDIC) concerning various targets.
At the end of 2005, the Commission uses an invitation to tender (Development of Prototype Components) to prepare the implementation of the future spatial data infrastructure (SDI) within the Commission.
For implementations within Russia, INSPIRE’s guidelines may be useful as well.
8.2 Raster servers
Raster images can be distributed in networks in various ways. Also ArcIMS is basically a raster server; always according to the current view, a new image is produced and sent. The image format may be typically jpg or gif. Wavelet based image compression formats like MrSID, DjVu and ECW are more effective for web distribution. They include the generalized, more coarse pyramid levels of the same imagery. There are also open source solutions, see e.g. http://djvulibre.djvuzone.org/. We have to evaluate the options for serving the image data.
Also ESRI has an Image Server product (www.esri.com/imageserver/) becoming available at the end of 2005. The price level will be such that it may be useful not for the smallest companies but already for bigger group. ESRI has never before offered its own image server, although it has been possible to store rasters in Geodatabases. The new approach enables reprojection and other on-the-fly processing (image enhancement, orthorectification, pan sharpening and complex image mosaicking). It supports various image formats and open standards, also Web Map Server (WMS) protocol and HTML viewers. Detailed information (like the possible packaging for the transfer) is not available yet (Ikola 2005).
8.3 RaveGeo streaming vector technology
For vector data, some users may have been disappointed in ArcIMS being slow and rather expensive to use. Slowness can be caused by several reasons, some not depending on ArcIMS. If St. Petersburg has decided to use ArcIMS, no problem, it should be a working solution. Anyhow, having heard about the slow speed connections and hardware, it is worth while to point out one basically different approach.
43
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
Nowadays it is also possible to serve vector data through the net effectively as a highly compressed format. Streaming means simultaneous transfer and display. The user can notice the information while it is being sent to their WWW browser or other application, instead of waiting for it to download and then showing it. Vector streaming compression is decoded at an application and displayed with the desired layout. Note that also the vector attributes are preserved and available for the user.
The Swedish Idevio AB company has developed such a vector compression and distribution technology, called RaveGeo. It enables a very fast data transfer, experienced by the user as almost undelayed usage. Always when the application is asking for a new map view, only the vector map information differing from the previous view is transferred.
The whole RaveGeo concept is based on the user point of view. In about 1995, some users started with ESRI platform but found out rather soon that there remain limitations in distributing the information practicably. Therefore, the RaveGeo technology has been developed especially to solve the distribution problems in a network environment and it does the job well.
8.3.1 What it takes
The map data is compiled by generalising more general (or small scale) versions from the original data. The result is a packed, seamless, topologically sound RaveGeo formatted dataset. Its size is 5–10 % of the original data (that was in Shape/VPF formats). The compiler will not create the generalized levels totally automatically, but the data must be introduced for it. When the necessary definitions have been done once, it only takes some computer time. At least the Karttakone company in Finland offers various services for preparing and hosting the data – or helping and training others to do it.
Karttakone is for example taking annually the huge National Land Survey’s (NLS) Topographic Database and transforming it into RaveGeo format. The transformation takes about a week of CPU time. They are serving NLS’s and others’ data on their servers. (More info about Karttakone Karhu & Karttakone Web services, www.karttakone.fi, [email protected]). Anyhow, if St. Petersburg considers using the RaveGeo technology, which may be reasonable, in addition to the Compiler the Server application is needed. The magnitude of costs will be something like:
The RaveGeo Compiler: a few thousand EUR / year. The RaveGeo Server: a few thousand EUR / year (perhaps 20 more than the Compiler). The costs for defining the datasets, learning etc.: at least 2 weeks of work in Finland or 4 weeks in a new environment. All these prices and conditions will be checked in case there is interest, and the tenders will be asked for.
44
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
More info about the software architecture: www.idevio.com/Products.htm. More info in Q & A pages of Idevio. More demo datasets are also available from Geography Network.
8.3.2 RaveGeo ArcGIS Plugin
Basically, RaveGeo data can be viewed directly using a web browser with Java. There is a Java application, made using RaveGeo SDK (Software Development Kit), and this Java application visualises the map. At least Karttakone offers such an application. If the organisation has the Server license, SDK comes along and does not cost extra, therefore if there are Java skills, the visualisation application could be programmed in Russia as well.
But RaveGeo is also available for the ArcGIS product suite from ESRI. The RaveGeo ArcGIS Plugin enables ESRI users to roam very large vector datasets in real time. The plugin works excellent with all ArcGIS products version 8.3 and higher, including ArcReader, ArcMap, ArcScene and ArcGlobe. RaveGeo also works with ArcIMS and ArcGIS Engine for embedded GIS. The ArcReader can be downloaded for free at ESRI. Anyone can download the RaveGeo ArcGIS Plugin for testing. For actual use, in Finland the annual fee for the Plugin has been about 3000 euro per organization, meaning free use (as many Plugins as desired can be used).
The difference with the plugin is that the browser (SDK) has available all the same information than ArcGIS (and what are stored in the database), but then all the functions readily available in ArcGIS must be implemented into the Java application. For example viewing the attributes.
45
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
CONCLUSION: PUTTING IT TOGETHER
The schema below shows what part of the information strategy should be addressed during project implementation. Note that a lot of aspects of developing Information Systems are not straightforard and require iterative process (e.g. producing metadata).
Start elaborating the data dictionary and the schema
Start elaborating the metadata catalogue. The first information can be filled in using the result of Task 3.1
Define your coordinate reference system and projection, map extends and gridss;
Establish rules and conventions for locating objects (tabular data);
Agree about resolution and minimum mapping units during image interpretation;
Define the geographical dataset formats for raster, vector, and tabular data;
Fix the language and conventions for naming files and attributes
Review all organizational functions: user access, database manager, database hosting , back-up and security.
Check the accessibility of the information system and set requirements for the client applications
Develop reports & map templates for the information products. Populate all themes with reports, maps & graphs, indicators.
Develop the supporting documentation
46
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
REFERENCES
EC 2004: COMMISSION OF THE EUROPEAN COMMUNITIES. Proposal for a DIRECTIVE OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL establishing an infrastructure for spatial information in the Community (INSPIRE). Brussels, 23.7.2004. www.mmm.fi/luonnonvarat_vesivarat_maanmittaus/maanmittaus/patine/COM_20 04_051 6_F_EN_ACTE[1].pdf
FNCGI 2004: National Geographic Information Strategy 2005–2010. Finnish National Council for Geographic Information. Ministry of Agriculture and Forestry, Publication 10a/2004. www.mmm.fi/patine/Paikkatietostrategia_Eng.pdf
Riikka Henriksson, M.Sc., researcher, Helsinki University of Technology, Institute of Cartography and Geoinformatics, Otakaari 1, Espoo, Finland. P.O. Box 1200, FIN-02015 TKK. tel. exhange +358 9 4511, GSM +358 40 5634516, e- mail Riikka.Henriks- [email protected]. Personal communication Nov 16th, 2005.
Riikka Henriksson. JHS-suositukset; paikkatiedon metatieto ja laatu. 9.2.2005. Kunnallishallinnon paikkatietoseminaari, Kuntatalo. http://www.kunnat.net/binary.asp?path=1;29;145;30546;38442;35072;58174;7760 4;7765 1&field=FileAttachment&version=2
Riikka Henriksson. JHS-suositus; paikkatiedon metatieto. 9.3.2005. Harmonisointijaoston 2. kokous, Maanmittauslaitos http://www.mmm.fi/patine/meta/JHS-metatieto.ppt
Riikka Henriksson. Paikkatietojen laatu ja metatiedot. JHS-seminaari – Paikkatiedot tietojärjestelmissä. 26.10.2005, Säätytalo, Helsinki. www.jhs- suositukset.fi/intermin/hankkeet/jhs/home.nsf/files/jhs-seminaari2005-10- 26henriksson/$file/jhs-seminaari2005-10-26henriksson.pdf
Timo Ikola, ESRI Finland. Kaukokartoituspäivät 17-18.11.2005, Merentutkimuslaitos, Dynamicum, Helsinki
Lassi Lehto, Tech.Lic., researcher, Finnish Geodetic Institute, +358 9 295 55210, lassi.le- [email protected]. Personal communication Nov 16th, 2005.
FMoE 2004: Paul Silfverberg, Päivi Piispa, Seppo Silvennoinen, Vladislav Furman. Study on the Institutional and Legislative Framework of Environmental Management in the Russian Federation and in the City of St. Petersburg. Finnconsult Oy and Planpoint Oy 20.12.2003, The Finnish Ministry of the Environment, Report 2004. www.miljo.fi/down- load.asp?contentid=15116&lan=fi
SPB 2002: THE MAIN DIRECTIONS OF THE POLICY OF ST. PETERSBURG IN THE FIELD OF ENVIRONMENTAL PROTECTION AND ECOLOGICAL
47
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
SAFETY FOR THE PERIOD FROM 2003 TO 2007. St. Petersburg City Administration -Committeefor Nature Use, Environmental Protection and Ecological Safety. 2002
Natural Resources Canada -Geomatics Canada -Centre for Topographic Information Geographical Names, Canadian Geographical Names Service (CGNS) Data Model and Data Dictionary, Edition 2.0, Ontario, Canada, 2003For the full document see: http://www.geobase.ca/doc/specs/pdf/GeoBase_CGNS_DB_Data_Model.pdf
W3C, 2005: Extensible Markup Language (XML), www.w3.org/XML/ EEA operational guidelines, Guide to geographical data, and maps, June 2005, Draft version 1.3 (available at www.eionet.eu.int/gis)
Modelling Our World, teh ESRI Guide to Geodatabase Design, Michael Zeiler, Environmental System Research Institute, 1999.
48
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
ANNEXE I: ST. PETERSBURG ADMINISTRATIVE DIVISIONS
St. Petersburg City administrative districts:
1. Admiralteysky district, with 6 municipal 10 Lomonosovsky with the municipal towns of districts; Lomonosov and Moskovsk, and 5 municipal districts; 2. Frunzensky with 6 municipal districts; 11. Nevsky including 9 municipal districts; 3. Kalininsky with 7 municipal districts; 12. Pavlovsky including the municipal town of 4. Kirovsky with 7 municipal districts; Pavlovsk and the municipal settlements of Tyarlevo; 5. Kolpinsky including the municipal town of 13. Petrodvortsovy including the municipal town of Kolpino and municipal settlements of Peterhof and the municipal settlement of Strelna; Metallostroy, Petro-Slavyanka, Pontonny, 14. Petrogradsky including 6 municipal districts; Sapyorny, and Ust-Izhora; 15. Primorsky including the municipal settlements of 6. Krasnogvardeysky, with 5 municipal districts; Lisy Nos and 7 municipal districts; 7. Krasnoselsky including the municipal town of 16. Pushkinsky including the municipal town of Krasnoye Selo and 6 municipal districts; Pushkin and the municipal settlementsof 8. Kronshtadsky, including the municipal town of Alexandrovskaya and Shushary; Kronstadt; 17. Tsentralny including 6 municipal districts; 9. Kurortny including the municipal towns of 18. Vasileostrovsky including 5 municipal districts; Sestroretsk and Zelenogorsk, and the municipal 19. Vyborgsky including the municipal settlements of settlements of Beloostrov, Komarovo, Levashovo and Pargolovo, and 6 municipal districts. Molodyozhnoye, Pesochny, Repino, Serovo, Smolyachkovo, Solnechnoye, Ushkovo;
49
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
ANNEXE II: INFORMATION RESOURCES AVAILABLE BY THE COMMITTEE
Extract from the List of Information resources of the information and analytical complex “Ecological Passport of St. Petersburg” that will be created and put into use for January 1st 2005, Annexe 2 to the decision N. 32-p dated 05.07.2004.
Code of Information Type of Code Name of the resource Type the layer information resource 01 Physico-geographical characteristics of the territory Temperature regime of the territory of the Layer 1 010101 city Temperature regime of the territory of the Database 1 010102 city Atmospheric pressure Database 1 010103
Wind characteristics Database 1 010104 Climatic Humidity Database 1 010105 010100 Characteristics of the territory Fog Database 1 010106
Relative humidity Database 1 010107 Climate monitoring Database 1 010108 Storm surge Database 1 010109 Flooding areas Layer 1 010110 Unfavourable meteorological conditions Database 3 010111
Surface water reservoirs on the territory of Layer 1 010401 the city Rivers on the territory of the city Layer 1 010402
Recharge area of water reservoirs Layer 1 010403 Hydrological characteristics of water Database 2 010404 Hydrographical reservoirs network Hydro-chemical characteristics of water territory, Database 2 010405 hydrological reservoirs characteristics, Hydro-biological characteristics of water Database 2 010406 010400 and assessment of surface water Level of eutrophication of water reservoirs Table 2 010407 quality (rivers, Characteristics of water intake from water Database 1 010408 streams, lakes, reservoirs etc.) Characteristics of the coastal line Layer 2 010409 Observation points Table 2 010410 Characteristics of the observation points Table 2 010411 Index of water pollution Data base 2 010412
50
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
Code of Information Type of Code Name of the resource Type the layer information resource 03 Normative documentation Norms of air quality Database 3 020501
Norms of water quality Database 3 030102 Normative Norms of soil quality Database 3 030103 documents on 030100 the state of the Norms of noise levels Database 3 030104 environment Norms of electromagnetic exposure Database 3 030105 Norms of radiation level Database 3 030106 04 Atmosphere Network of air monitoring stations Layer 1 040101
Characteristics of air monitoring stations Table 2 040102 System of air Primary data from air monitoring Database 4 040103 040100 monitoring Averaged data from air monitoring Database 4 040104 Network of noise monitoring stations Layer 1 040201 Characteristics of noise monitoring stations Table 1 040202
040200 System of noise Primary data from noise monitoring Database 2 040203 monitoring Averaged data from noise monitoring Database 2 040204 Network of electromagnetic monitoring Layer 1 040301 stations
Characteristics of electromagnetic 040300 System of Table 1 040302 electromagnetic monitoring stations Primary data from electromagnetic monitoring Database 2 040303 monitoring Averaged data from electromagnetic Database 2 040304 monitoring 05 Surface water Network of surface water monitoring stations Layer 1 050101 System of Characteristics of surface water monitoring monitoring of Table 2 050102 050100 surface water stations bodies in Primary data on surface water Database 3 050103 St. Petersburg Averaged data on surface water Database 3 050104 Network of monitoring stations on Neva Layer 1 050201 Delta and Gulf of Finland water bodies
Characteristics of monitoring stations on System of Database 2 050202 050200 monitoring of Neva Delta and Gulf of Finland water bodies Neva Delta and Primary data from monitoring stations on Database 3 050203 Gulf of Finland Neva Delta and Gulf of Finland water bodies Averaged data from monitoring stations on Database 3 050204 Neva Delta and Gulf of Finland water bodies
51
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
Code of Information Type of Code Name of the resource Type the layer information resource Pollution of surface water bodies Layer 3 050301
Characteristic of the pollution in surface Database 3 050302 water bodies Water quality in Pollution of surface water bodies according Layer 3 050303 St. Petersburg to chemical indicators 050300 surface water Characteristic of chemical pollution of bodies Database 3 050304 surface water bodies Pollution of surface water bodies according Layer 3 050305 to biological indicators Characteristic of biological pollution of Database 3 050306 surface water bodies Pollution of the water body Layer 3 050401
Characteristics of the water body pollution Database 3 050402 Pollution of the water body according to Layer 3 050403 Water quality in chemical indicators 050400 Neva Delta and Characteristic of chemical pollution of the Database 3 050404 Gulf of Finland water body water body Pollution of he water body according to Layer 3 050405 biological indicators Characteristic of biological pollution of he Database 3 050406 water body 08 Land Resources Land use Layer 1 080101 080100 Land use Land characteristics Database 2 080102 Type of soils in the territory of the city Layer 1 080201
080200 Main type of Level of preservation of soil cover Layer 2 080202 soils Characteristics of the soils Database 2 080203 Level of knowledge on soil Layer 2 080301
Point of soil sampling Layer 2 080302 Characteristics of soil sampling points Table 2 080303 System of 080300 monitoring of Primary data from soil sampling Database 3 080304 soil pollution Pollution by organic compounds (for each Layer 2 080305 combination) Pollution by heavy metals (for each metal) Layer 2 080306 Areas of radiological pollution Layer 3 080307 Points of radiological pollution monitoring Layer 3 080308 Characteristics of radiological pollution Table 3 080309 monitoring points Primary data from radiological pollution Database 3 080310 monitoring
52
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
Code of Information Type of Code Name of the resource Type the layer information resource Characteristics of areas of radiological Table 3 080311 pollution 09 Green areas
Green areas of Location of green areas of public use Layer 2 090101 090100 public use Characteristics of green areas of public use Table 2 090102 Location of green areas of restricted use Layer 2 090201 Green areas of 090200 Characteristics of green areas of restricted restricted use Table 2 090202 use Green areas of Location of green areas of specific use Layer 2 090301 090300 specific use Characteristics of green areas of specific use Table 2 090302 11 Ecological Safety Sediments sampling points in city water Layer 2 110701 reservoirs Deepening rivers Characteristics of sediments sampling points and channels Table 2 110702 in city water reservoirs bottom, Primary data from sediments sampling ecological Database 2 110703 rehabilitation of analyses weakened water 110700 reservoirs, Pollution of city water reservoirs sediments Layer 2 110704 cleaning and Map of deepening works in city water Layer 2 110705 maintenance of reservoirs water reservoirs, Rehabilitation Measures for ecologically water protection Layer 2 110706 areas, and weakened water reservoirs coastal areas; Dumping areas for sludge resulting from Layer 2 110707 ice-breaking deepening works works in Time-table for cleaning and maintenance the central part works in water reservoirs and water Layer 2 110708 of St. Petersburg protection areas Areas of algae blooming Layer 2 110709 Location of sunk ships or underwater Salvage and use Layer 2 110801 of sunk ships or facilities Characteristics of sunk ships or underwater underwater Table 2 110802 facilities in facilities 110800 St. Petersburg water reservoirs Plan for salvaging and using sunk ships or (Neva River, Database 2 110803 Neva Delta, and underwater facilities Gulf of Finland) Anthropogenic sources of negative impact on the 12 environment General Address of long-term rent Layer 3 120101 Address of short-term rent Layer 3 120102 Real-estate Layer 3 120103
53
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
Code of Information Type of Code Name of the resource Type the layer information resource Characteristics of real estate Database 2 120104 General Road network Layer 2 120105 information on 120100 Transport infrastructure Layer 2 120108 anthropogenic impact Characteristics of transport infrastructure Database 2 120109 Juridical and physical persons as nature users Database 3 120110 Point source pollution Layer 2 120201
Characteristics of point pollution sources Database 3 120202 Linear source of pollution Layer 2 120203 Protection of air 120200 against pollution Characteristics of linear sources of pollution Database 3 120204 Surface sources of pollution Layer 2 120205 Characteristics of surface sources of Database 3 120206 pollution
Authorised Limit of Emission12 Database 3 120207
Temporary Authorised Emission Limits13 Database 3 120208 Cleaning facilities Database 3 120209 Point of water intake from surface water Layer 2 120301 bodies Point of water discharges into surface water Layer 2 120302 Use and bodies protection of 120300 Used water reservoirs Layer 3 120303 surface water bodies Agreement on the use of water bodies Database 3 120305 License on the use of water bodies Database 3 120306 Characteristics of water intakes from surface Database 2 120307 water Municipal Polygons for waste disposal and areas of wastes, temporary municipal waste storage dangerous (transshipping) Layer 2 120401 120400 industrial wastes, and Norms of waste generation for nature users Database 3 120402 wastes resulting from mechanical
and biological Limit of waste disposal for nature users Database 3 120403 sewage treatment
54
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
ANNEXE III: TOP-LEVEL OBJECTS
Chosen among the following resources related to water: [01400, 050100 to 050400, 110700, 110800, 120100, and 120300].
Code of the Code of Geographic information Name of the resource Type of information the features layer resource Surface water reservoirs on the Layer (Shape file + attribute 010400 010401 Polygons territory of the city table) Rivers on the territory of the Layer (Shape file + attribute 010400 010402 Lines cityShape file + attribute table table) Network of surface water monitoring 050100 Shape file 050101 Points stations Characteristics of surface water 050100 Attribute table of 050101 050102 None monitoring stations Data from monitoring stations on 050100 Neva Delta and Gulf of Finland Database 050102 None water bodies Monitoring stations on Neva Delta 050200 Shape file 050201 Points and Gulf of Finland water bodies Characteristics of monitoring 050200 Attribute table of 050201 050202 None stations Data from monitoring stations on 050200 Neva Delta and Gulf of Finland 050203 None water bodies Sediments sampling points in city 110700 Shape file 110701 Points water reservoirs Characteristics of sediments 110700 sampling points in city water Attribute table of 050201 110702 None reservoirs Data from sediments sampling 110700 Database 110703 None analyses Location of sunk ships or underwater 110800 Shape file 110801 Polygons facilities Characteristics of sunk ships or 110800 Attribute table of 110802 None underwater facilities Point of water intake from surface Layer (Shape file + attribute 120300 120301 Point water bodies table) Point of water discharges into Layer (Shape file + attribute 120300 120302 Point surface water bodies table)
120100 Real-estate Layer 120103 Polygons
120100 Characteristics of real estate Database 120104 None
Juridical and physical persons as 120100 Database 120110 none nature users
55
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
ANNEXE IV: DATA DICTIONARY AND SCHEMA
Column Data Domain Description Type
CGNDB_K NOT The CGNDB14 Key is a five digit alphabetical sequence code assigned to each EY NULL record in the CGNDB. As a new record is entered in the database, an VARCHA unique CGNDB Key is automatically assigned to the new entry. The first R2(10) letter of the CGNDB Key indicates the region in which the feature is located.
GEONAME NOT The Feature Name is an alpha-numeric field that shows the actual NULL geographical feature name or the place name. VARCHA R2(100) FEATURE_ ID STATUS_C [The list of codes is given in document's annexes] ODE GENERIC_ [The list of codes is given in document's annexes] CODE REGION_C [The list of codes is given in document's annexes] ODE LATITUDE LATITUD The Latitude of The Longitude of the feature. It is provided as decimal degrees. E the feature. It is provided as decimal degrees. DATUM VARCHA NAD27, The horizontal reference system code for attribute data (Latitude, Illustration 5: This data model is a subset of the R2(20) NAD83 Longitude). Possible code values are: NAD27 (North American Datum Canadian Geographical Names Data Base 1927) or NAD83 (North American Datum 1983). (CGNDB) represented in the form of an Entity NTS_MAP VARCHA The number(s) of the NTS map sheet(s) on which the feature or place can Relationship diagram. R2(4000) be found.
Table 1: Data Dictionary used by the Canadian Geographical Names Service. For the full document see: http://www.geobase.ca/doc/specs/pdf/GeoBase_CGNS_DB_Data_Model.pdf
56
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
ANNEXE V: CODE CONVERSION TABLE
Illustration 6: Example of a code conversion table between English and French. Note that the use of a unique Concise_Code would simplify changing from one language to another.
Source: the Canadian Geographical Names Service. For the full document see: http://www.geobase.ca/doc/specs/pdf/GeoBase_CGNS_DB_Data_Model.pdf
57
LIFE THIRD COUNTRIES InfoCoSM(LIFE04 TCY/ROS/000051)
ANNEXE VI: EXAMPLE OF A GRID USED BY THE EEA
Illustration 7: Map illustrating a sample of the 100 km ETRS-LAEA grid in use by the EEA. This sample grid covers in kilometres from 0 x (East of origin / column number) and 700 y (north of origin / row number) to 6700 x and 9100 y. Inset map shows zoom of Ireland 100 km grid with cell code
58