RESPONSIVE URBAN MODELS BY PROCESSING SETS OF HETEROGENEOUS DATA

This paper presents some steps in experimentation aimed at describing urban spaces made following the series of earthquakes that affected a vast area of central Italy starting on 24 August 2016. More specifically, these spaces pertain to historical centres of limited size and case studies that can be called "problematic" (due to complex morphological and settlement conditions, because they are difficult to access, or because they have been affected by calamitous events, etc.). The main objectives were to verify the use of sets of heterogeneous data that are already largely available to define a workflow and develop procedures that would allow some of the steps to be automated as much as possible. The most general goal was to use the experimentation to define a methodology to approach the problem aimed at developing descriptive responsive models of the urban space, that is, morphological and computerbased models capable of being modified in relation to the constantly updated flow of input data.


INTRODUCTION
In scientifically approaching the knowledge and understanding of a phenomenon, it is common to make use of models, i.e., synthetic and selective representations of the object of research that are useful and even indispensable for interpreting, analysing, experimenting with, generalizing, etc., the phenomenon. Simplifying, this conceptual representation derives from the integration of two different interacting approaches: the abstract, logical/symbolic, interpretive hypothesis of the phenomenon and the data deriving from experiments on the phenomenon, which progressively lead to modifications and corrections of the interpretive hypothesis.
Therefore, when advancing the knowledge and understanding of a phenomenon, the model is not stably fixed, but is dynamically modified in relation to incremental increases in knowledge deriving from the experimental interpretation and analysis made, tending towards an increasingly accurate definition of its intrinsic characteristics.
This epistemological approach is usually adopted in the practice of surveying to understand and describe the existing built space. In fact, during a survey, progress in knowledge is made through the accumulation and comparison, construction, representation, and observation of models. Models for instrumentation, interpretation, verification, prefiguration, and transmission, are always and anyway operational models that conserve and relate criteria and data of different types : logical, analytical, formal, etc.; geometrical, metric, qualitative, etc. In this context, the paper presents some steps in particular experiments aimed at describing the urban space, and more specifically, historical centres of limited size and case studies that can be termed "problematic" due to complex morphological and settlement conditions, because they are difficult to access, or because they have been affected by calamitous events, etc. The experimentation presented was conducted following the series of earthquakes that affected a very large area of central Italy between 24 August 2016 and 23 January 2017. The area encompasses four Regions (Lazio, Umbria, Marche, Abruzzo) and about 140 municipalities, with a really impressive number of events registered by the INGV (Italian National Institute of Geophysics and Volcanology) -more than 49,000. The operational conditions were quite prohibitive because immediately after the events, most of the towns hit were not accessible and access was forbidden for a long time afterwards. In this context, it was necessary to produce documentation for different scopes that described the state of the places quickly and at reduced cost, even in their conditions preceding the earthquakes.
In this framework, an initial verification was made of the possibility of using sets of data already available to derive information useful for the experimentation. These conditions were met due to the spread of information in a culture of sharing and the advance of network technologies and photogrammetry techniques. At the same time, however, it was necessary to operate according to a set of procedures that would allow descriptions -or more precisely, models -to be developed that could be modified in relation to data that would be acquired over time or at a later date. These collections of data are inhomogeneous due to their difference in goal, type, quality, and accuracy, due to their reference to different periods, or because they were derived with different methodologies, procedures, and techniques, etc.
According to these goals for the experimentation, a workflow was first defined and procedures were developed to allow some of the steps to be as automated as possible. More in general, the experimentation was used to define a methodology to approach the problem aimed at developing descriptive responsive models of the urban space, that is, morphological and computer-based models capable of being modified as the flow of input data is constantly updated.

Methodology
The methodology defined via the experimentation and aimedas mentioned above -at developing descriptive responsive models of the urban space, derives conceptually from current systems to describe and manage the built space. These can be grossly summarized as Geographic Information Systems (GIS) and Building Information Modelling (BIM) systems. While they are both very different, the systems establish an information architecture organized starting with objects inserted in and referring to a given context. The first case relates to geographical, georeferenced objects equipped with a form. The second case relates to three-dimensional architectural elements whose individual parts are structured hierarchically and described with semantics.
While the approaches are analogous, the systems differ substantially, so they can be used to describe different objects. As is known, GISs are dedicated to the spatial management of geographical data and BIMs are dedicated to managing the set of data that describes a building three-dimensionally.
Various experiments have been done, especially in recent years, to connect and make the two systems interact profitably and uninterruptedly (Zhang, Arayici, Wu, Abbott, Aouad, 2009;Fosu, Suprabhas, Rathore, Cory, 2015). Nonetheless, the problematic question of the "change in scale" from the general scale of a GIS to the detailed scale of BIM -or in general, the shift from a synthetic to a detailed description -has still certainly not been resolved, thereby influencing problems related to the different informational sets and the relative visualizations and digital representations, even threedimensional ones.
In this context and for the specifics of the experimentation, the decision was made to proceed not via a solution that aimed to interconnect the two systems, but to define a methodology to approach the problem and a workflow specifically dedicated to describing the urban space.
The method was directed at, or rather centred on, developing urban models built using heterogeneous data from different sources -both data already available and data acquired via specific survey campaigns -so it could be used in operationally problematic contexts. The models developed were, in particular, responsive urban models, that is, models that react as the input data changes, therefore being susceptible to modification or refinement over time.
In this scope, the working method was developed entirely using a visual programming language (VPL), that is, a language in which graphical elements are manipulated to build a program. The language is therefore similar to the object one wants to describe, and closer to the skills of the operators in charge of activities related to all aspects of the built space, which range from knowledge and diagnostics to conservation, adaptive reuse, and management. This operational procedure can be proposed on a large scale because it is based on speedy, simple-to-use means with reliable quality and it can be implemented with reduced economic resources. This practice may be particularly effective in processes to enhance the so-called "minor" historical towns: walled citadels, villages, districts, military and religious settlements, etc. According to a census from the Italian Central Institute for the Catalogue and Documentation (ICCD), a reference institute for the Italian cultural heritage under the Ministry of Cultural Heritage and Activities and Tourism (MiBACT), this category contains more than 22,000 settlements that contribute to characterizing the historical and environmental richness of Italy.

Workflow
Through the experimentation, the methodology to approach the problem yielded a hypothesis to structure the workflow by developing Responsive Urban Models (RUM). The entire process was organized into two key points. The first was aimed at an essential description of the urban space using the morphology of the terrain and the general volumetric conformation of the buildings to achieve a preliminary model called a Synthetic Information Model (SIM). The objective of the second point was to describe the characteristics of the urban space more precisely, detailing the individual building units both qualitatively and quantitatively. Starting with the first model, a second model was developed, called the Detailed Information Model (DIM).
The entire process was designed to work seamlessly, in particular by establishing suitable relationships between the distinctive codes of information that enrich both threedimensional models. In this view, both the SIM and the DIM are responsive, i.e., organized so they can be modified in relation to the progressive change in input data, thereby allowing a workflow that runs continuously.
The process was then structured in order to work with input data that differ based on source and quality, processed using mostly automated operational procedures specifically developed with the VPL during the experimentation. Finally, the process foresaw the use of different three-dimensional modellers, both CAD and BIM, but operating exclusively through the procedures developed. This meant both the graphical/geometrical vector data and the associated alphanumeric information could be managed and processed, thereby guaranteeing the responsiveness of the different informed models.
The following describes more details about some of the steps in the experimentation, starting with the different types of data used and then illustrating the construction of the SIM and the DIM with a focus on some of the procedures developed in the VPL.

INPUT DATA
With regard to the different sources, the data used in the experimentation were grouped into two main classes: "direct" data, the result of a campaign specifically planned and carried out to acquire data; and "derived" data, i.e., data already available but produced for scopes other than the construction of 3D urban models.
"Direct" data comprise data deriving primarily from the application of different instrumental methods and techniques such as topographical surveying, 3D scans, monoscopic digital photogrammetry, spherical photogrammetry, etc. It was therefore essential to collect points characterized by threedimensional coordinates and also perhaps by other information such as RGB values, reflectance of the material, etc., which can be used to obtain metric, geometrical, and qualitative data about the built urban space. Direct data also include other types of information, both alphanumeric and textual, which can be organized into databases, such as, for example, building type, construction technology, construction technique, the thickness of floors or perimeter walls, surface finishing materials and their state of conservation and degradation, use, number of storeys, etc.
In contrast, "derived" data comprise all readily available data that, after a phase of analysis and verification followed by normalization, can be used to describe the built space on the urban scale. These data can in turn be organized into two main subsets. The first consists of vector data (for CAD environments), spatial vectors (for GIS environments), and numerical and alphanumeric data, that is, data already directly available for use and to develop the three-dimensional model, albeit after verification and with different precautions. A second subset was composed of raster data, such as GeoTiff images, orthophoto maps, and spherical panoramas available in the public domain, from which useful information can be obtained by applying the principles and techniques of photogrammetry and cartography.
The first subset in the experimentation includes Shapefiles of technical maps produced by the Territorial, Urban-Planning, and Mobility Department of the Lazio Region, along with those in .osm format available on the OpenStreetMap portal (www.OpenStreetMap.org), which stores the results of the collaborative project of the same name aimed at developing freely available cartographic data. The second set in the experimentation includes GeoTiff images available from the Earth Explorer project under the US. Geological Survey (earthexplorer.usgs.gov), georeferenced orthophoto maps from 2009 and 2014 in 1:2000 scale produced by the Territorial, Urban-Planning, and Mobility Department of the Lazio Region, and spherical panoramas available from Google Street View.
The following illustrates the main characteristics of some of the types of data used in the experimentation.

Shapefiles
Developed at the beginning of the 1990s by the ESRI in order to allow interoperability, the term "Shapefile" is used generically to indicate the vector format for GIS, which is now considered a standard. In reality, the term "Shapefile" indicates not one, but rather a collection of files containing spatial vector data (i.e., data enriched with metadata) interrelated by a unique prefix. In this way, each geometrical object is described by a set of attributes and topological information necessary to perform any spatial or query operation. Therefore, in a proper GIS environment, at least three main files corresponding to each operation to trace geometrical entities are generated automatically: *.shp, which describes the geometries, *.shx, which describes the index of the geometries, and finally *.dbf, which organizes the spatial table of attributes. Other files, which are not always all present, provide a more information on the geographical data. These include: *.prj and *.qpj, which store the information on the system of coordinates and the projection, *.sbn/sbx, which stores the spatial indices, *.fbn/fbx, which stores the spatial indices of the features only when reading, and *.shp.xml, which organizes the Shapefile metadata, etc.
Shapefiles from the Lazio Region used for the experimentation included files with the extensions .shp (geometries), .shx (geometry indexes), .dbf (spatial table of attributes), .prj, and .qpj (information on the system of coordinates and projection).

The format .osm
This is a standard developed by the collaborative Open Street Map project in order to be used easily via the web. These files are therefore characterized primarily by a reduced "weight" in order to allow them to be uploaded and downloaded more quickly. They are coded in XML (eXtensible Markup Language) and, with a single file, describe structured geographical data (vectors and sets of attributes) that can be exported and translated into the formats used by the most common GIS systems. An .osm file is normally organized into data primitives and the related tags. The data primitives are organized in nodes (points in space), ways (linear features and area boundaries), and relations (data structures that document a relationship between two or more data elements). All types of data elements (nodes, ways and relations) are characterized by tags that describe the meaning of the particular element to which they are attached.
Since it is a collaborative project, the data present on the Open Street Map portal are in the public domain and can therefore be used freely -thanks to the Open Database License -but in particular, they can be modified freely. The informational detail as well as the metric/geometrical accuracy of these data can therefore vary widely in relation to the attributes of the users equipped to edit the data, who are anyway registered on the OpenStreetMap portal. But as with all collaborative projects, the quality of the information is related to the fact that the first editing phase is followed by continual revisions and modifications.

GeoTIFF
The GeoTIFF format is an open format that, now considered a standard, is commonly used in GIS environments (Mahammad, Ramakrishnan, 2003). In addition to metadata containing information about the image (in TIFF format), it also incorporates georeferences through numerical codes expressed as tags, which describe projection types, coordinate systems, datums, ellipsoids, etc.
In particular, the GeoTiff images used in the experimentation were produced on space mission STS-99 flown in 2000 by the American and German space agencies within the space shuttle program. The main objective of the mission was to complete the Shuttle Radar Topography Mission (SRTM) project, which made a special mapping of the Earth's surface using radar technology.
The high-resolution topographical and photogrammetry data generated by the SRTM were then released by NASA into the public domain at the end of 2015.

Spherical panoramas from Google Street View
The range of data available to describe the built space includes spherical panoramas and the related equirectangular projections produced by Google Street View as applications of Google Maps and Google Earth.
This thus forms a very significant documentary heritage that attests to the state of the places and the transformation of a good part of the inhabited planet in the last ten years. It also includes products from which, under certain conditions, it is possible to obtain information about the photographed objects, applying the principles of photogrammetry and cartographic projections as demonstrated by the related literature. In fact, for about twenty years corresponding to the advance in technology, and digital photography and automatic photo stitching of digital photographic images in particular, various studies and research have aimed to investigate spherical photogrammetry and its possible uses in the field of surveying (Shum and Szeliski 1997;Shum and Szeliski, 2000;Luhmann, 2004;Fangi, 2006;Fangi 2013).
Various possible uses derive from the spherical photomosaic. In the field of surveying, it is not common to use the spherical photomosaic directly, but rather a particular cartographic transformation, i.e., an equirectangular projection. This transformation, which pertains to the category of cartographic representations, is obtained by transposing points of the sphere onto a straight cylindrical surface tangent to the sphere at its greatest parallel, where the meridians and parallels are all developed according to lines of equal length, respectively vertical and horizontal, parallel and equidistant, to form a square grid.

THE SYNTHETIC INFORMATION MODEL (SIM)
As mentioned above, the first point in the whole process of experimentation was aimed at the essential description of the urban space consisting of the morphology of the terrain and the general volumetric conformation of the buildings. The objective of this first phase was to develop the synthetic information model (SIM), which constituted the structure of the RUMs, which are characterized by a 3D model enriched with a set of attributes.
The workflow of this phase is organized into procedures that were partially automated and developed with VPL tools not only to allow for quick development, but also and especially to preserve the set of properties and attributes that characterize the input data. This initial phase was therefore carried out in the CAD environment (Rhinoceros 6), but using portions of VPL code (Grasshopper) so it could be available in the second phase of the process for its treatment in the BIM space (ArchiCAD).
The following illustrates some of the procedures developed in the different experiments using different types of input data organized in the two main steps: the step related to describing the morphology of the terrain and the volumes of the buildings.

The orography of the terrain
To describe the orography of the terrain, two different types of input data were experimented with, that is, the GeoTiff images produced with space mission STS-99 and the Shapefiles from the technical maps produced by the Territorial, Urban-Planning, and Mobility Department of the Lazio Region, where the latter have a scale of representation that obviously guarantees more precise information. In the first case, the Elk plug-in for Grasshopper dedicated to processing the maps and topographical surfaces was used to process the data deriving from the SRTM (Logan, 2015) and to interact with the mathematical modeller used in the experimentation. The operation of the procedure is illustrated in Figure 1: the block of instructions of the macro is indicated by number 1; number 2 indicates the GeoTiff file on input; number 3 denotes the portion of area defined by longitude and latitude; and number 4 indicates the extraction of the set of points with XYZ coordinates.
The first case, the city of Amatrice, was experimented with in October 2016, only fifty days after the first earthquake, which struck the town on 24 August 2016. The second case dealt with the small town of Grisciano, another historical centre hit by the series of earthquakes beginning in August 2016; experimentation on this town began in July 2017. In this case as well, the procedure was developed and defined in Grasshopper (gh) so that the Shapefile related to the area could be managed in the CAD modeller (Rhinoceros 6), as illustrated in the macro in Figure 2. Component 1 reads in the Shapefile that describes the level lines through the related geometries and the attributes that describe the altitude and georeferencing; component 2 is the add-on @It that translates the geographical coordinates into Cartesian coordinates, conserving the level lines still coded in the shape format and therefore conserving the geometry and attributes. Component 3 processes the data in component 2, returning lists of polylines and the related lists of altitudes associated with each individual polyline in the modelling space.

Figure 2. Instructions of the macro to process Shapefiles
The first transformation applied to the polylines is necessary to optimize the performance of the graphics card (4). It consists of a block translation of the polylines from the origin of the geographical space to the origin of the CAD space. The second transformation (5) is made to correctly position each single polyline at the correct altitude to describe the morphology of the terrain. The polylines of the level lines situated at altitude are used to extract the vertices (6); the resulting point cloud is appropriately filtered, eliminating points that are less than 1 metre away (7). The points of the filtered cloud are then interpolated with an unstructured triangular mesh (8).

Figure 3. Scheme to transform in structured quad-mesh
The operations aimed at rendering the structured mesh, that is, one that is informed and suitable for being imported more efficiently in the BIM environment are illustrated in Figures 3  and 4. The triangular mesh describes an area beyond the area of interest; therefore in the macro (Figure 4), component 1 is used to define the perimeter of the area. Component 2 fixes a rectangular grid of points pertaining to the horizontal plane, allowing the step to be varied along the two directions. This grid is then projected onto the triangular mesh, thereby generating a point cloud that is structured in space (3). The points are then interpolated, generating a polyhedral surface characterized by a quadrilateral mesh (quad-mesh) with an accuracy depending on the step of the first grid fixed (4).

The volumes of the buildings
To describe the volumes of the buildings, two different types of input data were also experimented with, in particular, data in the native .osm format available from the collaborative Open Street Map project, and the Shapefiles from the technical maps produced by the Territorial, Urban-Planning, and Mobility Department of the Lazio Region. Also in this case, the first type of data, whose reliability varies, was used on the case study of the city of Amatrice, while the second type of data was used on the case study for the town of Grisciano.
The .osm metadata available on the OpenStreetMap portal were then dealt with automatically with the Elk plug-in of Grasshopper and then processed in the mathematical modeller in order to conserve the informational content. Among other aspects, this content describes the street altitudes, the altitude of the building's attachment to the ground, and height of the eaves, as well as information about the type of buildings and the damage due to the earthquakes.
The macro of the procedure developed is illustrated in Figure 5. The component 1 serves to read in the files in .osm format, translating both the vector data and the alphanumeric metadata for the CAD environment. The component 2 transforms the information into structured coordinates of indexed points, which thus pertain to recognizable sets for each building. The next step (3) interpolates the structure of the indexed points with closed polylines that define the perimeter of the buildings. The second procedure developed, which is described below, is related to the use of the Shapefiles. In this particular case, the available data describe the buildings through polylines and pairs of altitudes for every vertex of the polylines, but which are not directly related to the polylines from the information point of view. The first point provides information on the altitude of the building's attachment to the ground (coded in the Shapefile with number 060119) and the second point gives information on the height of the eave of the roof (coded with number 060120). In this case as well, the procedure was developed in Grasshopper (gh) in order to manage the Shapefile describing the buildings in the Rhinoceros 6 modeller. The macro is illustrated in Figure 6. Component 1 reads in the Shapefile while component 2 manages the geometries still codified in the shape format. Component 3 acquires the geometries that describe the mass of the buildings (closed polylines) and the numerical attribute that distinguishes each polyline in the Shapefile with its own identification number; in the space of the modeller, the polylines are visualized on the plane of altitude 0. The transformation applied to the polylines (4), which is necessary to optimize the performance of the graphics card, is identical to what is done on the level lines; it consists of a block translation from the origin of the geographical space to the origin of the CAD space. Figure 6. Instructions of the macro using Shapefiles To describe the volumes of the buildings, it was necessary to define an additional macro (described in Figure 7) in order to associate the pairs of heights with the relative polylines. Figure 7. Instructions to describe the volumes of the buildings Component 1, as always, serves to read in the Shapefile that describes the pairs of points (and therefore pairs of heights) positioned within each polygon, which define its height. Component 2 returns the Cartesian coordinates of the pair of points and the respective numerical codes: one corresponding to the point informed with the distance to the foot of the building (060119 in this specific case) and the other related to the informed point of the height of the eave (060120 in this specific case). However, as in the preceding case, component 3 is aimed at extracting only the elevation heights relative to the points within the polygons. In the definition, a filter is set to first select points and attributes related to the height of the eave, that is, to code 060120. By programming the conditions of belonging (if the points are contained in the polygon, then they belong to the polygon), the points, and thus the related elevation attributes, are associated with the polygons themselves, structuring the data flow (4) in order to correctly order the heights and geometries. Finally, component 5 translates coordinate z of the polygon vertices from altitude 0 to the height of the eave.
The part of the code in Figure 8 deconstructs the polygons at an altitude, extracting the ordered vertices, which are projected on the mesh of the terrain (1). The lowest points of the projected vertices, which are ordered polygon by polygon, establish the horizontal planes on which the respective polygons positioned at the eaves are projected (2). Once the polylines that describe the buildings' attachment to the ground (foot) and to the sky (eave) are positioned, the polysurface that defines the vertical portions of the volumes is generated between the two curves. Figure 8. The part of code to construct the volumes This is then closed both in the upper and lower parts, realizing the closed polyhedrons that synthetically describe the masses of the buildings (Figure 9). Each volume that describes a building is then associated with an ID that relates it to a database that orders all the information characterizing the input data, allowing, in particular, further processing and associations of information.

DETAILED INFORMATION MODEL (DIM)
The second moment of the entire process of experimentation was aimed at a more detailed description of the characteristics of the urban space, detailing the individual building units quantitatively and qualitatively. The objective is concretized in the development of the DIM, which is made continuous with the SIM through the presence of suitable relationships between identification codes for the information that enrich the two models.
The construction of the DIM is realized either by developing the data already acquired in the previous phase, so it is already related to the SIM through tables of attributes, or by importing and processing new input data. In this phase, the model is also enriched with descriptive information organized in databases, such as, for example, building type, construction technology, construction technique, surface finishing materials and their state of conservation and degradation, use, number of floors, etc. The workflow in this phase was also organized through partially automated procedures developed with VPL tools, but in contrast to the first phase, it was performed in the BIM environment (ArchiCAD).
For reasons of space, in what follows, details of only one of the procedures are given. This relates to the acquisition and treatment of spherical panoramas available in Google Street View, which undoubtedly constitute an exceptional heritage of data and which are also of particular interest for the goals of the present experimentation.
Before proceeding to describe the procedure, it is useful to at least mention some of the specifics of the means of approaching the workflow to develop the DIM. In this scope, it is necessary to recall that the experimentation is aimed at describing an urban space whose detail is sufficient if it is consistent with a scale of representation equal to 1:500, that is, with an accuracy of around 15 cm. In particular, these are urban spaces in small historical centres with uniform, recurring characteristics: mostly aggregates of townhouses in stone, with a variable extension from 4 to 6 metres and gabled, pavilion, and-more rarely-flat roofs. The façades of the building units on the street, aggregated into blocks, are distinguished by very simple architectural elements, with windows and doors set on vertical axes and with cornices with slightly accentuated reliefs.
Starting with this verification, the means of developing the DIM was derived, where the description of the building unit is resolved by portions of flat surfaces whose IDs are associated with the volume that synthetically describes the entire building unit in the first phase. Contextually, each planar portion, which is also described through sets of attributes, is then associated with the individual architectural details. To describe each planar portion, the layout in space was defined relative to the inclination; this information can be managed with the VPL (Figure 10).
This setup was followed, for example, in constructing the roofs. Once the Shapefiles were acquired from the Lazio Region, the lines of the roof peaks, whose height is described in a table of attributes, were used to derive the inclination of the portion of plane describing the slope of the roof. The same setup was also used to organize the workflow to manage the point cloud data acquired through scans. The first step was to orient the clouds with respect to the synthetic volume described in the SIM. This was also realized by establishing a relationship between the barycentres of the polylines that describe the masses of the building units with different detail on the same horizontal plane. Then, for each pair of successive vertices that characterize the polyline deriving from the scan, the portions of vertical plane that describe the façades of the buildings were derived.
Finally, further information derived through subsequent processing of the cloud was referred to these portions of plane. For example, an experiment was made to project the points of the cloud with the associated RGB values onto the different portions of the plane, deriving a surface treatment capable of perceptively rendering the architectural detail of the façades (Figure 11). Another example is that the different architectural details characterizing the façades even in part were modelled to try and customize them. Figure 11. Detail of the buildings with point clouds

Spherical panoramas from Google Street View
Particular focus was placed on the possibility of using the spherical panoramas present in Google Street View. Among the different uses experimented with, however, the only procedure described below relates to the orientation and "scaling" of the spherical photomosaics in the space of the DIM, which was necessary for their further individual use. The procedure was necessary because the metadata associated with the panoramas, available together with the relative equirectangular projections on the StreetView Grabber site, are insufficient and, especially, were often shown to be too approximate for the goals of the experimentation. In addition, it should be highlighted that not all panoramas present characteristics that lend them to use, either for their evident lack of quality in the stitching phase or for the different photography conditions (the variable dimensions of street width and building height) that directly affect the quality of the snapshots. Therefore, before beginning the procedure, a filtering phase was necessary to acquire only those panoramas that were suitable for constructing the DIM.
In general, the procedure developed can be considered a particular application of what is used in so-called "photographic straightening", which allows measurements and reliable renderings to be obtained from the straightened photograms, but obviously only for those portions of the object considered to be acceptably described by a principal mid-plane of reference. As already described, this condition recurs often due to the particular characteristics of the urban spaces adopted in the experimentation. The procedure therefore uses the projective relationship between the spherical photomosaic, and the photographed space, more specifically between point C (the centre of the sphere and the photographic centre), the points on the surface of the sphere, and the corresponding points in space.
In general, the assumption that allows the projective principles to be applied to a photographic image derives from the identity relationships between the image and a central projection. When a principal mid-plane of reference can be identified for the photographed object and the photo is taken with the camera axis situated perpendicular to this plane, the photographed object is represented in a central projection, but with the vanishing point of both the vertical and horizontal lines pertaining to the plane of reference (or planes parallel to it) situated at infinity. The relationship between the points of the photographed object pertaining to the principal mid-plane and the related image is therefore a homothetic correspondence typical of perspective realized with the picture plane parallel to the façade. Therefore, in the image, the proportions of the photographed object remain unchanged in the image and as long as a length measured on the object can be identified in the photograph, the relationship of scale is known and constant, obviously relative to the single plane of reference for which the control measures have been determined.
To develop the procedure, the expedient adopted was to first use an auxiliary plane α tangent to the spherical panorama and parallel to the portion of vertical plane β that describes the part of the building unit considered. Next, a horizontal segment lying on the vertical plane β of the building unit is related to the corresponding images on the spherical panorama and the auxiliary plane α. Figure 12. Geometric relationships to use spherical panoramas The first step is to find the only vertical plane α that yields the first condition, as demonstrated below and as illustrated in Figure 12. For this scope, one can use any inclined plane, denoted in Figure 12a by three points ABC, that intersects vertical plane α along line a and vertical plane β along line b. Making plane α rotate rigidly around a vertical axis z, the two lines a and b will be parallel with an improper point of intersection only when plane α is situated parallel to plane β (Figure 12b). Now given a horizontal line segment AB on plane β, the corresponding representation A'B' on vertical plane α is defined by the intersection of the projecting plane ABC that passes through AB and the centre of projection C. The lines passing through AB and A'B' must be parallel (Figure 13a). If plane α is tangent to the spherical panorama, with C as its centre, and if vertical plane β pertains to the front of the building unit, in which AB is, for example, the corner of a window with a known size, the spherical panorama can be used because it is correctly positioned and "scaled" (Figure 13b). Figure 13. Geometric relationships to use spherical panoramas These geometrical/projective considerations were used to derive the algorithms necessary to control the procedure. Since these are variable algorithms, Galapagos was used in Grasshopper.
Going into more detail about the first part of the procedure (Figure 14), the desired condition to establish regards the rotation of plane α around the vertical axis z, which is expressed by varying the angle of rotation, λ (1), until the two lines are parallel. During the rotation, plane α intersects plane ABC producing the corresponding positions of line a (2). Finding the position of line a so that it is parallel to line b requires using the property in which two oriented segments (vectors) are parallel when the scalar product of the vectors is equal to 1. This property was therefore imposed on the two oriented segments pertaining respectively to lines a and b (3). Figure 14. Instructions to the orientation spherical photomosaics With the Galapagos it was possible to manage the values progressively assumed by the variable λ, the angle of rotation of plane α, automatically assessing when the result equals the value established. The iteration activated by Galapagos ends when the scalar product of the vectors of the oriented segments is equal to 1. The program then returns the corresponding value assumed by the angle of rotation λ and the position of vertical plane α tangent to the sphere and parallel to plane β of the building. Likewise, the condition of parallelism was fixed between the horizontal lines passing through AB and A'B'.

CONCLUSION
Although the experimentation presented here is undoubtedly still subject to improvements, it seems to demonstrate the technological possibilities of creating "models" that really correspond to the need for a "growing knowledge" necessarily to correctly manage and enhance the urban built space. In both quality and quantity, this space characterizes a large part of the historical environmental richness of Italy, but also of other countries, especially in Europe. Thanks to partially automated procedures, the use of visual programming tools-that is, closer to the skills of the operators-and the use of data already widely available in particular, this "growing knowledge" can be constructed with reduced economic investment. If adopted preventively, this knowledge would be of great use in managing the urban heritage at particularly critical moments such as after a natural calamity like an earthquake.
In addition to the indispensable procedural improvements of the experimentation presented, one line of research that could be implemented would be to carefully investigate the morphological characteristics of the urban fabrics and the building units, always for this type of small urban centre, in order to identify typical conformations and therefore define greater levels of automation and organization of the information.