Presentation is loading. Please wait.

Presentation is loading. Please wait.

University of L’Aquila, Department of Electrical and Information Engineering

Similar presentations


Presentation on theme: "University of L’Aquila, Department of Electrical and Information Engineering"— Presentation transcript:

1 University of L’Aquila, Department of Electrical and Information Engineering {tarquini,eliseo}@ing.univaq.it

2 Presentation summary Introduction Class Relations Case study Constraint for the river class and its subclasses River properties expressed using constraints Conclusions & Future Work Introduction Class Relations Case study Constraint for the river class and its subclasses River properties expressed using constraints Conclusions & Future Work

3 Interoperability & Integrity Interoperability in the world of geographical data and applications is a huge problem The quality and integrity of spatial data is very important to support interoperability A possible way to approach the problem is the introduction of a semantic level: The user level Interoperability in the world of geographical data and applications is a huge problem The quality and integrity of spatial data is very important to support interoperability A possible way to approach the problem is the introduction of a semantic level: The user level

4 The User Level Is a semantic layer that is able to describe all typical application and user concepts We also provide: translation criteria towards the background system layer: the geometric one Is a semantic layer that is able to describe all typical application and user concepts We also provide: translation criteria towards the background system layer: the geometric one

5 Why a user Level? At the user level, it is possible to express queries or deploy services in a more abstract way, using typical concepts of application and user domain. User level relations (e.g. The river flows into the sea) At the user level, it is possible to express queries or deploy services in a more abstract way, using typical concepts of application and user domain. User level relations (e.g. The river flows into the sea)

6 Originality Definition at the user level of integrity constraints for spatial objects Introduction of class relations Mapping rules that allow the translation of user relations into topological relations. Definition at the user level of integrity constraints for spatial objects Introduction of class relations Mapping rules that allow the translation of user relations into topological relations.

7 Presentation summary Introduction Class Relations Case study Constraint for the river class and its subclasses River properties expressed using constraints Conclusions & Future Work Introduction Class Relations Case study Constraint for the river class and its subclasses River properties expressed using constraints Conclusions & Future Work

8 Class relations “tributary rivers flow into other rivers” –every tributary river flows in a bigger river, but not that every river has a tributary river “the source is a part of a river”. –every source is a part of a river and every river has a source “tributary rivers flow into other rivers” –every tributary river flows in a bigger river, but not that every river has a tributary river “the source is a part of a river”. –every source is a part of a river and every river has a source

9 Type of constraints Among instances of the same class and among instances and their parts; Among instances of similar classes (part/whole relations included); Among instances of different classes. Among instances of the same class and among instances and their parts; Among instances of similar classes (part/whole relations included); Among instances of different classes.

10 Class relation Model We extended the model proposed by Donnelly and Bittner (2005)

11 Class relation model (2) Considering φ() and ψ() two function or two more general transformations

12 Presentation summary Introduction Class Relations Case study Constraint for the river class and its subclasses River properties expressed using constraints Conclusions & Future Work Introduction Class Relations Case study Constraint for the river class and its subclasses River properties expressed using constraints Conclusions & Future Work

13 Case Study class River some of its subclasses multi-representation scenario class River some of its subclasses multi-representation scenario

14 Similar classes and Methods Water_Field that will be the superclass of –Lake – Sea –River get_geometry(detail_level): River -> Geometry source ():River ->River_source mouth ():River ->River_ mouth Water_Field that will be the superclass of –Lake – Sea –River get_geometry(detail_level): River -> Geometry source ():River ->River_source mouth ():River ->River_ mouth

15 Sets of user level relations & Properties U= {disjoint, confluence, split}. S= {disjoint, originate, flow} Properties –P = {evaporation, infiltration, karstification}, U= {disjoint, confluence, split}. S= {disjoint, originate, flow} Properties –P = {evaporation, infiltration, karstification},

16 Sets of geometric topological relations T = {disjoint, touch, cross, in, overlap}

17 Presentation summary Introduction Class Relations Case study Constraint for the river class and its subclasses River properties expressed using constraints Conclusions & Future Work Introduction Class Relations Case study Constraint for the river class and its subclasses River properties expressed using constraints Conclusions & Future Work

18 Constraint of the river class User level River_Constraint = Constraint 1 (disjoint ∨ confluence) all-all(River,River) Constraint 2 (disjoint ∨ split ) all-all(River_source,River) Constraint 3 (disjoint ∨ confluence) all-all(River_mouth,River) Geometric level River_Constraint = Constraint 1g (disjoint ∨ touch)all-all(River.get_geometry(),River.get_geometry()) Constraint 2g (disjoin ∨ touch ∨ in)all-all(River_source.get_geometry(),River.get_geometry()) Constraint 3g (disjoint ∨ touch ∨ in)al-all (River_mouth.get_geometry(),River.get_geometry()) User level River_Constraint = Constraint 1 (disjoint ∨ confluence) all-all(River,River) Constraint 2 (disjoint ∨ split ) all-all(River_source,River) Constraint 3 (disjoint ∨ confluence) all-all(River_mouth,River) Geometric level River_Constraint = Constraint 1g (disjoint ∨ touch)all-all(River.get_geometry(),River.get_geometry()) Constraint 2g (disjoin ∨ touch ∨ in)all-all(River_source.get_geometry(),River.get_geometry()) Constraint 3g (disjoint ∨ touch ∨ in)al-all (River_mouth.get_geometry(),River.get_geometry())

19 Constraints of river subclasses

20 Main Rivers flow directly into the sea. They can possibly have tributary rivers that join the main river Constraint in addition to the river constraint: User level Disjoint all-all (River_Mouth,River) ∧ Flow all-1(River,Sea) Geometric level Disjoint all-all (River_mouth.get_geometry(), River.get_geometry()) ∧ touch all-1 (River_mouth.get_geometry(), Sea.get_geometry()) Constraint in addition to the river constraint: User level Disjoint all-all (River_Mouth,River) ∧ Flow all-1(River,Sea) Geometric level Disjoint all-all (River_mouth.get_geometry(), River.get_geometry()) ∧ touch all-1 (River_mouth.get_geometry(), Sea.get_geometry())

21 Single Rivers flow directly into the sea like main rivers but they do not have any tributary river Constraint in addition to the Main river constraint : User level disjoint all-all (River,River) Geometric level Disjoint all-all (River.get_geometry(), River.get_geometry(L1)) Constraint in addition to the Main river constraint : User level disjoint all-all (River,River) Geometric level Disjoint all-all (River.get_geometry(), River.get_geometry(L1))

22 Tributary rivers end their course into a bigger river through a confluence relation, and they are disjoint from the sea Constraint in addition to the river constraint : User level Confluence all-1 (River,River) ∧ disjoint (River,Sea) Geometric level touch all-1 (River.get_geometry(L1),River.get_geometry(L1)) ∧ in all-1 (River_mouth.get_geometry(L1),River.get_geometry(L1)) ∧ disjoint all-all (River_mouth.get_geometry(L1), Sea.get_geometry()) Constraint in addition to the river constraint : User level Confluence all-1 (River,River) ∧ disjoint (River,Sea) Geometric level touch all-1 (River.get_geometry(L1),River.get_geometry(L1)) ∧ in all-1 (River_mouth.get_geometry(L1),River.get_geometry(L1)) ∧ disjoint all-all (River_mouth.get_geometry(L1), Sea.get_geometry())

23 Influent rivers flow into lakes; hence they are disjoint from the sea Constraint in addition to the river constraint : User level Flow all-1 (Rive,Lake) ∧ disjoint all-all (River,Sea) Geometric level touch all-1 (River.get_geometry(),Lake.get_geometry()) ∧ touch all- 1 (River_mouth.get_geometry(),Lake.get_geometry()) ∧ disjoint all-all (River.get_geometry(), Sea.get_geometry()) ∧ disjoint all-all (River_mouth.get_geometry(), Sea.get_geometry()) Constraint in addition to the river constraint : User level Flow all-1 (Rive,Lake) ∧ disjoint all-all (River,Sea) Geometric level touch all-1 (River.get_geometry(),Lake.get_geometry()) ∧ touch all- 1 (River_mouth.get_geometry(),Lake.get_geometry()) ∧ disjoint all-all (River.get_geometry(), Sea.get_geometry()) ∧ disjoint all-all (River_mouth.get_geometry(), Sea.get_geometry())

24 Emissary rivers originate from a lake; they possibly can flow into the sea or join another river Constraint in addition to the river constraint : User level originate all-1 (River,Lake) Geometric level touch all-1 (River.get_geometry(),Lake.get_geometry()) ∧ touch all-1 (River_source.get_geometry(),Lake.get_geometry()) ∧ touch all-1 (Source_point, Polygon) Constraint in addition to the river constraint : User level originate all-1 (River,Lake) Geometric level touch all-1 (River.get_geometry(),Lake.get_geometry()) ∧ touch all-1 (River_source.get_geometry(),Lake.get_geometry()) ∧ touch all-1 (Source_point, Polygon)

25 Presentation summary Introduction Class Relations Case study Constraint for the river class and its subclasses River properties expressed using constraints Conclusions & Future Work Introduction Class Relations Case study Constraint for the river class and its subclasses River properties expressed using constraints Conclusions & Future Work

26 Evaporation rivers do not flow into sea or in a lake but evaporate into the air Constraint in addition to the river constraint : User level disjoint all-all (River,Water_field) Geometric level disjoint all-all (River.get_geometry(), Water_field.get_geometry()) ∧ disjoint all-all (River_mouth.get_geometry(),Water_field.get_geometry()) Constraint in addition to the river constraint : User level disjoint all-all (River,Water_field) Geometric level disjoint all-all (River.get_geometry(), Water_field.get_geometry()) ∧ disjoint all-all (River_mouth.get_geometry(),Water_field.get_geometry())

27 Infiltration rivers do not flow into sea or in a lake but at some point of their course, infiltrate into the ground Constraint in addition to the river constraint : User level disjoint all-all (River,Water_field) Geometric level disjoint all-all (River.get_geometry(), Water_field.get_geometry()) ∧ disjoint all-all (River_mouth.get_geometry(),Water_field.get_geometry()) Constraint in addition to the river constraint : User level disjoint all-all (River,Water_field) Geometric level disjoint all-all (River.get_geometry(), Water_field.get_geometry()) ∧ disjoint all-all (River_mouth.get_geometry(),Water_field.get_geometry())

28 Karstic rivers infiltrate into the ground to emerge again somewhere else and end their course towards the sea Constraint in addition to the river constraint : User level disjoint all-2 (River.comp(i),Sea) ∧ (Flow all-1(River.Comp(n),Water_Field) ∨ Confluence all- 1(River.Comp(n),River)) Geometric level disjoint all- 2 (River.Comp(1).get_geometry(), Water_field.get_geometry()) ∧ (touch all-1 (River_mouth.Comp(n).get_geometry(), Sea.get_geometry()) ∨ touch all- 1 (River_mouth.Comp(n).get_geometry(), Sea.get_geometry()) Constraint in addition to the river constraint : User level disjoint all-2 (River.comp(i),Sea) ∧ (Flow all-1(River.Comp(n),Water_Field) ∨ Confluence all- 1(River.Comp(n),River)) Geometric level disjoint all- 2 (River.Comp(1).get_geometry(), Water_field.get_geometry()) ∧ (touch all-1 (River_mouth.Comp(n).get_geometry(), Sea.get_geometry()) ∨ touch all- 1 (River_mouth.Comp(n).get_geometry(), Sea.get_geometry())

29 Presentation summary Introduction Class Relations Case study Constraint for the river class and its subclasses River properties expressed using constraints Conclusions & Future Work Introduction Class Relations Case study Constraint for the river class and its subclasses River properties expressed using constraints Conclusions & Future Work

30 The river graph

31 Conclusions We showed how class relations can be used to define integrity constraints. As a case study, we chose the class river and a set of different types of rivers. For each subset of river class we have defined a set of integrity constraints Finally, we produced an oriented graph that allows combining the previously defined constraints to characterize river subclasses and their intersections. We showed how class relations can be used to define integrity constraints. As a case study, we chose the class river and a set of different types of rivers. For each subset of river class we have defined a set of integrity constraints Finally, we produced an oriented graph that allows combining the previously defined constraints to characterize river subclasses and their intersections.

32 Future Work New user level spatial relations that will involve other kinds of spatial operators such as projective and metric operators Express constraints for a larger set of features, and capture additional kinds of spatially-related constraints, e.g., direction of flow. definition of an application-dependent visual language that could be used to express queries in a user-friendly interface New user level spatial relations that will involve other kinds of spatial operators such as projective and metric operators Express constraints for a larger set of features, and capture additional kinds of spatially-related constraints, e.g., direction of flow. definition of an application-dependent visual language that could be used to express queries in a user-friendly interface

33 Thank You Any Questions? Thanks for your Attention!!! Francesco Tarquini tarquini@ing.univaq.it Any Questions? Thanks for your Attention!!! Francesco Tarquini tarquini@ing.univaq.it


Download ppt "University of L’Aquila, Department of Electrical and Information Engineering"

Similar presentations


Ads by Google