Messages

1

General / Re: Dense Cloud and TLS positional mismatch by 0.5m in PhotoScan

« on: March 31, 2017, 09:27:06 AM »

I got this answer from agisoft support. I'm posting it here in case someone else has a problem with this.
I haven't tried the solution yet though but I'll post back when I know more


Dear Hans,

Thank you for contacting.

We assume that the issue is related to the following:

When you are exporting tiled model to zip format, it is actually saved in Euclidean (orthogonal) coordinate system that is tangential to the ellipsoid. In addition the coordinates of this system origin in WGS84 are stored in doc.kml (KML format only supports WGS84).
But exported point cloud is not in Euclidean coordinate system, as Transverse Mercator projection is not orthogonal, also the projected coordinate system takes into account the meridian convergence. So in your case only one point is transformed correctly - the origin of the tiled model, while in other areas the discrepancy can be observed due to the mentioned reasons.

So there are two ways, as we see it:
either to recalculate the coordinates of every vertex in the tiled model to the TM projection, or to export the dense cloud in local coordinates and adjust it's origin in accordance to the tiled model origin, as in this case the scale and orientation of the coordinate system axis should be the same.

2

General / Dense Cloud and TLS positional mismatch by 0.5m in PhotoScan

« on: March 30, 2017, 12:12:53 PM »

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:

3

General / Re: Export local coordinates, corresponding WGS84?

« on: January 19, 2017, 03:25:20 PM »

Hey Alexey,

Thanks for your quick reply.
I just realized I phrased my question very poorly.

What I wanted to do is to export a mesh using local coordinates, but I want to know what WGS84 coordinate that origo (in local coordinate 0,0,0) on that mesh corresponds too.

The project is geotagged with markers in WGS84 but I need to export it to local coordinates but still have a reference point to the WGS84 coordinate system.

Is there any way to do this?

4

General / Export local coordinates, corresponding WGS84?

« on: January 19, 2017, 12:45:54 PM »

Hi,

Is there any way to find out what coordinate origo (on the exported mesh) corresponds with, in WGS84 (or whichever coordinate system, really), when you export a model or Tiled Model?

Or is there any way to have origo correspond with one of the markers, for which I know the exact coordinates?

Very thankful for any help