Transcript Document
Spatial Information Systems (SIS)
COMP 30110 Spatial data structures (1)
Spatial data structures Data structures that have been defined for manipulating sets of spatial entities Two aspects:
–
storing: space occupied? redundancies?
–
querying, analysing, updating, etc.: time required?
In general, it is important to be able to manipulate efficiently, still maintaining a “low” space complexity Requirement: the stored information must allow for an unambiguous representation of the subdivision
Spatial data structures: evaluation Spatial data structures can be evaluated in terms of:
–
space complexity: amount of space (memory) needed for storing all information (entities and relations) that is explicitly represented
–
time complexity of the algorithms for calculating relations that are not explicitly represented
Constant and variable relations In a generic plane subdivision, a relation is: - constant if it involves a constant number of entities (e.g.: EV, EE, EF involve two entities each) e i P i f i e f j P j - variable if it involves a variable number of entities (e.g.: VV, VE, VF, FV, FE, FF involve a different number of entities depending on the different cases) f1 P2 e2 P f2 e1 P1 f2 e2 P2 e1 f P1 e4 f3 f1 e3 P3 e3 P4 P3 f3 f4 e j
Topology/Connectivity
•
Generic sets of entities: any possible topological relations
•
Overlayed sets of entities (plane subdivisions): only meet and disjoint
•
Meet: topological relation that defines connectivity between entities in a plane subdivision
•
Entities of different dimension are “connected” in different ways: relations (vertex-, edge-, face-based) seen before
• • • •
Spaghetti data structure Spaghetti data structure: represents sets of points, lines and polygons Can be used for both generic sets of entities and overlayed sets (plane subdivisions) The geometry of any spatial entity is described independently of other entities No topology/connectivity information is recorded
Spaghetti data structure: example Example: points, lines and polygons are stored separately X5,Y5 X6,Y6 X4,Y4 1 X3,Y3 X11,Y11 X10,Y10 2 X2,Y2 X9,Y9 X7,Y7 X1,Y1 X8,Y8 Polygon 1 Polygon 2 X1,Y1 X2,Y2 X3,Y3 X4,Y4 X5,Y5 X6,Y6 X7,Y7 X1,Y1 X8,Y8 X9,Y9 X10,Y10 X11,Y11 X3,Y3 X2,Y2 X1,Y1 X8,Y8 For each polygon, we store a (ordered) list of coordinates of points on its boundary (this is not the same as FV relation!)
ID P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 Coord.
X1,Y1 X2,Y2 X3,Y3 X4,Y4 X5,Y5 X6,Y6 X7,Y7 X8,Y8 X9,Y9 X10,Y10 X11,Y11 Another data structure P4 P11 P3 1 2 P2 P5 P6 P7 P1 P8 P10 P9 Polygon 1 P1 P2 P3 P4 P5 P6 P7 P1 Polygon 2 P8 P9 P10 P11 P3 P2 P1 P8 Points and polygons are related: for each polygon, we store a (ordered) list of points (not coordinates) on its boundary: FV relation
Spaghetti data structure: pros & cons
•
Advantages:
–
simplicity
–
easy insertions of new entities (all entities are independent)
•
Cons:
–
inefficient for topological queries
–
redundancies (and consequently, possible inconsistencies!)
Spaghetti data structure: remarks Example: X5,Y5 X6,Y6 X4,Y4 1 X3,Y3 X11,Y11 X10,Y10 2 X2,Y2 X9,Y9 X7,Y7 X1,Y1 X8,Y8 Polygon 1 Polygon 2 X1,Y1 X2,Y2 X3,Y3 X4,Y4 X5,Y5 X6,Y6 X7,Y7 X1,Y1 X8,Y8 X9,Y9 X10,Y10 X11,Y11 X3,Y3 X2,Y2 X1,Y1 X8,Y8 NOTE 1: coordinates of points along common boundary are recorded twice!
Redundancy: if we update coordinates of a point, we need to update them everywhere!
Spaghetti data structure: remarks (cont.d) Example: X5,Y5 X6,Y6 X4,Y4 1 X3,Y3 X11,Y11 X10,Y10 X7,Y7 X1,Y1 X2,Y2 2 X8,Y8 X9,Y9 Polygon 1 Polygon 2 X1,Y1 X2,Y2 X3,Y3 X4,Y4 X5,Y5 X6,Y6 X7,Y7 X1,Y1 X8,Y8 X9,Y9 X10,Y10 X11,Y11 X3,Y3 X2,Y2 X1,Y1 X8,Y8 NOTE 2: no easy way of solving queries such as: “Do Polygon 1 and 2 share a common bounding line?” Need to analyse all coordinates of points of Polygon 1 and compare with those of Polygon 2 and see if two consecutive pairs are the same: inefficient!!
Topological data structures for plane subdivisions
•
Incorporate “connectivity” among spatial objects by storing explicitly a subset of the relations seen before
•
Two types of points:
–
points that are endpoints of a line (vertices)
–
points that define the shape (geometry) of a line
•
For polygons/lines:
–
adjacency information (e.g., encode polygons on each side of a boundary line – left and right polygon with respect to the direction of the line: EF relation)
Topological data structures: motivations Storing connectivity information explicitly allows for more efficient spatial queries Example: if we store relation FE explicitely (i.e., for each polygon we store a list of IDs of edges bounding it), the query: “do Polygon 1 and 2 share a common bounding line?” only requires checking whether the two lists contain any common IDs e5 e4 e6 1 e7 e3 e2 e1 e12 e8 2 e11 e10 e9 Polygon 1 e1 e2 e3 e4 e5 e6 e7 Polygon 2 e8 e9 e10 e11 e12 e2 e1
Topological data structures: motivations (cont.d) Topology/connectivity: important criterion to establish the correctness (integrity, consistency) of geographic databases Examples:
–
neighbouring countries must share a boundary
–
seas and lakes cannot overlap
Doubly-Connected Edge List (DCEL) structure (Preparata and Shamos, 1985)
•
DCEL structure stores:
–
the three sets of entities V, E, F
–
the three edge-based relations EV, EE, EF (all constant)
–
the two partial relations: FE* and VE* EE EV VE * E FE * EF FE* : VE* : associates a face f with one of the edges bounding f associates a vertex v with one of the edges incident in v V F
Example (1) P5 e5 P6 f0 e4 f1 P4 P2 e3 P3 e12 e2 e1 e6 P7 e7 P1 e8 P11 e11 P10 e10 f2 P9 e9 P8 V E F Entities {P1,P2,….., P11} {e1, e2,….., e12} {f0,f1,f2}
P1 P2 P3 P4 Example (2) P5 P6 P7 P8 P9 P10 P11 Partial e5 e6 e7 e8 e9 e10 e11 e1 e2 e3 e4 VE * P5 relations f0 f1 f2 e3 e3 e1 FE * V E F Entities P1,P2,….., P11 e1, e2,….., e12 f0,f1,f2 e5 P6 f0 e4 f1 P4 P2 e3 P3 e12 e2 e1 e6 P7 e7 P1 e8 e10 e11 P11 e11 P10 e10 f2 P9 e9 e12 P8 e1 e2 e3 e4 e5 e6 e7 e8 e9 Edge based EV P1,P2 P2,P3 P3,P4 P4,P5 P5,P6 P6,P7 P7,P1 P1,P8 P8,P9 P9,P10 P10,P11 P11,P3 EF f1,f2 f1,f2 f1,f0 f1,f0 f1,f0 f1,f0 f1,f0 f2,f0 f2,f0 f2,f0 f2,f0 f2,f0 relations EE e7,e2 e1,e12 e2,e4 e3,e5 e4,e6 e5,e7 e6,e8 e1,e9 e8,e10 e9,e11 e10,e12 e11,e3
DCEL: space complexity
For every edge:
3 constant relations are stored (involving 2 entities): 6e
For every face:
1 relation involving one entity: f
For every vertex:
1 relation involving one entity: n Space required to represent relations: 6e + f + n For each vertex we also store the two geometric coordinates: 2n
Retrieving missing relations: FE Calculating complete relation FE: Obtained by combining FE * and EE For example, given a face f1 , we find the first bounding edge e3 using FE * . Then using EE we find the successor e4 of e3 (in counter-closkwise order) on the boundary of f1: if e3 is oriented in such a way that f1 is on its left hand side, then e4 is the second of the two edges associated with e3 through EE P5 e5 P6 f0 e4 f1 P4 P2 e3 P3 e12 e2 e1 e6 P7 e7 P1 e8 P11 e11 P10 e10 f2 P9 e9 P8
Retrieving missing relations: FE (cont.d) We apply the same method (2 nd element of EE) to obtain all other edges on the boundary of f1 , until we reach e3 again.
P5 e5 P6 f0 e4 f1 P4 P2 e3 P3 e12 e2 e1 e6 P7 e7 P1 e8 P11 e11 P10 e10 f2 P9 e9 P8
DCEL: FV and FF FV can be obtained by combining FE and EV: for each bounding edge e of a given face f (obtained with FE), we consider its endpoints using EV FF can be obtained by combining FE and EF: for each bounding edge e of a given face f (obtained with FE), we consider the other face f’ obtained by using EF
DCEL: VE, VV, VF