Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
V. D ATA RELATED TO DSS M ODELS While most sections of this report are based on the official documents produced by the DSS project, the description of the models have not been copied here: the detailed explanations of the models can be found in the relevant technical reports (in particular the Third Progress Report) available through the SRU. The paragraphs below summarize the data collection status for each model, along with some additional technical details. V.1 Water Demand Model This model has been developed in the last year, and, apart some minor refinements that might be required in relation to the evolution of the overall system’s structure, it can be considered completed. The conceptual model has already been presented in the 2006 annual Workshop, and the digitization of the hard-copy data needed to run the model is being finalized. The main data needed and collected for the water demand model are: -Monitoring stations; -Weather information (evapo-transpiration, pan-evaporation, temperature); -Cropping patterns; -Canals and drains parameters; -Water treatment plants; -Irrigation and drainage pump stations; -Underground water data. Data have also been adjusted to take into account irrigation efficiency, crop coefficients for summer and winter crops, crop coefficient on monthly basis within each region, starting date of cultivation and total duration for each crop, and soil permeability (on a regional level). The origin of the data pertaining specifically to this model is summarized i n the previous table. There are two main pending issues: the digitization of some hard-copy data (as discussed earlier), and the unofficial use of water. Farmers and industries make a widespread use of water not controlled by the government and therefore not accounted for: this can induce an effect on the water balance. A model that ignores this issue may never be able to reproduce the measured values of flows in the network because some water would be lacking in the model. There are also economic effects: on the one hand, if farmers complement official supply they can avoid deficits and hence produce more, that is increase their benefits; but on the other hand they are spending money, energy and time that may weigh on the negative side of the economic bala nce and the general environmental sustainability. There is also an environmental effect, as unofficial water is often taken from polluted sources and could affect both human health and soil salinity. The proposed solution is to assume that there is unofficial use and introduce a base information variable for it (assigning a 0 value until further information is available), and another variable depicting the maximum potential unofficial use (in each Spatial Unit). V.2 Underground Water Model This model will run as a separate module in the system, but nevertheless it will be fully integrated into it. It will therefore receive all sub-set of data needed from the system and provide the results for its visualization through the GIS interface. The application selected for handling the modeling equations is Sutra, a Fortran-based open source application widely used by the underground water specialists. The methodology for the development of this model has been devised by IT Synergy and the other Italian consultants. As the application will be running externally, the interconnection will be managed through the database and text files; the expected output of this model will be a mesh, 2 covering all Delta valley surfaces, with information about the ground water salinity. Given the complexity of the phenomenon, it has been decided to implement a model of underground transport referred only to the Delta, in order to obtain useful information on the saline intrusion and the management of this resource in the area. For the implementation of the model referred to the Nile Valley, it was agreed to utilize a simplified model of analytic type able to relate the abstractions to the average aquifer level. Needless to say, the results will strongly depend on the quality of the input data, and in particular on the recharge flows calculated through the Water Demand model. The Underground Water model could be implemented on a theoretical basis utilizing the existing data, postponing after the model implementation the acquisition of the rest of the information; in particular, the evolution of the phenomenon will be initially studied utilizing data on abstractions from wells subdivided by District, and information on the geometry of the aquifer provided by the Research Institute for Groundwater. Their data on ground water wells include the following information: wells characteristics; extraction rates; water levels; lithology profiles. V.3 Water Quality Model It is worth mentioning that a lot of efforts were made in the past 8 years trying to develop a Water Quality model for the Nile system, and not less than 3 years were spent trying to calibrate and validate it. The project in this second phase has obviously built on this experience. Three approaches have been envisaged so far: mass-balance of pollutants, which requires a deep calibration and is probably unfeasible on the large scale due to the tremendous requirement of reliable data; statistical (multivariate regression amongst state quality variables and potential cause variables); logical, that is a very simple reasoning stating that if loads increase with respect to the current situation, quality will worsen; and if water flows increase, quality will improve; although the estimation of loads is affected by high uncertainties, what counts here is the relative change associated with alternative development measures, and such a change should be much less affected by mistakes. Another significant difficulty lies in the fact that the real water quality problem shows up in the tiny irrigation and drainage networks, and not in the main ones 3 which, however, are the only ones where systematic monitoring is being carried out. That is, even if the model is perfect, it will represent a situation which does not capture the real problem. This difficulty can only be overcome by trying to extrapolate the quality from the available measurement nodes to the minor network, and this requires an articulated and lengthy process of data acquisition and model upgrade, which has not yet been completed. As a matter of fact, the WQ model should be able to simulate kinetic processes and pollutants transport in a superficial hydraulic system (canals and/or drainage network) by incorporating/simulating all the characteristic and the hydrodynamic processes occurring in the system, which constitute the basic elements necessary for the implementation of a real model of transport and accumulation. These models have to take into account all the physical, chemical and biological processes occurring in the various Spat ial Units, which require an accurate work of parameter-setting and a proper calibration to produce reliable results. The essential data requested for the model are the following: - Release from Assuan Dam; - Hydrometric and flow measurements along the Nile and the main canals; - Hydrometric and flow measurements along all the monitoring points of the drainage network; - Quality parameters of the canals and drainage networks collected at the measurement stations along the Nile, such as: 1. Temperature 2. Biological oxygen demand 3. Carbonaceous oxygen demand 4. Organic nitrogen 5. Ammonia 6. Nitrate 7. Phosphorous (organic and orthophosphate) 8. Coli bacteria 9. Ph 10. Total salinity 11. Chlorine concentration 12. Heavy metals - Qualitative and quantitative characteristics of all industrial downloads, including those from treatment plants; - Qualitative and quantitative characteristics of all urban downloads, including sewage systems; - Characteristics of the cropping patterns, cultural rotations, use of fertilizers and pesticides; - Chemical characteristics of the fertilizers and pesticides, including their time and quantity distribution; - Characteristics of soils (hydraulic, structural and chemical); 4 - Quality parameters of soils, minimum: 1. Nitrogen 2. Phosphorous 3. Ph 4. Total Salinity The treatment plants data listed above should include water and sanitation data, for instance: - total designed capacity of existing treatment plants; - actual amount of treated sewage; - extension of existing wastewater treatment plants; - planned extension of existing wastewater treatment plants; - capacity of new (future) plants under construction; - capacity of new (future) plants planned until 2017; - total designed capacity of existing wastewater treatment plants; - total wastewater discharge by 2017. The origin of the data collected so far are summarized in the previous table; for the time being, there are not enough data available to properly feed this model. EEAA could provide additional data on the municipal discharges from Aswan and Alexandria (obtained from a project carried out two years earlier - the “Water Master Plan”), and additional data on municipal and industrial discharges along the Nile River, but up to now they only provided some location of industries. SRU has only obtained limited point source discharge s from the 24 Governorates, and those locations are not sufficient to cover all data needed for the WQ model. Further data from the NAWQAM could also be obtained, but SRU is waiting to discuss the matter with the expatriate consultants, as to which type o f data is specifically needed in order to issue a detailed, formal request for obtaining such data. While there are more than 22,000 industries in Egypt and not all data are available regarding as to how many of those industries directly dump their industrial waste into the Nile, and whether restrictions apply to all industries regarding the waste treatment of the effluents discharged, the Industrial Financial Company may have pertinent data available. In order to achieve a full coverage of the missing industries, the available data could be extrapolated, on the basis of field studies and existing surveys. The General Authority for Industrial Development was also contacted, but the only information collected were data on industrial production in an aggrega ted format, with no specification or level of details, and only for a group of industrial projects in limited categories. 5 Finally, the Egyptian Federation for Industries (EFI) was contacted for possible industrial information, but no data were released so far. V.4 Agro-Economic Model An agricultural expert has joined the SRU team to collect the data and help in the implementation of this model. Up to the present time, the following data have been acquired at the governorate level: - cropping patterns, from year 2000 to 2005; - monthly labor wages, from year 2000 to 2005; - agricultural labor utilized for each crop, from year 1999 to 2005; - total production of fruits, from year 2003 to 2005; - production of vegetables and fruits, from year 2000 to 2005; - cost of production of all crops based on operations & inputs, from year 2000 to 2005; - net return for all crops, from year 2000 to 2005; - farm-gate prices for all crops, from year 2000 to 2005; The origin of data used by this specific model is summarized in the pre vious table. Unfortunately most of the data are in paper format and still need to be properly converted into digital spreadsheets and GIS layers (cf. “Data Corrections” paragraph). Besides, a number of other data are still needed to feed the model, for example: - number of farms, and distribution of farms for any agricultural surface area; complete input requirements for each crop cultivated and cultivable in the area: water, labor, energy, fertilizers and pesticides; cost and availability of irrigation equipment (following a recent discussion with the project staff, it seems that this will not be feasible); public support for agricultural sector: input or output subsides and taxes, trade policies for agricultural products, etc. V.5 Lake Nasser Release Model The Lake Nasser release model has been conceptualized and should perform the following operations: 1. A forecast of inflow at Dongola should be calculated and then discounted by the losses and abstractions from Sudan on a monthly 6 basis. Following the criteria adopted by the Nile Research Institute, these forecast will be obtained through different statistical methods and a statistical package software called STATGRAPHICS used for time series analysis and forecasting; 2. The demand will be calculated with the Water Demand Model at node a) (Nile system) and b) (Toshka), on a monthly basis. 3. First level approximation – 3/a The difference between the inflow and the demand will be calculated in order to obtain the new stored volume (with reference to the volume of the previous month), on a monthly basis. 3/b Based on this new stored volume, the new surface area of the lake and the new water elevation upstream of the dam will be calculated (monthly average), based on the available historical series of data and/or formulas presently used by the Nile Sector. 3/c The calculation of evaporation losses and seepage losses will be operated based on the surface area and the water level (monthly average), based again on available historical data and/or formulas used by the Nile Sector. 4. The final water level obtained will be compared with the constraints imposed by the dam operations. The LNR model will be a separate module (although fully integrated), which will receive most of the necessary data from the Water Demand Model. V.6 Other Models According to the level of models integration, some new models that complement the previous ones may be implemented. The identification of those models could suggest a road map for the future in-house development of the DSS application, which can be continued either by the SRU engineers or any other third party using the open source development architecture. Any additional work should be undertaken only when there will be a clear understanding of the new features that should be included in the models. While this activity is foreseen in November 2007 (according to the updated workplan), it is recommended to focus on the finalization of the five described models (and the collection of the necessary data) before working on the conceptualization of new models. 7 VI. D ATA CORRECTIONS VI.1 Validation and Integration of Maps from Different Sources The objective of this verification is to control the quality of the maps and validate their output before incorporating them into the DSS production system. The approach adopted at the beginning of the project consisted in having the international consultants correcting all the maps and layers produced from previous activities in a specific timeframe. This approach has been chan ged to save time and manage the available resources in a more efficient way: every layer produced is now reviewed right after it has been completed, so that the validation of the layers is performed in real time by the SRU staff. As maps are gathered, they are assessed in terms of quality, veracity, accuracy, feature sets presented and several other characteristics. The work required to ensure the map compatibility is being carried out in joint collaboration by the SRU, the technical team of MAI-Bari and the IT-Synergy consultants. IT Synergy has developed the following technique for the validation of the shape map layers: the shape files are converted into the KML format (the format used by Google Earth), geo-referenced and imported into the Google Earth application. For example, the overlapping of the canal and drainage layers with the satellite images allows to visually identifying any possible problem, such as: 8 a) Missing data due to the evolution of the canal and drainage networks: the maps obtained by the Egyptian Survey Authority are dated 1990 and do not reflect the evolution of the network occurred during the past 17 years. b) Small imperfections in the GIS shape layers, such as elements of the network that should be merged and indeed are not connected to each other, causing an interruption of the digital network. Many of the problems found have actually no significant effect in the water demand model implementation, but it was decided to perform a very detailed correction to allow the further integration of new models that might depend on those details. Besides, there seems to be no other organization in Egypt who has a comprehensive digital map of water and drainage canals: therefore, the work that is presently carried on should be valuable for the Egyptian community as a whole. Some of the corrections may have an impact on the current delimitation of the spatial units, but the project team agreed that changes should be made in order to provide a system as close to reality as possible. The SRU team is currently responsible for the correction under the supervision of IT Synergy. VI.2 Procedures for Correcting the Vector Layers Here are some of the issues that were not taken into consideration when the schematic network and nodes were created as layers for the DSS: ● The network nodes do not intersect with the canals layer: this is a problem that needs to be corrected manually (because the network nodes should be located along the canals path). 9 Mismatching between the canals vector layers and the satellite images: the canals layer is not completely accurate and some corrections needed to be done to match them with the satellite images provided by Google Earth. The satellite images obtained from Google Earth have an approximately scale of 1:2500, which is more than enough for an accurate correction, considering that the digital maps have a scale of 1:50000. Connectivity errors: there are many different connectivity errors, which are being corrected by editing the canals layer. 10 ● Some new canals and drains do not exist in the current available network layer. This situation can be corrected by inserting the new canals as features into the GIS layer. ● The schematic network needed to be converted to a network layer. In this way, all the different links in the maps are easily located and have an embedded GIS reference. If all the links that define the schematic network are included in the database as a layer, it becomes very easy to locate them. This revision process allowed identifying a number of problems existing in the official digital maps provided by the Egyptian Survey Authority. A first revision was done to identify all the problems that could affect both the schematic network and possibly the spatial units. As previously mentioned, it was then suggested to follow a different procedure, i.e. to correct on the spot the errors marked. This solution allows the correction of the KML file from Google Earth while visualizing the satellite images. These KML files are later exported, converted into shape format again and introduced in the corrected version of the digital map. More in details, the steps for correcting those errors are as follows: 1. Projecting the DSS maps from Red Belt Projection to WGS84 using FWTOOLS (a Linux utility for dealing with maps); 11 2. Converting the DSS projected maps from shape format to KML format (utilized by Google Earth) using FWTOOLS; 3. Providing two kinds of layers for canals and drains: in line type layer and point type layer, as a solution for labeling canals with specifi c identificators in order to spot and edit them. 4. Classifying canals according to the Egyptian orders, and correcting the errors and shifting up to the 3 rd order canals ( the visual order identification is based on colors and thickness). The above was done by using Google Earth with the support of the schematic network (2003) and the available paper maps for each irrigation directorate. After the completion of this task, all spatial units will have to be reviewed and eventually modified. This is a major activity since a modification of the spatial units layer will require a modification of all existing data, such as crop patterns, population data and so on. The SRU staff has acquired enough expertise to carry on this task, but the team of expatriate consult ants should review again the final results once achieved. VI.3 Data Digitization The conversion of the maps from hard copies to a digital format is actually implemented in three steps: scanning, geo-referencing and the digitization process itself. For example, once the hardcopy maps were obtained from the MWRI Irrigation Department, they were scanned using a high-resolution ColorTrac Smart LF4080 Scanner. The scanning was done for all irrigation directorates and included the locations of the monitoring stations obtained from the Irrigation Department. As part of the Rectification process, the Ground Control Points (GCPs) were collected from the scanned maps and the corresponding points were identified from the vector layers obtained from the Egyptian Surveying Authority (using ARCVIEW 3.2a). Identifying the points in the ESA maps that match those points collected from the scanned maps was somewhat difficult due the changes in the shape of the canals and the drains. Therefore, the query tools were used to find the canals and drains. The coordinates of the collected points were recorded from the ESA Digital Maps; then, those coordinates were used in the geo-referencing process using ArcGIS. Finally, the scanned maps were warped to the vector layers of the ESA maps. The rectified scanned maps lead to digitize the boundaries of the irrigation directorates and districts; new “Polygon” themes were created for each irrigation directorate, and the names of the irrigation districts within each directorate were entered into the Attribute Table. 12 In many other cases, the numeric data collected by the project are first inserted into a spreadsheet or database file, and the GIS layer is then created accordingly. VII. CONCLUSIONS AND RECOMMENDATIONS The main recommendations in terms of data collection and dissemination fall into three main categories: the database development (data collection/classification/exchange), the promotion of the initiative and a few technical specifications. VII.1 Database Development VII.1.1 Data Classification The data used by the DSS project, both in terms of base maps, GIS information and modeling data, should be classified with more accuracy, especially for what concerns the relevant sources. The following metadata classification can be suggested: 1. 2. 3. 4. 5. Name of Institute/Organization providing the data; Reference Year(s); Format: hard copy or digital (database file, shape file etc.) Name of DSS model using the data; Geographic information such as: o Measurement Unit (cm, km, feddan ...); o Part of the country covered; o Spatial scale (province, governorate, kilometers… ). This type of classification has been followed in the “Origin of Data” table reported earlier. This should allow a better assessment of the missing data needed to feed the DSS models, ensure a higher degree of credibility to the database, and, ultimately, improve the data collection efforts. The SRU should continuously update this table, and possibly add additional meta-information such as: 6. Type of o o o o Data: Chemical (anion, cation, heavy metals…); Physical (porosity, permeability, depth...); Climatic (temperature, humidity, evaporation...); Land use (building, cultivation, industrial area…); 13 7. Cost of the data, when applicable; 8. Date of collection (and/or time required to obtain the data) ; 9. Additional references concerning the source (field survey, investigation, literature…); 10. Degree of completeness/reliability (for example min/max error allowed when the datum is numerical), and corrections brought by the DSS staff; 11. Time coverage (i.e. since when the data have been collected by the providing organization) and frequency of updates; 12. Name of relevant file in the internal database; 13. Brief definition/description of the data. VII.1.2 Data Exchange To facilitate the exchange of information, the collected data should be returned as soon as possible to the original provider, in the corrected or digitized format (as per the procedures described in the “Data Corrections” paragraph); this would originate a win-win situation, where the provider would have their data corrected or digitized, and would feel more inclined to supply further data to the SRU. VII.1.3 Data Collection The project personnel have certainly been involved in intensive efforts to accumulate all possible sources of maps and data: these efforts should continue during the entire project timeframe, in order to fulfill the data needs of the newly-developed models. While acknowledging the difficulties in obtaining interchangeable data from the different authorities and agencies involved, and the validation/revision activities required, the amount of data collected so far by the project does not allow for the moment to run the different models (except the Water Demand model): a number of data are in hard-copy formats and are being converted into digital spreadsheets and relevant GIS layers, while others are yet to be requested. To avoid the risk of obtaining a highly-conceptualized end-product without enough data to feed the models – hence, without any practical real-world applications - it is recommended to focus on the data collection activities of the Agro-economic / Water Quality / Lake Nasser / Underground Water models before investing time and resources in the development of further models. More in details, on the basis of the required data individuated in the table (cf. “Status” Column) and their possible source, the project will need to submit the official requests through the Ministry of Water Resources and Irrigation, and plan additional field visits to obtain the missing information. 14 It should be noted that some data rightfully) postponed by the SRU, to discussed in the “Data Exchange” corrected/digitized data to the original information. requests have been deliberately (and allow a preliminary data exchange (as paragraph above), i.e. to return the owner before actually requesting further VII.2 Data Dissemination VII.2.1 Website Development The development of a project website showcasing the DSS scope, outputs, benefits and data is strongly recommended. Instead of building a sep arate website, the project pages should be hosted within the NWRC or MWRI domain. This would ensure: o a higher degree of “legitimacy” to the project; o a better visibility in terms of web searches; o an increased sustainability, since the DSS pages would still be online after the end of the project. VII.2.2 Technical Documentation The dissemination of informative documentation should be implemented as soon as possible, to assist participants in coming to a more rapid and clear appreciation of the scope and achievements of the project. The documents to be drafted fall into 3 main categories: 1. General documentation on the project’s outputs and results achieved; 2. DSS software manual; 3. Operational guidelines about how to interpret the DSS output. VII.2.3 Dissemination of the Beta-version The Beta version of the DSS should be distributed to selected stakeholders/end users during the 2007 summer workshop, in order to allow them to provide their feedback on the user interface and other technical aspects. It is in fact essential to involve end-users well before the training 15 phase, as it would be more difficult to have them endorse the software if they are not directly involved during the implementation process. To ensure a proper understanding of the software, some live “one-on-one” demonstrations are recommended – either in the SRU headquarters or directly in the end-users premises (through a regular internet connection). The project staff already invited stakeholders to the SRU premises, but obtained a limited response; it might be worth investigating the second option and promote the initiative in a more proactive way, according to the available human resources and time framework of the project staff. VII.3 Hardware Requirements VII.3.1 Web/GIS Servers The project purchased a server (currently located in the SRU building), a HPCompaq ML110 with a 3 GHz Pentium IV processor and 2 Gb of RAM. While this configuration certainly suits the current needs, it should be noted that both the Web server (PHP), the Apache server (post-GIS) and the modeling tools (Java) are currently installed on the same machine. When the whole system will be finalized and actually up and running, it will be strongly recommended to split the Web server from the GIS server and modeling tools used, to avoid network slowdowns and server crashes. Fortunately, the system architecture was already conceived in this manner by IT Synergy; the suggested transition to a 2-server hardware architecture should therefore be seamless. 16 VII.3.2 Data Backup All backup operations are currently being undertaken by each operator on a manual basis. Due to the large amount of data foreseen, it might be worth installing an automated backup system working on an incremental basis, to save space, time, money and avoid possible operators’ mistakes. The automated backup system could for example offer capabilities such as userdefined scheduling/merging of data, file omission rules (to remove swap files, temporary directories and other unwanted data from the backup), file checksum analysis, data redundancy and automated archive capability (to mirror tape volumes for offsite storage). ANNEX I - G LOSSARY The following glossary clarifies some of the database terms used, for readers who may not be familiar with the relevant terminology. Part of this glossary could also be included in the manuals mentioned in the “Technical documentation” paragraph. Access: An entry-level database management software from Microsoft, which allows to organize, access, and share information. Algorithm: A set of rules for solving a problem. An algorithm must be specified before the rules can be written in a computer language. Application program or package: A set of computer programs designed for a specific task. Arc: A line connecting a set of points that form one side of a polygon. Area: A fundamental unit of geographical information. See polygon. Attribute: Non-graphic information associated with a point, line, or area element in a GIS. Cell: The basic element of spatial information in the raster (grid) description of spatial entities. Clipping: A graphic process of cutting lines and symbols off the edge of a display area. Column: Database tables are made of different columns (fields) corresponding to the attributes of the object described by the table. 17 Contour: A line connecting points of equal elevation. Data: Piece of information collected and formatted in a specific way. The term data is frequently used to describe binary (machine-readable) information. Data Model: A data model is an abstract representation of the data used by an organization, such that a meaningful interpretation of the data may be made by the model's readers. The data model may be at a conceptual, external or internal level (as defined by ANSI). Database: A collection of interrelated information, usually stored on some form of mass-storage system such as magnetic tape or disk. A GIS database includes data about the position and the attributes of geographical features that have been coded as points, lines, areas, pixels or grid cells. Database management systems (DBMS): A set of computer programs for organizing the information in a database. Typically, a DBMS contains routines for data input, verification, storage, retrieval, and combination. DB2: DB2 is a relational database management system developed by IBM. DB2 runs on a variety of platforms including Sun Solaris, Linux and Windows. dBase: dBase is a popular relational database management system produced by Ashton-Tate corporation in the early 1980s. The dBase format is still in use today. Digital: The ability to represent data in discrete, quantized units or digits. Digital Elevation Model (DEM): A quantitative model of landform in digital form. Digitizer: A device for entering the spatial coordinates of mapped features from a map or document to the computer. Field: See Column definition File: A collection of related information in a computer that can be accessed by a unique name. Files may be stored on tapes or disks. Filter: In raster graphics, particularly image processing, a mathematically defined operation for removing long-range (high-pass) or short range (lowpass) variation. Used for removing unwanted components from a signal or spatial pattern. 18 Flat File: Flat file is a data file that has no structured relationships between its records. Font: Symbolism used for drawing a line or representing typefaces used for displaying text. Foreign Key: A foreign key is a key field (column) that identifies records in a table, by matching a primary key in a different table. The foreign keys are used to cross-reference tables. Format: The way in which data are systematically arranged for storage in a computer and for transmission between computers, or between a computer and a device. FoxPro: Visual FoxPro is a Microsoft development environment designed for database developers. Geodesy: The scientific study of the size and shape of the earth and determination of positions on it. Geodetic framework/network: A spatial framework of points whose position has been precisely determined on the surface of the earth. Geographic Information System (GIS): A system of capturing, storing, checking, integrating, analyzing and displaying data about the earth that is spatially referenced. It is normally taken to include a spatially-referenced data base and appropriate applications software. Geo-referencing: The process of delimiting a given object, either physical (e.g. a lake) or conceptual (e.g. an administrative region), in terms of its spatial relationship to the land; the geographic reference thus established consists of points, lines, areas or volumes defined in terms of some coordinate system (usually latitude and longitude, or UTM northings and eastings, and elevation). The background framework pertinent to geo-referencing includes: NTS and BCGS grids and related features. Geo-coding: The activity of defining the position of geographical objects relative to a standard reference grid. Geographics or geographic projection: Representation of the earth's surface as a projection onto rectangular lines of latitude and longitude. Global Positioning System: A system of earth satellites, each providing precise time and position information which enables a GPS receiver to compute the distance to each satellite. The distance measurements of at least three satellites are required to fix the receivers position in latitude and 19 longitude. Measurements from a fourth satellite are required to provide vertical (altitude) positioning . Graphic Tablet: A small digitizer ( usually 28 cms x 28 cms) used for interactive work with a GIS or CAD/CAM system. Grey scales: Levels of brightness (or darkness) for displaying information on monochrome display devices. Grid: 1. A network of uniformly spaced points or lines on the CRT for locating positions. 2. A set of regularly spaced sample points. 3. In cartography, an exact set of reference lines over the earth's surface. 4. In utility mapping, the distribution network of the utility resources, e.g. electricity or telephon e lines. Index: An index is a database feature (a list of keys or keywords), allowing searching and locating data quickly within a table. Indexes are created for frequently searched attributes (table columns) in order to optimize the database performance. Interpolate: To estimate the value of an attribute at an unsampled point from measurements made at surrounding sites. Latitude: Angular distance, expressed in degrees and minutes, along a meridian north or south of the equator. Legend: The part of the drawn map explaining the meaning of the symbols used to code the depicted geographical elements. Lock: Locks are used by Database management systems to facilitate concurrency control. Locks enable different users to access different records/tables within the same database without interfering with one another. Locking mechanisms can be enforced at the record or table levels. Longitude: The angular distance east or west from a standard meridian to another meridian on the earth's surface; expressed in degrees and minutes. Map: Cartography; a hand-drawn or printed document describing the spatial distribution of geographical features in terms of a recognizable and agreed symbolism. Digital; the collection of digital information about a part of the earth's surface. Map Generalization: The process of reducing detail on a map as a consequence of reducing the map scale. The process can be semi-automated for certain kinds of data, such as topographical features, but requires more insight for thematic maps. 20 Map projection: The basic system of coordinates used to describe the spatial distribution of elements in a GIS. Mathematics: The study of geometric properties and spatial relations unaffected by continuous change in the shape and size of figures. Meta-Data: Meta-data is data about data. It typically includes information such as currency, accuracy, extent, custodianship, and collection methodology. Meta-data is typically stored in data models, dictionaries, schemas and other representations. Modeling: 1. The representation of the attributes of the earth as surface in a digital database. 2. The studying of landscape processes using mathematical algorithms written in computer code. Module: A separate and distinct piece of hardware or software that can be connected with other modules to form a system. MySQL: MySQL is an open source relational database management system. MySQL can be used on various platforms including UNIX, Linux and Windows. Network: 1. Two or more interconnected computer systems for implement ation of specific functions. 2. A set of interconnected lines (arcs, chains, strings) defining the boundaries of polygons. Node: The point at which areas (lines, chains, strings) in a polygon network are joined. Nodes carry information about the topology of the polygons. Normalization: Normalization is the process of organizing data to minimize redundancy and remove ambiguity. Normalization involves separating a database into tables and defining relationships between the tables. ODBC: Short for Open DataBase Connectivity, a standard database access technology developed by Microsoft Corporation. The purpose of ODBC is to allow accessing any DBMS (DataBase Management System) from any application (as long as the application and the database are ODBC complian t), regardless of which DBMS is managing the data. ODBC achieves this by using a middle layer, called a database driver, between an application and the DBMS. The purpose of this layer is to transform the application's data queries into commands that the DBMS understands. OLE DB: Short for Object Linking and Embedding Data Base. OLE DB is a set of COM-based interfaces that expose data from a range of sources. OLE DB interfaces give applications standardized access to data stored in various information sources like Relational Database Management Systems (MS SQL Server, Oracle, MySQL), small personal databases like MS Access, 21 productivity tools like spreadsheets; plain text files, etc. These interfaces support the amount of DBMS functionality appropriate to th e data store, allowing the data store to share its data. Oracle: Oracle is an enterprise relational database management system. Polygon: A multi-sided figure representing an area on a map. PostgreSQL: PostgreSQL is an object-oriented open source relational database management system, which uses a subset of SQL language. Primary Key: The primary key of a relational table holds a unique value, which identifies each record in the table. It can either be a normal field (column) that is guaranteed to be unique or it can be generated by the database system itself. Projection: The representation on a plane surface of any part of the surface of the earth. Query: Queries are the main way to make a request for information from a database. Queries consist of questions presented to the database in a predefined format. Raster: A regular grid of cells covering an area. Raster-to-vector: The process of converting an image made up of cells into one described by lines and polygons. Record: The record is a complete set of information presented within a RDBMS. Records are composed of different fields (columns) in a table and each record is represented with a separate row in this table. Resolution: The smallest spacing between two display elements; the smallest size of feature that can be mapped or sampled. Row: See Record definition SQL: SQL is short for Structured Query Language and is an industry standard language used for manipulation of data in a RDBMS. Stored Procedure: Stored Procedure is a set of SQL statements stored within a database server and is executed as single entity. Table: A Table in RDBMS refers to data arranged in rows and columns, which defines a database entity. 22 Topography: The configuration of a planetary surface including its relief and the position of its natural and man made features. Topology: The way in which geographical elements are related to each other. The topology of the data must be defined before GIS analysis can be performed. Toponymy: The study of the place names of a region. A toponym is a place name. Transaction: Transaction is a group of SQL database commands regarded and executed as a single atomic entity. Transform: The process of changing the scale, projection, or orientation of a mapped image. Trigger: Triggers are special type of stored procedures executed automatically when certain events take place. Unix: A general-purpose, multi-user computer operating system. Vector graphics structure: A means of coding line and area information in the form of units of data expressing magnitude, direction, and connectivity. Window: A usually rectangular area that is used to view or to transform the original map. ANNEX II – L IST OF P ERSONS M ET Domenico Merola - UTL Director, DGCD Guido Benevento - Development Cooperation Advisor, DGCD Filippo Gotti - Expert, DGCD Luca Ferruzzi - Expert, DGCD Fabrizio Fuccello - Expert, DGCD Giuliano Soncini - Expert, DGCD Giuliano Basso - Expert, DGCD Stefano De Angeli - Expert, DGCD Raoul Martini - Expert, DGCD Marco Marchetti - Italian Co-Manager, EIECP Said El Dalil - Egyptian Co-Manager, EIECP Francesco Manzo - DSS Italian Co-Manager Nahla Abou El Fotouh - DSS Egyptian Co-Manager & Director SRU Alaa Abdin - Modeling Specialist, SRU Essam A. Khalifa - Minister’s Office Director for Research & Special Studies, MWRI Hussein I. El Afty - Sector Head, Minister’s Technical Office, MWRI 23 Essam Khalifa - Director, Minister's Office for Research & Special Studies, MWRI Sanaa Abdel Rasheed Mohamed - Technical office of Irrigation Sector Head, MWRI Mohamed Rami - Director General Center Information Systems, MRWI Wael Khairy - Director for Technology and Information, MWRI Talaat Abdel-Malek - Director, PEMA Mahinaz El Hewz - Assistant Director, PEMA Ahmed Hamed - Economic Researcher, PEMA Nancy Gamal Okail - Senior Economic Researcher, PEMA Laila Shahd - Senior Economic Researcher, PEMA Vincenzo Puliatti - CEO, IT Synergy Sherif Nagy - Dept. Manager, IT Synergy Alejandro Barros - Technical Manager, IT Synergy Gihan Samir - Administration Manager, IT Synergy Hosam Abdle Latif Besheer - Financial Officer, EIECP Antonio La Rocca - Civil Works Consultant, EIECP Eric Mino - Head of Technical Unit, EMWIS Andrea Tani - Co-Manager, EMWIS Ahmed Abou El-Soud - Director of Water Quality Management, EEAA Marco Spada - Director, Italian Egyptian Debt for Development Swap Program Mostapha A. Saleh - Vice president, Environmental Quality International Amany Nakhla - Programme Officer, UNDP Luigi Cavestro - Project Manager, IAMB 24