Java Reference
In-Depth Information
Figure 15.7 The structure of the GIS database
Decision point
How does the GIS data model keep track of the data origin?
We need to find the right balance between flexibility and usability. At one
extreme, we could decide to associate single geographic features (e.g. the
city of Naples or the Via Appia) with data records extracted from different
tables and databases. This approach is extremely flexible, but does not
guarantee semantic consistency. The user expects to get similar information
(e.g. people) when he or she browses the same type of geographic features
(e.g. cities). At the other extreme, we could associate an entire cartographic
map to a single data record. This approach makes the GIS almost useless.
We adopt an intermediate solution. For each map layer, every entity set
can be associated with only one table of a given database. For example, the
set of links in layer “Imperial Rome” of map “Roman History”, is associated
with table Routes in database GIS.HistoricGeography . The key of this table is
attribute ID and the label is attribute Name . Every feature instance is
Table 15.2 An example of content description of table Databases
ID
Name
Description
1
Historical evolution of human settlements in Italy
GIS.HistoricGeography
2
People that occupied the Italian peninsula in different ages
GIS.AncientPeople
Table 15.3 An example of content description of table Tables
ID
ID_DB
Name
Description
Key
Label
1
1
Main cities
ID
Name
Cities
2
1
Connection routes
ID
Name
Routes
3
1
Seaports
ID
City
Ports
4
2
Native people of the Italian peninsula
ID
Ethnos
Native
5
2
People that invaded the Italian peninsula
ID
Ethnos
Barbarians
 
Search WWH ::




Custom Search