Download DSS_data_collection_annex_pt_5

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