savenow / lod3-road-space-models

LOD3 road space models in CityGML+SketchUp of the research project SAVe and SAVeNoW
39 stars 4 forks source link

Incosistency in the CityGML dataset #5

Open OloOcki opened 3 years ago

OloOcki commented 3 years ago

This is a threat concerning inconsistency within the presented CityGML dataset. The threat will be updated periodically.

Albeit great effort to ensure geometrical and semantical consistency in modeling there could be some deviations present within the model. Thus, here is the list of things to be fixed:

Remap geometry:

benediktschwab commented 3 years ago

great @OloOcki! I will try to coordinate this with @Sophie876.

Do we also need to update the creation guidelines regarding the discovered inconsistencies?

OloOcki commented 3 years ago

I guess that it would be nice to have a short list of things that have to be carefully examined. Likes of empty/not empty geometry check, homogeneity check among others. I guess that a list of possible inconsistencies might expand together with the project's expansion.

I recommend to create a FME workspace that will be capable to perform validation of consistency (especially focusing on the geometry but also semantics) and attach it to the repo. The workflow should evolve with the project.

Sophie876 commented 3 years ago

Thank you for the thread @OloOcki! I found the listed things in the model, using FME. Can you clarify what exactly has to be fixed for them? Are they not correctly assigned to the CityGML Group Types?

Is it correct that e.g. "line UUID_6773c2e8-ba0d-4680-897c-26490ea6c1fc_BP.w8OJH2XnTm8nLMOllRO6 outerBuildingInstallation" indicates that this should be assigned to outerBuildingInstallation, which at the moment is not the case? Do you have a hint for how this can be done using the CityEditor Plugin in SketchUp? For the assignment to Group Types I can choose between BuildingInstallation, BuildingPart, Door, IntBuildingInstallation, Room and Window. (For the Opening Boundary Surface Type the options are Ceiling Surface, ClosureSurface, FloorSurface, GroundSurface, InteriorWallSurface, OuterCeilingSurface, OuterFloorSurface, RoofSurface and WallSurface). For "line id201 cityObjectMember" and "line UUID_e9bc7d3f-4abf-40b3-bf55-864517e6b05c cityObjectMember building" I am not sure what is the issue exactly, thank you if you could explain this, too!

OloOcki commented 3 years ago

@Sophie876 for now the aforementioned logs are just to point out where a problem exists without a detailed description. I totally agree that it is rather hard to understand the meaning behind them. Thus, the planned validating tool in a FME workspace should provide more meaningful logs. Thanks for your feedback!

At the very beginning the dataset was created without a geometrical representation in a Building class. Thus, this class should be empty w.r.t. geometry. For example, id201 is an unique ID of a Building and it contains a geometry (line). This is an incosistency in the dataset and stands as a problem for further processing.

The question regarding the _UUID_6773c2e8-ba0d-4680-897c-26490ea6c1fcBP.w8OJH2XnTm8nLMOllRO6 ID means that there are multiple geometries present (lines + surfaces) in the class which is not desired. The geometry should be homogen (in our case only surfaces).