A Generic Model to Exploit Urban Regulation Knowledge

The Right to Build is defined by textual elements that determine what an owner can build on a parcel. Such regulations contain elements that can influence the development of territories. Expressed through legal texts, their effects on the territory are difficult to assess because of the documents’ complexity and of the diversity of urban configurations. In this paper, we present a generic and extendable model to represent such regulations. This model is based on (1) a representation of geographical concepts (attributes, features and relations) mentioned in regulations and (2) rules formalized with Object Constraints Language (OCL). We also propose an implementation that allows the handling of formalized rules in order to check if a building configuration proposal respects urban regulations. Many applications are possible in order to assist in the conception of such regulations, land acquisition strategy or territorial evolution studies, in this article, we notably describe a future application dedicated to assist building permit surveyors.


Introduction
In most countries, the development of territories is ruled by a set of urban planning documents that regulates the development of different objects (like buildings or street networks) at different scales (national, regional, local). These documents are generally composed of maps, which indicate areas and objects concerned by such regulations, and legal writings to express rights and duties. The systematic assessment of the effects of such documents and their use for numerical studies remain a research issue. However, being able to verify that a plan achieves its objectives represents an important societal concern. Formalizing such knowledge in numerical models presents numerous advantages such as the diffusion of such information on geographical portals, and the design of applications to support decisions in urban planning policy.
Among these regulations, our attention is focused on the one that regulates the Right to Build. This Right to Build is notably limited through a set of morphological constraints that is expressed by legal texts and aims to regulate what can be built on each parcel. Providing a complete numerical model of such regulation is particularly relevant. We can make a non-exhaustive list of potential applications of such a model: • during regulation design, it can help a city administration to assess, for different scenarios, what can be built on parcels for a whole city; • when acceptance of regulation requires public participation, it may support the design of 3D representations that ease regulation understanding for the (non-expert) public; • for construction permit surveys, the model can ease the checking of a set of rules; • for building prospecting, it helps citizen, city or building promoters to assess constructibility to determine relevant zones for construction of a new project; • in the long term, prospective models that assess the impact of urban development on environmental indicators can be constrained by construction regulation.
The aim of this paper is to propose a generic and extendable model that represents such constraints in order to ease the design of applications. We focus our study on the French regulation named PLU (PLU for Plan Local d'Urbanisme, in French.) (for Local Urban Planning Schema) but provide extension mechanisms that allow for the application of this model in regulations from other countries. To begin with, the French regulation is briefly described with a presentation of key concepts (Section 2). Then, related works on regulation models and their application introduce the subject (Section 3). Next, our proposition is detailed including methodology, geographical model and rule formalization (Section 4). The final part presents an implementation to process the information described in the model and a discussion about a future application: surveyor assistance for building permit surveys (Section 5).

Local Urban Regulation
In French regulation, the definition of Right to Build is worked out at two levels. At a national level, the Code of Urban Planning establishes purposes (furthermore, the number of articles may depend on PLU design date), scopes and a structure for local regulations. This includes notably the definition of 14-16 articles with specific titles that compose a textual part of this regulation compiled by municipalities or inter-municipalities. Thus, at a local level, each PLU is elaborated by local administration according to the national level. It must specify a zoning plan where each zone is assigned to a type according to its expected development. Zone typology includes urban zones, zones to be built, natural zones or agricultural zones, some sub-types can be provided according to local particularities. Thus, according to its type, a code is affected to each zone. For example, code for urban zones is UA, N for natural zones and A for agricultural zones. For each zone type, a textual regulation is applied and is structured with the articles define in the Code of Urban Planning. Thus, for example, for every PLU, article 10 limits the maximal height and article 11 regulates exterior aspects of new buildings. The underlying logic of the regulation and the title of each article is presented in Table 1.
Concerning textual regulation, if the title and the scope of these articles is determined at the national level, the content is free and compiled by the local administration. Thus, an administration is free to define how to constrain new buildings for every articles. For example, a maximum height constraint can be defined by limiting the height of the top of the roof, the height of the gutter or a maximal number of floors. Thus, it is impossible to define a universal model to represent all rules (notably, because new ones may be invented), however, we aim in this paper to provide an open model generic enough to reflect the freedom of local administrations to design complex rules and extendable enough to easily integrate new elements of regulation. Even if textual information is different, the constraints expressed in the articles of French Right to Build remain nearly the same on the whole territory. This is quite interesting for our model because this stability may ease its adaptation for past or maybe future constructibility regulation.
In addition to textual regulations, PLU specifies very local constraints: graphical prescriptions are plans that indicate where textual regulation is associated with local constraints. For example, a PLU can set a maximum height of 16 m on a zone except on an area delineated in graphical prescriptions where the value is 14 m. Figure 1 provides an illustration of several categories of graphical prescriptions. They are generally specified on a map as an overlay of cadastral map with the zoning plans. Some restrictions are defined only by the geographic positions (for example, trees to preserve) but others by relationships between two objects (for example, inter-visibility constraint to preserve a view on an historical building or alignment on a specific line). For example, recoils require an object of reference to be expressed. This object is the border of public road in Figure 1 but this knowledge is implicit and not directly indicated in the map.

Related Works about Right to Build Applications and Their Models
Different types of applications based on Right to Build constraints have been proposed. In [2], the authors describe a 3D viewer that links geographic feature to related textual regulation. In order to propose an explicit representation of this regulation, some authors designed methods to generate buildable hulls from geometric constraints [3][4][5]. These hulls can be used for participation purposes or to help the design of buildings [6]. Some authors go further in the treatment of these rules by generating buildings [7][8][9] or proposing extensions to existing buildings [10]. As constructibility is strongly related to urban evolution studies, this regulation can constraint simulations of city evolution. For example, [11] defines a global degree of constraint by a manual analysis of regulation texts; zones strongly constrained are less likely to increase their density. In [12], density evolution is limited at the local level by constraining directly the footprint of potential constructions proposed by the system. If all these applications use a numerical representation of urban regulation, they propose different way to model constraints. In some works [3,13], constraints are directly hard-coded and strongly linked to underlying implementation. In other works, rules are expressed through generative language such as [14] who made a proposition based on GML (Generative Modelling Language) [15] or CityEngine [16] based on CGA (Computer Generated Architecture) shape grammar. These propositions are limited to the context of shape generation and cannot include non-directly geometrically interpretable constraints (for example, limitation of built surface cannot be interpreted in such without extra heuristics). Some formalization propositions are designed with ad hoc declarative languages based on a set of geometric constraints [17] or by declaration of effective conditions and consequences [5] and are limited by their expressiveness notably in terms of usable geographic features. Existing standards are focused on representation of regulation geographic features. [18] is a French National standard that defines all necessary cartographic information such as regulation zoning, local Right to Build restriction (i.e., historical building to preserve, limitations due to energy transport infrastructures). In the context of urban planning national infrastructure, all local administrations must provide information about their territory for 2016 in order to produce a national reference database with respect to this standard. An other initiative is the XPlannug [19] German standard that provides models to describe information relative to urban planning and Land Use. The focus is set on the description of plans (zoning plans, regional plans and land uses plans) to ease the exchange between city actors. The Land Administration Domain Model [20] is a standard recently recognized by the International Organization for Standardization (standard ISO 19152). The aims of the standard are to offer a possibility to implement land use policies. It describes the spatial unit, legal geographic objects and legal persons. All these approaches are more focused on geographic description than on the contents of legal texts and do not allow an automatic reasoning on these contents.

A Model for Local Urban Regulation
The aim of this work is to define a model that represents knowledge contained in PLU regulations. We illustrate the issue with an example, by observing a typical rule ( Figure 2). We can notice that the rule is expressed with geographical objects, spatial properties, relations and numerical values. Thus, modelling regulations requires dealing with two aspects: • a geographical model that describes the underlying territorial logic necessary to express rules; • a formalization of urban rules built on the geographical model. Concretely, for the example rule, a model should be able to organize relevant spatial information, that means: • geographical features: zone, street, boulevard, main roofing, alignment, road; • properties: name of the zone (EN UB 44), height of the roofing, name of the street (Georges Wodli, Président Wilson); • relations: inclusion in a zone ("in"), "at the border", "on a width"; but also to express with these elements the rule formed by the whole text.
In CEN UB 44 zone, at the border of Georges Wodli street and Président Wilson boulevard, maximal height measured to main roofing is 20 m on a width of 30 m from the alignment of these roads. In the next Section 4.1, our modelling choices are presented, then, in Section 4.2 the geographical model for urban local regulation is introduced and finally, our regulation formalization based on Object Constraint Language (OCL) [21] is presented 4.3. The model is also available in the XML Metadata Interchange format on our project repository [22].

Modelling Scope
In order to produce an operational model, the scope of our model is limited by a set of filters: • Considered features: our model is mainly focused on rules concerning buildings. Thus, we do not include in this study rules not dedicated to building, such as rules about vegetation or about the number of parking spaces. Inside an article, some rules which do not concern buildings are also not considered; • Frequency of uses: as each PLU is local, it is difficult to have an exhaustive study of all existing documents. Thus, the concepts of our model are based on the study of a set of PLU and on its synthesis that highlights the most frequent legal elements. Such simplification strengthens the interest of integrating an extension mechanism; • Availability of data: in order to design applications based on our model, we integrate in the model concepts related to existing features in common databases (i.e., CityGML Level of Detail 1 or 2 for buildings). Thus, some elements concerned by regulations, such as balconies or windows, missing in most databases, are not considered in this study. Nevertheless, information that can be assessed with geometric operators or heuristics are kept in the final model; • Objectivity: PLU rules can be classified into objective rules (defined by metric or numerical expressions) and qualitative rules (that requires a judgement from local authority). As we want to formalize rules interpretable by computers, we consider qualitative rules out of the scope of our formalization. Thus rules such as "(...)imposed for harmony reasons(...)" that require human judgement are not considered in our study.

Geographic Model
In this section, we describe our geographical model that provides an organization of geographical concepts of the PLU in order to ease rule formalization.
The design of the model is based on related works [23], a synthesis of good common practices written by GRIDAUH Research Group for the Institutions and the Law of Development, Urban Planning and Housing) research team [24], a set of PLU from different French cities and two research projects dealing with Right to Build issues (TerraMagna [25], e-PLU [26]). In order to ease inter-operability our proposition is based on a set of existing standards: • CityGML (version 2.0 [27]) that provides a 3D urban model and notably themes relevant to our issue such as buildings, relief and roads; • Inspire specifications for cadastral parcel [28] is an exchange model that geographic information producers have to respect according to Inspire European Directive and describes a modelling of cadastral information (i.e., parcels, separation limits); • COVADIS standards for PLU [18], this French standard, compliant with Inspire specifications for Land Use [29], represents graphical prescriptions and zoning plans of PLU.
As these standards are not entirely adapted to our issue, we proceed to some adjustments by the addition of classes, relations and properties. To simplify the understanding of our model, we only describe relevant information (classes, relations and attributes) and a color code is applied to specify the class origin (CityGML, INSPIRE or COVADIS). White classes are additions; they are created to provide links between different standards.
In the following section, we present the different parts of our model: urban zones (Section 4.2.1); parcels (Section 4.2.2); public spaces and roads (Section 4.2.3); buildings (Section 4.2.4) and graphical prescriptions (Section 4.2.5). Figure 3 summarizes classes of our model, without their attributes.

Urban Zone
Our proposition to model zoning elements is mainly based on COVADIS standards (Figure 4). PLU define regulations that apply to different zones. Each zone holds some information such as its name, its type code or its validity dates. Hence, the notion of rule is defined for a given zone. The rule is expressed, on the one hand, through a textual attribute, to keep a link to legal documents (text attribute) and, on the other hand, through our OCL formalization (see Section 4.3).

Parcels
Right to Build is defined at the level of the property unit (BasicPropertyUnit): a set of contiguous parcels (CadastralParcel) that belong to the same person. As a parcel or a property unit can intersect different zones (with possibly different rules), we find it necessary to introduce the SubParcel concept. A parcel is composed of sub-parcels and each sub-parcel belongs to only one zone. Parcel properties mentioned in PLU documents concern the area, the built ratio (var) and the floor area ratio (far).
Constraints on the position of new buildings may be specified according to separation borders (SpecificCBoundary). This concept is present in Inspire cadastral model [28], but we extend it as this distance may differ according to the type of the border. Thus, we distinguish: border adjacent to road (FRONT), back border (BACK), lateral border (LAT) and border inner to a basic property unit (INTRA). We can notice, for example, that inner borders are not submitted to recoil constraints, as adjacent parcels belong to the same landowner. Furthermore, as some constraints refer to objects adjacent (NeighbourFeature) to borders (i.e., other parcel, roads), the notion of adjacent object is attached to the cadastral boundary (SpecificCBoundary). Indeed, information concerning these adjacent objects can determine the parameters of applied rules. For example, the maximal height along a border adjacent to a road is often determined according to the width of this road. Thus, it is necessary to model the relationship between the border and its adjacent object. The proposed model is presented in Figure 5 and an illustrative situation is presented in Figure 6.

Public Space and Roads
This theme refers to various objects that represent public zones. Some constraints are expressed in relation with public zones according to its type (i.e., public garden, channels, rail track zones). Public roads are a particular type of public space, it is represented by a surface and has a type according to administration typologies (i.e., channel, public garden, public place). Some rules are applied according to various information about roads such as its name, its type or its width. Roads are geometrically modelled by their axes or their surfaces because different references for recoil constraints can be defined (i.e., from road axis or from its border). This multiple representation is necessary because constraints (notably distance constraints) can be defined from the nearest border of the road or from the road axis. Both types of information has to be present but it is only instantiating in regard to actual regulation. Generally, alignment constraints refer to a road or to a distance to a road, but a PLU designer can substitute this reference by a linear artificial geometry (alignment class) according to the distance from another object. Figure 7 presents the model concerning these features.

Building
Right to Build is applied to every building. Our complete building model is presented in Figure 8. According to the CityGML standard, we consider a building modelled by a surface. As a building (building class) can be laid on two different PLU zones, different regulations can be applied to its different parts. Thus, it is necessary to provide building parts decomposed according to sub-parcels. Each building and building part is composed of a roof (SpecificRoofSurface) and several facades (SpecificWallSurface). A facade is formed by a set of contiguous and coplanar walls belonging to the same construction. Additional information is necessary about buildings to assess the respect of regulations, the type of buildings (destination), their footprints and their floor areas.
Some information is attached to facades, notably the information that indicates if a facade contains at least one window (isWindowLess attribute). Even if windows are modeled in CityGML, it is interesting to add this information because some acquisition techniques can indicate if a facade has a window without necessarily determining the number and the positions of windows [30]. Concerning roofs, we extend CityGML to add some information about its structure such as minimum and maximum angles, number of pans, gables, roofing and gutters that can be involved in regulations to preserve architectural harmony (illustration provided in Figure 9).  In order to assess regulations, some specific geometric operators are required: • respectProspect(): this constraint aims to define a recoil (d) according to building height (h) and a slope (s) from a given object geometry (g). The constraint is checked if: ∀ P∈R 3 ⊂g H ini + s × distance2D(c, P) > P.z; • epsilonBand(): as some rules' values can differ according to a distance from an object (for example, maximal height is 10 m on a distance of 6 m from a road and then 5 m), the epsilonBand is an operator that cuts an object according to two distances (depthMin and depthMax) from a geometry; • height: height of new buildings is limited by the difference of altitude given by a bottom point and an high point. Several definitions of high point and bottom point exist (see Figure 10).

Graphical Prescriptions
Our prescription model is mainly based on the COVADIS standards and is presented in Figure 11. Prescriptions are local regulations that hold a geometric type (punctual, linear or areal) whose effect on Right to Build is determined by a type code (defined according to a type code list). We propose to add references to the cadastral parcel boundary: the COVADIS standards are not linked to geographic features, but some prescriptions are clearly linked to them; we find it necessary to make this relationship necessary.

Rule Formalization
In the previous sections, we presented our proposition to organize geographic concepts. In this section, we present how these concepts are used in order to formalize regulations.
Our proposition for rule formalization is based on OCL [21] normalized by the Object Management Group [31]. This formal language defines constraints on concepts (classes, relations, methods and attributes) of a schema defined in UML (Unified Modelling Language) to form constraints with important expressiveness. Geometric operators may be included in these constraints through ISO 19107 standards [32]. This language is without side effect: evaluating OCL rules will not change the value of concerned objects. OCL is notably used in GIS to check integrity constraints [33] for example to control GPS positions relatively to 3D buildings [34].
As OCL is based on UML, it is possible to provide new elements to create rules by extending the model or by adding new operators. In this paper, we propose to model regulations with the geographic concepts and the operators presented in the previous section as a set of OCL rules. Thus, it is possible to translate the constraint: "In any parcel, buildings must be built at a distance greater than 5 m from lateral boundaries" by: context SubParcel inv: self.specificCB−>select(type = "LAT").geom −> forAll(g |self.buildingsParts.footprint.distance(g)−>min() ≥ 5) Once the model is instantiated, the OCL rules are evaluated for each object of the relevant urban zone. context SubParcel indicates the class of the objects concerned by the evaluation. Thus, the rule is applied to each sub-parcel (the sub-parcel is chosen and not CadastralParcel because we are sure that an homogeneous regulation is applied to the SubParcel) (see Figure 6). self is a keyword that represents the object under evaluation and it is possible to assess the different attributes and methods of the object by using the dot operator. In this example, .specificCB allows to get all the different cadastral boundaries (class SpecificCadastralBoundary). In order to get only boundaries with lateral as type, a selection is proceeded with the operator −>select(type = "LAT") that may be applied to object sets. Then, the operator forAll() allows for measuring the distance from each building part footprints to all lateral boundaries. As this last step provides a set of distances (the distances between one building to all lateral boundaries are measured), the operator −>min() extracts the minimal distance and checks if it is lesser than 5 (≥ 5).

Model Extension
Furthermore, the model can be further extended to formulate new regulation elements specific to other contexts. For instance, we propose to integrate the concept of Baufenster from German regulations (described in [14]). A Baufenster is an area inside a parcel in which a new building has to be built. In Figure 12, we present an extension of our model ( Figure 12b) and an OCL constraint (Figure 12a) in order to allow the use of the Baufenster concept.

Use of Regulation Representation
In this section, we illustrate potential uses of the proposed model. In a first section, we present our implementation to check the respect of rules (Section 5.1) and, in a second section, we introduce an application under development dedicated to the assistance of surveyors during building permit survey (Section 5.2).

Implementation and Rules Checking
A rule checker based on our proposition has been implemented. It takes geographic data formatted according to the proposed model and OCL files as the inputs.
This implementation is based on two Open-Source projects ( Figure 13) and is released itself as SimPLU3D Open-Source project in two modules: SimPLU3D-rules for the model part [35] and SimPLU3D-ocl for the OCL rules management [36]: Figure 13. Schema of the architecture.
• GeOxygene: a GIS platform providing a 3D module [37]. It provides a framework to implement the general model and geometric operators for data integration and for OCL evaluation purposes; • OCL Dresden: a library [38] dedicated to OCL constraints management. This includes parsing, checking of OCL constraints and methods to check their respect. Constraints assessment is made through a meta-model that enables the representation of a geographic model and its instances. Thus, the library provides an implementation of this meta-model that allows the representation of Java object concepts (such as classes and attributes). A mechanism in OCL Dresden library allows for instantiating the Java model from the set of Java classes that represent our model. Then, this model can be directly populated by adding Java instances provided by GeOxygene. During the interpretation phase, the OCL checker can therefore access these instances (and their properties) instantiated in the Java model in order to check the constraints.
For more rule information about rule formalization, a translation of each rule family of the Strasbourg UB Zone. PLU is provided on SimPLU3D-ocl repository [39].
In order to instantiate the model, we propose a data integration process adapted to French datasets. They include: • Parcels, from BD Parcellaire R database [40]; • Zoning plan and graphical prescription, manually captured according to format [18]; • Roads, from BD Topo R database [41]; • Buildings, either in LOD1 from BD Topo R database or LOD2 from Bati3D R [42]. According to the type of data, all the information of the model is not instantiated. For example, with LOD1, attributes relative to roof structure are missing.
A test zone is provided in SimPLU3D-rule with all data in Shapefile R format [43] and can be loaded with the LoadShp class [44]. More detail about the integration process can be found in [9].
Once the model is instantiated, it is possible to check OCL constraints on the features. If we consider the constraint described in Section 4.3, the constraints evaluation is processed as follows according to information provided during data integration process: 1. Selection of separation borders of context subparcel; 2. Selection among these borders of lateral ones; 3. Selection of their geometry; 4. For each geometry: (1) Selection of all building parts inside context subparcel; (2) Access to their footprint; (3) Distance evaluation of each footprint to limit geometry; (4) Getting the minimum of all these distance values; (5) Checking if the minimum is less than 5 m. For each constraint, three possible states are returned by the checker: checked, not checked or missing information (Figure 14). The last state is interesting as it highlights some constraints that the checker cannot evaluate. Thus, a user who does not hold all the necessary information to instantiate the model can know what is missing to correctly process the checker on its urban regulation.

Design of an Application for Building Permits Survey
As a first application of the model and of the rule checker, we are aiming to develop a web application in order to assist building permit surveyors. This application proposes several functionalities ( Figure 15): • Data visualization and edition: in order to consult regulation data, we propose an interface of 3D visualization based on ITowns API [45]. This viewer enables the consultation of data in the database according to the model and also the editing of information. Information editing is very important for such applications as concept definitions (for example: the definition of lateral borders) can vary according to concerned municipality and also because the project may modify the other geographic objects (creation of new roads, parcels fusion). Thus, this feature allows the user to define feature attributes according to local specificities. • Capture/insertion of building project: in order to check regulations, the user needs to insert geometric data about the building project. As this information is generally given in an architect paper plan, it will require the production of simple tools in order to ease its capture. Some propositions have been made to generate 3D buildings from footprints with smart extrusions [46], and the surveyor just has to capture the building footprint in the plan and choose the right parameters to produce the roof. In the case where a digital model is attached to the permit request, the model has to be integrated into the dataset. One difficulty is that a generic integration procedure is impossible to realize as architects use different tools, formats and produce semantically different models. If such data is expected, the municipality has to provide specifications to architects as it is already demanded in Monaco (Ministerial Ordinance No 2012-595 of Monaco), for example. • Capture/selection of rules: Either the surveyor chooses some existing rules or regulation in the database and applies it to parcels or s/he captures some new rules. As all surveyors are not experts in computer programming, it may be important to design an intuitive interface that produces OCL rules. Letting the surveyor choose applied rules is essential as building permits are legal and sensitive documents, and the users must perfectly know which rules the system is assessing and have a control on the whole checking process. • Rules checking and report visualization: This is the last step of the process; the selected rules are checked on the project parcel. The result is the list of respected and non respected rules with 3D visualization of non respected rules in order to assess how important is the non-conformity of the building. Some propositions to present the non respect of distance or of prospect rules in a 3D environment are made in [5]. Furthermore, as geographic data is not accurate, it will be important to simulate the influence of data imperfections on the rules checking process in order to provide confident indicators to the surveyor. We are expecting to produce such indicators by using a data perturbation method (such as described in [47]) and by calculating the percentage of case where a rule is respected.
Rule: the height of a building must be lesser than 12m. Rule: distance between front boundaries and buildings must be higher than 4.5 m. JavaModelInstanceObject [19]

Conclusions
In this paper, we propose an extendable and generic model to integrate spatial knowledge contained in French PLU documents. This model is based on a representation of 3D urban objects, properties and relationships encountered in PLU textual documents. This model reuses concepts of existing standards (National Council of Geographic Information (CNIG), COVADIS, INSPIRE) with some changes to accomplish our objective. An OCL formulation enables us to use model concepts to form constraints. In order to exploit such knowledge, we describe the Open-Source implementation of a checker based on Open-Source libraries. Once the model is instantiated, it allows the checking of OCL rules on the features. We also discuss potential uses of the checker in the introduction and present a future application to assist surveyor with building permit surveys.
A major issue concerning the checker is that it does not take into account data quality. Thus, it can be interesting to take into account some fuzzy measures in rules definition in order to model data accuracy. Nevertheless, it is possible to manage such fuzziness by considering some error margins during rules formalization, but a better method should be to use an extension of OCL that integrates such elements as proposed in [48].
Another subject of interest is the assessment of the genericity of our proposition. We are interested in the modelling of other urban regulations. This research has some interest in order to compare how Right to Build is defined in these countries and what the differences are. In the future, we may consider providing an open platform that allows designers to integrate their own regulations in the common model and to be a forum to compare good practices and building configurations.
Giving a formal expression of urban rules is an opportunity to think about the well definition of underlying rules. If it is not possible to express them into a numerical formalism, it may mean that some concepts are too fuzzy or too subjective to be automatically assessed. It may also mean that people concerned by such regulations are not able to correctly interpret it. Thus, we think that such formalization is progress in order to make such public policies more accessible, more transparent and more objective. It also allows comparison between different local regulations and simplifies sharing good practices.