Transcript Workshop 1: Quality Management for Geodata FIG Commission 3, 5 and 7 Application Redesign FIG General Assembly in Munich, Germany Monday October 9, 2006

Workshop 1: Quality Management for Geodata
FIG Commission 3, 5 and 7
Application Redesign
FIG General Assembly in Munich, Germany
Monday October 9, 2006 10:30-13:00 Room 21a
Dr. Gerhard Joos
dotGIS – Beratender Ingenieur für Geoinformation
[email protected]
http://www.dotGIS.de
Reasons for application redesign
• Reasons for migration to different GIS software
• GIS base software is no longer supported by vendor
• Developments of system enhancements are getting
more and more expensive due to old base technology
• Change of hardware and/or operating system required
 GIS software does not run on new system
• New system architecture required (e.g. web-based)
• Reasons for migration to a different application
schema
• Application schema does not support all requirements
• If different GIS software has to be chosen, it may
require a different data model
• Some business processes are not supported by the old
application schema
Gerhard Joos
Actions
•
•
•
•
• System architecture
• Interfaces
• Application schema
• Functionality
Migration
• Transfer of data
• Transfer of functionality
• User interfaces
Testing
Employees training
Roll-out
Quality-Management
• Strength - weakness and opportunities - threats (SWOT) analysis
• Redesign
Gerhard Joos
SWOT analysis
• Emphasis on
•
•
•
•
•
Implications on costumers
Economical benefits
Business opportunities
Transition phase
Involvement of user community
Gerhard Joos
Data migration
• Especially migration process has to be
accompanied by QM
• Experience shows: data quality usually improves
when adapting to a new application schema
• Data errors show up:
• Not closed polygons
• Selfintersecting lineStrings
• FeaturePropertyValues that are in the wrong domain
• Is this our experience as well?
Gerhard Joos
Application schema development
ISO/TC 211
Open Geospatial Consortium
• GML: Definition of standardized data
Model driven approach
Unified
Modelling
Language
types in XML Schema
eXtensible Markup
Language Schema
Gerhard Joos
Example for land management cadaster
• ALKIS-predecessor ALK was outdated
• Graphical oriented
• No object structure
• E.g. parcel consisted of an object parcel-Nr and boundary
lines – the area feature was not explicitly modelled
• Complex analyses on parcels were not possible (although
the system was all about management of parcels)
• Many users relied on the ALK data for their business
processes
• Especially utility companies
Gerhard Joos
Implications to the costumer
25
utility data
5.75
25
cadastre data
• What happens if the underlying cadastre data
• chances structure?
• chances content?
• chances geometry?
• chances format?
Gerhard Joos
• Structure
• Change or redesign of application schema
• Content
• Updates to the database due to changes of
the real world or due to error correction
• Geometry
• Change to CRS / datum, new survey with
more accurate data, combination of old
survey data with GPS data
• Format
• Raster (e.g. GeoTIFF)
• System-specific (e.g. e00, oracle-dump)
• Proprietary or de-facto standards (e.g.
has
impact
on web
map
services
(WMS)
has
impact
on web
feature
services
(WFS)
format is “fixed“
shape-file, DXF)
• Application-specific (e.g. EDBS, WLDGE)
• Standard (e.g. GML)
Gerhard Joos
Conclusions
• Interoperability on a technical level is solved
(more or less)
• Interoperability on business logic is an issue
Migration has to emphasize on
• data consistency
• functionality
• continuity in business processes
• Users have to get involved in the redesign
Gerhard Joos
Questions for discussion
• Which business processes are involved?
• How do costumers benefit from a redesign?
• How can costumers get involved in the
redesign process at an early stage?
• How do standards support a redesign?
• Do web-services make a difference?
Gerhard Joos
Thank you for listening!
Gerhard Joos