# An Inspection of IFC Models from Practice
## 5 Results
### Georeferencing  
The detailed results of the inspection with respect to georeferencing information is reported in Table 3.  
\begin{table}
\begin{tabular}{c c c c c c c c c c c c} \hline \hline
**Model** & \multicolumn{2}{c}{**LoGeoRef North East**} & \multicolumn{4}{c}{**LoGeo Ref Elev.**} & \multicolumn{4}{c}{**Rotation**} & \multicolumn{2}{c}{**Notes**} \\ \hline  & 0 & 10 & 20 & 30 & 40 & 0 & 20 & 30 & 40 & 0 & 20 & 30 & 40 \\ \hline
1a & \(\mathbf{\times}\) & \(\mathbf{\times}\) & & & x & & & x & & & & \\ \hline  
& & \(\mathbf{\times}\) & & & x & & & x & & \\ \hline \hline \end{tabular}
\end{table}
Table 3: Kind and quality of georeferencing of the inspected models. The numbers refer to the corresponding _LoGeoRef_ (with 0 as not georeferenced or using default values) and the colours refer to the accuracy of georeferencing: red = wrong; orange = approximation as a point in the same Country than the building; yellow = approximation as a point in the same city than the building; green = accurate location of the building in its actual location.  
Figure 3: Used Building Information Modelling pieces of software to design and export the models.  
We can notice that in most cases some georeferencing information was present (only in one case there was no information at all). However, in many cases the georeferencing information was misleading, because it was wrong. In 24 cases out of 57 the information about planar coordinates stored in the higher _LoGeoRef_ available was completely wrong; often probably associated by the software using a default location in the US (close to Boston). In another seven cases, such information was highly approximated, as a random point in the country where the building was supposed to be built, or where it was designed. Since in most of cases those two correspond, it is not possible to say if it was mainly due to the used national version of the software (usually _Rexit_) or to default metadata attached to models based on their planned location. In two models, the approximation arrived at the level  
by designers for energy-related assessments (an approximated latitude is sufficient to perform energy simulations), however it was not sufficient to support integration with further geoinformation.  
The models presenting a sufficient accuracy in the georeferencing information to potentially allow the integration with geoinformation were only nine, out of which five also stored information in lower _LoGeoRefs_ with a lower accuracy (random point in the country or wrong information).  
In any case, it was apparent how there was no rule or best practice, at present, about how the georeferencing information must be stored and what criteria it must follow, and the road towards systematic and reliable georeferencing requires more attention. The _LoGeoRef30_ and higher allowed the storage of Cartesian coordinates and that is why they should be preferred when high accuracy is necessary. However, lower levels could also be useful, depending on use cases.  
Finally, no model used the entities added to version 4 of IFC to store more specific georeferencing information.  
Essential is the kind of storage used to be explicit and to give the user control on it, to produce models where information can actually be found exactly where expected. In fact, different tools using the IFC file would likely refer to specific kind of geoinformation as stored in a specific _LoGeoRef_.  
It should be also noted that not all the disciplinary models belonging to the same federated BIM always had common georeferencing information. This is also what influenced the georeferencing information available in IFC files in a bad way.  
Besides solving the technical issues, the increase of awareness of designers and modellers about the meaning and value of a correct georeferencing will be a critical, but not obvious, step.