GLTF and WGS84 or ECEF about importer-exporter HOT 6 CLOSED

In digging deeper into the spec, I've discovered I was mistaken and that units in meters are required by spec. I assume the requirement is that the X,Y,Z coords are relative to ground, so not ECEF.

https://github.com/KhronosGroup/glTF/blob/master/specification/README.md

I'm wondering if there's an easy way around this, my probably naive thinking is as follows:

1. Import in EPSG:4326 (and tagging it as such in the DB postgis srid)
2. Populate a column of cityobject table with the center (or use the center of the envelope for speed)
3. When an export occurs (to gltf files or through WFS), convert the lat+long+z to meters from pre-calculated center, and write to gltf. Add in the CESIUM_RTC extension and define the center to be the one previously calculated.

Edit: Naive thinking was wrong

from importer-exporter.

Actually, can't populate a column as the RTC would be different depending on tile size and is the center of multiple objects. So modified:

1. Import in EPSG:4326 (and tagging it as such in the DB postgis srid)
2. When an export occurs (to gltf files or through WFS), calculate the center of the tile and add in the CESIUM_RTC extension with that tile center (in degrees). Vertices would then become the x,y,z components of the line connecting the center to the tile to the vertice.

from importer-exporter.

I've asked on https://groups.google.com/forum/#!topic/cesium-dev/t6VgLN5wtVI and was told GLTF supports ECEF coordinates, which would probably satisfy the need of low distortion for placing GLTF models.

I did an import with ECEF coordinates instead of EPSG:4326, it didn't help and the tile was still missing (but the extent was calculated correctly)

Is there something missing/or an assumption in the 3dwebmap client that prevents the use of ECEF coordinates?

Sorry for all the questions, this is unfortunately a major roadblock issue for me

from importer-exporter.

Hi,

the KML/COLLADA/glTF-Exporter has been implemented based on the assumption that the imported CityGML datasets shall use a projected or a 3D compound spatial reference system, because according to the best of our knowledge, none of the existing official CityGML data employed by the cities or mapping agencies worldwide are using the geographic coordinate reference system (e.g., EPSG: 4326). Thus, if you import a CityGML dataset with EPSG:4326 into the 3DCityDB. the KML/COLLADA/glTF-Exporter may sometimes produce unexpected results when exporting KML/COLLADA/glTF models.

Besides, according to the glTF spec, the exported glTF model vertices are defined in a local space which is a 3D cartesian coordinate system. Here, we simply use the KML <Model> element to store the location (lat, lon, alt) and orientation of the reference point in world space for each building object, instead of using the CESIUM_RTC extension. The 3dcitydb-web-map is able to parse the KML<Model> element to retrieve the ECEF coordinates of each building object and place it on the Cesium Virtual GLobe.

So, the only solution that i can see is to use a coordinate transformation tool like FME to convert your CityGML data onto another proper projected SRS (e.g. Gauss–Krüger System), and perform the workflow (3DCityDB-setup ->CityGML-import -> glTF-export ->visualization again.

from importer-exporter.

As of today, a new release of the Importer/Exporter is available. The glTF export has been updated as well, so maybe results are looking better now.

from importer-exporter.

Closing this issue now. Feel free to reopen if you got any news related to WGS84 and glTF.

from importer-exporter.