Triangulation

[rsevero]

I believe the triangulation method to calculate azimuths is working.

As I mentioned before, I implemented it as a on survey creation option and not as a loop closure as it is a setting that should apply to specific surveys only: it actually overwrites the azimuths obtained by the measuring device with the calculated ones.

Please let me know how it looks to you.

[marcocorvi]

i think that triangulation, like trilateration, is of no use in cave surveying.
the basic problem is that one need to work with almost equilateral triangles and measure the sides with high accuracy.
trilateration tries to mitigate these with redundant measurements, provided azimuths are "acceptable". still i do not think it is a solution.
triangulation aims to do surveying without compass, with only tape and clino. it relies heavily on accuracy of data.

i think nobody will ever use either in cave surveying.
trilateration has a narrow binding with the rest of the code, just one call, and can be easyly dropped, by removing that call.
triangulation enters the app more deeply, and it affects the database.

i think this is too invasive.

[rsevero]

Here in Brazil we have iron ore caves. They usually are not big but we need to map them. People usually uses other methods but triangulation would be perfect for these caves. We currently have these already mapped in the thousands. But there are many more. I agree triangulation is invasive but it is doing something very specific only when the user actually chooses that for a survey. It does not affect the code at all when not activated. I really believe it could be a very good feature for these specific cases were compasses aren't usable.

…

-------- Mensagem original -------- Em 22/12/2024 17:35, marco corvi escreveu:

i think that triangulation, like trilateration, is of no use in cave surveying. the basic problem is that one need to work with almost equilateral triangles and measure the sides with high accuracy. trilateration tries to mitigate these with redundant measurements, provided azimuths are "acceptable". still i do not think it is a solution. triangulation aims to do surveying without compass, with only tape and clino. it relies heavily on accuracy of data. i think nobody will ever use either in cave surveying. trilateration has a narrow binding with the rest of the code, just one call, and can be easyly dropped, by removing that call. triangulation enters the app more deeply, and it affects the database. i think this is too invasive. — Reply to this email directly, [view it on GitHub](#134 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AACM6EA5373QGY7NFRKKEP32G4PAXAVCNFSM6AAAAABUB4XIFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJYGU4TAMRSHE). You are receiving this because you authored the thread.Message ID: ***@***.***>

[marcocorvi]

magnetic anomaly compensation has been used for survey in lava cave.
it is easy, and good enough for small caves.

i agree that the piece of code is bypassed if not activated. the same occurs for many other features.
however, changes to the database are not light, because, once published, they stick forever.

in order to be viable triangulation must not have to change the database.
it could require a strict data acquisition protocol like magnetic anomaly policy, but have path to handle the cases when it is not followed.

it should have warning if the equilateral condition is badly broken.

with these triangulation would be another loop compensation, with a well confined interface

• one class

[rsevero]

You are right, there are more auxiliary classes than actually necessary in triangulation.

I started creating than (mirroring existing auxiliary classes) as I was still understanding several parts of TopoDroid than I didn't know well enough and I didn't wan't to eventually mess with something already in use. New classes, only for triangulation, was safe bet in this aspect at the moment.

As they are, more or less, mirror of other auxiliary classes some, if not all of them, can be substituted by the original auxiliary classes already present in TopoDroid. I was planning this move for latter. The first issue was to make triangulation work as expected.

And there are the support interfaces necessary with their classes. The only way to remove those would be to lose necessary functionality.

Another point you raised it that there is the possibility that triangulation won't be much used. That is definitely a possiblity. Even if it were used on all situations were it is a good fit, there are a rather limited amount of situations for it but lets remember that we now know that trilateration has never been used with more than one shot per leg surveys as it was not working at all on this situation. Not until commit f5b2658 at least.

Despite this fact, what troubles me more about trilateration is that it is really fragile in terms of the situations it can actually deal with. It's troubles to deal with quasi rectangular triangles and the increase of situations it simply fails makes it really an experiment. It is not something to be actually used in the field.

But the main issue, as far as I see, are not the amount of classes or the excepted rate of adoption of this code but the fact that triangulation code changes the measured azimuths and rewrites data on tables. I agree that is a behaviour radically different than everything else currently done in TopoDroid. I tried really hard not to do it.

The main reason I spent so much effort to solve the issue solved by commit f5b2658 was that my code had the same problem and I needed it solved, among other reasons, to see if the exported files would carry the corrections made by triangulation (and trilateration).

It doesn't, for trialteration. If we consider loop closures as error corrections that can be reproduced by outside TopoDroid, many times with more data, complete surveys for huge caves instead of "just the survey my team did today" as usually is the case with TopoDroid, not outputing the "corrected" data is fine. In fact, more than fine, it is the correct thing to do.

But for the use case of triangulation, where the measured azimuths are treated as garbage and are trigonometrically calculated, it does not make sense to output the original ones. Just the calculated ones means something usefull.

Triangulation is not an error correction method, it is an alternate method to obtain azimuths.

The data exported by it can (and should) be treated as regular data outside TopoDroid, even pass through traditional loop closure error correction.

As always, the final decision of whether to use this code or not is yours. I just needed to register my thoughts about it. If not for anything else, to help me go forward on other endeavours without the feeling that I lost time for nothing.

Happy Christmas to you Marco. I hope one day we meet in person.

[marcocorvi]

the same computation done in topodroid on the data in the data reduction, can be done by a pc program, and maybe better than in topodroid.

therefore topodroid should export the data as close as possible to how they have been acquired.
clearly there is information reduction in the export.
data reduction is necessary only for 3d formats, like kml, it is a sort of "conversion". however 3d format are mostly for presentation not post processing.

the result of the data reduction is in the exported sketches.

triangulation is ok if it affects only the data reduction and is isolated in a class (maybe inner classes) and a method call like trilateration.
and an additional item in the loop-closure setting.

this pull request can be closed.

[marcocorvi]

i was pondering about triangulation ...
first of all i was wrong: triangulation is not a data reduction. i think it is a station policy.

triangulation is a way to assigns stations to shots and at the same time compute the azimuths.

it works in a very different way than usual, because it assigns stations at a pair of shots (except the first), and user defines a branching point selecting a leg instead of a station.
shots are best taken backwards, the triangles form a staircase, eg
1 0
2 0 + 2 1
3 1 + 3 2
4 2 + 4 3
the next triangle attaches to 4 3:
5 3 + 5 4
...
shots are oriented.
and the "extend" flag is assigned to shot pairs (ie, to triangles)

right shots cannot be selected because they have two attached triangles, left shots can be selected to start a branch. for example selecting 3 1 (when the next station number is 7)
7 1 + 7 3
8 3 + 8 7
...
it could be that the user wanted 1 3 instead of 3 1
and this should be handled.

i have not thought about how the forward policy looks.

with this approach triangulation would need a new stationnameXXX class, and a replacement of the "current station" with "current leg".

several other functions that apply to polyline should be disabled/hidden with triangles.
for example triangulation cannot have splays.

the user works on shot-pairs (which implicitly are triangles) instead of working with legs:
station --> shot
leg --> shot-pair

splays could come back in as single-shot triangles instead of triple-shot triangles.

although data reduction for plan view can proceed as normal (without loop compensation), data reduction for the extended profile cannot be done in as usual: it could work on the dual graph, the polyline that connects the centers of the triangles (shown also in the plan view for the user benefit).

overall, it seems that surveyjng with triangles is quite different from surveying with segments, and requires a rethinking of the workflow, and the functionalities that are needed.

[rsevero]

i was pondering about triangulation ...
first of all i was wrong: triangulation is not a data reduction. i think it is a station policy.

I believe I agree. I say "I believe" because the concept of "data reduction" is still not entirely clear to me. BTW, if you could point me some source where I could read about this concept that treats this subject in the meaning you use I am sure it could be really insightfull to me.

Having said that, I believe it's definetely not a "loop closure" method and it could use a "station policy" dedicated to the way users got to work when using "triangulation".

I see it as a type data aquisition method for the survey. One of the reasons I made it a "survey" option, not a "app" option was exactly to minimize the risk of users having their data messed in some unexpected way.

triangulation is a way to assigns stations to shots and at the same time compute the azimuths.

it works in a very different way than usual, because it assigns stations at a pair of shots (except the first), and user defines a branching > point selecting a leg instead of a station.
shots are best taken backwards, the triangles form a staircase, eg
1 0
2 0 + 2 1
3 1 + 3 2
4 2 + 4 3
the next triangle attaches to 4 3:
5 3 + 5 4
...
shots are oriented.
and the "extend" flag is assigned to shot pairs (ie, to triangles)

As far as a triangulation station policy goes, that looks good but I would like to highlight that if we are talking about the actual algorithm available at the triangulation branch what happens is more flexible: the code looks for the first triangle is can find (looking in order of aquisition).

After that, it identifies new triangles defined by one new station connected to 2 pre-existent stations. The intra triangle order and the direction the shots are created don´t matter.

right shots cannot be selected because they have two attached triangles, left shots can be selected to start a branch. for example selecting > 3 1 (when the next station number is 7)
7 1 + 7 3
8 3 + 8 7
...
it could be that the user wanted 1 3 instead of 3 1
and this should be handled.

Are you talking only about the actual naming of stations or are you also trying to solve the issue of discovering the side the new station should be placed in relation to the "pre-existent" shot: the real or imaginary shot that connects 2 pre-existent stations?

As far as I understood when developing the triangulation code, there is no good way to automatically discover the right side of the new station. The code currently mounts the triangle in a counteclockwise fashion (because the internal angles are calculated in a clockwise order). If that's correct, perfect. If not, the user mirrors the station on the drawing window using the "triangulation mirror" button available at the "edit station" dialog box.

i have not thought about how the forward policy looks.

with this approach triangulation would need a new stationnameXXX class, and a replacement of the "current station" with "current leg".

It looks to me that you are creating a more restrictive process than the one I created. My triangulation code does not need any kind of "current leg" or whatever. It just needs that each new station to be connected to 2 pre-existent stations and that's all of it.

several other functions that apply to polyline should be disabled/hidden with triangles.
for example triangulation cannot have splays.

Yes. I completely agree.

the user works on shot-pairs (which implicitly are triangles) instead of working with legs:
station --> shot
leg --> shot-pair

splays could come back in as single-shot triangles instead of triple-shot triangles.

That would be great.

although data reduction for plan view can proceed as normal (without loop compensation), data reduction for the extended profile cannot be done in as usual: it could work on the dual graph, the polyline that connects the centers of the triangles (shown also in the plan view for the user benefit).

I have not thought about extended profile yet.

overall, it seems that surveyjng with triangles is quite different from surveying with segments, and requires a rethinking of the workflow, and the functionalities that are needed.

Yes. For sure.

I have a team of friends on the field right now surveying several iron ore caves and making some tests with different methods including my triangulation code. If everything goes as planned, they will survey one choosen small cave with 5 different methods:

1. calculating angles with a protractor
2. calculating by hand the magnetic error at each station manually (shot and counter-shot)
3. using TopoDroids "magnetic anomaly" station policy
4. using my triangulation survey option and
5. 3D survey with an iPhone.

I am quite curious to see how they compare one to the other.

[marcocorvi]

the approach i was considering is to replace the polyline (a tree graph if there are no loops) with a planar graph made of triangles.
(if the normal survey has loops the graph may not be planar).
if the normal survey has N stations (vertices in the tree) with N-1 shots,
the triangle survey has N triangles, that is 2*N+1 shots, and N+2 stations.

the important point is that one has a fictional polyline that can be used as in the usual map drafting (as long as real points are shown with this polyline)
the stations of this polyline are usually in the mid-air, but could happen to be inside the rock.
it could be used also in exports for PC programs.

a protractor may not be accurate enough to measure angles.
the "magnetic anomaly" policy is taken from a paper, the author of which i don't remember.
it is exactly like nr. 2.
triangulation will do a good job as long as distances are measured accurately and triangles are close to equilateral.
The problem with these four is that they are affected by "large" errors, and errors sum up, because there is no absolute reference.
i expect iphone to do a good job because it uses also images.

[marcocorvi]

by data reduction i mean the processing of the survey data (legs and splays with stations) to compute a model of the survey line in 3d, ie, stations are points with X-Y-Z coordinates,

from this the 2D projection in the plan view is straightforward.
for the extended profile the model stations must have also an "horizontal" coordinate H (here is where "extend" enters).

basically it is just simple trig.

repeated measurements, foresight-backsight, loop closure compensation, magnetic declination correction, georeferencing, cartographic projection, etc. are additional complication in the data reduction.