The output from WebODM isn’t really good so I tried using
CloudCompare for adjusting it. Problem is that it’s in the projection Sweref99 and the numbers are to big for CloudCompare so it transform it down and keeps global
coordinates.
Problem is that when I trie to reproject it it ends up in the wrong place.
Geo referencing problem
Re: Geo referencing problem
Normally you should accept the 'Global Shift' as suggested by (it's only temporary, and large coordinates are restored at export time). Otherwise you will lose accuracy.
Daniel, CloudCompare admin
Re: Geo referencing problem
Hello,
I am struggling with a geo-reference problem as well; it is different from APOS80's, but maybe someone can help.
I am building my own LAS file writer with geo position baked in the LAS points directly: each point coordinate is set as real world LLA(latitude, longitude, altitude) coordinate.
When I try to display it with Cloud Compare(v2.12Alpha) it is shown as a long line instead of the shape it has to have(as if it is missing precision).
Exporting the LAS to TXT, I correctly get the coordinates that I would expect as LLA coordinates, with a good enough precision(more than 10 decimal places), so I would assume the LAS file is correct, isn't it?
Is there a header, different point type or whatever I should specify in order for CC to correctly display a LAS file like that?
For the record, the way I built this file is, I take an existing LAS(that displays in cloud compare), I read a coordinate as lat, lon, alt as doubles, representing long/lat as degrees and alt in meters, I set this as the offset in the header, so that it would be considered the center of the scene. The scales are set by hand as 1e-11 for long/lat and 1e-6 for the alt (I have tested with the default -7/-2 and other combinations, no change other than precision when exporting back as text or possible loss of points).
As for the coordinates, I calculate the ECEF coord for the center LLA position and I add the input LLA coordinate to ECEF center(since I know the input LAS is scaled so that a unit is one meter in the real world) and convert it back to LLA coordinates for every point.
The laspoint INT coordinate that ends up in the file is calculated as '(LLA point - LLA center) / xyz_scale'.
Any thoughts, hints or links are welcomed.
Thank you.
I am struggling with a geo-reference problem as well; it is different from APOS80's, but maybe someone can help.
I am building my own LAS file writer with geo position baked in the LAS points directly: each point coordinate is set as real world LLA(latitude, longitude, altitude) coordinate.
When I try to display it with Cloud Compare(v2.12Alpha) it is shown as a long line instead of the shape it has to have(as if it is missing precision).
Exporting the LAS to TXT, I correctly get the coordinates that I would expect as LLA coordinates, with a good enough precision(more than 10 decimal places), so I would assume the LAS file is correct, isn't it?
Is there a header, different point type or whatever I should specify in order for CC to correctly display a LAS file like that?
For the record, the way I built this file is, I take an existing LAS(that displays in cloud compare), I read a coordinate as lat, lon, alt as doubles, representing long/lat as degrees and alt in meters, I set this as the offset in the header, so that it would be considered the center of the scene. The scales are set by hand as 1e-11 for long/lat and 1e-6 for the alt (I have tested with the default -7/-2 and other combinations, no change other than precision when exporting back as text or possible loss of points).
As for the coordinates, I calculate the ECEF coord for the center LLA position and I add the input LLA coordinate to ECEF center(since I know the input LAS is scaled so that a unit is one meter in the real world) and convert it back to LLA coordinates for every point.
The laspoint INT coordinate that ends up in the file is calculated as '(LLA point - LLA center) / xyz_scale'.
Any thoughts, hints or links are welcomed.
Thank you.
Re: Geo referencing problem
So once again, CloudCompare can only display 'cartesian' coordinates, where the 3 dimensions are in metric units. Here you have angles for X, Y and metric units for Z. The scales are indeed very different (you could try to rescale the Z coordinate to something much smaller (with Edit > Multiply / Scale). But still, the geometry will be a little weird since X and Y would still be angles.
Daniel, CloudCompare admin