Hi,
I'm a developer at a company in Sweden called SkyMap Innovations.
We're developing a solution that requires use of both dense-cloud and TLS (Tiled Model).
However, we've now noticed a big flaw, hopefully it's just a bug. Worst case scenario it's a limitation in precision of your software when calculating TLS coordinates. The issue is that the TLS and the dense-cloud export does not match to the precision that we we are expecting.
As you can see in Fig.1, the dense cloud (in the background) and one of the tile parts (from f-level LOD, most detailed) are roughly half a meter (0.5 units) off.
Some specifications of the data:
The dense cloud is exported in Sweref99TM which is a TM projection. (basically UTM)
The TLS is exported in WGS84, which is an LL projection. (As far as I understand, there is no way to have PhotoScan export the TLS in any other coordinate system, right?)
To accomplish overlapping of WGS84 tile and Sweref99TM dense cloud they obviously need to be transformed into the same coordinate system. As I understand it, the TLS is in a TM projection with metric units in local coordinates with an origo defined in doc.kml in WGS84.
To get the points and TLS in the same TM system, I extract the origo point of the TLS (TLSorigo) from doc.kml (Placemark for model a.dae), translate this point into Sweref99TM and then shift the Sweref99TM points (p) in the dense cloud with negative that value (p = p - TLSorigo).
I'm pretty confident (after multiple days of research, debugging and testing) that this should work and the dense cloud and TLS should be on the exact same positions after doing this process.
I've tried using both proj4 and FME for transforming the WGS84-origo in doc.kml, but they both yield the exact same result.
I've tried every possible thing I can think of, including:
Exporting dense cloud as WGS84 and transforming it with FME, to rule out the possibility that it is the transformation in PhotoScan that is wrong, with similarly faulty results..
Trying different Sweref and WGS84 coordinate definitions in FME and PhotoScan.
Checked that it's not a precision error in the .dae-files in the TLS-zip.
That's made me confident that this is not a floating point precision issue.
So, any ideas why my point cloud and TLS-data does not match?
One of them is incorrectly positioned, and I have a strong feeling that it is the TLS.
It could perhaps also be a very small rotational error btw.
Fig.1:
Fig.2: