# Big Data in Smart City: Management Challenges
## 3 Materials and Methods
### Development of GAMINESS Conceptual Model  
The conceptual model of the GAMINESS management system was defined as an extension of the existing CityGML model. This standard is described in detail through CityGML specifications [46; 56; 57]. The conceptual model consists of two submodels: a geospatial and a sensor submodel. The geospatial submodel has an extension for the interior orientation parameters defined by the IndoorGML standard. The sensor submodel is based on the Dinamizers submodel of CityGML standard, which is extended for IoT and SensorThings standards. The CityGML standard is a common information model for 3D urban objects and provides a comprehensive and detailed representation. The standard is defined as XML format for storing objects based on ISO 19,118 with a possibility to share virtual 3D city models. Proposed extensions defined by the GAMINESS management system are in accordance with the OGC (Geography Markup Language--GML3) and the definition of the CityGML 3.0 conceptual model for storage and exchange of 3D city models presented by [PERSON] et al. [58]. The geometric and the thematic models are described through the defined structure. For the geospatial submodel which represents imlementation of the 3D city structure, general representation is possible using data input regardless of data collection technology (LiDAR, remote sensing, UAV, GNSS, classic geodetic terrestrial methods, etc.). Considering the difference in the classic storage systems, there is a possibility to import point cloud data divided into more files. Consequently, the system locates files in clusters and provides a parallelization process, and this is the concept of the MapReduce paradigm on big data. Data can be recorded in LAS format, polygon file format (PLY), and delimited text layer format (XYZ). This way, the value objective is provided. Figure 3 shows the component model of the system and the main packages.  
The problem of the variability on input is solved in the geospatial submodel. The point cloud data reader transforms and normalizes input data to the geospatial structure through the calculation of the Morton codes. To make this possible, user defined type was created for reading such data. The sensor submodule was based on the Dynamizers model. The created extensions allow standardized reading of data collected by sensors. The GAMINESS management system provides real-time connectivity between sensors and the system. To solve the variability problem, the basic Dynamizers model is extended with the elements of IoT and SensorML standards. Collected data are sent as JSON format, no matter which type of sensor is on the input (automatized total stations, levels, permanent stations, temperature sensors, etc.). GAMINESS is connected to the OpenADMS platform that has standardized connectivity to different types of sensors and trasfer's sensor data as JSON messages. This is how the variety objective is provided.  
[PERSON] et al. [59] benchmarked a number of possible management systems for point clouds and relational data as sensor data in standard relational databases, distributed NoSQL databases, and file-based alternatives. The proposed framework extends the standard MapReduce paradigm for in-memory processing using Hadoop. Therefore, point cloud visualization is commonly known as a point-based rendering. [PERSON] et al. [60] proposed a LiDAR point cloud visualization approach that scales thanks to a pit-of-core approach. Based on these recommendations, the structure of the model is described as a set of data frames which are defined by previously created user defined types and user defined functions. In the next sections, the model is described in regard to conceptual and implementation levels in detail.