1. 1 Jantien Stoter Kadaster Apeldoorn jantien.stoter@kadaster.nl & Technical University of Delft j.e.stoter@tudelft.nl A UTOMATED GENERALISATION OF TOPOGRAPHIC DATA

2. Overview EuroSDR generalisation research project TOP10NL-TOP50NL research project Research questions for follow-up research automated generalisation for processes Kadaster

3. EuroSDR Generalisation project

4. 4 Core project teamTemporal membersTestersVendors Dirk Burghardt (Zurich) Blanca Baella (ICC) Cécile Duchêne (IGNF) Maria Pla (ICC) Nicolas Regnauld (OS GB) Guillaume Touya (IGNF) Connie Blok (ITC) Karl-Heinrich Anders, Jan Haunert (Hanover) Nico Bakker (Kadaster, NL) Francisco Dávila (IGNS) Peter Rosenstand (KMS, DK) Stefan Schmid (Zurich) Harry Uitermark (Kadaster, NL) Magali Valdepérez (IGNS) Patrick Revell (OS GB) Stuart Thom (OS GB) Sheng Zhou (OS GB) Willy Kock (ITC, NL) Annemarie Dortland (Kadaster, NL) Maarten Storm (formerly Kadaster, NL) Patrick Taillandier (IGNF) Axes systems ESRI University of Hanover 1Spatial

5. Objectives To study: – capabilities/limitations of commercial software systems for automated generalisation with respect to NMA requirements – what different generalisation solutions can be generated for one test case and why do they differ?

6. Overview of presentation Requirement analysis Oct 2006 till June 2007 Testing June 2007 till Spring 2008 Evaluation Summer 2008 till Spring 2009 Finalising the project Autumn-Winter 2009 Conlusions Requirement analysis Testing Evaluation Conclusions

7. Requirement analysis 1.Selection of test cases 2.Formalisation of NMA map specifications for automated generalisation 3.Harmonisation of the specifications 4.Analyses of the defined specifications to learn more about similarities and differences between map specifications of NMAs Requirement analysis Testing Evaluation Conclusions

8. Step 1: Selection test cases Area type Source dataset Target dataset Provided by Nr input layers Main layers Urban area1:12501:25kOS GB37 buildings, roads, river, relief Mountainous area1:10k1:50k IGN France 23 village, river, land use Rural area1:10k1:50k Kadaster, NL 29 small town, land use, planar partition Costal area1:25k1:50k ICC Catalonia 74 village, land use (not mosaic), hydrography Requirement analysis Testing Evaluation Conclusions

9. ICC, 1:25kIGN France, 1:10K Kadaster, 1:10kOS GB, 1:1250

10. Step 2:Defining requirements Result: 250 constraints often covering similar situations Example on one object Example on two objects Example on group of objects Condition to be respected Area of buildings > 0.4 map mm 2 building must be parallel to road target building density should be equal to initial density ± 20 % Requirement analysis Testing Evaluation Conclusions

11. Step 3: harmonised requirements 45 generic constraints: 45 generic – 21 generic constraints on one object – 11 constraints on two objects – 13 constraints on group of objects About 300 constraints are defined as specialised specific constraints Requirement analysis Testing Evaluation Conclusions

12. Step 4 Analysing test cases Total number of constraints Number of objects Number of constraints for different constraint types Number of constraints on different feature classes on one object on two objects on group of objects Model generalisation Min. dimension and granularity Position Orientation Shape Topology Distribution / Stat Other Building Land use Road Water Relief Coastal features Any 1378623281280041912553920162581910 5227214111810160151013233003 6132151421524 1229332129203 49241312216100802224181807 299169725816 129483538751106365938181923 Requirement analysis Testing Evaluation Conclusions

13. Tests Were performed: – by project team members on out-of-the-box versions – by vendors (1Spatial, ESRI, University of Hanover, Axes systems), possibly on improved and/or customized versions Requirement analysis Testing Evaluation Conclusions

14. EuroSDR generalisation state-of-the-art project EuroSDR Meeting 14 May 1:50K, derived from 1:25K, ICC1:25K, derived from 1:1250, OSGB 1:50K, derived from 1:10K, IGN, France

15. Evaluation of outputs Tests performed by project team: Tests performed by vendors: Total: 35 test outputs were obtained (appr 700 thematic layers). NB: 1 test cost appr 1 week SystemArcGISCPTAxpandClarity Test case IGN1321 ICC2302 OSGB1301 Kadaster2313 SystemArcGISCPTAxpandClarity Test case IGN0101 ICC0100 OSGB0100 TDK1101 Requirement analysis Testing Evaluation Conclusions

16. Evaluation Evaluation of: – System capabilities (based on completed system templates) – Processing (based on actions templates) – Constraint expression (based on constraint expression templates) Evaluation of generalised data: – Automated constraint-based evaluation – Evaluation which visually compared different outputs for one test case – Qualitative evaluation by cartographic experts Requirement analysis Testing Evaluation Conclusions

17. Evaluation of generalised outputs, three methods Automated constraint-based evaluation Dirk Burghardt, Stefan Schmidt, University of Zurich Evaluation which visually compared different outputs for one test case Cecile Duchene, IGN France Qualitative evaluation by cartographic experts Connie Blok, Jantien Stoter, ITC Requirement analysis Testing Evaluation Conclusions

18. Automated constraint based evaluation of generalised data Requirement analysis Testing Evaluation Conclusions

19. 1 2 1. Town centre blocks and streets representation (selection, aggregation) 2. Coastline simplification 3. Conflicts in road interchanges 3 3 3 4. Generalization of suburban buildings (namely: preservation of buildings spatial distribution, buildings alignments) 4 5. Parallelism between roads and buildings 5 Comparison evaluation Evaluation made on "focus zones" defined for each test case after the test stage => Classical generalisation problems covered => Feedback from testers/producers Requirement analysis Testing Evaluation Conclusions

20. ICC dataset – buildings in suburban areas (a) Initial(f) CPT, TDK tester (novice) (g) CPT, ICC tester (expert) (h) CPT, CPT tester (vendor) (b) Clarity, IGNF tester (expert) (c) Clarity, OSGB tester (expert) (d) ArcGIS, TDK tester (novice) (e) ArcGIS, ICC tester (novice) Requirement analysis Testing Evaluation Conclusions

21. Expert evaluation: methodology Global indicators Level of manual editions required to meet the constraints Deviation from initial (ungeneralised) data Preservation of the geographic characteristics of the test area Legibility Seriousness and frequency of main detected errors Number of positive aspects Information reduction (undergeneralisation / overgeneralisation) Individual constraints assessed in expert survey Constraints on one object Constraints on two objectsConstraints on group of objects minimal dimensionsspatial separation between features (distance) quantity of information (e.g. black/white ration) granularity (amount of detail) relative position (e.g. building should remain at the same side of a road) spatial distribution shape preservationconsistencies between themes (e.g. contour line and river) Requirement analysis Testing Evaluation Conclusions

22. Expert evaluation: example results Good scores for: Requirement analysis Testing Evaluation Conclusions

23. Lower scores for: Future work: – Include interactively generalised – Compare in detail with automated evaluation Compare in detail with automated evaluation Expert evaluation: example results

24. Conclusions capabilities of systems (1/4) Discussed with vendors at IGN, Paris at 22 September 2009 All systems offer potentials for automated generalisation, especially for single objects

25. Conclusions capabilities of systems (2/4) – No generalisation problems are fully solved by the out-of-the-box systems Some are close to being solved: – buildings and roads Some are far from being solved: e.g. – apply different algorithms/parameters in different contexts (either not supported and/or detection measures are missing) – operations that concern more than one object (e.g. network typification) – terrain generalisation –.....

26. Conclusions capabilities of systems (3/4) For other problems solutions do exist (e.g. building simplification), but algorithms are difficult to parameterise – a direct match between parameters and constraints was often missing

27. Conclusions capabilities of systems (4/4) Satisfying complete NMA requirements requires customisation, progress in automated generalisation should focus on: – Good customisation tools – Generic solutions (includes default parameterisation and default tools) – User friendly parameterisation: provide insight into effect Some shortcomings have been solved by research/NMAs (e.g. detection tools), and also by vendors in parallel tests (e.g. displacement in Clarity and ArcGIS)

28. Final thoughts – Disappointing results? High expectations of the project (constraints, selection of complex/known problems, high quality paper maps) Some missing functionalities have been fixed in vendors’ parallel tests Not a surprise that out-of-the box versions are not capable of fulfilling NMAs requirements; customization is definitely required Systems are used more satisfactory in practice Project is well received by vendors to push internal developments

29. Future project – Evaluating generalisation software on criteria beyond constraints – Preservation of topology – Creation of links between initial and output data – Generalisation of incremental updates – Support for parameterisation – Scalability and performance – Customisation!

30. RGI TOP UP: TOP10NL to TOP50NL Research team: ITC: Jantien Stoter ESRI: John van Smaalen, Paul Hardy, Jean Luc Monnot Kadaster: Harrie Uitermark, Nico Bakker

31. Objective Define specifications for automated generalisation by enriching existing specifications for interactive generalistaion

32. Methodology Implement current specifications for roads, landuse and buildings in TOP50 Compare result with current interactively generalised map Enrich specification and data if required Resulting in: improved map generated with automated generalisation only

33. Buildings: current specificationscurrent specifications “If density of buildings in urban areas is sufficiently high, buildings can be replaced by built-up area, with the exception of detached houses and buildings in industrial areas. In rural areas built-up areas are never created. Important buildings are never aggregated to built-up area.” “Remaining buildings should: – never be aggregated – should have a minimum size: (20x20m; in exceptional cases 15x15m; protrusions should at least be 15x15 m) – have minimum distance to other buildings (10m)”

34. Buildings Enrichments: – Information on industrial polygons and on building types (“detached house”) from other sources – Urban areas were computed based on global building densities – Sufficiently dense translated to 10%

35. Area to consider (partioning) Presence of ‘too small’ buildings Locating buildings in limited amount of space Minimum distance between buildings Many detached houses in interactively generalised map are converted into built-up areas (35% in rural areas;65% in urban areas)+ which is not according to specs Buildings: results compared to interactive data

36. Roads: specifications Convert road polygons to lines Select important roads

37. Roads: results (1/2) Not possible to use TOP10NL road lines: – Road surface in TOP10NL; whole road constructions in TOP50NL – TOP10NL road lines are not complete

38. Roads: results (2/2) Important roads, dead ends and through roads are not encoded TOP10NLInteractiveComputed

39. Land Use: trivial problem

40. Final results

41. Conclusions Satisfying results Making current specifications suitable for automated generalisation: Completing and adjusting specifications Data enrichment Formalising specifciations Include formal description how specifications interact (i.e. priority, weighting) Align them with funtionality of systems

42. Research questions for follow-up research Implementing automated generalisation in processes Kadaster

43. Starting point Cartographic multi-scale data set

44. Cartographic databases not optimal as multi scale information source Inaccuracies in cartographic representations ´Error` propagation in cartographic small scale databases No links TOP10NL is more up to date

45. Future multi scale information provision Explicit separation between cartographic and database representations: – To make users aware of the characteristics of the data – Different challenges for generalisation – Meet different information demands

46. Research questions for cartographic representations Apply and complement research results in larger context: – Specific attention for road representation at different scales Starting from current database, study generalisation of updates: – study characteristics of updates – data matching between different scales If data matching not possible: automatically generalise smaller scale data to obtain links (and better coherence)

47. Research questions for database representation Use of multi scale info: – Visualisation requirements – Requirements wrt level of details (different as traditional map scales?) Multi ´lod´ information model supporting multi representations of objects Generalisation of multi level of detail information: more dynamic, less demanding?: – vario scale data structure: Including issues for client-server, symbolisation, multi scale

48. Future topographic information provision 1.Only cartographic representations at different scales, TOP10NL for GIS analyses – Advantages: Less demanding for small scale databases (BRT): only visualisation Keep current situation – Disadvantages: No links between scales Not meeting multi scale information demand May be hard for implementing automated generalisation 2.Generate multi scale database representations and keep current cartographic databases at different scales – Advantage: Meet multi scale information demand – Disadvantage: No links between database rep and carto rep 3.Integrated provision of multi scale information and carto rep – Advantage: Optimal starting point for information approach BRT instead of carto, resulting in integrated provision of all small scale topo products Ideal for automated update propagation, consistency and vario scale datastructure – Disadvantage: Ignore much past efforts Will users accept (slightly) different products?

49. Thank you