Web services for Improving the development of automatic generalisation solutions Nicolas Regnauld Research & Innovarion Ordnance Survey 07 th March 2006, Dagstuhl, Germany

Outline Strategy for research in Generalisation at Ordnance Survey 1:50k generalisation project Objectives Algorithms developed Results obtained Lessons learned during the project Lots of past research to build on Little to reuse Web services Conclusions

Research strategy: the aim Derive automatically our current products and new custom products from our single database. OS database 1:10k 1:25k 1:50k Stage 1: current map series ? ? ? Stage 2: new scales and representation External Database ? Stage 3: integration of external information

Research strategy: the plan We want to build a system that can generate dedicated generalisation applications. Product specs External Database Generic Generalisation System OS Database Dedicated Generalisation Application Product Heart of the system Used for all applications External information used by the system Output of the system Manual, then automatic Automatic

Current project: MADGE50k Objectives Prototype to demonstrate the potential of automatic generalisation for producing 1:50k maps from OS data. What do we want out of this project? An idea of what can be achieved automatically towards the creation of a 1:50k map (Landranger style) from OS base data. A set of generic algorithms that can be reused for other generalisation application A knowledge base about how to use the algorithms developed A set of “processing” specifications, i.e. all the information that the prototype needs to run MADGE50k is only our first step towards a generic generalisation system, so strong emphasis on reusability.

Schedule for the Madge50k project 3 phases of development March 04 – November 2004 Setting up the environment Developing first set of tools Dec 04 – June 2005 Developing further tools Promoting the work (internal and external communications) Jul 05 – Oct 2005 Completion of the development to produce trial map 1 phase of evaluation and reporting Nov – Dec 2005 Evaluate the result Report on the findings of the project

Madge50k: algorithms researched Building generalisation Rural context Urban context Road generalisation Collapse of dual carriageways Displacement Generalisation of the hydrology Generalisation of woodlands Generalisation of contours

Spatial analysis tools: Create Partitions from roads

Spatial analysis tools : triangulation and proximity graphs Triangulation Proximity graph Clusters

Generalisation of buildings in rural context

Building generalisation in urban areas 1.Identify clusters 2.Identify the shadow lines of the clusters on the roads 3.Buffer these shadow lines 4.Extend the buffers to include the remaining buildings

Collapse of dual carriageways 1.Automatic pairing 2.Skeleton (based on triangulation) 3.reconnection

Hydrology 1- Collapse and classify 2- Prune and smooth OS Landranger map (1:50k)

Results Automatic generalisation Manual generalisation

What have we learned Building an automatic generalisation prototype is long and costly Reasons: there is little ready to reuse Lots of valuable research exists, but very few prototypes are available for testing. They proved a concept, and died. => redevelopment required, difficult to know the best approach to follow. Transfer Research -> Commercial GIS not working: Limited set of generalisation tools available Limited control over the tools available often makes them unusable. Spatial analysis tools mostly absent

Why is there so few tools available? Most of the research is done at university or NMA research departments Common characteristics of a research prototype: Proves a concept Suited for the data structure of the data available during the development Relies on the local development environment (very limited portability) Requires the developer to operate it. (limited interface) Short lived. (does not survive the developer changing working environment) Efficiently not really an issue. => Research prototypes not really usable, they prove a concept (that is what they are for) Transfer Research => commercial GIS not happening Profitability issue? (high development cost, limited demand)

What does it cost us? Limited impact on cartographic production lines so far Not many good tools available, on different systems. New research is getting more and more difficult Difficult to build new research reusing what has already been done, because it is not available, needs to be redeveloped.

Possible solutions GIS company redevelop research prototypes Research redevelop their prototype into usable software Examples: Change, PUSH (University of Hanover) Then it becomes a product, Need to buy the software to try it. Carto2001 (IGN France) System developed and used internally, not available outside Research build their prototypes on a set of standards and make them available. Idea of Generalisation Web Services

Generalisation services: benefits & constraints Advantages Large library of tools available Provides interoperability between GIS platforms Constraints Packaging algorithms Efficiency at runtime Extra time required to translate and transfer data both ways Maintain servers MixedMixed Each potential user needs to have a plug-in that will translate data from it’s local data format to the standard format used by generalisation services => The idea is to make the best of the existing prototypes at low cost

Generalisation services: potential users Researchers Can use directly the available services to build new ones Time cost rarely an issue, as long as the transfer and translation times can be evaluated. Map producers Can use directly to build prototype production systems Processing time is an issue, so once the components of the system are identified, negotiations can take place with the authors to build the production system. GIS companies Can use the services to evaluate the algorithms, and choose those they want to implement (negotiations with authors) => benefits for everyone, as the GIS version of algorithm would be more stable and efficient and would also be maintained.

Conclusion Putting together an automatic generalisation system today is extremely long and costly because of the lack of available tools. Generalisation Web Services have the potential to unlock the situation Once in place, it is easy to use (to publish an algorithm or to use some) Research is going on at the moment to prove the concept (GiMoDig, University of Zurich, ITC), so this is the right time to plan a long term solution.

Thanks for your attention, any questions?