Title: IDRISI Data Storage Files
1(No Transcript)
2(No Transcript)
3(No Transcript)
4(No Transcript)
5(No Transcript)
6(No Transcript)
7(No Transcript)
8(No Transcript)
9(No Transcript)
10IDRISI Data Storage Files
11Entity Model, Cell Values, and File Structure of
a Raster GIS
12(No Transcript)
13Raster File Structure IDRISI names raster files
as images. Each image consists of a defined count
of rows and columns thus forming cells. These
cells are stored as a sequence of numbers (byte,
integer or real) representing values (vegetation
classcodes, reflectance numbers, political units,
z-values in a DEM, ...). Let us imagine a very
simple image
5 columns, 4 rows. The values may represent some
code for land usage. IDRISI is starting in the
upper-left corner (row 0/column 0), then advances
column by column and row by row. In the simplest
format - ASCII - the cellvalues are stored one in
each line 22221818181515(...)11151212
12
14- Commonly the images are stored binary, one value
after the other. Depending on the datatype a
value occupies more or less of memory. Simple RLC
(run length compression) is supported as packed
binary (i.e., the cellvalue is followed by the
number of occurrences in the series) - not packed 22 22 18 18 18 15 15 18 16 16 11 15
15 18 16 11 15 12 12 12 - packed 22 2 18 3 15 2 18 1 16 2 11 1 15 2 18 1
16 1 11 1 15 1 12 3 - Unfortunately our image is not well suited for
compression. The compressed image requires 4
additional bytes! But images with large areas of
the same values can show packing ratios up to
1100 and more. - The table shows IDRISI's datatypes (except
compression they apply to vectorfiles as well)
Evidently the image 'does not know' about its
dimensions or about the area one cell covers in
real. So we need a 'header file', the
documentation file, which corresponds with a
image.
15Raster Documentation Files remember, a raster in
IDRISI carries no information about 'itself' - we
need to store that metadata separately. This is
done by so-called raster documentation files
(.RDC). All images must have their corresponding
RDC-files. These are ASCII files made up by a
sequence of lines, each representing metadata. To
ease handling, IDRISI comes with a tool called
METADATA
16You see a lot of fields which can be divided into
obligate and facultative ones
As indicated, several fields are purely
descriptive. Nevertheless it is highly
recommended to provide any additional information
about the data to help assure higher accuracy
17(No Transcript)
18(No Transcript)
19(No Transcript)
20Vector File Structure primarily IDRISI is
raster-based, but vectors can be used to get data
from other sources into IDRISI. Further they
serve as overlays for better visual orientation.
We can digitize vector-polygons onscreen during
the process of supervised image classification to
define our training areas, and we will tell
IDRISI where to put texts in our maps through
vector-points. See how IDRISI vector-files are
structured Id n x1 y1 x2 y2 x3 y3
...... xn yn Id n x1 y1 x2 y2 ......
...... 0 0
2 columns, 1st line holds an identifier (integer
or real) plus the number of coordinates following
(in case of point-files 1). As many lines as
specified before define the vertex-coordinates.
Each vector-file has to end with 0 0 (zero
zero).Polygon-vectors are cycled in that the
last X/Y-pair equals the first one for each
single polygon.
21Let us take height-data (eg. from a GPS) as an
example for a point-vector file 1211 1
212328.0 424876.0 1250 1 212400.0
425090.0 1283 1 213222.5 426112.5 ...... 1423
1 215089.2 428987.6 1423 1 215234.0
429876.7 0 0 Identifiers need not be
unequivocal. In this case they mean the heights
of the points.
22Vector Documentation Files The vector-file too is
a 'dumb thing', that has to be told about its
nature, so every IDRISI vector-file (.vct) comes
with a vector documentation file (.vdc). The
module METADATA again helps to input the
metadata
23(No Transcript)
24(No Transcript)
25(No Transcript)
26Geographic features on a map are represented as
points, lines, and polygons
27(No Transcript)
28(No Transcript)
29(No Transcript)
30(No Transcript)
31(No Transcript)
32(No Transcript)
33Comparison of Raster and Vector Models
34(No Transcript)
35(No Transcript)
36(No Transcript)
37(No Transcript)
38(No Transcript)
39Effect of Model Resolution
40(No Transcript)
41(No Transcript)
42DBMS and GIS Database Design
- Understand some basic definitions
- Introduce levels of abstraction
- Identify database requirements
- Understand how DBMS responds
- Introduce GIS database design
43What is meant by the term data?
- A collection of facts, concepts, or instructions
in a formalized manner suitable for communication
or processing by humans (Worboys 1995)
Data Information Knowledge
Wisdom
44What is meant by the term data model?
- An abstraction of the real world which
incorporates only those properties thought to be
relevant to the application at hand - In GIS, the mechanistic representation and
organization of of spatial data (McDonnel and
Kemp 1995) - A model of the structure of the information
system, independent of implementation details
(Worboys 1995)
45What is a database?
- A collection of data organized according to a
conceptual schema (McDonnel and Kemp 1995) - Schema a structured framework (Merriam-Webster
2002)
46A repository of varied views
47The origins and forms of data
- Captured recorded by devices
- Interpreted some kind of human intervention
- Field sketches
- Surveys and questionnaires
- Encoded as in maps or digital data
- Structured organized in some way
48In order to provide processes
- There are requirements of digital databases
- Security
- Reliability
- Integrity
- Providing user views
49and more requirements
- Being independent of the underlying data
- Providing support for metadata
- High performance
- Providing concurrency to users
50What is a response to these requirements?
- A Database Management System (DBMS)
- A software system that manages a database
- A system providing the functions
51How databases are designed to support the
requirements ?
- Four levels of data modeling
- External
- Conceptual
- Logical
- Internal
52GIS Database Design
A specific applications area
- Application Domain
- Modeling the Application Domain
- Application Domain Model
-
-
-
System analysis
Conceptual Model
System Design
Logical Model
computational
System Implementation
Physical Model
(after Worboys 1995)
53What is a RDMBS?
- A type of DBMS that organizes data into a series
of records held in linked tables - Aids in data access and transformation because of
flexible linkages based on record values
54Some definitions
- Domain a pool of values from which specific
attributes of specific relations draw their
actual values - Tuple an ordered list of values
- Primary key a unique identifier for a table
any column or combination of columns with the
property that no two rows of the table have the
same value in that column or columns
55The Suppliers Relation
Supplier
City
Status
Sup_Name
TUples
Relation
Attributes
56Terminology for Relational Data Objectst
After Date 1995
57Database Queries
58Database query Reclass Overlay Assign Histogra
m Area/Perimeter Mathematical operators Overlay
Scalar Transform Distance operators Distance B
uffer Cost
Context operators Surface Filter Group Statisti
cs Regression Random Numbers others Image
Processing Decision Support
59(No Transcript)
60(No Transcript)
61Boolean Algebra
62Relational Algebra
- Relational Algebra consists of a collection of
operators, such as join, union, and intersect,
that take relations as their operands and return
relations as their result - Relational Closure because the product of every
operation is the same kind of object as the
input, the output can become input for additional
operations.
63Relational Algebra
Relation
Relation
Operator
Union
A
B
64E.F. Codds 8 Operators
- Traditional
- Union
- Intersection
- Difference
- Product
- Special
- Restrict
- Project
- Join
- Divide
1970, A Relational Model of Data for Large Shared
Data Banks, in Communications of the ACM, Vol.
13, No. 6, June 1970, pp. 377-387
65Union
- Returns a relation consisting of all tuples
appearing in either or both of two specified
relations. Relations must be same shape
66Intersect
- Returns a relation consisting of all tuples
appearing in both of two specified relations.
Relations must be same shape.
67Difference
- Returns a relation consisting of all tuples
appearing in the first and not the second of two
specified relations. Relations must be same shape
68Examples
A
B
A union B
A intersect B
A difference B
69Product
- Returns a relation consisting of all possible
tuples that are a combination of two tuples, one
from each of two specified relations. The
cardinality of the result will be the product of
the cardinality of the two relations, and the
degree will be the sum of the degrees of the two
relations.
x y
70Restrict
S
- Returns a relation consisting of all tuples from
a specified relation that meet a specified
condition. Usually expressed as a WHERE clause.
Rome
London
Paris
London
London
Rome
S WHERE City London
London
Madrid
71Project
Parts
- Returns a relation consisting of all tuples that
remain as (sub)tuples in a specified relation
after specified attributes have been eliminated.
length
weight
shipper
part_no
manufacturer
Parts color, city
72Join
a1 b1 a2 b1 a3 b2
- Returns a relation consisting of all possible
tuples that are a combination of two tuples, one
from each of two specified relations, such that
the two tuples contributing to any given
combination have a common value for the common
attribute(s) of the two relations (and that
common value appears just once, not twice, in the
resulting tuple).
b1 c1 b2 c2 b3 c3
Join
a1 b1 c1 a2 b1 c1 a3 b2 c2
73Divide
- Takes two relations, one binary and one unary,
and returns a relation consisting of all values
of one attribute of the binary relation that
match (in the other attribute) all values in the
unary relation.
x z
a x a y a z b x c y
Divide
a
b
74Query Language
- A computer language used in database management
systems to retrieve, add, modify, or delete data
75SQL Structured Query Language
- Standard language used with relational databases
to build complex logical expressions to access
data - Developed by IBM in the 1970s, has become an
industry standard - Considered to be a 4GL
76SQL Statements
- SELECT column(s)
- FROM table(s)
- WHERE row condition(s)
- Returns a table