26
Copyright © 2012 Op en G eos pati al Consortium
Due to specifics of the Paris data model regarding multiple occurrence of object ids in various CityGML files, the resulting internal representation contains few inconsistencies
for buildings cut at data tile borders see next Subsection, which however could be resolved by extending feature extraction mechanisms to work across input files.
To reduce processing time, we exploited the HPI Future SOC Lab, a high performance computing platform, which provides, e.g., server systems with huge main memory up to
2 TB and multiple CPUs up to 128 logical cores. To reduce IO costs, a 160 GB RAM disk for processing the Paris data was used. Also, the CityGML input files were
processed by 8 threads in parallel. So, it took, e.g., less than 6 hours to import the Paris data set without texture atlases 418 CityGML tiles with JPEG-compressed textures and a
total data size of 12 GB unzipped. The size of the resulting internal data is currently 4.4 GB in total.
8.5.3 Proble ms and solutions
8.5.3.1.1 Granularity of obje ct ids
Assigning object ids to the extracted and processed geometries is required for associating the internal geometries to additional feature data, e.g., feature attributes. However, it is
not fully specified what granularity should be used for assigning such object ids. Therefore, several object ids could be assigned according to different criteria. For
example, they could be assigned for each occurring city object e.g., each sub feature of a Building instance gets assigned an own id, per object class e.g., same id for all Building
objects, or per top level CityObjects e.g., same id for all sub features of a Building instance. Finally, we chose an assignment of object ids per top level city object, because
this fits best to the Paris dataset, which is modeled primarily in CityGML LOD2.
8.5.3.1.2 Te rrain data encode d in CityGML
In earlier implementations of the preprocessor, there was no focus on supporting terrain elevation data included in the CityGML data source; rather a separate data source had
been used for generating a separate digital terrain representation . However, the approach of merging geometry into batches of triangles originally designed for single objects such
as buildings proved to be applicable also to the tiled terrain data. Nevertheless, this tiling leads again to a problem of object id assignment: The data loading and import
mechanisms might need to recognize the Relief data distributed over several files as parts of one special scene object, i.e., one terrain model.
8.5.3.1.2.1 Strict ge ographical tiling of the data se t
The Paris 3D city model was delivered strictly tiled by geographical space: F eature’s
whose geometries overlap tile borders were cut into several parts and distributed over these tiles each stored in a separate file. However, all these feature parts carry the same
gml:id. Currently, this conflicts with the 3D server’s internal data import and object id
assignment mechanism, which assumes that one feature i.e., one gml:id shows up only once during the overall processing of the input data. Hence, these different parts get
assigned different object ids. However, this circumstance does not affect the image rendering and display process; only functionalities that rely on object ids e.g., object
Copyright © 2012 Op en Geos pati al Consortium
27 selection are affected by this fact. While it is perfectly valid in CityGML to have the
same gml:id in several CityGML documents, it could ease the processing of this data if a single feature would be completely included in one document, e.g., by assigning the
whole overlapping feature to a single tile and accepting possibly overlapping bounding boxes of the single tiles. However, the HPI 3D Server
’s import process is planned to be extended to cope with such multiple occurrences of identical gml:ids.
8.6 Importing O pe nStree tMap data into O SM-3D We b 3D Se rvice
