Hari Ginardi

Ahmad Saikhu

Riyanarto Sarno

Dwi Sunaryono

Ali Sofyan

Ratna Nur

Tiara Shanty

Intelligent Method for Dipstick Urinalysis Using Smartphone Camera

Keywords: color sensing, dipstick urinalysis, color constancy

This paper introduces an intelligent method for helping people to maintain their healthy by doing a self urinalysis utilising a smartphone camera. A color sensing method using a smartphone camera is designed to determine the value of a reagent strip in a urinalysis dipstick. In the dipstick urinalysis, a color change in each reagent strip is examined. This color change is a result of the reaction of dipstick to the chemical contents of urine including pH, Protein, Glucose, Ketones, Leucocyte, Nitrite, Bilirubine, and Urobilinogen. Performing disptick urinalysis can be done in almost any places even on the very remote area where medical laboratory cannot be found, and it is much easier and cheaper than medical lab visit.

The proposed intelligent method includes a framework for color acquisition using a smartphone camera which

covers the color management system, color correction, color matching, and quantification. The usage of RGB and CIELAB color space is discussed in the color management part. An automated color constancy approach is introduced to provide a better color correction, and a step-wise linear interpolation is introduced to better estimate the urinalysis value.

To implement this proposed method, a closed acquisition box does not required. Disptick capturing can be done directly with a smartphone camera in almost any normal lighting condition.

Introduction

Many methods have been applied to reduce or control the blood sugar for diabetes mellitus (DM) patients. A periodic postprandial glucose test and fasting plasma glucose test are among the most commonly practiced. Those require the patient to visit a medical laboratory. The test itself requires a blood sample from patient which is taken using a needle. Besides these blood glucose tests, an examination of the concentration of glucose in patient urine is performed through a method called urinalysis.

Urinalysis has been largely used as a method to determine the presence of chemical composition in urine. Currently, urinalysis can be performed using urine dipstick reagents. It can be done by placing the dipstick into a collected sample of urine and visually comparing the reactive color of each reagent with the dipstick color chart based on their color similarities. This manual interpretation has its limitation, including differences in a perception of color, differences in the lighting condition [START_REF] Peele | Evaluation of Ames Clini-Tek[END_REF] and limitation on categorical or semiquantitative assessment only [START_REF] Penders | Quantitative Evaluation of Urinalysis Test Strips[END_REF].

Dipstick reader is a device used by most laboratories to interpret the dipstick results automatically. This device can minimize errors caused by lighting condition and differences in color perception, significantly [START_REF] Tighe | Laboratory-based quality assurance programme for near-patient urine dipstick testing", 1990-1997: development, management and results[END_REF]. However, its price is expensive for individual treatment. Considering the possibility of most smartphones to capture color image using its digital camera, a smartphone could be an alternative device to interpret urine dipstick results.

Automatic dipstick interpretation using a smartphone camera requires a method for color acquisition and a method of color similarity measurement to determine the corresponding chemical content concentration. Incosistencies may occur in lighting condition, focus, and angle of view [START_REF] Capurso | Mobile Document Capture: Scanner vs. Phone Camera[END_REF]. A color constancy technique is used to approximate the original color of the captured image [START_REF] Bianco | Automatic color constancy algorithm selection and combination[END_REF], [START_REF] Gijsenij | Computational color constancy: Survey and experiments[END_REF]. It enables consistent color acquisition.

In this research, a framework for intelligent dipstick color acquisition using a smartphone is proposed. We analyse the color constancy measurement for image acquisition using a smartphone camera in a daily lighting condition without a closed box, and choose the optimal color constancy method to provide the color correction. An approach for smoother color quantification is done by introducing a stepwise linear interpolation [START_REF] Nur | Interpretation of Urine Dipstick Results Based On Color Similarity Using Linear Interpolation Curve Fitting[END_REF]. It gives a better approximation to determine the reagent score of urine substances with quantitative assessment such as glucose.

2

Related Works

Color Space

A color space is a mathematical model to specify and visualize colors. Several color spaces have been defined namely RGB, CIEXYZ, CIELAB, HSV, and CMYK.

Color perception by human visual is defined by three basic attributes. Those are hue, saturation, and brightness [START_REF] Burns | Dimensional interactions and the structure of psychological space: The representation of hue, saturation, and brightness[END_REF]. Hue defines the differences in specific tone of color; such as red, green blue, or yellow; brightness defines the level of lightness or darkness of a color, while saturation describes the purity of a color.

RGB is a standard color space used by electronic imaging devices such as monitor, camera, and scanner [START_REF] Süsstrunk | Standard RGB Color Spaces[END_REF]. It consists of red, green, and blue components which are represented in a threedimensional cube. Each component has a value ranged from 0 to 255 [START_REF] Pascale | A Review of RGB Color Spaces[END_REF]. RGB does not represent how the human visual interprets colors [START_REF] Cie | Recommendations on uniform color spaces, color difference equations, psychometric color terms[END_REF].

CIELAB is a color space defined by CIE (Comission Internationale de l'Eclairage/International Commission on Illumination) in 1976. It is used in most of digital image processing, because it describes the representation of human visual interprets the color.

Color Constancy

Digital color images which are taken by using a digital camera, is highly dependent on three things, they are illuminants, sensor sensitivity, and reflectance. It is represented by the following Equation 1.

( ) = ( ) ()ρ ()S(x, )d, (1)
where is the captured color, I is illuminant,  is wavelength, is camera sensitivity, and is the ability for reflecting lightness from the object, Assuming the sensitivity  c and the wavelength  in different types of camera are constant, those variables can be neglected, therefore the differences in color acquisition will be highly dependent on the varieties of illumination.

Color constancy is a process to restore an image into a certain illumination value even if it is captured in different illumination conditions [START_REF] Gijsenij | Computational color constancy: Survey and experiments[END_REF]. Color constancy plays significant roles when color recognition or quantification is required in an image acquisition with varieties of illumination such as colorimetric analysis [START_REF] Iqbal | Colorimetric analysis of water and sand samples performed on a mobile phone[END_REF][13] [START_REF] Bianco | Color constancy using faces[END_REF], and it is also applied in dipstick urine analysis.

In general, color constancy process is begun with an evaluation of lighting source color and its intensity to determine the required color correction. The result is an image in which its color is corrected as it was captured with a white source color.

White Patch Retinex is one of the color constancy method based on the amount of illumination. It is done by using white color as a ground truth. This color is used to adjust the level of illumination [START_REF] Gijsenij | Computational color constancy: Survey and experiments[END_REF]. It ignores the differences on reflectance value of the object. Other methods are uniform, non-uniform, and learning method. Uniform method is capable for image enhancement purpose.

Based on its complexity, Gijsenij [START_REF] Gijsenij | Computational color constancy: Survey and experiments[END_REF] divided color constancy algorithms into three methods, namely stastistical method, gamut method, and machine learning. Statistical method has a lower computing complexity, but it is less accurate in correcting image with high variance such as real photos.

Another method, Grey-World, is a uniform [START_REF] Cie | Recommendations on uniform color spaces, color difference equations, psychometric color terms[END_REF] and statistical method. This method failed to correct an image with one dominant color such as leaf color image [START_REF] Cie | Recommendations on uniform color spaces, color difference equations, psychometric color terms[END_REF]. Gerson [START_REF] Gershon | From [R, G, B] to Surface Reflectance: Computing Color Constant Descriptors in Images[END_REF] improves the Grey-World by applying a segmentation first. An illumination correction is performed differently for each segment.

Grey World and White Patch uses low level of RGB values of an image. Van de Weijer, et all [START_REF] Van De Weijer | Edge-based color constancy[END_REF] proposed the usage of high level RGB which is derived from low level RGB Worlds, which is then named Grey Edge algorithm. However, Grey Edge is not optimal for images with one dominant color.

Color Distance Measurement

Color similarity can be done by measuring the distance between points on a geometry space. Several techniques to calculate distances on a geometry space are Euclidean distance, angle vector distance, Canberra distance, and Minkowski. However, Canberra distance and Minkowski distance perform poorly in color similarity for an image retrieval research [START_REF] Androutsos | Distance measures for color image retrieval[END_REF].

Vector angle distance and Euclidean distance are mostly used for measuring color distance. Hue and saturation differences can be quantified well using Vector angle distance. While Euclidean distance quantifies well illumination intensity. Since Euclidean distance has the lower computational complexity, we prefer this technique as a first step to determine the color similarity.

Methodology

Proposed System

Our proposed system is shown in Fig. 1. A test dipstick is captured by using a smartphone camera. Due to the lighting condition and the characteristic of the camera sensor, the color in the produced digital image might be different with the original color of tested dipstick. Therefore, color constancy measurement is needed to approximate its original color and perform an automated color correction. For each image capture, the whole dipstick is captured, containing a series of ten or more reagent color. To separate each reagent color into an individual image file, a cropping process is required. Those reagent color can be organized in a RGB color space or CIELAB color space.

Quantification is done by matching the tested color with its corresponding color chart based on their color similarity and retrieve the related chemical value. For qualitative or semi-quantitative urine analysis, a color similarity approach is adequate, however a further analysis is required for an absolute value determination. Concerning the stepped value in the color chart, a stepwise linear interpolation method is proposed. This interpolation method can estimate a more precise measurement value.

The result from above color quantification is used by the health monitoring system application. A prototype of this application has been built in an Android platform.

Color Constancy

The proper color constancy method is obtained by evaluating the existing methods. Evaluation is done by measuring the distribution of colors on each reagent in a specific color space.

A statistical range of color distribution in a reagent image is chosen to evaluate how the result is spread or fold-up. Range is used rather than variance since it provides a wider result [START_REF] Ebner | Color constancy[END_REF] and it is more sensitive to outlier.

White Patch Color Constancy method is done by getting the maximum value of color from each color component (R, G, and B) as described in Equation 2.

= max (max( ) , max( ) , max( ))

(2)

After obtaining the maximum value, the ratio of each color component is calculated, as described in Equation 3.

= max ( ) , (3)
where C is color of R,G,B color space.

After getting the ratio, the value range of each color component will be widened according to the ratio as described by Equation 4, in order to get the original color.

( ) = × ( ) (4)
As an improvement method from White-Patch, Grey-World [START_REF] Buchsbaum | A spatial processor model for object colour perception[END_REF] has a similar approach. Firstly it calculates statistical mean of each color element. An inversion is required as shown in Equation 5, where C is a color from RGB color space.

( ) = 1 ( ( )) (5)
The following Equation 6shows the calculation of maximum value K from K(C).

= max ( ( ), ( ), ( ))

The result of Kmax is used to find a ratio for scaling factor as given in Equation 7. This Equation is actually an inverse of Equation 3.

= max ( )

Furthermore, as in White-Patch, this ratio value Rc is used in Equation 4. The pattern similarity between White-Patch and Grey-World shows that both methods are equivalent. They are originating from the same equation as shown in Equation 8, where p is equal to 1 for Grey-World and p is equal to ∞ for White-Patch.

( ) = ( ( )) ) (8)

Quantitative Assessment

By its nature, reagents in dipstick urinalysis provides result in a stepped values. Glucose reagent for example, has a specific color for value 0, 2.8, 5.5, 14, 28 and >= 55.

Comparing the color in the tested dipstick to the series of color in the dipstick color chart and finding its similarity will select one of the closest color as the quantification result. This method is used in most dipstick reader device.

To improve the accuracy of dipstick color interpretation, a curve fitting approach is considered. This curve is used to estimate the value if the tested color lies between two reference colors in the color chart as shown in the following Fig. 2.

Stepwise Linear Interpolation

A stepwise linear interpolation is used to estimate the value between two given values. This interpolation is applied for each pair of neighboring color in the color chart. The distance between two colors in the color chart and the distance between a tested color and a color chart is evaluated in a cartesian coordinate system with three-elements of color space are used as the coordinate system. From the previous research [START_REF] Nur | Interpretation of Urine Dipstick Results Based On Color Similarity Using Linear Interpolation Curve Fitting[END_REF], a CIELAB color space is chosen, therefore its color component L, a, b are mapped into a cartesian coordinate system. X, Y axis defines the level of a reagent, and the value of color component, respectively. Assessing the score of the tested reagent is described as follows:

1. Using euclidean distance, calculate the distance between two adjacent reference data, and the distance between a test data and each reference data using Equation 9, as shown in Fig. 3. 3. Check if the distance between test data to node "B" is longer than the distance between node "B" and node "C", OR the distance between test data and node "C" is longer than the distance between node "B" and node "C", this test data is beyond the color chart range. Skip the next step and mark the test data as an error. 4. Calculate the distance of test data to node n-1 and the distance of test data to n+1. Find the shortest one and note the node. 5. If the resulted node is n-1, check whether the distance between test data and node n-1 is smaller than the distance between node n-1 and n. If it is true, denote n-1 as "B" and denote n as "C". 6. If the resulted node is n+1 check whether the distance between test data and node n+1 is smaller than the distance between node n+1 and n. If it is true, denote n+1 as "C" and denote n as "B". 7. If both of two conditions on step 5 and 6 above are not fulfilled, this test data is beyond the color chart range. Skip the next step and mark the test data as an error. 8. As shown in Fig. 4, the relationship between test data, B, and C is evaluated using trigonometry model to project the current test node position into its relative position between node B and C. Equation 6is used for this evaluation model. 9. The tested reagent score can be assessed using Equation 11.

( ) ( ) ( ) , b Δ a Δ L Δ d
= - - -2 (10)
  ScoreofB ScoreofB ScoreofC Bc Bx          (11)

4

Results and Analysis

Color Constancy

As shown in Table II, White Patch technique able to reduce the range of inconsistency up to 63% of red component, 88% of green component, and 59% of blue component.

Color Quantification Result for Glucose Reagent

A glucose estimation is chosen for color interpretation using our approach.

A series of test data and reference data considered as the real color from reagent is prepared in Table III. The reagent score assessment in ten samples is shown in Table IV. We provide quantitative assessment resulted from our approach, assessment by dipstick reader, and interpretation by human visual. The interpretation results produced by dipstick reader and human visual are in categorical values only, therefore the results of quantitative assessment cannot be compared exactly. Furthermore, we provide qualitative assessment to be evaluated.

Outlier data might occur from wrongly captured reagent or out-of-range colors as shown in Table V, and it should be detected. We evaluate the assessment using our approach by comparing with the assessment using Euclidean distance and human visual. The system is able to determine the score of glucose for the first type of real data and recognise the rest as unwanted or outlier colors.

Reagent Score Assessment Using Proposed Approach

In this section, a test data as shown in Table III is used as an example to be measured by the formula resulted from our algorithm. The score is assessed and described by Equation 12 and 13. The trigonometry model is illustrated in Fig. 6. Proportional position determination of the tested data is shown in Fig. 7.

Conclusion

Using the proposed intelligent method for dipstick urinaysis, a self monitoring of blood sugar of diabetes mellitus patient can be done without examining the patient blood. This approach helps people in remote areas which have limited access to the hospital or medical labratory to maintain their health. Evenmore, this approach does not require any physical intervention compare to blood test, makes it painless alternative for blood sugar control. With the highly availability and cheaper dipstick reagent strips, the operational cost of this method is considered cheaper than bood test.

The accuracy of the color quantification using this digital approach is very high makes the automatic color acquisition using smartphone is possible, even in the various lighting conditions.

The further improvement is a challenge to improve the color constancy performance with an automatic color calibration or using a relative calibration technique.

Fig. 1 .

 1 Fig. 1. Process Flow of The Proposed System

Fig. 2 .

 2 Fig. 2. Dipstick Color Interpretation

  ΔL = L test -L ref , Δa = a testa ref, Δb = b test -b ref 2. Find a node n in reference data that has the shortest distance to test data. The value of n represents the location of the selected data. a. If n-1 is equal to 0, then the node is located on the first level. Assign the node number n as node "B" and the node number n+1 as node "C". Go to step 3. b. If n+1 is more than the numbers of reference data, then the node located is on the last level. Assign the node number n as node "C" and the node number n-1 as node "B". Go to step 3. c. Otherwise, this node is between two nodes. Continue to step 4.

Fig. 3 .Fig. 4 .

 34 Fig. 3. Test Data and Reference Data Distances Calculation

Fig. 5 .

 5 Fig. 5. Color Constancy using White Patch

Fig. 6 .

 6 Fig. 6. The Relationship between Test Data, Reference Data 1, and 2.

TABLE II

 II

	.	COLOR CONSTANCY RESULT
	USING WHITE PATCH
			R	G	B
	Original		51	51	49
	Grey World		50	52	53
	White Patch*		19*	6*	20*
	Shades of Grey		51	52	50
	Grey Edge		98	99	39
	Gamut Mapping X-	93	105	46
	Derivation
	Gamut Mapping Y-	86	113	45
	Derivation
	Gamut Mapping 1st	104	111	40
	Order

TABLE V .

 V INTERPRETATION COMPARISON RESULT OF OUTLIER DATA

Acknowledgment

This research is supported by Japan Indonesia Corporation Agency (JICA)-Predicts phase-2, group B2-6 and a research grant from the Ministry of Education and Culture, The Republic of Indonesia


Aida Maleki

Kristina Kiesel
email: kristina.kiesel@tuwien.ac.at

Milena Vuckovic
email: milena.vuckovic@tuwien.ac.at

Ardeshir Mahdavi

Empirical and Computational Issues of Microclimate Simulation

Keywords: Urban climate, Modeling, Evaluation, CFD

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Urban microclimate displays a considerable variance due to the differences in morphology and density of urban spaces and the thermal and radiative properties of surfaces [START_REF] Oke | The energetic basis of the urban heat island[END_REF][START_REF] Arnfeld | Two decades of urban climate research: a review of turbulence, exchanges of energy and water, and the urban heat island[END_REF]. Microclimate conditions are affected by two main parameters: the local weather conditions and the urban fabric at the very location [START_REF] Katzschner | Microclimatic Investigations as Tool for Urban Design[END_REF][START_REF] Kurbjuhn | Impact of different urban structures on the microclimate in the city of Dresden, Germany[END_REF]. Random weather patterns and the wide variances of the urban geometry impose significant limitations regarding purely empirical microclimatic studies such as simple on-site collection of weather data [START_REF] Bourikas | Addressing the Challenge of Interpreting Microclimatic Weather Data Collected from Urban Sites[END_REF]. Hence, detailed numerical models are being increasingly deployed as they can provide additional information toward urban microclimate analyses. The numerical simulation thoroughly deals with the complexities and nonlinearities of the urban climate systems [START_REF] Arnfeld | Two decades of urban climate research: a review of turbulence, exchanges of energy and water, and the urban heat island[END_REF][START_REF] Yao | Simulation of urban microclimates[END_REF].

In this context, the present study addresses the use of numerical tools for the simulation of urban microclimates. As such, an increasing number of differing tools are becoming available for microclimatic modeling of urban areas [START_REF] Mirzaei | Approaches to study Urban Heat Island -Abilities and limitations[END_REF]. Some tools are rather limited in terms of the range of pertinent variables they can consider. Other, more detailed tools display limitations in terms of domain size and resolution. Nonetheless, numerical models still present a valuable resource for the assessment of complex thermal processes in the urban field. For the purposes of the present contribution, we focus on a state of art CFD-based numeric simulation environment (ENVI-met [START_REF] Huttner | Numerical modelling of the urban climate -A preview on ENVI-met 4.0[END_REF]). We describe the general structure of ENVI-met, its features and limitations, and the model calibration process (including the application of sensitivity analysis).

Methodology

Overview of the Deployed Modeling Tool

The tool ENVI-met was selected as it has the capability to simulate the urban microclimate while considering a relatively comprehensive range of factors (complex building shapes, vegetation and different types of pavements, etc.). The high-resolution output generated by this tool includes air, soil and surface temperature, air and soil humidity, wind speed and direction, short wave and long wave radiation fluxes, gas particles and many other important metrological factors. ENVI-met 3.1 was deployed at the early stage of our inquiry. Additional simulations were run in version 4.0 and the results were compared.

General Structure. ENVI-met is a 3-dimensional non-hydrostatic model fit for the simulation of surface-plant-air interactions within urban environments. It is a microscale model with a time step between 1 to 10 seconds and resolution that ranges from 0.5 to 10 m, for the grid length (x) and the width (y). Height of the grids (z) can be more than 10 m. ENVI-met calculates the dynamics of microclimate during a diurnal cycle (24 to 48 hours) using the fundamental laws of fluid dynamics and thermodynamics [START_REF] Elnabawi | Use and evaluation of the ENVI-met model for two different urban forms in Cairo, Egypt: measurements and model simulations[END_REF]. An overview of the data flow within the ENVI-met is given in Figure 1.

Calibration of the Model

The accuracy of the microclimate simulation results is strongly dependent on the quality of the input data, and the initial/boundary conditions. Therefore, appropriate input data should be prepared for the simulation. Ideally, an optimization-supported approach can be used toward an automated model calibration process [START_REF] Taheri | A case study of optimization-aided thermal building performance simulation calibration[END_REF]. However, such an approach faces major computational challenges if applied in the urban simulation domain: Complexity of the climatic simulation models and the highly timeintensive simulation runs make comprehensive optimization-based calibration rather infeasible. Thus, in the present case, calibration relied on a heuristically guided trial and error process based on a small control area (as shown in Figure 3, area bound by the dashed rectangle) in the city of Vienna, Austria. Two stationary weather stations (BPI and C*) are located in the selected area, monitoring the conditions constantly. The BPI weather station is located at the highest point of the Vienna University of Technology, above the urban canopy, without any obstacles blocking the sky -Sky View Factor (SVF) = 1. Therefore, it represents a good model receptor location to evaluate the ability of the software to predict the solar radiation. The second stationary weather station C* is located inside the urban canopy, at the height of 7 m, and records the weather condition continuously. The data obtained from this station was used to evaluate the accuracy of the simulation outputs for the urban canopy.

As it is shown in Figure 3, the input data of the simulation model is composed of two types of data, the weather data and geometry/materials of the area. Since the geometry of the area is not subjected to calibration, the geometrical model was generated with relatively low resolution (the grid size equal to 5×5×2) to accelerate the calibration process.

Fig. 3. The plan of the selected areas for model calibration and application

In order to determine the optimal settings for the initial/boundary conditions, a number of trial runs were conducted. Several combinations of input variable options were probed until an acceptable convergence of the simulated and measured results was achieved.

To evaluate the offset between the modelling results and the values obtained through measurements, three different indicators were defined. First indicator was the index of agreement (d) suggested by (Willmott 1982). Index of agreement is a descriptive measure and can be applied to make Cross-Comparison between models as a relative and bounded measure. Index of agreement (d) is calculated as follows:

2 2 ( ) 1
( )

n i i i n i i i s m d s m - = - ′ ′ - ∑ ∑ 0 1 d ≤ ≤ ( 1
)
where i i s s m ′ = -and i i m m m ′ = -, m
is the mean value of measured variables, m i is the measured variable, and s i the simulated one.

The second used indicator was the Root Mean Square Deviation (RMSD) or Root-Mean Square Error (RMSE), a measure of the differences between outcomes of a model and the associated observed values. RMSE is a good measure to show the accuracy by comparing different prediction errors within a dataset, lower values indicate less error in prediction. It is calculated using the following formula:

( ) 2 1 n i i i m s RMSE n = - = ∑ (2)
And the third indicator was the Coefficient of Variation of the Root Mean Square Deviation CV (RMSE), and is calculated by: ( )

CV RMSE 100 RMSE m   = ×     (3)
These indicators were used in each of the modelled scenarios to obtain the offset between the measured values and the simulation results concerning air temperature and solar radiation for both, aforementioned receptors.

The calibration process proceeded as follows. Slight modifications to the starting model input assumptions for trial runs (Scenario 0 in Table 1) using ENVI-met 3.1 ("none-forcing" mode) resulted in the input data set of Scenario Ia and a better predictive performance. Subsequently, the use of the same input information (Scenario Ib) with the updated ENVI-met 4.0 further improved the results, albeit slightly. Since ENVI-met 4.0 introduced the possibility of user defined diurnal variations of atmospheric boundary conditions (forcing), allowing the creation of user specific weather scenarios, this new feature was tested within the Scenario II (hourly forcing). Again, an improvement was achieved. However, the forcing option with minimum and maximum air temperature values (Scenario III) did not result in improvements. -------- The respective statistics pertaining to the comparison of modelled and measured results are given in tables 2 to 4. Given these results, the input value set of scenario II was selected as the most appropriate one for the intended simulation studies.

Illustrative Use of the Calibrated Simulation Model

The Model. To illustrate the application of the calibrated model, a slightly larger urban domain was selected (see Figure 3, rectangle with continuous boundary). The size of the modelled area was 296 by 296 m, which allowed for the complex building structure to be modelled in higher detail. Two stationary weather stations are located within the boundaries of the study area. First one is BPI and the second one WIS ("Wien, Innere Stadt"), operated by the Central institute for meteorology and geodynamic (ZAMG).

Sensitivity Analysis of the Grid Size. In order to examine the sensitivity of the simulation results with respect to the grid size, three identical models with different grid sizes (3х3x2), (4х4x2), and (5х5x2), were generated. The weather data collected by WIS was used for forcing the diurnal variations of atmospheric boundary conditions. The 3х3x2 model produced erroneous results, thus it was ignored. The models with 4 m and 5 m grid sizes, named 4m-w and 5m-w respectively, were used for further analysis. These models were used to compute temperatures for a day in summer 2011 at two locations corresponding to BPI and WIS weather station locations. Table 5 shows the summary of the statistics pertaining to the comparison of the simulation results with the corresponding measurement results. The difference between the two is not significant, but due to a higher resolution and potential of having more detailed outputs, model with 4 m grid size was selected as the most appropriate for subsequent inquiries.

Fig. 1 .

 1 Fig. 1. The overview over the data flow within the ENVI-met

Fig. 2 .

 2 Fig. 2. The schematic overview of the model layout

Table 1 .

 1 Simulation input data for various model calibration stages (simulations conducted for a location in Vienna, 22 nd of July 2010, wind direction = 163°, relative humidity = 57%)

		Scenarios	0	Ia	Ib	II	III
		ENVI-met Version	3.1	3.1	4	4	4
	Basic Input data	Wind Speed [m.s -1 ] Initial Temperature [K]	0.2 301	2 303	2 303	2 303	2 303
		Solar Adjustment	1	0.82	0.82	0.82	0.82
		Specific Humidity [g/kg air -1 ]	7	8	8	8	8
	Buildings	Albedo Walls Albedo Roofs	0.2 0.2	0.4 0.4	0.4 0.4	0.4 0.4	0.4 0.4
		Max temperature
		[K]
	Simple Forc-
	ing

Table 2 .

 2 d, RMSE, and CV (RMSE) for comparison of simulated temperatures with weather station measurements (BPI)

	Scenarios	0	Ia	Ib	II	III
	d	0.50	0.88	0.92	0.95	0.92
	CV(RMSE) [%]	11.04	7.84	6.32	4.51	11.04
	RMSE [K]	3.15	2.24	1.80	1.29	3.15

Table 5 .

 5 Predictive performance of the calibrated urban microclimate model Future Applications. A process was demonstrated to calibrate a comprehensive urban microclimate simulation tool with the aid of limited measurement data. The calibrated tool displays improved predictive performance and can be used to evaluate the effect of different urban intervention scenarios (e.g. mitigation measures pertaining to the Urban Heat Island phenomena) on the respective temporal and spatial variance of urban microclimate. Such interventions imply certain changes to specific urban features such as areas of vegetation, bodies of water, surface properties of constituent materials in the urban canyon, etc. The outcome of such parametric simulation-based analyses of urban intervention scenarios can provide valuable feedback to the decision makers toward more sustainable urban environment design and maintenance practices.

	Model	grid size	Forced by	RMSE	at BPI CV	d	RMSE	at WIS CV	d
	4m-w	4m	WIS-data	1.54	5.54 0.95	0.88	3.10	0.99
	5m-w	5m	WIS-data	1.59	5.74 0.95	0.78	2.75	0.99


Stefan Glawischnig
email: stefan.glawischnig@tuwien.ac.at

Harald Hofstätter
email: harald.e259.hofstaetter@tuwien.ac.at

Ardeshir Mahdavi
email: ardeshir.mahdavi@tuwien.ac.at

A Distributed Generic Data Structure for Urban Level Building Data Monitoring

Keywords: Urban Monitoring, Generic Data Structure, Distributed Systems

Building a generic data structure that handles building realated data at an urban scale offers certain challenges. Real world entities must be captured in an environment that allows for the communication of relevent data. The associated software components must be maintainable and reliable. The present contribution describes efforts to enhance a well tested building monitoring framework to handle building data at an urban scale. This requires the development of a distributed, generic and enhancable data store, as well as the conceptualization of a modular and scalable application architecture. The scalable data store is introduced, as well as the modularization process of the application logic, including data handling and communication routines. Furthermore, the concept of Virtual Datapoints and Virtual Datapoint Collections enables urban entities (for instance buildings) to communicate their status to the system in an effective way.

Introduction

Urbanization and sustainability strategies (e.g. Europe 2020) raise the need to address ecologic and economic issues on an urban level. A building is not to be recognized as a discrete entity but as part of a dynamic system, that interacts with it's surroundings [START_REF] Mahdavi | From Building Physics to Urban Physics[END_REF]. The urban environment produces massive amounts of data, not all of them related to buildings, but nevertheless influential. For instance, it is common practice to integrate weather forecasts and historical weather data into a building's Energy Management and Control System (EMCS) as well as to utilize it as base data for light and thermal simulation [START_REF] Schuss | The influence of online weather forecast uncertainties on the performance of predictive zone controllers[END_REF] [START_REF] Saipi | Comparison of simulated and actual energy use of a hospital building in austria[END_REF]. Pang et al. introduced a framework to compare the building performance with predictive values of an EnergyPlus simulation in real time [START_REF] Pang | A framework for simulationbased real-time whole building performance assessment[END_REF]. The EMCS transmits data to the simulation via a BACnet interface. The presented approach offers a promising solution for accessing EnergyPlus models in real time, but the resulting data collection is very specific and task oriented.

Previous research by the authors concentrated on the development of a vendor and platform independent building monitoring system [START_REF] Zach | Most: An opensource, vendor and technology independent toolkit for building monitoring, data preprocessing, and visualization[END_REF] [START_REF] Zach | Most -designing a vendor and technology independent toolkit for building monitoring, data preprocessing, and visualization[END_REF]. The motivation was to develop a storage concept that handles building related data in an unified way, regardless of the initial data format or producer. Nevertheless, a majority of research projects focused on various stages of a building's life cycle and considered buildings as singular entities. For instance, the SEMERGY project developed a concept to help remove data-related disincentives and to facilitate the integration of building performance evaluation in building design and retrofit [START_REF] Wolosiuk | Semergy: Performanceguided building design and refurbishment within a semantically augmented optimization environment[END_REF]. On a lower application level, monitoring related projects elaborated a generic data structure that is used in a number of simulation applications and building data representations.

Monitoring System Toolkit

The Monitoring System Toolkit (MOST) was designed to offer platform and vendor independent access to building data and follows a distributed and service oriented approach [START_REF] Zach | Incorporation of run-time simulation-powered virtual sensors in building monitoring systems[END_REF]. It offers the possibility to integrate third party data (EMCS, BMS, etc.) by implementing a connector interface [START_REF] Zach | An open-source, vendor and technology independent toolkit for building monitoring, data preprocessing, and visualization[END_REF]. The toolkit consists of various decoupled services (Fig. 1). A building data service establishes connections between client applications and the system backend. To handle input data sources generically, all data is organized by datapoints and zones. A datapoint is mapped to any data producing entity, for instance a physical sensor, an entire building's accumulated energy demand or a person. Zones define administrative entities that establish location contexts for datapoints. Data might be added to the data store via three methods: a connector implementation, the service layer or a virtual datapoint [START_REF] Zach | Simulation-powered virtual sensors in building monitoring systems[END_REF]. The connector service introduces a vendor independent communication process with common building management systems and building automation technologies. Furthermore, connector implementations enable the integration of historical datasets, for instance weather data that was generated by a CSV export. Beside connectors, the framework's functionality is exposed via two standard industry protocols, OPC Unified Architecture, and Open Building Information Xchange (oBIX). Additionally, a custom REST and RPC implementation offer data access. Entities that access the service layer always read or write one specific datapoint value at a time. The initial data store consists of a relational database (MySQL) that defines entities for datapoints and zones with the respective configurations, as well as an data entity that stores the imported or recorded values. A data tuple has the following form: < tuple id, timestamp, value, datapoint ref >. Data access (read, write) as well as data processing routines (calculating periodic values) are encapsulated in database procedures. To minimize the security risk of SQL injections, database access is restricted to these procedures. To fit different use cases data replication was introduced. The partitions on the master machine were optimized to provide live data access. Two slave machines handeled batch processing jobs and long term, historic data access. The database performance was evaluated by running three testcases that consisted of two scenarios (Tab. 1) Test case #1 evaluated the write performance of the system. Five concurrent connections are established and scenario A and B executed. Test case #2 analyzes the data retrieval performance of scenario A and B by calling various data processing routines. The third test case consists of an iteration of the same read operations as test case #2, as new values are simultaneously added every 50ms. The benchmarking results showed no significant performance bottlenecks. For instance, test case #1 performed a maximum write throughput of 1000 values per second. A thorough documentation of the performance tests can be found at [START_REF] Zach | Improving building monitoring using a data preprocessing storage engine based on mysql[END_REF].

To test the suitability of the application and data store architecture at an urban scale five buildings were concurrently administrated by one framework instance. Physical sensor's recording intervals are specified in seconds and can theoretically be defined as r = [1, 1844674407e + 19] for r ∈ N sec. Practically sensor recording intervals r = [3600, 86000] sec. This corresponds to a range between one hour and an entire day. Currently, the database handles 8.0*10 4 transactional commits, 1.3*10 5 inserts, 7.0*10 5 selects and 5.3*10 5 updates per day. Managing multiple buildings simultaneously revealed performance problems that were not identified by the performance tests. Adding and retrieving data, especially functions that conduct calculations, resulted in severe performance incursions and eventually even crashed the system. Aside the given technical limitations the lack of framework modularization appeared as an conceptual limitation.

Approach

The initial framework implementations were intended for single building use and did not support several buildings or even entire cities. Although it followed a web-based approach with well defined layers, the framework was only deployable as one compound application, entailing problems both in scalability and reliability. To provide an environment that operates at an urban scale and thus allows simultaneous handling of buildings, as well as the establishment of relationships between buildings and building data required the solution the following conceptual problems:

-Optimize and generalize the data store -Modularize the application into standalone components -Establish a data communication process between components

Data Storage

The database was designed to offer a generic data store for one building. Sensor measurements as well as other building related data (for instance user data, sensor configurations, datapoint definitions, etc.) are stored in one central database. Experience showed that up to 90% of the database-induced network traffic was caused by read and write operations on the measurement data table. Resolving this issue was established by these steps:

-Seperating the highly dynamic data entities from the configuration data -Move data processing routines to a higher application layer to allow parallelization at software level As can be seen in Fig. 2 four objects show a highly dynamic behaviour: datapoint, data, zone and warning. A datapoint maps a physical entity, be it a sensor, a person or a calculated aggregation object (e.g. accumulated temperature of a room). A zone administrates datapoints and handles access right management. A zone might refer to a room or a floor. The data table holds all imported and recorded data tuples. If an error occurs (for instance a broken batch process, or a broken sensor) it is written into the warning table.

To store these data generically, multiple relational and non-relational data stores were analyzed regarding their performance, scalability and data model. Following requirements were elaborated to ensure scalability: -Ensure transaction security for sensitive master data (for instance configurations, user information) -Flexible and extensible data model -High read and write performance for the datapoint value data -High read performance for the master data store Due to potential security risks [START_REF] Okman | Security Issues in NoSQL Databases[END_REF] of non-relational stores and the fact that relational databases are well established in productive environments the master data should be kept in a relational environment. Transaction security is not a crucial condition for storing datapoint values. In practice, sensors send a vlaue every minute or even second. In case a measurement gets lost, the effect on an entire day's data is negligible. As to the reduction of transactional checks, NoSQL stores provide better access speeds than relational databases. Bogdan et al. compared various databases and found that NoSQL databases provided better read and write latencies in a write intensive environment than relational databases [START_REF] Tudorica | A comparison between several NoSQL databases with comments and notes[END_REF]. Specifically Cassandra [START_REF]The apache cassandra project[END_REF] is well established in high load environments [START_REF] Han | Survey on NoSQL database[END_REF] and was therefore chosen to be integrated in the framework. Another benefit of NoSQL data stores is the schemaless data model that allows the extension of the database schema at runtime. As mentioned before, collecting building related data at an urban level must be generic, easily extensible and flexible. To store generic data of various data sources, the need to refer to a datapoint was removed from the tuple definition. A generic data tuple is thus defined as < tuple id, timestamp, value >. The context of the measurment is established via a partition or node id and is not stored in the tuple itself. To develop a sustainable scaling strategy, the data store requirements were calculated as followed: To allow real-time data analysis a short recording interval is chosen. It is assumed that one entity contacts the database every second. This results in 3.15*10 7 operations per year. The tuple size is calculated by considering the data type (64-bit IEEE-754 floating point) and the Cassandra specific overhead of 39 bytes per tuple. This results in 1.18 GB data per year for one sensor. Considering the Cassandra specific maximum file size (5 TB) specifies that one file can hold 4237 years of data per sensor. NoSQL stores distribute data randomly accross nodes. To increase read performance, 30-day shards are introduced. One monthly shard can hold 2.6*10 6 measurements.

3 Application Architecture

Highly reliable and scalable Design

A scalable architecture is realized by a distributed system that is based on loosely coupled modules for data processing data retrieval data persistence data access data presentation To reduce the database load that is induced by processing routines [START_REF] Zach | Incorporation of run-time simulation-powered virtual sensors in building monitoring systems[END_REF] the responsible logic was extracted from the database and moved to an indepedent module in a higher application layer. To realize modularity, scalability and to increase reliability on the application level, modules can be deployed redundantly and on different machines. Stateless core components allow new instances to be added during runtime, for instance to serve load peaks (i.e. monitoring occupancy during the morning rush hour) and to be removed in the cooling-down period.

Such a concept implementation requires a central distribution mechanism that routes requests between modules, respective physical machines that are distributed via a city's buildings. As the proposed framework is written in Java, all components are bundled by a Message Oriented Middleware (MOM) that is accessed via a Java Message Service (JMS) API.

The communication process is established by dynamically created queues (point-to-point) and topics (publish-subscribe). On binary protocol level, the Advanced Message Queuing Protocol (AMQP) was chosen, as it is secure, reliable, high performant and vendor-neutral [START_REF] Vinoski | Advanced message queuing protocol[END_REF].

Every single instance of redundantly deployed components listens to the same queue. The transferred request messages are always handled by exactly one instance (the one who initially took the message from the queue). Changes in datapoint values can be observed by subscribing to a datapoint's topic. That specific topic is identified via the owning datapoint's unique name and the prefix "OBSRV ": OBSRV <dp-name>. For instance, the activity observation of the specific sensor "con1" (contact sensor) would be realized via the topic id OBSRV con1.

Virtual Datapoint Collections

Datapoints always represent physical entities (for instance sensors). As has already been mentioned, the concept of virtual datapoints realizes data representations that are not bound to a physical sensor. For instance, this might be the on demand calculation of an entire building's accumulated energy consumption, average temperature or requesting values from a weather forecast. As VDPs work at a very low application level and behave like native datapoints, other application parts can use them transparently. VDPs can be seen as plug-in components and are extensively used to support data simulation, model calibration and data prediction. The implementation of a virtual datapoint is deployed as a distinctive component and is accessed through a dynamically created queue which's name is derived from the VDP's type by prefixing "DATA ": DATA <type>. For instance, a VDP that provides Radiance [START_REF] Radiance | A validated lighting simulation tool[END_REF] simulations could use the queue DATA RADIANCE. VDPs that implement the same type share the same queue which realizes support for multiple instances and hence increases reliability and availability.

VDPs offer a way to establish communication between buildings and components within one application context which is an essential step towards a distributed urban monitoring and simulation structure. However, VDPs can only return a primitive value, for instance the aforementioned overall energy consumption. To decrease configuration effort for buildings we introduce Virtual Datapoint Collections (VDC) that combine a set of VDPs to a bundle. This bundle is configured once and applies standardized calculations on the respective building's data. A VDC uses the same communication process and protocols as described in the VDP concept.

Security

Application access is only granted to registered users. By default, communication between components is entirely encrypted via SSL to prevent eavesdropping of sensitive data. Data access is handled at zonal level but will not be introduced in the scope of this paper.

Results

The application is divided into four layers. As Fig. 3 shows, these are a persistance, service and presentation layer, as well as a service adapter that offers access to the data collection via standardized protocol implementations (OPC Unified Architecture, oBIX, REST). The presentation layer consists of two client applications, a web client and a mobile client. The service layer implements the BMS business logic (data processing) and the VDCs. The persistence layer manages the relational master data store and the NoSQL datapoint value store. To allow a distributed module deployment, all components communicate via the MOM.

Fig. 4 illustrates the specific module implementations of the persistence layer after the revising process. Configuration and security sensitive data is stored in a MySQL database. Sensor configurations are partly kept in BIM models that are managed by a BiMserver instance. The metadata-module handles configuration requests and accesses the two databases. Datapoint values are either stored in the well tested initial MySQL environment, in a Cassandra cluster or a neo4j graph database. Neo4j support was partly introduced to monitor relationships between urban entities, partly to store sensor measurements. The configuration data and datapoint data is merged and connected in the persistence-module. This module also implements the processing functionality that was extracted during the refactoring process.

Conclusion

The present work describes the efforts to scale a generic building monitoring system and the underlying data structure to support a distributed urban data exchange process. This process focuses on two main parts:

building a highly generic data collection that offers an extensible and flexible data model developing a distributed application that offers standardized communication between physically distinct deployed modules

The ideas and concepts presented in this work should be understood as platformindependent and provide a first step towards the realization of an urban data warehouse. The developed hybrid data store that includes both relational and non-relational components will be tested against the well established relational base system in terms of both reliability and performance. This will be realized not only by running extensive database tests, but also by simultaneously deploying both systems in a project environment.

Fig. 1 .

 1 Fig. 1. Monitoring system service structure

Fig. 2 .

 2 Fig. 2. High-traffic producing database entities. Excerpt from the ER diagram.

Fig. 3 .

 3 Fig. 3. The proposed urban monitoring framework's system architecture.

Fig. 4 .

 4 Fig. 4. Persistence layer: specific module implementation.

Table 1 .

 1 Database performance test scenarios

	Test scenario	#Datapoints	#Zones	#Values
	A	10*10 3	2.5*10 3	2.5*10 6
	B	10*10 4	2.5*10 4	>2.5*10 6


Neda Ghiassi
email: neda.ghiassi@tuwien.ac.at

Stefan Glawischnig
email: stefan.glawischnig@tuwien.ac.at

Ulrich Pont
email: ulrich.pont@tuwien.ac.at

Ardeshir Mahdavi
email: amahdavi@tuwien.ac.at

Toward a Data-Driven Performance-Guided Urban Decision-Support Environment

Keywords: GIS, Semantic Web Technologies, Ontologies, Data-Driven, Building Performance, Urban Performance, Urban planning, Sustainability, Information Systems 1

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Building Performance Evaluation (BPE), defined as "the process of obtaining knowledge about building performance and using the feedback to improve buildings" originated in the 1960's [START_REF]BSRIA Topic Guides-Building Performance Evaluation[END_REF]. Ever since, efforts have been directed towards development and refinement of tools and methods to assess and/or predict the performance of buildings in terms of use of natural resources, contribution to undesired environmental phenomena, and user comfort.

Despite the advances in the development of Building Performance Evaluation (BPE) tools over the past decades, the adoption of such tools to support and guide design decisions has been relatively slow and their implementation mostly limited to certification purposes [START_REF] Hensen | Building Performance Simulation for Better Design: Some Issues and Solutions[END_REF][START_REF] Pang | Improving Building Performance at Urban Scale with a Framework for Real-Time Data Sharing[END_REF]. Among stated reasons for the insufficient adoption of such tools for sustainable planning and informed decision making were non-technical, socio-cultural barriers such as lack of financial justification, lack of motivation, or professional skepticism and prejudices [START_REF] Pang | Improving Building Performance at Urban Scale with a Framework for Real-Time Data Sharing[END_REF][START_REF] Alsaadani | The Social Component of Building Performance Simulation-Understanding Architects[END_REF]. Stated technical barriers include the discordance of the available tools with the capabilities and expectations of the design community [START_REF] Attia | State of the Art of Existing Early Design Simulation Tools for Net Zero Energy Buildings: a Comparison of Ten Tools[END_REF] and complexities related to data availability and accessibility, which render the process of data provision for BPE applications cumbersome, error prone and time consuming [START_REF] Mahdavi | Efforts and Effectiveness Considerations in Computational Design Evaluation: a Case Study[END_REF].

The SEMERGY project [START_REF] Mahdavi | SEMERGY: Semantic Web Technology Support for Comprehensive Building Design Assessment[END_REF][START_REF] Mahdavi | Exploring the Utility of Semantic Web Technology in Building Performance Simulation[END_REF], was a recent (2011-2013) research and development effort, intended to address the data-related technical barriers to the integration of performance assessment tools in the building design process. SEMERGY aimed to explore the potential of semantic web technologies to facilitate the process of data accumulation and entry for building performance evaluation and optimization.

Although integration of performance evaluation in the design of new buildings and retrofit projects supports informed decisions and sustainable design, an approach focused on individual buildings may not be singularly sufficient to insure energy efficiency and sustainability of the built environment. Certain performance aspects of the built environment, such as microclimatic conditions (air flows, incident solar radiation) or energy flows are only properly grasped, when buildings are regarded as active agents within a network of interconnected and inter-influential elements, as opposed to independent entities isolated from the context. Such a perspective reveals opportunities and issues, which may have been overlooked, when considering a single building.

On the other hand, the decision to improve the performance of a building depends mainly on the owner, who may be affected by the previously-stated barriers such as lack of motivation or financial means for such an undertaking. As such performance guided decision making has to be endorsed also at a higher level by local/national authorities to support conception of sustainability strategies, efficient allocation of resources and identification of opportunities. Intended as a comprehensive software environment to facilitate performance-guided decision making at various scales, this top-down perspective was also included in the initial description of the SEMERGY project as a future use-case. As such, a second phase of the SEMERGY project has been planned to support performance-enhancing decisions transcending the scale of a single building, through utilization of Semantic Web technologies to harness the potential of the immense pool of web-based urban data.

The present contribution briefly represents the structure and main features of the SEMERGY environment, discusses the particularities of urban scale performance considerations, offers an overview of related previous research, and suggests a framework to upscale the SEMERGY approach towards development of a data-driven performance-guided urban decision support environment.

SEMERGY Structure and Features

As mentioned earlier, the primary objective of the SEMERGY project was to help remove data-related disincentives to integration of BPE in building design process. SEMERGY intended to explore developmental opportunities toward effective evaluation environments for comparative assessment of alternative design and retrofit options [START_REF] Mahdavi | SEMERGY: Semantic Web Technology Support for Comprehensive Building Design Assessment[END_REF], focusing in particular (as proof of concept) on the scattered pool of webbased building product and material data.

The overall structure of SEMERGY is depicted by Figure 1. SEMERGY consists of three main components: The User Interface, which is reponsible for the communication of user intents and initial design to the program, the Reasoning Interface, which includes the relevant performance computation methods and the optimization algorithms, and most importantly, the Semantic Interface which provides links between SEMERGY and web-based data sources to facilitate semi-automatic extraction of appropriate data.

Efficient generation of BPE-compliant models is hampered in part by the missing link between users' simplified component representations (e.g., "external wall", "window") versus the complexity of specifications of real world products. In other words, users are obliged to map such simple notions of building components to appropriate real world products that meet calculation procedures' informational requirements [START_REF] Mahdavi | Exploring the Utility of Semantic Web Technology in Building Performance Simulation[END_REF]. In optimization tasks, the model iteratively assumes alternative sets of properties and is subjected to the evaluation procedures, which lead to the identification of the optimal set of solutions according to the estimated values of functional, ecological, and economical performance indicators.

Fig. 1. SEMERGY structure

The SEMERGY project's approach to bridge the gap between required and available AEC data sets was based on two main pillars: First, creation of a compact and versatile ontology of building products compliant with a shared perception of AEC concepts; Second, mapping of the scattered building product information resources on the web to this ontology [START_REF] Mahdavi | Exploring the Utility of Semantic Web Technology in Building Performance Simulation[END_REF].

To achieve an acceptable building data representation, compatible with the requirements of BPE methods of various resolutions and precisions, and in accordance with the notion of the design community, various building data models were studied and several BPE applications were reversed analyzed. These efforts led to the development of a coherent and sufficient view of building data, known as the SEMERGY Building Model (SBM) [START_REF] Ghiassi | A Comprehensive Building Model for Performance-Guided Decision Support[END_REF]. Further on, an ontology of building products and construction materials was created, which structurally complied with the developed model. This ontology was linked to data sources, which represent building products by their various physical attributes, production data and cost information. The property inheritance structure of the ontology allowed the systematic enrichment of the extracted data with additional properties, which are obvious to human observer (such as stability of shape), yet essential for rule based queries that support the semi-automatic identification of design alternatives, in accordance with user-specified preferences and constraints [START_REF] Ghiassi | Improving the Usability of Energy Simulation Applications in Processing Common Building Performance Inquiries[END_REF][START_REF] Shayeganfar | An Ontology-Aided Optimization Approach to Eco-Efficient Building Design[END_REF][START_REF] Pont | Recent Advances in SEMERGY: a Semantically Enriched Optimization Environment for Performance-Guided Building Design and Refurbishment[END_REF][START_REF] Heurix | Multi-Objective Optimization in the SEMERGY Environment for Sustainable Building Design and Retrofit[END_REF]. The same method can theoretically be applied to other relevant types of web-based data such as building codes, financial subsidies, microclimatic data, building systems, etc. Since these domain ontologies are developed based on a unique perception of a building (SBM) or mapped to it, they can be combined to cater for various types of inter-domain inquiries. For instance, building systems data and building product data can be used in combination to identify the optimal retrofit strategies for a historical building, according to budget limitations expressed by the user.

This approach is expected to encourage the utilization of BPE methods to guide design and retrofit of individual buildings by overcoming certain structural barriers to data accumulation and entry. However, data availability and accuracy issues still hamper the systematic implementation of such a method due to the wide distribution of data sources and lack of standard data formats acknowledged by various data providers.

3

Particularities of Urban Data

Data size

Decision making and development of policies and strategies at an urban scale require dependable, robust, and up-to-date information. A large amount of potentially useful data exists on-line. Much of this data is either partially available or is intended to be made available to the public as part of open data initiatives (e.g., demographics, detailed representations of buildings and their various properties, transportation patterns, energy flows, natural resources, etc.). Analyzing this large source of rather unstructured data with conventional methods may not lead to the discovery of opportunities, detection of systemic problems or leakages of resources.

Data Diversity

City is an ecosystem composed of intertwined and interacting sub-systems, which may be physical or virtual, static or dynamic, predictable or complex, alive or inanimate. Buildings, climate and natural context, transport systems, media, energy production and distribution networks, financial and legal structures, inhabitants, etc. are all various subsystems forming this ecosystem. The entire system's performance is a product of the various chains of events within different sub-systems and the interactions between them. Data pertaining to these various sub-systems is collected and organized by domain specialists from different sectors. The availability of data on various aspects of the city presents an immense potential for conception of interdomain sustainability strategies. Nonetheless, due to this diversity, navigation through the available data -to identify data sources relevant to a certain inquiry -may not be trivial.

Multiple Perceptions, Multiple Representations

Urban data is produced and accumulated by various stakeholders, each perceiving the city from a domain-specific point of view. These varied perceptions are also observed at the scale of single buildings, where involved disciplines are much less divergent than at the urban scale. The fundamental differences in common and standard building representation schemas such as IFC [START_REF]Building Smart[END_REF] and gbXML [15] are rooted in these multiple viewpoints. However, the scale and scope of building related data makes a mapping between these perceptions possible (See, for example, [START_REF] Bazjanac | IFC BIM-Based Methodology for Semi-Automated Building Energy Performance Simulation[END_REF]). At the urban scale, though, the wide range of disciplines and authorities involved in the production and storage of the urban data, results in a large number of parallel perceptions of the urban environment. The available data sources may capture certain aspects of the urban environment and ignore others, view the same physical phenomena from different perspectives, or use different terminologies to express the same concept. A building for instance may be viewed as an active agent from the urban performance point of view, as a mere physical obstruction from the mobility point of view or ignored completely by a botanist.

Analyzing this data to find strategies to overcome various types of problems respond to different inquiries or identify hidden opportunities is hampered not only by the overwhelming size and diversity of the available data, but also by the multiplicity of perceptions and representations, according to which the data is produced.

In order to effectively utilize urban data, it needs to be properly structured and presented in a coherent and interoperable form. The effectiveness and efficiency of Semantic Web technologies to organize and structure web-based building related data has been tested and approved through the SEMERGY experience. However, to upscale this method to the urban level, the above-mentioned particularities of urban data have to be considered.

Data Availability and Currentness

A data-driven approach to decision making, requires substantial data to support implemented analytical methods. Despite the existence of various types of urban data, certain computational methods or optimization tasks may have informational requirements not met by the existing data sources. Furthermore, time is a significant aspect of a large portion of data pertaining to the built environment. Collection of such data occurs in different intervals, resulting in various temporal resolutions. Cer-tain computational methods may require resolutions of data unsupported by the existing data collection structures. Facilitation of collection and storage of urban data in required temporal resolutions is fundamental to any data-driven endeavor.

Related Work

Use of ontologies to capture and structure urban data was discussed in the field of Geographical Information Systems (GIS) by Fonseca and Egenhofer [START_REF] Fonseca | Ontology-Driven Geographic Information Systems[END_REF] in the late 1990's, leading to the suggestion of Ontology-Driven Geographical Information Systems (ODGIS) as means to share urban knowledge and data [START_REF] Fonseca | Ontologies and Knowledge Sharing in Urban GIS[END_REF]. Fonseca and Egenhofer identified "the lack of formal methods to reuse knowledge and data" as a major obstacle hampering the utilization of existing data and knowledge. They support an object-oriented view of the world to represent geographic entities and propose a system-architecture with four main components. These components are data ontologies, the container (domain model), data warehouses and the User Interface. The user selects the desired type of data by browsing the ontologies through the User Interface.

The ontology server provides pointers to relevant data warehouses. The container communicates with the data warehouses commanding the extraction of the desired information while maintaining the ontological hierarchies and structure, serving the data to the end user [START_REF] Fonseca | Ontology-Driven Geographic Information Systems[END_REF]. In a similar attempt, Pundt and Bishr [START_REF] Pundt | Domain Ontologies for Data Sharing-an Example from Environmental Monitoring Using Field GIS[END_REF] demonstrate the effectiveness of ontologies in enhancement of interoperability is a specific information community in the field of GIS. Wiegand and Garcia [START_REF] Wiegand | A Task-Based Ontology Approach to Automate Geospatial Data Retrieval[END_REF], explore the potential of a task-based Semantic Web model to help automate the discovery of web-based data sources, thereby, facilitating the rapid generation of task-appropriate models. They argue that certain tasks such as crisis management activities require the same types of data, regardless of the location of the event. Establishing formal relationships between a type of task and the types of data sources needed for its completion, adds a level of organization to the data, allowing for the rapid retrieval of the desired data, given the intended task and location. In other words, they extend the work of Fonseca and Egenhofer by establishing links between various GIS-related tasks and the types of data stored in different databases, reducing user effort in the development of the model.

Sharing the same perception or committing to the same conceptualization of the object under study is a pre-condition of data sharing and integration. In order to overcome the predicament of parallel perceptions and expressions, in this case of the urban environment concepts, different solutions have been extensively discussed, which are beyond the scope of this paper [START_REF] Bergamaschi | An Intelligent Approach to Information Integration[END_REF][START_REF] Rodriguez | Assessing Semantic Similarities among Geospatial Feature Class Definitions[END_REF][START_REF] Bishr | Overcoming the Semantic and other Barriers to GIS Interoperability[END_REF].

Ongoing research conducted by the authors, concerns communication processes of urban entities (for instance buildings, people, and smart infrastructure). Integrating diverse and distributed data sources establishes the need for a modular and extensible data store design. Experiences in building related data handling [START_REF] Zach | Improving Building Monitoring Using a Data Preprocessing Storage Engine Based on Mysql[END_REF] shows that these requirements are hardly met by common building data collections. To ease the rigid structure of these static data models, other data storage mechanisms are considered (for instance non-relational). By modifying common databases, a generic and scalable data store is developed that can hold any kind of data. Relational concepts cannot provide a solution for this issue.

Proposed Framework

Based on the experience of the SEMERGY project and the above mentioned research activities, the present contribution would suggest a twofold approach to bridge the informational gap between building scale and urban scale performance evaluation requirements. The proposed strategy, on one hand, utilizes ontologies to structure the available urban data repositories with a task-based approach; and on the other hand, addresses the low-level issues of data collection and storage, where the requirements of the task are not met by available data sources.

A globally acknowledged ontology of the urban environment data shared by all involved disciplines and data providers may be an ideal solution to the data accessibility and heterogeneity issues. However, such a solution, given the diversity of the urban data and the variety of domain representations is non-trivial, to say the least. Even if such a comprehensive urban model (encompassing informational requirements and vocabularies of all involved disciplines and sectors) was possible to develop, the complexity of the schema would render its navigation a daunting task.

Definition of a domain, in our case the domain of energy performance of the urban building stock, reduces the scope of the data substantially, however not enough to warrant a manageable degree of complexity. Specifying defined tasks within this domain helps provide a manageable framework for the development of task-based data ontologies, which facilitate automatic creation of task-based models of the desired geographic location or boundary.

Given the multi-disciplinary nature of nearly any urban performance inquiry, such task-based ontologies must not only acquire data pertaining to various fields, but also define a common basis to associate these various data structures with one another to provide data interoperability. The resulting ontology presents a network of Linked Data relevant to the specified task. Different task-ontologies defined in a certain domain include in all likelihood shared data-sources. Given the inter-connected nature of each ontology, such data overlaps establish links between various task-ontologies resulting in the gradual formation of a network of Linked domain Data.

On the other hand, the existing pool of data can be augmented with virtual (calculated) data and/or qualitative information through inclusion of the intermediate or final results of the performance-operation within the task-ontology. This provides a base for exchange of field knowledge through previously formed interoperable (mapable) task-ontologies .

Figure 2 illustrates the proposed ontology structure for two tasks within the same domain. Each task involves two sub-tasks, for accomplishment of which certain data types are required. Each data type is referenced to one (or multiple) datasets belonging to various databases. Based on the geographic location or boundary of the intervention case, the appropriate portion of data from the referenced dataset can be extracted. Different subtasks within a certain task or sub-tasks of different tasks may share data requirements (e.g., sub-task 1.2 and 2.1 both utilize dataset B1). If the compatibility issue of the shared dataset with the general schema of one task ontology is solved (for instance through use of a mediator to translate data to the right format), the interoperability of the translated dataset with the second ontology is simultaneously achieved. This diminishes the need for redevelopment of translation methods and mapping schemas for various applications, which share some informational requirements. If various tasks include similar sub-tasks, the results of that specific sub-task linked to one task-ontology can be directly used in the second task (knowledge sharing), provided that the geographic perimeter of the first task includes that of the second.

Fig. 2. Proposed task ontology structure

The above schema would help reorganize the existing data to surmount the challenge of web-based data navigation for a specific task. However, data availability issues (within the limits of the task at hand) must be solved before the computational procedures can utilize the data. Each building typically maintains its own data store. These stores handle similar data, however it is not possible to integrate the data in a generic structure. In the majority of cases this is not caused by differences in the data typology but simply by differences in the data storage concepts. Generalizing data stores facilitates automated enhancement of data models at runtime, suitable to solve a certain task. In case certain types of data required by the task are not available, the ontology assumes the generic database as the source of data, thereby issuing a request for the collection of the missing data. Collection and storage of unknown urban Big Data can be supported by generic storage concepts. Custom data might be stored in generic databases regardless of the data model. Such databases do not have a fix structure. Rather, the data model is extended at runtime to fit the incoming information. Regarding the importance and size of imports, new nodes might be added on demand.

Requested data types are collected via automated search routines (i.e. web crawl) and made available to the computational procedure through the ontology. Such an approach would support task-based real-time data collection and utilization (Figure 3).

Fig. 3. Collection and provision of required data

In order to explore and demonstrate the potential of the above method to extend the SEMERGY approach to urban scale, the following steps have to be taken.

1. Definition of a task 2. Definition of relative sub-tasks (preferably such that further tasks in the same domain may be supported by the outcomes of these sub-tasks) 3. Identification of required data types 4. Identification of associated existing data-bases and missing data 5. Identification of an ontological representation compliant with the involved datasets and the task in hand (where such a unique structure does not exist, a convenient representation is to be selected in accordance with the data composition and the task nature)

6. Development of methods or mediators to help represent data from non-compatible sources in the above-mentioned vocabulary and structure 7. Integration of the extensible database as a generic container of the missing data in the developed ontology 8. Automatic readjustment of the generic data structure to the required data 9. Collection and storage of the required yet missing data 10. Integration of computational and visual analytics methods to accomplish the desired sub-tasks (and ultimately task), using the developed task ontology 11. Organization of the intermediate and final results under new ontology classes linked to the original data 12. Development of an appropriate interface to support user interaction

Conclusion

Sustainable design and retrofit of the built environment requires software solutions to facilitate integration of performance assessment and optimization in the design process. Such software solutions should cater for interventions at building scale, as well as at larger (neighborhood and urban) scales. SEMERGY is a recent research and development effort, aimed at addressing the data-related barriers to performancebased design by exploring the potential of Semantic Web technologies towards utilization of the abundant, yet ill-structured web-based data. Ongoing work intends to extend and augment SEMERGY so as to transcend building scale performance optimization towards urban scale. Various characteristics of urban data including the overwhelming size, diversity, and multiplicity of perceptions and representations hamper the efficient use of such data in urban performance analysis and optimization tasks. Based on the SEMERGY experience at building scale and previous research on implementation of ontologies (Linked Data concept) for semi-automatic generation of domain models in the field of GIS, a twofold approach was proposed to overcome the data navigation challenge. A task-based approach to creating domain ontologies reduces the scope of the data to a manageable size. Moreover, such an approach provides a strong basis for exchange of previously structured data and knowledge derived from related tasks, within a shared geographical boundary.

Despite the importance of organizing the available yet unstructured data, such a top-down approach is not sufficient. The process of data collection and storage should be supported by generic, efficient, and sizable data structures to tackle the low-level urban data issues. Integration of such databases in the task-based ontology facilitates the task-based automatic retrieval of the missing data for computational purposes.

Once such a data structure is in place, various intervention scenarios can be simulated and optimization techniques may be employed to identify the best course of action in response to objectives pertaining to energy efficiency, environmental performance, and spatial quality of urban domains. Such a data-driven approach could alter conventional problem-solving trends, actively engage stakeholders, accelerate change, and support realization of long term goals.

Acknowledgements

The SEMERGY project (first phase) was funded under the FFG Research Studio Austrian Program (grant No. 832012) by the Austrian Federal Ministry of Economy, Family and Youth (BMWFJ). In addition to the authors, the SEMERGY team includes: A. M. Tjoa, F. Shayeganfar, A. Anjomshoaa, S. Fenz, J. Heurix, T. Neubauer, C. Sustr, M. Taheri, D. Wolosiuk, K. Hammerberg, and A. Wurm.