Research Outcomes Aug.Dec. 07

1
Research Outcomes Aug.-Dec. 07

• PhD Thesis Development Methodology for an
  Integrated Legal Cadastre
• GISt-GiGb Lunch meeting
• João Paulo Hespanha
• 2007-12-07

2
Presentation Summary

• Research Aims Questions Literature search
• Extending the Model on the Cadastral Domain
  Portugal country profile and Legal Model
• Spatial UML Profile in EA GeoUML and
  SimpleFeatures
• Refining spatial and aspatial constraints through
  OCL
• Development of a CASE Tool implementing a UML/OCL
  Model into a Spatial DB OO Abstraction Layer
• Building a test data set for the CASE Tool
  (issues of working with real data!)
• Future developments on the CASE Tool and 2008
  research plan

3
Thesis Aim Research Questions

• Thesis Aim
• Propose a Cadastral System Development
  Methodology capable to achieve an effective and
  efficient legal cadastre as a core to support
  other main functions of the Cadastral System,
  namely Valuation (for Tax purposes) and issuing
  of Permits (by the Municipalities).
• Research Questions
• How can a system development methodology achieve
  an integrated legal cadastre, while addressing
  its socio-technical nature, and thus the
  interrelations between the technical, legal and
  organisational aspects?
• How to implement an enriched semantic model
  (through spatial and aspatial constraints and
  spatial profiles) on current SDBMS?
• Furthermore, how can this enriched model support
  integrated update procedures in an Editor
  environment?
• What type of consistency checks should be
  implemented on such model?
• Which methodological steps should be taken to
  cope with new land related rights and regulations?

4
Literature search

• During the study period, facilities at TUDelft
  library, specially the electronically available
  books and journals (through Springer Link and
  Elsevier Science Direct) where researched on the
  following Fields of Study
• IT Development Methodologies Business Process
  Modeling and Model-Driven Architecture
• IT and GIS Standards UML, Object Constraint
  Language, ISO19000 series standards (the last
  ones available through OTB)
• Spatial UML Profiles (initial references supplied
  by the Supervisor)
• Articles and tutorials on the Eclipse Modeling
  Framework
• For further modeling the Legal Domain, a search
  for articles on Cadastral Registration, Real
  Rights and Property Rights returned a small (but
  important) set of documents.
• Later on, after a decision was made to report the
  Thesis outcomes using LaTeX, the JabRef utility
  application was used to start a database of
  research references.

5
The JabRef BibTeX reference DB
6
Cadastral Domain extending the model

• Land Administration Domain Model
• The start point for the research it describes
  the Cadastral Domain using a UML Class Diagram
  containing a series of packages of related
  sub-domains (Register Objects, Survey, Geometry
  and Topology, Persons and Legal and
  Administrative packages)
• Deriving a Country Profile
• First step on the research was to derive Portugal
  country profile from LADM, combining generic
  (LADM) and country specific requirements and
  generating a proposal for a prototype. This first
  version did not elaborate on the Legal and
  Administrative package
• Modeling the Legal and Administrative Domain
• Starting with a generic conceptual proposal from
  related research (J. Paasch, KTH Stockholm), a
  refined legal and administrative model was
  produced, combining the Private and Public Law
  into an overall conceptual framework

7
The Integrated Legal Cadastre Model

• An extended country profile
• The term in the title refers to a model where the
  conceptual framework encompassing Public and
  Private Law related to Land is integrated with
  the remaining Cadastral model packages
• Modeling behavior through UML
• The full power of the UML language is used in
  order to model a number of typical Real Property
  Transactions. This will contribute further to the
  specification of requirements and cadastral
  update functions
• Using Enterprise Architect as modeling and MDA
  tool
• Following slides give an idea on the use of this
  tool in order to obtain the different types of
  diagrams composing the Integrated Model

8
Enterprise Architect Class Model
9
EA Use Case depicting Cadastral Update
10
EA Activity Diagram on Cadastral Update
11
EA Integrated Model Forms of Property
12
TODO Integrating Public Law
13
Spatial UML Profile in EA

• Reasons to apply a Spatial Profile
• The UML Profile is a standard UML mechanism
  provided to extend the standard to new
  application domains. The generic GIS field is an
  example, once implies the use of new, complex
  data types which possess their own behavior and
  associations
• Spatial Data Standards
• To be widely used, a spatial UML Profile should
  rely on international standards, the more
  relevant here being ISO19107 (Spatial Schema) or
  derived implementations as GML Simple Features
• An existent UML Profile Intesa GIS GeoUML
• There were no Spatial UML Profiles available in
  EA the GeoUML profile was first considered
  because consistently derived its spatial features
  from ISO, using UML with OCL, contrary to a
  number of other proposals that were not based on
  standards.

14
The GeoUML Spatial Profile (initial)
This class diagram shows GeoUML spatial types as
specialized types from the ISO spatial schema,
defining override methods and constraints.
15
GeoUML Topological Profile view in EA
After studying proposed types and constraints, a
profile diagram is generated in EA, as a
collection of related metaclasses and
stereotypes. This diagram is then exported as an
EA Profile (a special format XMI). For GeoUML,
only the topological relationships were
translated into a UML Profile.
16
GeoUML Applying the Profile
In order to be applied to another EA Model, the
Profile XMI should be first imported into the
project resources (left) and then be called
through the toolbox, clicking on more tools
(right). For practical reasons concerning the
development of a CASE Tool performing the schema
implementation into a spatial database, this UML
Profile was later discarded in favor of the
Simple Features Access for SQL (see next diagram
for the profile)
17
Simple Features Profile in EA
The SFA-SQL standard (ISO19125) has a fundamental
advantage when compared with GeoUML, that being
its widely adoption and implementation into a
number of databases with spatial extensions,
namely Postgresql or Oracle. The Profile diagram
above shows the geometry types implemented in
PostGIS it was used to define the test data
schema for the CASE Tool.
18
Refining spatial and aspatial constraints with OCL

• Purpose of OCL
• To refine specifications of UML model elements
  through the use of a formal language forming
  regular expressions. These expressions should not
  have side effects, i.e. when evaluated, they
  should not alter the state of an object. It is
  now a component of the UML standard (version 2).
• Use of OCL in the Integrated Model
• /
• Test for Integrated Model defined constraints
  concerning GDBPropertyCadastre,
• legaladministrative and IntegratedModel
  packages.
• Dresden OCL2 Parser file generated manually.
  UML Model produced with Enterprise
• Architect and saved as XMI, can not be used
  for absolute syntax cause is using UML2.
• Refer to package model diagrams for visual
  check of the absolute syntax.
• /
• package GDBPropertyCadastre
• context CornerStone
• inv self.tipo TypeOfCornerStoneTwoEdgesCorner
  Stone implies
• self.parcel_Edge -gt size() 2
• inv self.tipo TypeOfCornerStoneThreeEdgesCorn
  erStone implies
• self.parcel_Edge -gt size() 3
• inv self.tipo TypeOfCornerStoneFourEdgesCorne
  rStone implies
• self.parcel_Edge -gt size() 4
• inv self.tipo TypeOfCornerStoneMultipleEdgesC
  ornerStone implies

19
OCL parsing and validation with Dresden OCL2
application
The picture shows the parsing and validation of
GeoUML spatial type GU_Point2D constraints. Only
the concrete syntax was validated, once it was
not possible to import the UML Model to validate
the absolute syntax. CST stands for Concrete
Syntax Tree and concerns the OCL expression
itself (not considering related UML model
elements, which together form the absolute
syntax).
20
Dresden OCL2 usefulness and drawbacks

• Project structure
• This is an open source project written in Java,
  which fits with the current development
  environment for the CASE Tool. Furthermore,
  besides parsing and validation, also a library to
  generate SQL scripts for checks and queries from
  OCL expressions is supplied (OCL22SQL)
• The basic libraries were also ported to a number
  of UML tools, with different implementations, the
  most interesting (for the CASE Tool) being the
  Eclipse TOPCASED plugin
• Drawbacks
• Current implementations refer to UML 1.5 and MOF
  1.4 Current UML tools produce UML 2 models (not
  compatible) Model and OCL expressions are
  treated in a separate way (different file formats
  to store model elements and OCL expressions)

21
CASE Tool development

• Purpose
• To perform a model-to-text transformation
  (following the MDA approach) where a spatially
  profiled UML model constrained with OCL is
  translated to a set of SQL script expressions
  capable to implement a Spatial Database Schema
• Current EA MDA approach
• Although implementing the majority of MDA
  functionalities, EA lacks significant support for
  OCL, and the transformation language (templates
  based) is also very poor. Using current XSD
  generation, OCL constraints are completely
  ignored in the automated process
• Standards based development
• A number of standards, like XMI, UML, OCL and
  Simple Features, will be taken into consideration
  during design and implementation of the tool, in
  order to provide as generic functionality as
  possible

22
CASE Tool the Open Source path

• The best support
• Opting for Open Source software offers the best
  development support for the CASE Tool, because a
  number of current libraries can be used and its
  functionality extended through a Java programming
  environment.
• Development environment
• The Eclipse IDE will be the main development
  framework to produce the CASE Tool (and further
  applications), the basic pack being complemented
  with the Modeling Framework (EMF) and also other
  relevant plug-ins like UML Tools, OCL and
  Hibernate Tools.
• Full Open Source solution
• A desirable result from the research, justifying
  the migration of the current schema into
  Postgresql (with PostGIS), but currently limited
  by the use of EA. Eclipse UML Tools like TOPCASED
  could supply an alternative solution for the
  Integrated Model, completing thus the full Open
  Source solution.

23
Use of Hibernate Hibernate Spatial

• Usefulness
• Can perform an automated mapping from an Object
  Oriented implementation of the UML Model, called
  the OO Abstraction Layer, to a spatial database
  schema, assuring a proper connection to the
  Postgresql server through one or more sessions
• The mappings are defined through a number of XML
  files, typically representing Java classes
  (simpler solution 11 mappings)
• Reverse engineering capabilities are supported,
  meaning that the OO Abstraction Layer can be
  generated from an existent schema, supporting
  does the MDA paradigm.

24
CASE Tool Activity Diagram
25
CASE Tool Building a test data set

• In order to define a set of (manually) produced
  input / output artifacts for the CASE Tool, a
  number of applications was used, namely
• Enterprise Architect a reduced sub-set of the
  Integrated Model class packages was used in order
  to specify the UML Model input (in the final form
  of a XMI file)
• PostGIS a manually derived implementation schema
  was produced, and all the relevant SQL script
  expressions were saved to a sql file. This should
  form the final CASE Tool output
• OCL expressions and topologic relationships are
  still missing from the data set (TODO)
• The PostGIS test data set was populated with
  cadastral data from the Pilot Project (Ilhavo
  Municipality) this required a previous data
  conversion to an intermediary ArcGIS Geodatabase.
• Following slides show examples of the different
  artifacts in the data set.

26
Test data UML Model in EA
27
Test data XMI file (input to the Tool)
28
Test data SQL scripts (pgsql output)

• CREATE TABLE "Parcel"
• (
• "area_E" double precision,
• "area_NE" double precision,
• "area_S" double precision,
• "dataRec" date,
• perito character varying(70),
• dicofre double precision,
• observ character varying(150),
• "nFolhaPredio" character varying(15),
• "nomePredio" character varying(50),
• CONSTRAINT "nFolhaPredio" PRIMARY KEY
  ("nFolhaPredio") USING INDEX TABLESPACE
  pg_default
• ) WITH OIDS
• TABLESPACE pg_default
• ALTER TABLE "Parcel" OWNER TO postgres
• COMMENT ON COLUMN "Parcel"."area_E" IS 'Parcel
  built up area. Sum of the Building objects areas
  within the Parcel.'
• COMMENT ON COLUMN "Parcel"."area_NE" IS 'Parcel
  area free of buildings.'
• COMMENT ON COLUMN "Parcel"."area_S" IS 'Parcel
  social area. Sum of all the Parcel Social Area
  objects areas within the Parcel.'
• COMMENT ON COLUMN "Parcel"."dataRec" IS 'Date of
  (last) field survey from which Parcel object was
  acquired.'

29
Test data PostGIS schema (PgAdmin)
30
Test data intermediary ArcGIS GDB
31
Test data Java class in Eclipse
32
CASE Tool next steps

• Identify specific mappings to define through
  application code (starting by a detailed Activity
  Diagram)
• Implement the test data set using Hibernate
  Spatial a first, hard-coded implementation will
  be produced
• Design XMI parsing code which generates the OO
  Abstraction Layer.
• Examine OCL constraints mappings to database
  check constraints, triggers and stored procedures
  (also related to queries and views definition)

33
PhD Research study plan 2008