Kml/Collada/glTF Export Display Geometry and Collada why so different ?

[scar95]

I want to put the gml made by Fme into DB and export it to Kml for use on the web. My modeling is so close together that when I export to Collada, the size of the building suddenly grows and overlaps. I tried Gml in the Fme viewer because I wanted the modeling to go wrong in the DB, but there was no problem, and even if I output to Geometry, it sticks together without any problem. Only when outputting to Collada, a situation where the position, angle, etc. do not match will occur.

My Export Option :

Geometry Export result :

Collada Export result :

Why does this result differently? I'm a beginner and I do not understand.

My Model EPSG is 3857.

[Son-HNguyen]

Could you provide us an excerpt of your dataset so we can test it?

[scar95]

우리가 테스트 할 수 있도록 데이터 세트의 발췌 부분을 제공해 주시겠습니까?

A file that reduces the number of buildings. Sample_City.zip

When we look at geometry and collada together, it looks like the image below. The settings for export are printed with different display options.

[Son-HNguyen]

The coordinate reference system EPSG 3857 in your data set could be the problem. According to epsg.io/3857:

Scope: Certain Web mapping and visualisation applications. It is not a recognised geodetic system: for that see ellipsoidal Mercator CRS code 3395 (WGS 84 / World Mercator).

Remarks: Uses spherical development of ellipsoidal coordinates. Relative to WGS 84 / World Mercator (CRS code 3395) errors of 0.7 percent in scale and differences in northing of up to 43km in the map (equivalent to 21km on the ground) may arise.

Although the geometry export was correct (transformation from EPSG 3857 (WGS 84 / Pseudo-Mercator) to KML in WGS 84), the COLLADA export (which uses local coordinates in the transformation) might not give the same results if the given reference system has e.g. a scaling factor error (as seen in the quote above).

In a small test, I changed the CRS from EPSG 3857 to e.g. EPSG 5179 using the Dabase tab in the Importer/Exporter (see picture below).

The resulting geometries and COLLADA objects do not have size inconsistencies anymore, as shown in the picture below.

In short, it really boils down to the reference system you are using.

Hope this helped.

[thomashkolbe]

The issue with the used coordinate reference system (EPSG:3857 or "Pseudo Mercator / Spherical Mercator") is that it has been mainly created for simple and worldwide uniform 2D map visualization. It is normally being used by Google Maps, Bing Maps or other web map application allowing to map the Earth surface onto quadratic tiles which is convenient for storage and rendering.

It is not recommended to use this CRS for analysis or the original storage of 3D models. There is even a warning message from the US national geospatial intelligence agency about usage of this reference system, because it introduces large inaccuracies: http://earth-info.nga.mil/GandG/wgs84/web_mercator/index.html

See also: https://glenbambrick.com/2016/02/03/web-mercator-fallacy/ https://www.esri.com/arcgis-blog/products/arcgis-enterprise/mapping/measuring-distances-and-areas-when-your-map-uses-the-mercator-projection/

[thomashkolbe]

The reason why the 3DCityDB Importer/Exporter tool creates different visualizations for KML on the one side and COLLADA/glTF on the other side is, that for KML the coordinates of each individual polygon point of the buildings are transformed to the combined CRS EPSG:4326 (lat/lon in degree) and EPSG:5773 (height over EGM96 geoid in meters) as used/required by Google Earth. For these coordinate transformations we use the builtin transformation routines from PostGIS or Oracle Spatial respectively.

In order to visualize COLLADA models embedded within KML files in Google Earth (or glTF models in Cesium Webglobe) the 3D models have to be given using a local cartesian and metric coordinate reference system where the origin (0,0,0) lies within or very close to the 3D model. Then in the KML file only the real world coordinates of the origin of the 3D model together with an azimuth (rotation angle around the vertical axis) are provided. In the KML/COLLADA/glTF exporter of 3DCityDB we assume that the dataset is stored using a projected coordinate reference system (like WGS84/UTM or typically some national grid). We then translate each 3D object (e.g. a building) to a local CRS by subtracting the Xmin, Ymin, Zmin values of the bounding volume of the 3D object from each coordinate value. This 3D model is then exported in COLLADA (and/or glTF). Then the lat/lon/height value of the origin (i.e. the Xmin, Ymin, Zmin values of the bounding volume of the 3D object) together with a computed azimuth is written in the KML file. This means that only one coordinate (the origin of the 3D model) is really being transformed using the builtin transformation routines from PostGIS or Oracle Spatial. The coordinate values of the polygon points are taken untransformed (besides the translation near to (0,0,0)). Since the EPSG:3857 reference system introduces large errors, these deviations become visible when comparing the simultaneous visualization of the KML and the COLLADA exports.

[scar95]

Thank you very much. The problem has been fixed! My modeling has a normal size and position.

[Son-HNguyen]

Glad it helped.