1 / 12

Application Redesign

Application Redesign. Workshop 1: Quality Management for Geodata FIG Commission 3, 5 and 7. FIG General Assembly in Munich, Germany Monday October 9, 2006 10:30-13:00 Room 21a. Reasons for application redesign. Reasons for migration to different GIS software

dragon
Download Presentation

Application Redesign

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. Application Redesign Workshop 1: Quality Management for GeodataFIG Commission 3, 5 and 7 FIG General Assembly in Munich, Germany Monday October 9, 2006 10:30-13:00 Room 21a

  2. 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

  3. Actions • Strength - weakness and opportunities - threats (SWOT) analysis • Redesign • System architecture • Interfaces • Application schema • Functionality • Migration • Transfer of data • Transfer of functionality • User interfaces • Testing • Employees training • Roll-out Quality-Management

  4. SWOT analysis • Emphasis on • Implications on costumers • Economical benefits • Business opportunities • Transition phase • Involvement of user community

  5. 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?

  6. ISO/TC 211 Model driven approach Application schema development Open Geospatial Consortium • GML: Definition of standardized data types in XML Schema Unified Modelling Language standard: rules eXtensible Markup Language Schema

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

  8. utility data 25 14.95 25 5.75 • chances structure? • chances content? Implications to the costumer • What happens if the underlying cadastre data cadastre data • chances geometry? • chances format?

  9. has impact on web feature services (WFS) has impact on web map services (WMS) format is “fixed“ • 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. shape-file, DXF) • Application-specific (e.g. EDBS, WLDGE) • Standard (e.g. GML)

  10. Conclusions • Interoperability on a technical level is solved (more or less) • Interoperability on business logic is an issue • Users have to get involved in the redesign • Migration has to emphasize on • data consistency • functionality • continuity in business processes

  11. 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?

  12. Thank you for listening! What is your experience?

More Related