1 / 33

Spatial relations between classes as integrity constraints

Spatial relations between classes as integrity constraints. Francesco Tarquini and Eliseo Clementini. University of L’Aquila, Department of Electrical and Information Engineering {tarquini,eliseo}@ing.univaq.it . Terra Cognita 2008 - 26.10.2008 Karlsruhe , Germany.

Thomas
Download Presentation

Spatial relations between classes as integrity constraints

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Spatial relations between classes as integrity constraints Francesco Tarquini and Eliseo Clementini University of L’Aquila, Department of Electrical and Information Engineering {tarquini,eliseo}@ing.univaq.it Terra Cognita 2008 - 26.10.2008 Karlsruhe, Germany

  2. Presentation summary • 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

  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

  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)

  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.

  7. Presentation summary • 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

  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.

  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

  13. Case Study • 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

  15. Sets of user level relations & Properties • 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

  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())

  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())

  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))

  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())

  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())

  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)

  25. Presentation summary • 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())

  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())

  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())

  29. Presentation summary • 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.

  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

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

More Related