exploring plant topological structure with the amapmod software

Silva Fennica 31(3) review articles

Exploring Plant Topological Structurewith the AMAPmod Software:an Outline

Christophe Godin, Evelyne Costes and Yves Caraglio

Godin, C, Costes, E. & Caraglio, Y. 1997. Exploring plant topological structure with theAMAPmod software: an outline. Silva Fennica 31(3): 357-368.

In the last decades, architectural analysis has been used to understand and to model plantdevelopment. These studies have lead us to reconsider the problem of measuring plantswhile taking into account their topological structure at several scales of detail. Acomputational platform, called AMAPmod, was created to work on such plant represen-tations. This paper outlines the general methodology used in AMAPmod to representplant topological structures and to explore these special types of databases. Plantstructures are first encoded in order to build corresponding formal representations. Then,a dedicated language, AML, enables the user to extract various types of informationfrom the plant databases and provides appropriate analyzing tools.

Keywords plant, architecture, development, coding, analysis, virtualAuthors' addresses Godin & Caraglio: CIRAD, Laboratoire de Modelisation des Plantes,BP5035,34032, Montpellier, France. Costes: INRA, Laboratoire d'Arboriculture Fruitiere,2 Place Viala, 34060, Montpellier, FranceReceived 24 January 1997 Accepted 29 July 1997

1 Introduction Bouchon et al. 1997. In these approaches, sam-ples of plant entities were designed according totopological and morphological criteria and then

Topological structures of plants have been wide- studied using classical statistical methods. How-ly explored at a qualitative level since the intro- ever, this strategy assumed that the biologicalduction of architectural models by Halle and phenomenon of interest could be satisfactorilyOldeman (1970). In order to take topology into characterized by an a priori choice of topologi-account, first quantitative approaches to plant cal and morphological parameters. We have nowarchitecture made use of topology-driven sam- reached a second stage in which the problem ispling strategies, e.g. Honda et al. 1982, Rem- to study variations of biological phenomena asphrey et al. 1983, Fisher and Weeks 1985, functions of their topological location. In mostde Reffye et al. 1988, Prusinkiewicz et al. 1994, cases, these variations cannot be characterized

357


by simple direct observations. It is thus neces-sary to preserve the information related to plant3D structures, including both the type of entitiesand their topological relationships, during themeasurement processes. If topological structureis recorded and can be reconstructed within com-puters, then we may develop efficient computingtools for exploring these complex objects quan-titatively.

We have developed such a general methodolo-gy for analyzing plants which makes use of therepresentation of plant topological structures. Thismethodology is implemented in the AMAPmodsoftware (Godin et al. 1997). Data bases, createdfrom field measurements of plants, can be ana-lyzed with various exploring and modeling tools.These tools are available through a program-ming language named AML (AMAP ModelingLanguage) which enables the user to work onvarious objects, i.e. formal representations ofplants, samples of data, or models. The user canuse specialised functions to load, save, analyze,display or operate on each type of object.

This paper gives an outline of the AMAPmodmethodology for coding and exploring plants.Section 2 sketches the multiscale model of plantswhich has been designed in order to formallyrepresent plant topological structures. This for-mal representation of plants can be encoded intextual form, which enables users to encode planttopological structures in order to process themwith computers. Section 3 illustrates this codingstrategy in a simple example. Section 4 showshow computer representations of plant structurescan be loaded and explored within AMAPmodat several levels of complexity to illustrate dif-ferent types of computing operation.

2 Formal Representation ofPlants

Plants are formally represented in AMAPmodby multiscale tree graphs (MTGs). The MTGformalism has been designed to enable users toexpress both the modularity and the multiscalenature of plant structures (Godin et al. 1997). Ata given scale, plant modularity is represented bya directed graph. A directed graph is defined by

a set of objects, called vertices, and a binaryrelation between these vertices. The binary rela-tion defines a set of ordered pairs of vertices,called edges. Vertices represent botanical enti-ties and edges correspond to physical connec-tions between these entities. The direction ofedges respects the temporal causality of the con-nection between entities: edges are always di-rected from older entities to younger ones. Giv-en an edge (a,b), we say that a is si father of band b is a son of a. Directed graphs representingplants have tree-like structures: every vertex, ex-cept the root one, has exactly one father vertex.Moreover, in order to identify the different axesof a given plant, two types of connections aredistinguished: an entity can either precede (type'<') or bear (type '+') another entity. Among thesons of a given vertex, only one can be linked toits father by a '<' edge (one entity can onlyprecede at most one entity). The other ones arenecessarily linked to the father by a '+' edge. Inthis way, an axis is a maximal series of entitiesin the graph connected by a '<' link. In order todescribe different characteristics of plant enti-ties, vertices can have values, e.g. length, diame-ter, spatial location, leaf area, number of flow-ers, type of branched entities, etc. (Fig. 1).

A plant can be analyzed at several scales, interms of internodes, axes or, at more macroscop-ic scales, in terms of branching systems. Ac-cording to the above discussion, each scale ofanalysis corresponds to a modular structure whichcan be formally represented by a tree graph. Inaddition, we observe that entities at one scaleconsist of entities at a finer scale. For instance,growth units are structured sets of internodesand reiterated complexes may be analyzed asbranching systems made of axes. Therefore, thereexist relations between the different scales whichhave to be formally represented. A MTG inte-grates in a homogeneous framework the differ-ent tree graphs corresponding to plant descrip-tions at different scales (Fig. 2). Vertices at onescale are composed of vertices at a higher scale(Fig. 2e). If an entity a is composed of n entitiesJC], JC2, •••, xn, for every i G [1, n], a is called thecomplex of xh and x, is a component of a. Thecomplex of any entity JC, is denoted K(X,). If thescale of a is defined by the integer s, then forevery i e [I, n] the scale of x< is s + 1. The most

358

Godin, Costes and Caraglio Exploring Plant Topological Structure with the AMAPmod Software

Fig. 1. (a) Growth units constituting an annual shoot Quercus ilex (Fagaceae). (b)Graph representation of the growth unit organization.

2. A tree at different scales of percep-tion. The formal representation of theoverall tree structure is the superposi-tion of the partial structures existingat different scales (a) tree scale s = so= 0, (b) axis scale s = 1, (c) growthunit scale, s = 2, (d) internode scale(leaves are not represented in the treegraph. They would be represented asinternode attributes), s = 3, (e) corre-sponding multiscale tree graph.

359


macroscopic scale SQ consists of a single vertex,representing the entire database, and by conven-tion has value 0. In order to maintain coherencebetween the different tree graph representationsof the same individual, MTGs must respect thefollowing consistency constraint: if there existsan edge (x,y) in the tree graph representing theplant structure at scale s + 1, and if the complex-es of x and y are different, then there necessarilyexists a corresponding edge (n(x), n(y)) betweenthese complexes in the tree graph representingthe plant at scale s. This expresses that the con-nection between two macroentities results fromthe connection between two of their components.

3 Coding Individuals

Different strategies have been proposed for re-cording topological structures of real plants ei-ther for representing plant at a single scale, e.g.(Room et al. 1996, Hanan and Room 1997) orfor multiscale representations (Godin and Costes1995, Godin et al. 1997). In AMAPmod, planttopological structures are abstracted as multi-scale tree graphs. Describing a plant topologythus consists of describing the multiscale treegraph corresponding to this plant. The descrip-tion of a given plant can be specified using a"coding language". This language consists of anaming strategy for the vertices and the edges ofmultiscale graphs. A graph description consistsof enumerating the vertices consecutively usingtheir names. The name of a vertex is constructedin such a way that it clearly defines the topologi-cal location of a given vertex in the overall multi-scale graph. The vertices and their features aredescribed using this formal language in a socalled "code file". Let us illustrate the generalprinciple of this coding language by the topolog-ical structure of the plant depicted in Fig. 3.

Each vertex is associated with a label consist-ing of a letter, called its class, and an integer,called its index. The class of a vertex often refersto the nature of the corresponding botanical enti-ty, e.g. I for internode, u for growth unit, B forbranching system, etc. The index of a vertex isan integer which enables the user to locally iden-tify a vertex among its immediate neighbors.

U2

tU3

U2

Ul

Fig. 3. Coding the topological structure of a two yearold poplar tree.

Apart from this purely structural role, indexesmay be used to convey additional meaning: theycan be used for instance to encode the year ofgrowth of an entity, its rank in an axis, etc.

At a given scale, plants are inspected by work-ing upwards from the base of the trunk and sym-bols representing each vertex and its relationshipto its father are either written down or keyeddirectly into a laptop computer.

The coded string starts with the single symbolV . Coding a single axis (e.g. the series of inter-nodes of the trunk depicted in Fig. 4a) wouldthen yield the string:

360

Godin, Costes and Caraglio Exploring Plant Topological Structure with the AMAPmod Software,

a -bFig. 4. (a) Tree graph at internode scale, (b) Multiscale tree graph (MTG).

For a branching structure (Fig 4a), encoding atree-like structure in a linear sequence of sym-bols leads us to introduce a bracket notation,frequently used in computer science to encodetree-like structures as strings (e.g. Prusinkiewiczand Lindenmayer 1990). A square bracket isopened each time a bifurcation point is encoun-tered during the visit (i.e. for vertices havingmore than one son). A square bracket is closedeach time a terminal vertex has just been visited(i.e. a vertex with no son) and before backtrack-ing to the last bifurcation point. In the aboveexample, entity 16 is a bifurcation point since thedescription process can either continue by visit-ing entity 17 or 120. In this case, the bifurcationpoint 16 is first stored in a bifurcation point stack

(which is initially empty). Secondly, an openedsquare bracket is inserted in the output string andthirdly, the visiting process resumes at one of thetwo possible continuations, for example 120, lead-ing to the following code:

The entire branch 120 to 128 is then encoded likeentities n to 16. Entity 129 has no son, and thus isa terminal entity. This results in inserting a closedsquare bracket in the string:

/Il<12<13<14<15<16[+120<121<122<123<124<125<126<127<128<129]

The last bifurcation point can then be read at thetop of the bifurcation point stack and the visitingprocess can resume on the next possible continu-

361


ation of 16, i.e. 17, leading eventually to the finaloutput code string:

/Il<12<13<14<15<16[+120<121<122<123<1124<125<126<127<128<129][<17<18<19<110<lll<112

Once all the continuations of a bifurcation pointhave been processed, it is popped out from thebifurcation stack.

Let us now extend this coding strategy to mul-tiscale structures. Consider a plant described atthree different scales, for example the scale ofinternodes, the scale of growth units and thescale of plants (Fig. 4b). The depth first proce-dure explained above is generalized to multi-scale structures in the following way. The multi-scale coding strategy consists basically of de-scribing the plant structure at the highest scale ina depth first order. However, during this process,each time a new boundary of a macroscopicentity is crossed when passing from entity a toentity b, the corresponding macroentity label,suffixed by a V, must be inserted into the codestring just before the label of b and after the edgetype of (a,b). If more than one macroscopicboundary is crossed at a time, correspondinglabels suffixed by V must be inserted into thecode string at the same location, labels of themost macroscopic entities first. In the multiscalegraph of Fig. 4b for example, the depth first visitis carried out at the internode level (highest scale).The visit starts by entering in vertex n at thescale of internodes. However, to reach this entityfrom the outside, we cross boundaries of Pi andUl, in this order. Then the depth first visit startsby creating the code string:

/P1/U1/I1

Then, the coding proceeds through vertices II to16, with no new macroscopic boundary encoun-tered. 16 is a bifurcation point and as explainedabove, this vertex is stored in the bifurcationpoint stack, a ' [ ' is inserted in the code stringand the depth first process continues on the sonof 16 whose label is 120. Since to reach 120 from16 the new macroscopic boundary of the firstgrowth unit of the branch is crossed, on 120 thegenerated code string is

One can note that the boundary of growth unit Ulof the trunk is also crossed when passing from 16to 120. However, since this is not a new bound-ary - it has already been encountered during thevisit process before - it produces no symbol.

Similarly on the new branch, coding continuesand crosses a growth unit boundary between in-ternodes 124 and 125:

<I23<I24<U2/I25<126<127<128<129]

Once the end of the branch is reached at entity129, a ' ] ' is inserted in the code string and theprocess backtracks to bifurcation point 16 in or-der to resume the visit at the internode scale onthe next son of 16, i.e. u. Then coding goesthrough to the end of the poplar trunk since thereare no more bifurcation points. Between entities17 and 119, two new growth unit boundaries arecrossed which generate the final code string:

<I23<I24<U2/I25<126<127<128<129]

It is often the case in practical applications that anumber of attributes are measured on certainplant entities. Measured values can be attachedto corresponding entities using a bracket nota-tion, ' { . . . } ' . For instance, assume that one wantsto note the length and the diameter of observedgrowth units. For each measured growth unit, apair of ordered values defines respectively itsmeasured length and diameter. Then, the prece-dent code string would become:

,5.<I6[+Ul{7,3.5}/I20<121<122<123<124

<U2{4,2.1}/I25<126<127<128<129]

<I13<I14<I15<U3{7.5,3.

In this string, we can read that the first growthunit of the trunk, Ul, has length 10 cm and dia-meter 5.9 mm (units are assumed to be knownand fixed).

362

Godin, Costes and Caraglio Exploring Plant Topological Structure with the AMAPmod Software...

In practical applications, coding plants as rawsequences of symbols becomes quite unreada-ble. In order to give the user a better feedback ofthe plant topology in the code itself, we canslightly change the above code format in order toachieve better legibility. Each square bracket isreplaced by a new line and an indentation levelcorresponding to the nested degree of this squarebracket. Similarly, a new line is created aftereach feature set and the feature values are writ-ten in specific columns. The following table givesthe final code corresponding to the example inFig. 3.

/Pl/Ul

Length Diameter

10 5.9

+U1 7/I20<I21<I22<I23<I24<U2 4/I25<126<127<128<129

<I7<I8<I9<U2 815<U3 7.5

3.52.1

4.33.9

4 Exploring Plants

Once a plant database has been created, it can beanalyzed using the AMAPmod software. Thedifferent objects, methods and models containedin AMAPmod can be accessed through a func-tional language called AML. This language hasbeen designed to optimize access to plant data-bases.

4.1 Creating Plant Representations

The formal representation of a plant, and moregenerally of a set of plants, can be built byAMAPmod from its code file using the AMLfunction MTG( ):

AML > g = MTGCtree_code_file.txt")

The procedure MTG attempts to build the plantformal representation, checking for syntactic andsemantic correctness of the code file. If the file isnot consistent, the procedure outputs a set oferrors which have to be corrected before apply-ing a new syntactic analysis. Once the file is

syntactically consistent, the MTG is built (cf.Fig. 4b) and is available in the variable g. How-ever, for efficiency reasons, the latest construct-ed MTG is said to be "active": it will be consid-ered as an implicit argument of most of the func-tions dealing with MTGs. To get the list of allvertices contained in g, for instance, we write:

AML > v l is t = VtxListC )

instead of

AML > v l is t - VtxList(g)

The function VtxListC ) extracts the set of verti-ces from the active MTG g and returns the resultin variable vlist.

Once the MTG is loaded, it is frequently use-ful to make sure that the database actually corre-sponds to the observed data. Part of this check-ing process has already been done by the MTG( )function. But, some high-level checking maystill be necessary to ensure that the database iscompletely consistent. For instance, in our ex-ample, we might want to check the number ofplants in the database. Since plants are repre-sented by vertices at scale 1, the set of plants isbuilt by:

AML > plants - VtxList(Scale -> 1)

Like vlist, the set plants is a set of vertices. Thenumber of plants can be obtained by computingthe size of the set plants.

AML > plant_nb = Size(plants)

Each plant constituting the database can be indi-vidually and interactively accessed via AML.For instance, assuming the plant correspondingto the example of Fig. 4b is represented by avertex (at scale 1) with label PI. Plant PI can beidentified in the database by selecting the vertexat scale 1 having index 1:

AML > plantl = Foreach _p In plants:Select(_p, Index(_p)==l)

In this expression, the Foreach construct is usedto browse the set of plant vertices plants. For

363


each plant vertex _p in this set, operator Select isapplied and returns a non void value only forvertices whose index value is 1. Planti thus con-tains the vertex representing plant PI. Now it ispossible to apply new functions to this vertex inorder to explore the nature of plant PI. Assumefor instance we want to know the number ofgrowth units composing PI:

AML > gu_nb = SizeCComponentsCplantl))

ComponentsC ) is a built-in function which ap-plies to a vertex v and returns the vertices com-posing v at the next superior scale. Since plantiis a vertex at scale 1, representing plant PI,components of planti are vertices at scale 2, i.e.growth units. It is also possible to compute thenumber of internodes composing a plant by sim-ply specifying the optional argument Scale infunction Components:

AML > internode_nb =Size(Components(plantl, Scale 3 ) )

Many such direct queries can be made on the plantdatabase which provide interactive access to it.However, a complementary synthesizing view ofthe database may be obtained by a graphical re-construction of plant geometry. Geometrical pa-rameters, like branching and phyllotactic angles,diameters, length, shapes, are read from the data-base. If they are not available, mean values canbe inferred from samples or from additional datadescribing plant general geometry (Godin et al.1996). A 3D interpretation of the MTG providesthe user with natural feedback on the database.Built-in function PlantFrameC ) computes the 3D-geometry of plants. For example,

AML > framel = PlantFrameCplantl)

computes a 3D-geometrical interpretation of PItopology at scale 2, i.e. in terms of growth units(Fig. 5a). Like in the previous example, Plant-FrameC ) takes Scale as an optional argumentwhich enables us to build the 3D-geometricalinterpretation of PI at the level of internodes(Fig. 5b):

AML > frame2 = PlantFrameCplantl, Scale —> 3)

a D

Fig. 5. 3D geometrical reconstruction of the MTG.Reconstruction (a) at growth unit scale, (b) atinternode scale.

Refinements of this 3D geometrical reconstruc-tion may be obtained with the possibility tochange the shape of the different plant compo-nents, possibly at different scales, to tune geo-metrical features (length, diameter, insertion an-gle, phyllotaxy, ...) as functions of the topologi -cal position of entities in the plant structure.

4.2 Extraction of Plant Entity Features

When attributes of entities are available in MTGs,it is possible to retrieve their values by using thefunction FeatureC ):

AML > f i rs t_gu = TrunkCplantl)@l

AML > first_gu_diameter =

FeatureCfirst_gu, "Diameter")

The first line retrieves the vertex correspondingto the first growth unit of the trunk of PI (func-tion TrunkC ) returns the ordered set of compo-nents of the trunk of vertex PI, and operator @with argument 1 selects the first element of this

364

Godin, Costes and Caraglio Exploring Plant Topological Structure with the AMAPmod Software...

set). Then, in the second line, the diameter ofthis growth unit is extracted from the database.Variable first_gu_diameter then contains the value5.9 (see the code file). Similarly the length of thefirst growth unit can be retrieved:

AML > first_gu_length =Feature(first_gu, "Length")

Variable first_gu_length contains value 10.The user can simplify this extraction by creat-

ing alias names:

AML > diameter(_x) = Feature(_x, "Diameter")

AML > length(_x) = Feature(_x, "Length")

It is then possible with these functions to builddata arrays corresponding to feature values asso-ciated with growth units.

AML > growth_unit_set = VtxList(Scale —> 2)

AML > Foreach _x In growth_unit_set: length(_x)

Moreover, new synthesized attributes can be de-fined by creating new functions using these ba-sic features. For example, making the simpleassumption that the general form of a growthunit is a cylinder, we can compute the volume ofa growth unit:

AML > volume(_x) =(PI*diameter(_x)"2 4)*length(_x)

where PI denotes the real constant n and ' de-notes the power function. Now, the user can usethis new function on any growth unit entity as ifit were a feature recorded in the MTG. For in-stance, the volume of the first growth unit iscomputed by:

AML > first_gu_length = volume(first_gu)

The total volume of the trunk:

AML > trunk_volume = Sum( Foreach _guIn Trunk(plantl) : volume(_gu) )

The wood volume of the whole plant can becomputed by:

AML > plant_volume = Sum( Foreach _guIn Components(plantl) : volume(_gu) )

4.3 Extracting More Information fromPlant Databases

As illustrated in the previous section, plant data-bases can be investigated by building appropri-ate AML queries. Built-in words of the AMLlanguage may be combined in various ways inorder to create new queries. In this way, moreand more elaborated types of queries can beconstructed by creating user-defined functionswhich are equivalent to computing programs. Inorder to illustrate this procedure, let us assumethat we would like to study distributions of num-bers of internodes per growth units, such distri-butions being an important basic prerequisite forbotanically-based 3D plant simulations (e.g. Bar-thelemy 1991, de Reffye et al. 1991, Jaeger andde Reffye 1992, Bouchon et al. 1997). At a firststage, we consider all the growth units containedin the plant database together. We first need todefine a function which returns the number ofinternodes of a given growth unit. Since in thedatabase, each growth unit (at scale 2) is com-posed of internodes (at scale 3) we compute theset of internodes constituting a given growthunit _x as follows:

AML > internode_set(_x) = Components(_x)

The object returned by function internode_set( )is a set of vertices. The number of internodes ofa given growth unit is thus the size of this set:

AML > internode_nb(_x) =Size(internode_set(_x))

Second, the entities on which the previous func-tion has to be applied, must be located in thedatabase. A set of vertices is created by selectingplant entities having a certain property.

The set of growth units is the set of entities atscale 2:

AML > gu_set = VtxList(Scale -> 2)

Third, we have to apply function internode_nb( )to each element of the selected set of entities:

AML > samplel =Foreach _x In gu_set : internode_nb(_x)

365


a

30-

20-

10-

0

order 4

- 1..II

1

I..I.L...0 5 10 15 20 25 30

Fig. 6. Different distributions of the numberof internodes per growth unit, in differ-ent topological situations.

We use iterator Foreach in order to browse thewhole set of growth units of the database, and toapply our internode_nb( ) function to each ofthem.

Now, we want to get the distribution of thenumber of internodes on a more restricted set ofgrowth units. More precisely, we would like tostudy the distribution of internode numbers ofdifferent populations corresponding to particularlocations in the plant structure. We thus have todefine these populations first and then to iteratethe function internode_nb( ) on each entity ofthis new population like in the previous exam-ple. Let us consider for example the populationmade of the growth units composing branches oforder 1. Consider again the whole set of growthunits gu_set. Among them, those which are lo-cated on branches (defined as entities of order 1in AML) are defined by:

AML > gul = Foreach _x In VtxList(Scale -> 2) : Select(_x, 0rder(_x) == 1)

Here again, we use the iterator Foreach in orderto browse the whole set of growth units of thedatabase, and to apply the Select operator to

each of them. Select will return only growth unitvertices whose order is 1. AML variable gul thuscontains all the growth units in the corpus whichare located on branches. Eventually, after thesample of values is built, the above function isapplied to the selected entities:

AML > sample = Foreach _xIn gul : internode_number(_x)

At this stage, a set of values has been extractedfrom the plant database corresponding to a topo-logically selected set of entities. This sample ofdata can be further investigated with appropriateAML tools. For example, AML provides thebuilt-in function Histogram( ) which builds thehistogram corresponding to a set of values.

AML > histol = Histogram(sample)

AML > Plot(histol)

This plot gives the graph depicted in Fig. 6a.Similarly, by selecting samples corresponding todifferent topological situations, we would obtainthe series of plots in Fig. 6 (Caraglio et al. 1990).

366

Godin, Costes and Caraglio Exploring Plant Topological Structure with the AMAPmod Software.

5 Conclusion References

This paper outlined the general methodology forrepresenting, encoding and exploring plants asdefined in AMAPmod, by giving simple andfully explained examples. Using the AML lan-guage, the user can define complex queries bycombining functions and design in this way hisown exploring strategy. Since plants are repre-sented in databases by structured objects, i.e.MTGs, queries may return objects which pre-serve parts of the structure of MTGs: e.g. spatialor temporal sequences of events or tree-struc-tured data. Tools for studying these complexobjects are currently under development inAMAPmod (Godin et al. 1997, Guedon et al.1995, Costes and Guedon 1997).

Moreover, preservation of plant topologicaland spatial information in measurements enablesus to achieve better independence between plantdatabases and end-user applications: potentially,various types of analyses can be applied on thesame database. In addition to studying morpho-logical characteristics (architecture, geometry,form, allometric relations,...), plant structure de-scriptions can be used to study the coupling ofstructure and physiological functions (photosyn-thesis, fruiting, mechanical support, water trans-port, etc.).

The will to have a common language whichcan be used to describe a wide range of speciesand the need to factorize the development ofcomputer tools to work on plant structure data-bases have been major motivations in the devel-opment of AMAPmod. As a consequence, a cur-rent key issue in using AMAPmod is related tothe definition of plant corpora. This would first-ly enable research scientists to efficiently ex-change plant data. Secondly, this would enablemodelers to compare their models on the basis ofpublic (or at least partially shared) sets of data.As a counterpart, data collection may be moreexpensive in this more general perspective thanin the context of a precise study. This might notbe a too severe limitation if the definition ofplant corpora are justified in terms of facilitatingcollaborative research.

Barthelemy, D. 1991. Levels of organization and rep-etition phenomena in seeds plants. Acta Biotheo-retica 39: 309-323.

Bouchon, J., de Reffye, P. & Barthelemy, D. (eds.)1997. Modelisation et simulation de 1'architecturedes vegetaux. Science Update. INRA editions.

Caraglio, Y., Elguero, E., Mialet, I. & Rey, H. 1990.Le Peuplier. modelisation et simulation de sonarchitecture. Rapport annuel, convention idf/cirad,CIRAD, Laboratoire de Modelisation des Plantes.

Costes, E. & Guedon, Y. 1997. Modelling the syllep-tic branching on one-year-old trunks of apple cul-tivars. Journal of American Society for Horticul-tural Science 122(1): 53-62.

de Reffye, P., Dinouard, P. & Barthelemy, D. 1991.Modelisation et simulation de 1'architecture del'Orme du Japon Zelkova serrata Thunb. MakinoUlmaceae: la notion d'axe de reference. In:L'Arbre, Biologie et developpement. NaturaliaMonspeliensia: 251-266.

— Edelin, C, Francon, J., Jaeger, M. & Puech, C.1988. Plant models faithful to botanical structureand development. In: Dill, J. (ed.), Proceedings ofSIGGRAPH'88, vol. 22, p. 151-158, Atlanta.Computer Graphics.

Fisher, J. & Weeks, C. 1985. Tree architecture ofNeea (Nyctaginaceae): geometry and simulationof branches and the presence of two different mod-els. Bull. Mus. natn. Hist, nat 7: 385^01.

Godin, C, Bellouti, S. & Costes, E. 1996. Restitutionvirtuelle de plantes reelles: un nouvel outil pourTaide ä 1'analyse de donnees botaniques etagronomiques. In: Proceedings of the Interface toReal and Virtual Worlds, p. 369-378.

— & Costes, E. 1995. How to get representation ofreal plants in computers for exploring their botan-ical organization. In: Proceedings of the 4th Inter-national Symposium on Computer Modelling inFruit Research and Orchard Management, p. 45-52.

— , Guedon, Y., Costes, E. & Caraglio, Y. 1997.Measuring and analyzing plants with the AMAP-mod software. In: Michalewicz, M. (ed.), Advancesin computational life sciences I: Plants to ecosys-tems, p. 63-94. CSIRO, Australia.

Guedon, Y., Costes, E. & Caraglio, Y. 1995. Modeli-sation de structures vegetales resultant de la suc-

367


cession d'entites botaniques elementaires. In:L'Arbre. Biologie et developpement. NaturaliaMonspeliensia. in press.

Halle, F. & Oldeman, R.A.A. 1970. Essai sur1'architecture et la dynamique de croissance desarbres tropicaux. Masson, Paris.

Hanan, J. & Room, P. 1997. Practical aspects of plantresearch. In: Michalewicz, M. (ed), Advances incomputational life sciences I: Plants to ecosys-tems, ch. 2, p. 28-43. CSIRO, Australia.

Honda, H., Tomlinson, P. & Fisher, J.B. 1982. Twogeometrical models of branching of tropical trees.Ann. Bot. 49:1-12.

Jaeger, M. & de Reffye, P. 1992. Basic concepts ofcomputer simulation of plant growth. Journal ofBiosciences 17: 275-291.

Prusinkiewicz, P. & Lindenmayer, A. 1990. The algo-rithmic beauty of plants. Springer Verlag.

— , Remphrey, W., Davidson, C. & Hammel, M.1994. Modeling the architecture of expanding Frax-inus pennsylvanica shoots using L-systems. Ca-nadian Journal of Botany 72: 701-714.

Remphrey, W.R., Neal, B.R. & Steeves, T.A. 1983.The morphology and growth of Arctostaphylosuva-ursi bearberry: an architectural model simu-lating colonizing growth. Canadian Journal of Bot-any 61: 2451-2458.

Room, P., Hanan, J. & Prusinkiewicz, P. 1996. Virtu-al plants: new perspectives for ecologists, pathol-ogists and agricultural scientists. Trends in PlantScience, p. 33-38.

Total of 19 references

368

exploring plant topological structure with the amapmod software

Documents