boolean expression; it may contain too a fuzzy 
expression; every time, the condition only concerns 
the carrier, namely the a.d.t. carrying that condition; 
the real world, unhappily, presents conditions more 
complex, simultaneously linking several 
components, and in our approach, several a.d.t. That 
is why, we introduce new elements of vocabulary. 
When a link between classes is created, carrying a 
relationship, for instance: 
CREATE "ARC" "going out of" "VERTEX" 
REVERSE "entering" ; 
we express that an arc MAY go out of a given 
vertex; when creating a link such as "neighbor" : 
CREATE "AREA" "neighbor" "AREA" 
REFLEXIVE ; 
we express that an area MAY have some neighbors. 
If we want that a relationship MUST be verified, we 
express that in a different way; for instance, 
considering a vehicle A which has to follow another 
one, a vehicle B, in an urban network, we may use 
the next statement: 
  
A [ "VEHICLE" ] MUST "follow" 
B [" VEHICLE'] ; 
  
  
  
The constraint may be more complex, sometimes 
requiring a RULE; for instance, when a vehicle has 
to stay on the pavement, it must stay in a parking. 
Many constraints can be expressed by using a rule 
or even , sometimes, a set of rules. 
But, in some cases, another tool is more convenient: 
the CANNOT clause; for instance, if we consider a 
water network and a high-voltage electricity 
network, and we intend that their arcs must not 
intersect, using a rule would be heavy and 
unelegant. To express that, simply concerning two 
arcs A and B, belonging respectively to the both 
networks, we only need the following statement: 
  
A [ "MEDIUM VOLTAGE : ARC" ] 
CANNOT "intersect" 
B [ "WATER : ARC" ] ; 
  
  
In some cases, the relationship is a little more 
complex, and the CANNOT clause is not suficient, 
no more than a RULE. A classical example deals 
with the thermodynamics, where P (Pressure), V 
(Volume) and T (Temperature) are linked by a 
relationship. One only parameter cannot decide of 
the others; with two parameters, the third one is 
completely determined; instead of expressing three 
rules or emitting the formula and calling it every 
time, we only have to apply the concept of 
CONSTRAINT. For instance, if we have a DAMP, 
a TRANSFORMER STATION, some PILES 
44 
supoporting a CABLE, and we want to protect a 
viewpoint in a PANORAMA, we have a complex 
(fuzzy) constraint which is represented on the figure 
14 below (we do not give the statements). 
  
panorama X 
S X s 
1 E 
M et 2 
cable NE i 
rre PP} p 
te Cio 
Diy damp 
x 2D 
transformer 
station 
  
  
  
Fig. 14 : An example using the CONSTRAINT. 
For dealing with constraints, we create a hyperclass 
named CONSTRAINT, which carries, among 
others, an attribute named FORMULA; all classes 
included in this hyperclass inherit of the 
FORMULA, which can be expressed in an 
algorithmical way, the structure being rather simple, 
shown on the figure 15 below. This body may 
contain things such as relationships belonging to the 
preceding cases: MAY, MUST, CANNOT, linking 
the constraint to other components. 
  
  
  
   
  
  
  
rg 
ym MUST 
ephisbanphcen y - CANNOT 
CONSTRAINT / | 
| 
aa [osi] 
Coad D FORMULA 
COC hc Dy 
CD 7» c» 
CD C» c) 
S titu iei d 
Fig. 15 : The hyperclass CONSTRAINT and its 
components. 
But, an object of a class of CONSTRAINT has to be 
connected to components which are various a.d.t.; a 
link cannot join any type. According to a 
transformation based upon the theory of categories 
(Cousin, 1988), any a.d.t. may be associated with 
another different, allowing to build these necessary 
links. In toponymy automated positionning (Titeux, 
1989), as well as in urban network structuring, the 
constraint is the mowt well-suited tool. 
In the 
we wa 
cannot 
netwol 
3-D i