FEDERATING GEOGRAPHIC DATABASES: A STEP TOWARDS INTEROPERABILITY

Transcription

1 1 FEDERATING GEOGRAPHIC DATABASES: A STEP TOWARDS INTEROPERABILITY North Sea Belgium The Netherlands Germany Robert LAURINI INSA of Lyon France Switzerland Rhine River When is a GIS Federation Worthwhile? I - Introduction Natural or technological risks Street repairs Environmental monitoring and studies International transportation Huge public works Marine cartography (navigation) etc. II - Spatial Schema Integration III - Multidatabase Spatial Querying and Indexing IV - GIS Interoperability V- Conclusion

2 2 "within a few years, isolated GIS will be seen as dinosaurs" GIS Interoperability A Dream for Users A Nightmare for System Developers Open GIS Consortium OGIS "Open Geodata Interoperability Specifications" Cross platform compatibility Necessity of standardization I - Introduction 1.1. Why Distributed Geographic s? 1.2. Definitions / Classifications 1.3. Specificities of Geographic s 1.4. Metadata 1.5. Fragmentation

3 3 Structure of a GIS Separation of Geographic s S u b -s y s te m fo r G e o g ra p h ic D a ta A c q u is itio n U P D A T IN G S u b - s y s te m fo r S p a tia l A n a ly s is S u b -s y s te m fo r th e M a n a g e m e n t o f G e o g ra p h ic a l D a ta b a s e S u b -s y s te m o f C a rto g r a p h ic P re sentation S H A R IN G Geographic MINI Geographic MICRO Geographic Geographic Application A Application B Application C 1.1. Why Distributed Geographic s? Advantages, Drawbacks cost of data re-acquisition, updating remote sites coupling different GIS belonging to several services/institutions splitting of information security responsibility different layers (each user having his own layer) same layers, but different spatial coverages easiness of pereniality (each user is responsible of updating his own information) same GIS product (ex Arc-Info) different GIS products (ex Arc-Info, SmallWorld, SICAD, etc.)

4 Distributed s and alike, Definitions Remote s Distributed s Federated s Distributed DBMS Homogeneous Distributed s Heterogeneous Distributed s Data Dictionary Schema Query Distributed Query Horizontal Fragmentation Vertical Fragmentation Mixed Fragmentation Interoperability Client-server Schemata Views local global export import external transparent to the user located on one site located on several sites

5 5 Decomposition of Schemata according to Several Sites: Distribution Schema Integration of several already Existing s: Federation Global conceptual external # 1 external #2 external #3 external # 1 external #2 external #3 Global conceptual 1.3. Specificities of Geographic s Homogeneous GIS Same GIS on all sites and same spatial representations vertical fragmentation horizontal fragmentation ===> > zonal fragmentation > layer fragmentation Heterogeneous GIS in addition to the previous ones: Scales and accuracy Multiplicity of spatial representations + standardization; conversion > Spatial queries + distributed spatial analysis

6 Metadata Data about data : global / local Spatial metadata contents data name/identifier - definition creator of the data spatial representation - spatial coverage year validity sites - access rights updating procedure duplicates (location) authorized users for modification 1.5. Fragmentations Relational domains : Horizontal, Vertical, Mixt Spatial domains : Zonal, Thematic, Heterogeneous Site A Site B Horizontal fragmentation of a relational table - a piece on site A - a piece on site B Layer Fragmentation Thematic Partitioning keys keys Site C Site D Site E Site F Site G Vertical fragmentation of a relational table (keys are present on both sites) - a piece on site C - a piece on site D Mixed fragmentation of a relational table - a piece on site E - a piece on site F - a piece on site G Electricity Building Parcel

7 7 Zonal Fragmentation Geographic Partitioning Example of Zonal Fragmentation in a Client-server Architecture Zone A Zone B Zone C II - Spatial Schema Integration 2.1. Integration of ta 2.1. Generalities about Schema Integration Scope : starting from different local ta, obtain the global 2.2. Semantic and Topological Discrepancies 2.3. Implications for zonal and layer fragmentations Idea : intermediate ta Approach : Pure binary integration Binary ladder integration N-ary integration

8 8 Global Schema Conventional Schema Integration Intermediate Schema Intermediate Schema User external Imported Exported Exported Exported Exported Schema Schema Schema Schema User Integration of classical databases Site 1 Site 2 Site 3 Site 4 Schema Integration Procedure (Parent and Spaccapietra) Schema 1 Schema 2 Schema 3 Users Transparent Access to Distant Relations SELECT * FROM Peter.L_BLOCK@gis1.paris.fr UNION SELECT * FROM Jim.L_BLOCK@gis2.athens.gr Integration rules Correspondence declaration On the London Site Conflict resolution Schema fusion Administrator CREATE VIEW BLOCK (...) AS SELECT * FROM Peter.L_BLOCK@gis1.paris.fr UNION SELECT * FROM Jim.L_BLOCK@gis2.athens.gr

9 Semantic and Topological Discrepancies Semantic discrepancies in distributed databases type discrepancies definition discrepancies format discrepancies unit discrepancies data acquisition period discrepancies encoding discrepancies interpretation of "nulls" meaning varying over sites existence of synonyms and polysems data capture errors replicate updating discrepancies Semantic discrepancies in distributed geographic databases diversity of geometric representation diversity of coordinate values (scales) presence generalization/detailization diversity of spatio-temporal samplings variability of definition over time and space Gas Company (G-site) G-STREET (#street, street_name, (#axis_segment, width)*) G-SEGMENT (#segment, #point1, #point2) G-POINT (#point, x, y) G-PIPE (#edge, #node1, #node2) G-NODE (#node, x, y, z, type) Water Company (W-site) Integration of Coordinates W-STREET (#street, (#right_segment, order)*, (#left_segment, order)*) W-SEGMENT (#segment, #from_point, #to_point) W-POINT (#point, x, y) W-PIPE (#edge, #from_node, #to_node) W-NODE (#node, x, y, z, (#edge)*, category) X, Y Z X, Y Z Street Repair Company (SR-site) SR-STREET (#street, street_name, (#parcel_segment)*,( kerb_segment)*) SR-SEGMENT (#segment, #point1, #point2, begin_address, end_address) SR--POINT (#point, x, y) SR-G-PIPE (#edge, #node1, #node2) SR-G-NODE (#node, x, y, depth, type) SR-W-PIPE (#edge, #node1, #node2) SR-W-NODE (#node, x, y, depth, type) Ellipsoid 2 Ellipsoid 1

10 Implications for Zonal and Layer Fragmentations Problems measurement errors boundaries do not coincide coordinates not aligned Elastic Transformations (Rubber-sheeting) based on homologous points force-fitting of all points in the plan possibly with constraints Constraints no modifications on any database solving when querying (updating problems) Example of a simple rubber-sheeting function 4 control points to force-fit; no constraints x, y: old coordinates; X, Y: new coordinates 8 unknowns X=axy+bx+cy+d Y=a xy+b x+c y+d 8 equations in total (4 for X s, 4 for Y s) 8 8 matrix to invert to get the parameters Example of Geometric Discrepancies in Layer Fragmentation Geodetic point Water Company Water Pipe Street Repair Gas Company Gas Pipe

11 11 Example of Terrain Integration A : Example for Terrain Integration B : - Grid file representation - UTM co-ordinates - Type A ellipsoid - Convention for sea-level (z=0) in Jackson Harbour - Relations: - TIN's - Gauss co-ordinates - Type B ellipsoid - Convention for sea-level (z=0) in Johnson Harbour - Relations: A_Terrain (#terrain, # mesh) A_Mesh (#mesh, #nw_pt, #ne_pt, #sw_pt, #se_pt) A_Point (#point, x, y, z) B_Terrain B_Triangle B_Point (#terrain,#triangle) (#triangle, #pt1, #pt2, #point3) (#point, x, y,z) Federation AB: - Triangulated irregular networks - Gauss co-ordinates - Type B ellipsoid - Convention for sea-level (z=0) in Johnson Harbour Contour of A A Intermediary zone B Contour of B - Relations AB_Terrain (#terrain, #triangle) AB_Triangle (#triangle, #point1, #point2, #point3) AB_Point (#point, x, y,z) Terrain Matching Terrain Continuity Geographic Schema Integration User external Elastic Transformations Imported Geographical Exported Excerp of 2 terrain databases which are to be federated and matched Matching 2 terrain databases by transforming squares into triangles and adding some intermediary triangles User Integration of geographic databases Exported Remote Geographical Exported Remote Geographical Exported Remote Geographical

12 12 Schema 1 Schema 2 Schema 3 Users III - Multidatabase Spatial Querying and Indexing Geographic Schema Integration Procedure Integration Rules Correspondence declaration Solving Semantic Conflicts Solving Geometric Conflicts Boundary Matching Topological Continuity Spatial Indexing Schema Fusion Administrator 3.1. Boundary Matching 3.2. Interdatabase querying 3.3. Multidatabase Spatial Indexing 3.4. Using Indexing for Some Spatial Queries 3.5 Conclusions about Multidatabase querying and indexing 3.1 Boundary Discrepancy and Matching Matching the Boundaries Elastic Swaths DATABASE #1 DATABASE #1 Geographic A Geographic B A Elastic zone B DATABASE #2 Correction swath DATABASE #2 Geographic C C

13 13 Correction Swaths Practical Consequences Swaths at the borderline of each database Outer swaths are better Necessity of homologous points Necessity of control points (i) - the points located in zone A have no modification (ii) - the points located in zone B, but outside the elastic swath have no modification (ii) - only points located in zone B and within the elastic swath will be modified (outer swath). Advantages maps look good no content modification no replication updates are possible (even for homologous pairs) distribution transparency delimitation of the outer swath via a visual interface Procedures to be Performed When entering the federation When running a query Limitations automatic finding of homologous points (visual interfaces) impossibility of handling some constraints Scope : Maintaining of updates near the boundary

14 14 Initialization of the Federation Transforming coordinate systems (when necessary) Exported and imported ta Schemata mapping (spatial representations) Determination of the outer swath Homologous points Computation of the elastic function Running of the Federated System (when Querying) Running formulae for coordinate transformation Running formulae for elastic transformation Fit-forcing Points at the Boundary 3.2. Multidatabase Querying City A Zone B Points to be forced Boundary according to City A City B Boundary according to City B Zone A Zone to be elastically transformed when B has a spatial query astride A and B (outer swath for Zone B) Zone to be elastically transformed when A has a spatial query astride B and A (outer swath for Zone A) City A Swath width of the elastic zone Spatial query Zone A Zone B Zone without deformation of coordinates Swath width of the elastic zone City B Zone without deformation of coordinates Zone with elastic transformation of coordinates

15 15 If same query from A and B Semantic and Topological Continuity Results not superimposable Site A Zone A Geometric continuity Maps look good Site B RN 75 Roads RD 34 Building artificially into two parts RN 75 Zone B RD 41 River C Tributary to the River C Fit-forcing 3.3. Multidatabase Spatial Indexing Zone A RN 75 Global spatial index Zone B Building Sense of force-fitting index #1 quadtree style index #2 Grid style index #3 Peano style

16 16 Multidatabase Spatial Indexing Rapidly locate pertinent sites Can be based on - Peano-keys - R-trees - etc. DB - 2 Minimum Bounding Rectangles of s R - trees Structure of Indices DB - 4 DB - 1 DB - 3 (a) Various databases to federate (b) Bounding rectangles for each database Where to put the Global Index? Indices and Global Index Location Parallel with the location of data dictionary Two possibilities: - local index #1 - global spatial index Either a single copy on one privileged site (but violation of Date's rule) - local index #2 - global spatial index - local index #4 - global spatial index - local index #3 - global spatial index Or one copy per site

17 17 Indexing in a client-server architecture Client with external spatial index Client with external spatial index Client with external spatial index Using dictionaries and spatial indices NETWORK Global spatial index London site Server with local spatial index Server with local spatial index Server with local spatial index Spatial and alphanumeric query List of relevant sites (spatial) List of relevant sites (alphanumeric) List of relevant sites Madrid site Oslo site Global data dictionary Berlin site Geographic 1 Geographic 2 Geographic Using Multidatabase Indexing Point Query Point and Region query Buffer zone query Path query Pertinent sites directly located by the global spatial index One single site when zonal fragmentation Several sites when layer or heterogeneous fragmentations Problems when within correction swaths or holes

18 18 Region Query Buffer-zone Query Zone query Definition of buffer-zone Some parts of the buffer-zones are located on another databases Site vicinity matrix for each site Adjacent sites Using spatial index afterwards (a) Example of a zone query against several databases (b) Only three rectangles and so three databases are concerned by the zone query Solving a Path Query Topological Continuity Between s Arrival point Departure point Site 4 ID = RN 75 Site 4 ID = RD 38 Site 5 ID = RD 57 RD 29 RN 75 Relevance ellipse Selected sites for the query Site 1 ID = 678 Site 2 ID = 3216 Site 3 ID = 8906 RN 75

19 19 Interdatabase Continuity Ensuring Continuity Between Sites Semantic continuity Geometric continuity Topological continuity Continuity table between sites Located in each sites, for its own objects Continuity-Table (#object, (#site, #site_object)*) and global identifiers 3.4 Conclusions on Multidatabase Spatial Indexing Location of global spatial indices Necessity of simulation Taking boundary errors into account Taking continuity into account Links with spatial data dictionaries Field-Orientation and federation IV - GIS Interoperability Legacy systems variety of softwares and applications difficulty of re-writing and re-use of existing programs (re-engineering) easy connection between several sites

20 20 Interoperability Cooperation between Softwares Levels of interoperability Introduction Semantic cooperation Interoperability based on ontologies Conclusion about interoperability Applications Access to databases Remote procedure calls Files Network Protocol I N T E R O P E R A B I L I T Y Applications Acces to databases Remote procedure calls Files Network Protocol Introduction Definition of interoperability Vocabulary Fundamentals of interoperability Introduction to semantic interoperability Metadata Technical capacity of software applications for cooperating without conflicts neither of systems, nor of contents, between several organizations.

21 21 Continuum of interoperability Various types of interoperability Stovepipes Applications Client-server Application view Connectivity Transfer of data and management Sharing data on various domains Implementation Continuum Interconnectivity Interoperability Total integration of systems and data Organizational view Interoperability protocols for facilitating the connection between islands of objects differently implemented: syntactic interoperability (high level): CORBA semantic interoperability (more difficult), for which it is necessary to know the domains, and the behaviors of services and objects Semantic cooperation Metadata Metadata Mediators Ontologies Multi-agent Data about data = Data dictionary Metadata are information which allow the description of any kind of data: nature, definition, origin, organization, availability, updating, usage, consistency, etc..

22 22 Custodian Identification Name Name information Keywords Status Mediators Description Geographic coverage Software environment Data quality Accuracy Logical consistency Completeness Source / Lineage Entity/attribute Identification information Type and coverage formats Description Domains Status Measurement Software units Overview of the FGDC Metadata Content Standard Client Mediators Data server Distribution information Distributor Access procedure Format Spatial data reference Map projection Coordinate system Datum Mediator = a data transformer located on the network Examples of mediators Mediator-based interoperability support conversion of supports structure conversion unit conversion attribute encoding name translation object classification semantic clustering (layers) etc. Mediator Data base Data base Mediator Mediator Data base

23 23 Interoperability based on mediators Mediator = software module which solves the tic and semantic conflicts Wrapper = software module which provides the services for data access thanks to a language common to databases and mediators: translates queries, formats the results and transmits them to mediators Integration methodology based on mediators Principle : small modules distributed along the network find data couples which are similar in each database write conversion function (generally, one mediator per attribute) install those mediators at appropriate locations 4.3 Ontologies Example of ontology Formal vocabulary for describing data and situations Ontological commitment Languages : Ontolingua, KIF, some extensions of XML Attributes Node List Lookup_one_of Direct variables Dynamic_node_characteristics_t Link Node_type_t One_of Demand_point Pump Valve List Water_treatment_works Lookup Demand_type_t Water_characteristics_t Primary_source Lookup Primary_source_type_t List Water_characteristics_t

24 24 Electicity Company GIS Mappings Information mapping Shared urban ontology Data set 1 Geo-data sets level Data set 2 Ontology sharing Information mapping Information mapping Information mapping Application ontology Domain ontology Concepts Data set 1 Abstraction rules Data set 1 Corresponds with Refers to Refers to Concepts Domain ontology Concepts Data set 2 Abstraction rules Data set 2 Application ontology Domain ontology Cadaster GIS Water Supply Co. GIS Street Repairs Co. GIS REAL WORLD Ontology-based interoperability Data base ONTO LOGY Integration methodology based on ontology Principle: the ontology must pre-exist. Find mappings between the data base contents and the ontology vocabulary Define the transformations Dynamic resolution of conflicts Data base Data base

25 Conclusions about GIS interoperability Very important for all applications Increasing importance of the ontology approach Sometimes difficulties in writing the mappings between attributes Necessity of defining a complete ontology of geographic features V - General Conclusions "within a few years, isolated GIS will be seen as dinosaurs" Cost of data acquisition Real-time data sharing Standards, SQL etc.. Integration of yet-existing heterogeneous databases Handling measurement errors Inter-institutional agreements Multidatabase spatial indexing GIS interoperability "The GIS's of the future will be federated and interoperable" Thanks for your attention! Information Systems for Urban Planning: A Hypermedia Co-operative Approach