A framework for geometric constraint satisfaction problem Julien Wintz LSIIT, UMR CNRS-ULP 7005 Universit ´ e Louis Pasteur Strasbourg, France wintz@lsiit.u-strasbg.fr Pascal Schreck LSIIT, UMR CNRS-ULP 7005 Universit ´ e Louis Pasteur Strasbourg, France schreck@lsiit.u-strasbg.fr Pascal Mathis LSIIT, UMR CNRS-ULP 7005 Universit ´ e Louis Pasteur Strasbourg, France mathis@lsiit.u-strasbg.fr ABSTRACT This article presents a metalanguage called GCML which al- lows the description of geometric constraint problems. In the spirit of algebraic specifications, it constitutes a frame- work to accompany a geometric problem from its expression to its solution. Its originality is to provide a problem with its framework called geometric universe, a tuple (syntax, semantic) which allows to get rid of ambiguities and limi- tations concerning description which is then freed from any software restriction. Moreover, distinction between syntax and semantic allows pre and post treatments in order to generate tools while adopting different semantic points of view in the following fields : modeling, visualization, resolu- tion and documentation. Pragmatically, this metalanguage is based upon XML which is a language of terminology de- scription, and allows to embed other terminologies to ex- press different semantics. Categories and Subject Descriptors F.3 [Logics and Meanings of Programs]: Miscellaneous; D.1.2 [Programming Techniques]: Automatic Program- ming; D.2.1 [Software Engineering]: Requirements/Spec- ifications Keywords Algebraic specification, Geometric constraint systems de- scription, Geometric universe, Software engineering 1. INTRODUCTION In Computer Aided Design (CAD), the dimensioning of a sketch is an integral part of a finished machined drawing. So, the intent of a dimensioned sketch is to be a graphical specification of a real object geometry. This specification can also be given in a formal way under the form of a set of dimensional constraints, ie. a set of predicative terms. For instance, the dimensioned drawing given on Figure 1 is a hand-sketched 2D graphical representation of a constraint Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’06 April 23-27, 2006, Dijon, France Copyright 2006 ACM 1-59593-108-2/06/0004 ...$5.00. system containing four distance constraints and an angular one. Figure 1: A dimensioned hand-sketch As for all specification languages, a dimensioning should fulfill a non-ambiguousness property. But, sometimes, a graphical specification can be ambiguous. Let’s consider the sketch on Figure 1. One can wonder whether the dou- ble arrow labeled with k4 represents an horizontal distance constraint or a point to point distance constraint. This is a typical case of double sense. One can also wonder wether a is an oriented angle or not, whether it is an angle between lines or not. This ambiguousness is perhaps less perceptible when the sketch is drawn within a software toolset. In this case, proposed construction methods are explicitly defined such as ”make an oriented angle between two lines in the trigonometric direction”, but the resulting figure does not mention construction informations anymore. Furthermore, it can happen that such a construction creates implicit con- straints that do not appear on the drawing either. As an example, one can wonder whether there is an orthogonality constraint in the previous sketch. Besides, CAD softwares are currently offering several ex- change formats. Each one of them has pros and cons and is specific to one software or to a need. As an example, the Drawing eXchange Format [1] contains informations rela- tive to the way of drawing the dimensioning, whether the distance between two points has to be drawn with a stipple or a plain line etc. In our case, much of this information is useless and, on the contrary, a lot of information related to the constraints are missing. More generally, data exchange between softwares poses the well-known problem of a com- mon format definition understood by each software. Each