Proceedings of the 21st International Cartographic Conference (ICC) Durban, South Africa, 10 � 16 August 2003�Cartographic Renaissance� Hosted by The International Cartographic Association (ICA)ISBN: 0-958-46093-0 Produced by: Document Transformation Technologies

THE IMPLEMENTATION OF NEW TECHNOLOGYTO AUTOMATE MAP GENERALISATION AND

INCREMENTAL UPDATING PROCESSES

Jahard, Y., Lemarié, C. and Lecordix, F.

Institut Géographique National, Carto2001 project, 2-4 av. Pasteur,94165 Saint-Mandé CEDEX, France. Tel: (33) 1 43 98 85 45 / Fax: 81 71.

E-mail: yolene.jahard@ign.fr , cecile.lemarie@ign.fr and francois.lecordix@ign.fr

ABSTRACT

In 1999, the French National Mapping Agency (IGN) decided to launch a new 1:100 000 scale map series calledTop100: these maps will be derived from the reference database BDCarto® covering the whole French territory with a10-meter resolution. The Carto2001 project was entrusted with designing the process leading to the realisation andmaintenance of the future IGN 1:100 000 topographic map series using the IGN BDCarto® database as unique datasource. The main challenges identified were automated generalisation, text placement and updating process. The majoreconomical stake concerned the incremental updating process, to be automated from the source database evolutions inorder to reduce costs. The project's needs to perform its mission were luckily being met by research advances. TheEuropean, IGN led, AGENT project and its commercial partner Laser-Scan placed the latest generalisation technologyat our disposal while the IGN COGIT laboratory was also providing the main foundation stones regarding textplacement and updating methods. Our problematics then became the actual industrialization of these powerful tools andin particular, the transition from a research context to a production constrained one. In this paper, we will describe theimplemented generalisation process as well as the updating operations performed on data, illustrating our arguments byconcrete examples and trying to mention any trap or dead ends we encountered and how we got round the difficulty.Eventually, a panel of effective results will be displayed and time as well as cost savings will be assessed.

Keywords: 1:100 000 scale maps, generalisation, updating map from database, multi-agent system, elastic beams.

1. INTRODUCTION

Defining a digital production line for the 1:100.000 scale map series (called Top100) by deriving the maps from theBDCarto® database is not a bright new idea in IGN. A previous project had started in 1994 on the same bases but in aquite different technological context. The production cost was eventually too expensive to launch the new productionline for the Top100. The generalisation process had been estimated to 1000 hours of operator work per map, while thewhole process was during 16 months (2500 hours). This cost is explainable by a mostly interactive process, devoid ofefficient generalisation algorithms and working with a somewhat poor GIS that did not allow the development ofsophisticated interactive tools and conflict detection functionalities. Taking advantage of the previous project'sconclusions and being in a context of research maturity, the Carto2001 project could be launched in 1999.

2. CONTEXT AND OBJECTIVES

2.1 The project objectives and constraintsThe Carto2001 project general goal is to design a controlled automation of the production of the Top100 map series:! make the best use of research results in order to ensure that the initial map can be drawn in less than 8 months.! design a process that will allow to spend less than 3000� to update a map.

The initial constraints were the use of the LAMPS2 GIS designed by Laser-Scan, the use of the BDCarto® as the initialand updating data source and the respect of the previously set cartographic specifications Rapidly, three maindevelopment axes were identified and launched simultaneously:! AGENT project exploitation! Automatic updating implementation! Automatic text placement

In addition to the project's actual goals, some technical challenges appeared from the beginning of the project in order toreduce generalisation and updating costs. The most ambitious objective was to design a cartographic Top100 Databasewhich would cover the whole French territory.

Once again, this constraint was pointed out by the previous project's conclusions: the average overlapping rate betweenTop100 maps reaching 40%, the benefit of a unique cartographic database covering the whole territory is significant.

2.2 Automatic text placementConcerning text placement, IGN's experience had reached a step further than in the generalisation or updating area andsome map production line already called for the home-made software modules developed by the COGIT Laboratory[1,2].

However, the project mission in this area is very important for IGN and consists in giving access to text placement to allpotential users within IGN, which was not at all the case before because the code was stored and kept alive at theCOGIT research laboratory

Practically, the ADA VMS code had to be shifted to a PC version, and the initial placement module (working onhorizontal texts and road numbers) had to be extended to new placement types like hydrographical names Eventually, toprovide a complete and stand-alone software called WINPAT, some functionalities have been added so that the user cannow fully adjust the placement parameters and visualise the obtained results.

Figure 1. Automatic text placement: altitudes, river names, pictograms, horizontal names, road numbers.

2.3 Research set-up in generalisation and updatingThe advent of the Carto2001 project is coinciding with research accession to maturity in both generalisation andautomated updating. As a matter of fact, the European, IGN led, AGENT project was planned to end by the end of year2000. One of the expected results was a prototype for automatic generalisation developed on the LAMPS2 GIS andusing a multi-agent based approach. This prototype was going to become the foundation for the Carto2001generalisation process.

2.3.1 AGENT European ProjectAfter 6 years of research in cartographic generalisation, IGN engaged the 3-year AGENT European project. It finishedin December 2000 and had gathered five partners: the COGIT laboratory of IGN, LaserScan Limited (editor of theLAMPS2 GIS), the Leibniz laboratory of INPG (specialised in multi-agent techniques), and the GeographyDepartments of Zurich and Edinburgh Universities (specialised in generalisation).

The purpose of the project was to design a prototype for cartographic generalisation using multi-agent concepts and itsimplementation in a commercial GIS software [3,4]. Moreover, the prototype had to integrate generalisation algorithmsdeveloped in three research laboratories (COGIT, Zurich and Edinburgh).

Principles involved in the AGENT project are mainly based on the PhD research works of Anne Ruas [5]. Automaticgeneralisation consists in working with cartographic objects which have to solve numerous conflicts (with themselvesbut also with other objects) in order to produce legible maps. The AGENT's method aims at giving them autonomy tosolve such conflicts by themselves. These objects are called agents and they each and together have sets of goals toachieve. They are able to analyse their own state (some measures are available), to trigger algorithms and to assess

whether conflicts are solved. The state of each object is defined by a set of constraints to satisfy, which represents atranslation of the cartographic rules to be taken into account in the cartographic derivation process.Results of the AGENT project seem at first sight to be very powerful for the automation of the Top100 derivationprocess. That is mainly why LAMPS2 has been naturally chosen as GIS platform for the Carto2001 project. Thesoftware also provides other very interesting characteristics for the development of the updating prototype: versioningcapacities, handling of large data volume, reflex methods on objects, multi user controlled access to the data.

2.3.2 Updating researchIn 1996, IGN via the COGIT laboratory decided to engage research on the propagation of updates in multi-scalegeographic databases. Results of this research are detailed in the PhD research work of Thierry Badard [6]. The majorinnovations are:! The implementation of a generic method for the retrieval of updates between two versions of a same geographic

database. This method relies on geographic data matching algorithms and allows the extraction of a minimal butdetailed updating information, expressive of the modifications performed in the GIS.

! In order to deliver this updating information to users, new delivery modes for updates have been defined. One ofthese modes relies on the XML (eXtensible Markup Language) encoding of the updating information [7]. It allowsa minimal and dynamic description of updates and enables communication for instance on the Internet.

! A mechanism for the integration of updates and the propagation of their effects in multi-scale geographic databases(which includes systems with user added information) has also be defined and tested. It relies on a set of ruleswhich enables to automate and control the propagation of updates in order to preserve the consistency of databasesand avoid information losses. The different tests conducted showed that about 85% of the updates can beautomatically propagated by this mechanism.

The Carto2001 project will be at IGN, the first product which will take advantage of these innovations: the structure ofthe updating process and evolution data involved in the project are inspired by these research works.

3. MAIN STEPS: FROM THE GEOGRAPHICAL DATABASE TO THE MAP

3.1 Source databaseThe BDCarto® database is a 10-meter precision geographical database, covering the whole french territory. Informatinis stored in the database as different themes that are composed of different classes of objects linked together by specificrelationships. The main layers among the 13 composing the database are road network, railway network, land cover,hydrography, administrative and tourist information. The altimetric information are partly stored in a distinct databasecalled BDALTI® (contour lines, shading�).

Some topological relationships are implemented in the BDCarto® (roundabouts are stored as points connected to theroads, railway stations are connected to the railroads etc.).

Some buildings are present in the database but only administrative establishments or structures having a tourist interest,and they are implemented as point objects, without any contours. So, the actual generalisation of buildings(simplification, aggregation�) did not have to be developed for the Top100 purpose.

3.2 Generalisation dataTop100 maps belong to the topographic range of the IGN map series, their use is dedicated to cycling rides and"promenade". Even if some tourist information is given, the communication network and in particular the road network,is one of the main themes depicted on the map: it has to be exhaustive and fully legible. That's why the Carto2001project decided that the Top100 generalisation would start with generalisation of roads. Pursuing the same approach, wedecided to propagate road geometry modifications to other themes that could be affected and would need to follow orreact to the induced displacement.

The coherence with hydrographic network, administrative boundaries and referenced footpaths will be maintained, aswell as relative positions to point objects (a church is to remain on the same side of the road after generalisation).

Contour lines and land cover will not participate at all to the generalisation process. The main reason is that these 2themes don't need any intrinsic generalisation at the 1:100000 scale. In the other hand, contour lines are to be perfectlycoherent with shading and lakes, so the propagation of road generalisation on contour lines would generate too manyside effects and the appropriate algorithms are not available.

3.3 Cartographic derivation overview

Data import

Automatic generalisation process

Interactive solving of cartographic conflicts

Interactive solving of placement defaults

Automatic texts placement

LAMPS2

(LASER-SCAN)

WINPAT

(IGN)

MERCATOR

(ESKO GRAPHICS)

Data consistency preliminary treatments

Interactive solving of remining problems

Software Treatment BDCarto DB

Top100 DB

Map Editing process

Data structuration

Top100 Map

LAMPS2

Figure 2. First derivation outline.

3.4 Preliminary treatmentsWhen giving a closer look to the source BDCarto® database, we noticed that the different themes were not coherent theones with the others (speaking in terms of topology). For instance, administrative boundaries naturally follow someparts of roads or rivers and this sharing of geometry is not effective in the BDCarto®. That's why the Carto2001 projecthad to implement preliminary enrichment, in order to prepare the data, to make sure that data can be matched whereverthey should and to integrate every link between objects that the generalisation process requires to ensure propagation.

Here are the actual preliminary treatments that are performed on the original database before road generalisation:! administrative boundaries are matched to roads and rivers! footpaths are matched to roads where they run alongside them! point objects are linked to the roads by a virtual segment (so that they can stay on the right side of the road)

Notice that these treatments are mostly automatic ones and in some few cases, well identified and recorded, the operatorhas to step in manually and solve the problem using interactive tools.

Once data consistency problems are solved, generalisation takes place. The project decided to first clear up internalcoalescence problems (a road and its bends), before solving neighbouring problems (two roads overlapping eachothers).

3.5 First automatic generalisation process: bend generalisation3.5.1 Agent techniqueObjective: solve coalescence conflict induced by symbol width and narrow bends.

The multi-agent approach proposed to solve generalisation conflicts thanks to specific measures and algorithmsinvolved in a self evaluation process of the objects. These principles have been implemented in the LAMPS2 software(Laserscan Limited) and constitute the bases of the generalisation prototype involved in the Carto2001 project.

The derivation of BDCarto® data into map objects a the 1:100.000 scale requires:! to remove tiny details which could be detected by the eye as noise (simplification)! to stretch some bends to make them legible (exaggeration)! to remove some bends in bend series (typification)

In the AGENT prototype, each road is considered as an agent. If the coalescence constraint is not satisfied then the roadwill be cut into several parts, each one of a homogeneous coalescence value, considered in its turn as an agent on whichspecific algorithms will be tested: the algorithm which gives the best result is chosen. So, at the end, the resulting roadis the best which can be found with the available measures and algorithms.

AGENT is thus used for bend generalisation on each road object separately.

Such a use of AGENT takes advantage of the capability that AGENT has to find the best solution to solve internalconflicts, and ignores the problem of time processing due to launching AGENT on numerous sets of objects. The levelof generalisation we are willing to reach for Top100 doesn�t suffer from such a choice but for higher degrees ofgeneralisation, where independent generalisation could create more conflicts with surrounding objects, such a choicecould be discussed.

3.5.2 ResultsAgent process is performed on a whole map in 13 hours on a Pentium III and less than 1% of objects are still presentingcoalescence conflict afterwards.

Figure 3. BDCarto® data. Figure 4. Result of the AGENT process.

3.6 Second automatic generalisation process: network displacement3.6.1 Elastic BeamsObjective: solve overlapping between linear symbols and acute intersections.

The first tests on AGENT showed the agent technique was not usable for this purpose since the cartographic result wasnot always good and too few overlapping conflicts were solved. Moreover, processing time was not acceptable, even ona few objects (each time an object is displaced, others re-evaluate themselves to check whether displacement isacceptable).

At the same time, Matthias Bader [8], from the University of Zurich, was working on �elastic beams� - another type ofdisplacement algorithm, using an optimisation approach different from the sequential techniques used in AGENT.

Beams consists in defining internal and external forces on each vertex of the linear object, and in finding the minimumof energy for this system. Objects will conform to this force more or less easily, depending on their ability to be

distorted, compressed or extended. This technique which seemed to bring a noticeable improvement for roaddisplacement was finally developed by LaserScan and the �moveability� of objects was setup by the Carto2001 project.Very satisfying results came out, even in very crowded areas and in very specific configurations such as interchanges.The advantage of beams is that they try to find the best compromise between all the repulsion forces, thus solving a biteach conflict, which in most cases is cartographically acceptable.

Figure 5. Beams forces. Figure 6. Beams result.

3.6.2 Flexibility graphs to divide in subset of dataOnce the cartographic quality of beams had been recognized to solve overlapping conflicts, the next problem was anoperational one: beams cannot process thousands of objects at the same time due to the fact that beams are based onmatrix inversions involving all vertices of selected road objects.

To process all map objects together could not be as easy as appeared at first sight. Two solutions were tested:! The first one was to simply partition data from the network of main roads. In this solution however conflicts on the

main roads are not processed in the same way in both parts. The effect would then be that the partition limits mightbe visible on the map because of breaks instead of nice continuous displacement.

! The second solution was to detect all the conflicts, and for each one to define, in function of the road sinuositycharacteristics the set of roads which could be displaced to solve the conflicts. This set of roads is called theflexibility graph. It represents the extent of the conflict in terms of displacements to solve it. Then, these graphs areaggregated and beams are launched on each resulting graph. Conflicts are detected with the available AGENTmeasures. This is the solution we chose

The flexibility of a road is a measure which qualifies the sinuosity of the road, the more bends the road has, the moreflexible it is. Concerning displacements, the more flexible a road will be, the faster the displacement will be cushioned.Cartographic results are very satisfying even in town centres where roads are very short and straight, and even oninterchanges where slip roads are often completely hidden underneath the motorway (see Figure 7).

BDCarto® data Result of the BEAMS process

Figure 7. Elastic beams results.

3.6.3 ResultsThe automatic processing time on a Pentium III is 30 hours by map, and interactive corrections will have to be madeonly in dense areas and along motorways.

Note that this technique is also used for rivers that are shifted away from roads when their axes lie underneath the roadsymbol: actually, this treatment is launched before any road generalisation is performed on roads (but it is still morerelated to generalisation than to preliminary data matching).

3.7 Data consistency maintenance3.7.1 Diffusion and frozen objectsTo preserve the �geometry sharing� between objects, the project asked LaserScan to develop a �diffusion� functionwhich makes it possible to diffuse road displacements on connected objects but also on objects which share the samegeometry. This function has been interfaced with the AGENT and beams tools.

To contain generalisation effects, we asked Laser-Scan to introduce the possibility to freeze some objects, which nowensures that roads will not be displaced in lakes and will not cross the coastline.

3.7.2 Isolated pointsWe have also used the diffusion tool to maintain consistency between the road network and isolated points by adding afictive line object which links an isolated object to the road network. It is a quite simple method but the results areacceptable and generally avoid relative position between the road and the point to become reverted.

4. BRINGING THE MAP UP TO DATE

4.1 Updating rulesThe updating process [9] has been developed in LAMPS2 can be decomposed in two main parts:! a generic updating engine, able to deal with any type of data which implements a set of functions called in a

predetermined order.! an updating rule base which allow for the definition of behaviours to adopt when a particular operation is

performed on a specific object. This module is depending on the user application and related to cartography.Table 1 is an simplified example, giving a set of rules concerning road network objects.

Table 1. Updating rules for roads.

Object modified(ROAD NETWORK)

modification type Treatment

ANY TYPE OFOBJECT

Creation Calculate object symbol

POINT OBJECT Semantic modification Calculate symbol if TYPE attribute has changedCalculate orientation if it represents a landing stageor an access barrier

Creation Calculate orientation if it represents a landing stageor an access barrier.

LINEAR OBJECT Semantic modification Calculate symbol if any of the involved attributeshas changed (number of lanes, type of road �)Calculate the symbol of any connected slip road.

Geometric modification Calculate orientation of connected nodes if theyrepresent a landing stage or an access barrier.Check topology of point objects relying on the road(like facilities).

Creation Calculate orientation of connected nodes if theyrepresent a landing stage or an access barrier.

4.2 Updating main steps4.2.1 Filtering stepThe cartographic database is a distorted image of the reference database, and some modifications performed in thereference database are not always significant for the map. In this step, BDCarto® evolutions are analysed: updateswhich are not �cartographically� significant are ignored and the other ones are imported in the database (in particularclasses). Criteria involved in this filtering step are for example: minor modification of the geometry (i.e. less than athreshold), updating of insignificant attributes. At this step of the updating process, about 30 to 50% of the geometricalupdates can be filtered out.

4.2.2 Automatic updatingThis step constitutes the kernel of the process and consists of the integration of updates and the propagation of theireffects in the cartographic database. Updates are processed in a defined order to avoid incoherent states: for example,deletions are integrated before any other updates. For each update, geographic objects involved in the modification andmethods for maintaining (at each step) the consistency of the database are identified. Updating rules are thenautomatically called by LAMPS2 to define the effects of the update on the cartographic aspect of the object (symbolchange, symbol orientation) and on the other surrounding objects (road number, bridges, kilometres�). Propagation ofupdates on surrounding objects can not always be defined during the updating of an object since the contextsurrounding the object is not up-to-date, so for specific treatments (road numbering for example where the number isplaced considering a set of road sections) the effects of updates are not calculated during the integration step but at theend of the process (when data directly corresponding to the reference database are up-to-date).

The two main characteristics of the process are:! The consistency of the cartographic database is always maintained. It is important to mention that the BDCarto®

stores graph relationships which indicate the connections of road sections and that the evolution data also deliverthe modifications concerning these relationships. They can thus be used to maintain the connectivity of thenetwork. These evolutions are used to ensure that an updated object is correctly connected to an existing part of thenetwork. An evolution can thus be integrated in the cartographic database only if one of the objects connected tothe updated object is already in the cartographic database and up-to-date. This constraint is the easiest way toalways preserve a correct network topology.

! The previous generalisation process is used for integration of updates. To avoid local distortion and topologicalerrors, it is necessary to take into account the displacement operated from BDCarto® to Top100 and to reproduce iton the updated object.

4.2.3 Conflicts solvingAll the propagation effects can not be fully defined by the means of the updating rule base, so these effects can not beautomatically processed. Any object that need to be visited later by an operator either for a simple check or to performthe actual updating effect will be automatically "marked" and a description of the problem will be attached to the object.The strong point in this interactive step is that all the updating rules are still automatically triggered by the LAMPS2engine (reflex methods are dynamically invoked). It is important to mention that there is no difference betweencartographic processing of objects which are updated by the automatic process and objects which are updated by theoperator.

4.2.4 Consistency checkingThis step checks that the updates have been correctly integrated and propagated: all the evolutions have been taken intoaccount, topology is in accordance with BDCarto®, etc. The versioning mechanism of LAMPS2 is used to check thatno unfortunate updates have been performed (deletion of an object which has not been removed in the BDCarto®,modification of the object identifier) in order to enable future updating.

4.3 Generalisation and updatingAt this stage, the project is validating the generalisation process on a sample map with the help of an operator who is incharge of the interactive corrections. The next step is the validation of the updating process that is going to beperformed on the generalised data by integrating evolution data. The updating process is not quite complete at this datebecause we did not yet plug the generalisation part of it.

So far, it has been decided to store the generalised object geometry as well as the original one in the cartographicdatabase so that when an object is updated, it can be displaced in the same way as its neighbours were during thegeneralisation process. Which means that the updating engine is designed to work with an environment of generaliseddata. Still to come, now that automatic bend generalisation and overlapping conflicts solving are satisfying, we need togeneralise the objects newly created during the updating process when they need such a treatment.

Thanks to the conflict detection tools, objects to be generalised will easily be retrieved and then, either Agent will belaunched on the object itself if coalescence is to blame, or elastic Beams will be performed on the object flexibilitygraph if overlapping is the reason of the conflict.

Nevertheless, consistency maintenance when updating is quite a sharp problem to solve (is the new road portionsupposed to share geometry with any administrative boundary?) and the project is now working on it.

4.4 ResultsAutomatic updating process is performed on a whole map in 2 hours on a Pentium III and the interactive part isestimated to 2 days.

Figure 8. Before updating. Figure 9. Updating result(without generalisation on new objects)

5. CONCLUSION

The Carto2001 project is now approaching the last straight line. Technical results are more than satisfying. Significantsteps have been made. Many problems occurred because of the large number of constraints that industrialisationinvolves and because of the difficulty we encountered to appropriate the research results and make them suitable for ourdata. But at this stage, all these problems have been jumped over, and despite some sporadic interactive break-in that wedid not manage to avoid, the controlled automatisation of the Top100 maps production is going to come up by the endof the year and will be use to produce and update the 76 sheets of the IGN Top100 map Series.

The automatic phase of the Carto2001 generalisation process has been estimated to about 50 hours on a Pentium IIIcomputer. The interactive part should be of about 100 hours and limited to specific areas (interchanges and urbanareas). Thus, the total increase in productivity would reach a factor 10 compared with previous project's estimations.

The first test has demonstrated that automatic updating should reduce delays and costs considerably. We expect todecrease them to a drastic 10% of current updating delays and costs.

Other products in IGN should soon take advantage of the knowledge and experience of the Carto2001 project. Thedepartmental map (1:125.000 and 1:140.000 scale) derived from the BDCarto® are already using some of thegeneralisation and updating tools. A new project concerning the production of 1:50.000 maps derived from theBDTopo® (1-meter precision IGN geographical database) could also reuse some specific tools and adapt thegeneralisation process to building objects.

6. REFERENCES

[1] F. Lecordix, C. Plazanet, F. Chirié, J.P. Lagrange, T. Banel, Y. Cras, " Placement automatique des écrituresd'une carte avec une qualité cartographique", EGIS/MARI 1994, volume 1, p22, (1994).

[2] M. Barrault, "Le placement cartographique des écritures: résolution d'un problème à forte combinatoire etprésentant un grand nombre de contraintes variées" Mémoire de thèse de doctorat en Sciences de l�InformationGéographique de l'Université de Marne La Vallée, Marne-la-Vallée, France (1998).

[3] S. Lamy, A. Ruas, A., Y. Demazeau, M Jackson, W. Mackaness, R Weibel, "The Application of Agents inAutomated Map Generalisation", Proceedings of the 19th International Cartographic Conference (ICA'99),ICA/ACI (Eds.), Ottawa, Canada, pp. 1225(1999).

[4] M. Barrault, N. Regnauld, C. Duchêne, K. Haire, C. Baeijs, Y. Demazeau, P. Hardy, W. Mackaness, A. Ruas, R.Weibel, "Integrating Multi-agent, Object-oriented, And Algorithmic Techniques For Improved Automated MapGeneralisation", Proc. of the 20th International Cartographic Conference, vol.3, Beijing, China, p.2110 (2001).

[5] Ruas, "Modèle de généralisation de données géographiques à base de contraintes et d'autonomie", Mémoire dethèse de doctorat en Sciences de l�Information Géographique de l'Université de Marne La Vallée, Marne-la-Vallée, France (1999).

[6] T. Badard, "Propagation des mises à jour dans les bases de données géographiques multi-représentations paranalyse des changements géographiques", Mémoire de thèse de doctorat en Sciences de l�InformationGéographique de l�Université de Marne-la-Vallée, Marne-la-Vallée, France (2000).

[7] T. Badard, D. Richard, "Using XML for the Exhange of updating information between geographical informationsystems", Computers, Environment and Urban Systems (CEUS), vol. 25, Elsevier Science Ltd., Oxford, pp. 17(2001).

[8] M. Bader, "Energy Minimization Methods for Featur Displacement in Map Generalisation", PhD Thesis,University of Zurich (2001).

[9] C. Lemarié, Th. Badard, "Cartographic Database Updating" Proceedings of the 20th International CartographicConference (ICC 2001), ICA/ACI (Eds.) Beijing, China, vol2. pp.1376-1385 (2001).

THE IMPLEMENTATION OF NEW TECHNOLOGYTO AUTOMATE MAP GENERALISATION AND

INCREMENTAL UPDATING PROCESSES

Jahard, Y., Lemarié, C. and Lecordix, F.

Institut Géographique National, Carto2001 project, 2-4 av. Pasteur,94165 Saint-Mandé CEDEX, France. Tel: (33) 1 43 98 85 45 / Fax: 81 71.

E-mail: yolene.jahard@ign.fr , cecile.lemarie@ign.fr and francois.lecordix@ign.fr

Biography

Yolène Jahard is a Survey Engineer from the French National Mapping Agency (IGN). She has been primarily workingin 1994 on a national geographical database updating project, then she joined the map production department anddeveloped a semi-automatic process to derive and update the 1:1000000 scale map from a database road network.Eventually, she participates to the Carto2001 project as an analyst and focused on automatic generalisation techniquessince 1999.