Multiple fixes for the same point
I'm sure that this has been covered, but I cannot find it anywhere. I have 3 different gps results for a surface point, all taken with the same gps but on different days, so rather then picking one I just used fix on all 3. However, therion appears to be taking only the last one I enter. This does not seem to be the right behaviour! Is there a way for Therion to take all 3 and 'average' them? thanks in advance Andrew
To average it before (in GPS software) and to add all three as comment? m.s. On Sep 07, 2017, at 02:08 PM, Andrew Atkinson via Therion <therion@speleo.sk> wrote: I'm sure that this has been covered, but I cannot find it anywhere. I have 3 different gps results for a surface point, all taken with the same gps but on different days, so rather then picking one I just used fix on all 3. However, therion appears to be taking only the last one I enter. This does not seem to be the right behaviour! Is there a way for Therion to take all 3 and 'average' them? thanks in advance Andrew _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Yes I could do that, but it does not feel very elegant, and not really the way you should do it, it would be the equivalent of reversing all backwards legs and adding the original as a comment Andrew On 07/09/17 13:46, Martin Sluka via Therion wrote:
To average it before (in GPS software) and to add all three as comment?
m.s.
On Sep 07, 2017, at 02:08 PM, Andrew Atkinson via Therion <therion@speleo.sk> wrote:
I'm sure that this has been covered, but I cannot find it anywhere.
I have 3 different gps results for a surface point, all taken with the same gps but on different days, so rather then picking one I just used fix on all 3.
However, therion appears to be taking only the last one I enter. This does not seem to be the right behaviour! Is there a way for Therion to take all 3 and 'average' them?
thanks in advance
Andrew _______________________________________________ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Way to coerce Therion to to substitute GPS software? m.s. On Sep 07, 2017, at 03:01 PM, Andrew Atkinson via Therion <therion@speleo.sk> wrote: Yes I could do that, but it does not feel very elegant, and not really the way you should do it, it would be the equivalent of reversing all backwards legs and adding the original as a comment Andrew On 07/09/17 13:46, Martin Sluka via Therion wrote: To average it before (in GPS software) and to add all three as comment? m.s. On Sep 07, 2017, at 02:08 PM, Andrew Atkinson via Therion <therion@speleo.sk> wrote: I'm sure that this has been covered, but I cannot find it anywhere. I have 3 different gps results for a surface point, all taken with the same gps but on different days, so rather then picking one I just used fix on all 3. However, therion appears to be taking only the last one I enter. This does not seem to be the right behaviour! Is there a way for Therion to take all 3 and 'average' them? thanks in advance Andrew _______________________________________________ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
On 2017-09-07 13:07 +0100, Andrew Atkinson via Therion wrote:
I'm sure that this has been covered, but I cannot find it anywhere.
I have 3 different gps results for a surface point, all taken with the same gps but on different days, so rather then picking one I just used fix on all 3.
However, therion appears to be taking only the last one I enter. This does not seem to be the right behaviour! Is there a way for Therion to take all 3 and 'average' them?
I've wanted to do this too, but wasn't sure how. From *FIX on https://survex.com/docs/manual/datafile.htm The standard errors default to zero (fix station exactly). cavern will give an error if you attempt to fix the same survey station twice at different coordinates, or a warning if you fix it twice with matching coordinates. You can also specify just one standard error (in which case it is assumed equal in X, Y, and Z) or two (in which case the first is taken as the standard error in X and Y, and the second as the standard error in Z). So I just checked and if you add some variances you can then give more than one set of locations for it without getting errors, and the final location is the average. Alternatively you can give them different names (with variances), then equate them. So survex can do the right thing. Hopefully therion will pass this through so that it works right, but I've not tested that. So this works: *fix pt1 5 5 5 1 1 1 *fix pt1 5 5.5 5 1 1 1 dump3d fixtest.3d: ERROR_INFO #legs 2, len 0.00m, E 0.20 H 0.25 V 0.00 NODE 5.00 5.25 5.00 [pt1] FIXED And so does this: *fix pt1_1 5 5 5 1 1 1 *fix pt1_2 5 5.5 5 1 1 1 *equate pt1_1 pt1_2 dump3d fixtest.3d: ERROR_INFO #legs 2, len 0.00m, E 0.20 H 0.25 V 0.00 NODE 5.00 5.25 5.00 [pt1_1] FIXED NODE 5.00 5.25 5.00 [pt1_2] FIXED Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
On 07/09/17 14:23, Wookey via Therion wrote:
I've wanted to do this too, but wasn't sure how.
From *FIX on https://survex.com/docs/manual/datafile.htm
The standard errors default to zero (fix station exactly). cavern will give an error if you attempt to fix the same survey station twice at different coordinates, or a warning if you fix it twice with matching coordinates.
Hmm therion has an error message from survex 3> /tmp/th5506/data.svx:27: error: Station already fixed or equated to a fixed point 4> *fix 14 57300.000000 52840.000000 240.000000 5> /tmp/th5506/data.svx:28: error: Station already fixed or equated to a fixed point 6> *fix 14 57302.000000 52844.000000 240.000000 but processes it any way
You can also specify just one standard error (in which case it is assumed equal in X, Y, and Z) or two (in which case the first is taken as the standard error in X and Y, and the second as the standard error in Z).
So I just checked and if you add some variances you can then give more than one set of locations for it without getting errors, and the final location is the average.
Alternatively you can give them different names (with variances), then equate them.
So survex can do the right thing. Hopefully therion will pass this through so that it works right, but I've not tested that.
So this works: *fix pt1 5 5 5 1 1 1 *fix pt1 5 5.5 5 1 1 1
dump3d fixtest.3d: ERROR_INFO #legs 2, len 0.00m, E 0.20 H 0.25 V 0.00 NODE 5.00 5.25 5.00 [pt1] FIXED
And so does this: *fix pt1_1 5 5 5 1 1 1 *fix pt1_2 5 5.5 5 1 1 1 *equate pt1_1 pt1_2
dump3d fixtest.3d: ERROR_INFO #legs 2, len 0.00m, E 0.20 H 0.25 V 0.00 NODE 5.00 5.25 5.00 [pt1_1] FIXED NODE 5.00 5.25 5.00 [pt1_2] FIXED
Okay that probably will get round it, but is that the right solution? As this entrance has 3 locations it gets a variance, but most of the other 9 entrances only have one fix. This would mean they are deemed perfectly correct, while the ones with more than one location will be moved by the averaging and the surveys that connects all the entrances together. So in this case I could just go through and give a the variances for all the fixes in the data files (it is only a small set.) However it is part of a very large data set, with something like 200 entrances, that will take me sometime (or a script.) Now one of the answers which I might start to do is always be explicit in the variance, however, is it really reasonable for survex and therefore therion to assume a fix is perfect, we know that they are not. 2 gps locations fixed by survey legs all the error is distributed to the survey legs, does not seem right. So what I'm suggesting is that the default for fix to be perfect should be looked at and maybe amended to almost perfect variance. thanks Andrew
On 2017-09-07 14:46 +0100, Andrew Atkinson via Therion wrote:
On 07/09/17 14:23, Wookey via Therion wrote:
I've wanted to do this too, but wasn't sure how.
Alternatively you can give them different names (with variances), then equate them.
Okay that probably will get round it, but is that the right solution? As this entrance has 3 locations it gets a variance, but most of the other 9 entrances only have one fix. This would mean they are deemed perfectly correct, while the ones with more than one location will be moved by the averaging and the surveys that connects all the entrances together. So in this case I could just go through and give a the variances for all the fixes in the data files (it is only a small set.) However it is part of a very large data set, with something like 200 entrances, that will take me sometime (or a script.) Now one of the answers which I might start to do is always be explicit in the variance, however, is it really reasonable for survex and therefore therion to assume a fix is perfect, we know that they are not.
No. Almost all fixed points really have some sort of variance. Having standard 'GPS' assumptions for GPS points would be helpful. We really should be putting some numbers in for this until Survex/Therion does it for us. Fixed points coming off map benchmarks or laser surveys could have very small variances which might be close enough to zero that leaving them as zero is not too innacurate.
2 gps locations fixed by survey legs all the error is distributed to the survey legs, does not seem right. So what I'm suggesting is that the default for fix to be perfect should be looked at and maybe amended to almost perfect variance.
Agreed, or at least some shorthand for 'type of fix'. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
From Andrews post
Now one of the answers which I might start to do is always be explicit in the variance, however, is it really reasonable for survex and therefore therion to assume a fix is perfect, we know that they are not.
That is the right approach I think Andrew. I have always omitted variance when I want Therion to assume a fix is perfect (knowing of course it is not quite perfect) and included a variance on EVERY fixed point I want therion to adjust in the same way it adjusts survey legs. The variance is analogous to survey grade or sd, and so we tweak each in every survey according to the perceived quality of each component (if we want to, otherwise just ignore it).
gps locations fixed by survey legs all the error is distributed to the survey legs, does not seem right. So what I'm suggesting is that the default for fix to be perfect should be looked at and maybe amended to almost perfect variance.
As above, I think Therion already provides users with straight forward control. Aside from a few quirks and maybe bugs of course. Guidance on typical fixed point variances for common devices and coordinate sources would not go amiss however. Bruce
On 08/09/17 20:47, Bruce Mutton via Therion wrote:
As above, I think Therion already provides users with straight forward control. Aside from a few quirks and maybe bugs of course.
Yep I'm sure this is a quirk, maybe even a bug. The default of no variance means that multiple entrance co-ordinates cannot be entered in the most obvious manor, as currently Therion will only take one of them. There is a way round it, that takes experience, it would be better if the most obvious way of entering it, did what you might assume, which is what I and probably others, especially beginners did/do. thanks Andrew
Survex manual https://survex.com/docs/manual/datafile.htm fix fixes the position of <station> at the given coordinates. … The standard errors default to zero (fix station exactly). Cavern will give an error if you attempt to fix the same survey station twice at different coordinates, or a warning if you fix it twice with matching coordinates. Further reading about fix and cs in the survex manual explains some reasoning and how you can use the implemented behaviour to best effect. Therion manual fix <station> [<x> <y> <z> [<std x> <std y> <std z>]] fix station coordinates (with specified errors—only the units transformation, not calibration, is applied to them). 1. As a beginner, years ago, I took it as self-evident (after reading only the Therion manual) that omitting standard errors was tantamount to the user telling the software, ‘I want you to fix this position with no corrections or adjustments’. I expect this would be the usual assumption, for a non-technical user, and the easiest input arrangement. They should expect an error if they accidentally apply two fixes to the same station. This means all the distortion due to loop closure occurs in survey legs. And it means that a user can be confident that they more or less have control over what the software is doing. 2. The next step is to realise that applying standard errors to fixed stations allows the distortion to be shared between the survey leg network and the fixed stations. That means fixes for positions of your cave with at least two entrances (and at least 2 fixed stations) can self-adjust to what is perhaps some sort of best fit. 3. For users who want to add another level of complication, as I eventually did, the concept of applying multiple coordinates to a single fixed station can be used. Requiring standard errors to be defined explicitly case by case protects newer users from what would usually be unintentional duplication. There are tricks to getting this to work in Therion, as the old forum posts I linked to allude to. (I am not even sure if they are working in my projects, as I have not focused on those areas for a few years – perhaps I should have another look!) My vote is squarely with the status quo (with any bugs that may remain in step 3 repaired, of course). Bruce -----Original Message----- From: Therion [mailto:therion-bounces@speleo.sk] On Behalf Of Andrew Atkinson via Therion On 08/09/17 20:47, Bruce Mutton via Therion wrote:
As above, I think Therion already provides users with straight forward control. Aside from a few quirks and maybe bugs of course.
Yep I'm sure this is a quirk, maybe even a bug. The default of no variance means that multiple entrance co-ordinates cannot be entered in the most obvious manor, as currently Therion will only take one of them. There is a way round it, that takes experience, it would be better if the most obvious way of entering it, did what you might assume, which is what I and probably others, especially beginners did/do. thanks Andrew
Bruce Okay I can see your logic, but I'm not sure I agree. However, the following is a thought dump, which may not be my final position and partly might just be to argue to check your rohbustness, but hope it helps us all in understanding. First Therion throws an warning not an error for a multiple fix with no variance, I think this is a big, taking only one result is not useful or intuitive. Maybe the ultimate answer is Therion to throw an error. (I have lots of warnings so don't always notice a new one) That said, a variance is set to other readings, which can be changed, why treat fix as different. There has never been an exact fix. And yes I can see the arguement for keeping the status quo, but feel there is a strong arguement for changing it to a default no zero variance, as I think most people believe that is what is happening ( yes we should all read the survex manual in more detail, but often we do not.) Now I do think there is an agreement to have whether a variance for read off map or GPS should be set, but maybe some predictive ones a bit like the survey grades is the way to go. Anyway, I doubt anything will happen, explicitly defining variances will solve the problem and the programmers have more important things to work on, but it has been interesting debate and certainly got my head find it Thanks Andrew On 9 Sep 2017 10:35 pm, "Bruce Mutton via Therion" <therion@speleo.sk> wrote:
Survex manual https://survex.com/docs/manual/datafile.htm
*fix* fixes the position of <station> at the given coordinates. … *The standard errors default to zero (fix station exactly).* *Cavern will give an error if you attempt to fix the same survey station twice at different coordinates*, or a warning if you fix it twice with matching coordinates.
Further reading about fix and cs in the survex manual explains some reasoning and how you can use the implemented behaviour to best effect.
Therion manual
*fix* <station> [<x> <y> <z> [<std x> <std y> <std z>]] fix station coordinates (with specified errors—only the units transformation, not calibration, is applied to them).
1. As a beginner, years ago, I took it as self-evident (after reading only the Therion manual) that omitting standard errors was tantamount to the user telling the software, ‘I want you to fix this position with no corrections or adjustments’. I expect this would be the usual assumption, for a non-technical user, and the easiest input arrangement. They should expect an error if they accidentally apply two fixes to the same station. This means all the distortion due to loop closure occurs in survey legs. And it means that a user can be confident that they more or less have control over what the software is doing.
1. The next step is to realise that applying standard errors to fixed stations allows the distortion to be shared between the survey leg network and the fixed stations. That means fixes for positions of your cave with at least two entrances (and at least 2 fixed stations) can self-adjust to what is perhaps some sort of best fit.
1. For users who want to add another level of complication, as I eventually did, the concept of applying multiple coordinates to a single fixed station can be used. Requiring standard errors to be defined explicitly case by case protects newer users from what would usually be unintentional duplication. There are tricks to getting this to work in Therion, as the old forum posts I linked to allude to. (I am not even sure if they are working in my projects, as I have not focused on those areas for a few years – perhaps I should have another look!)
My vote is squarely with the status quo (with any bugs that may remain in step 3 repaired, of course).
Bruce
-----Original Message----- From: Therion [mailto:therion-bounces@speleo.sk] On Behalf Of Andrew Atkinson via Therion On 08/09/17 20:47, Bruce Mutton via Therion wrote:
As above, I think Therion already provides users with straight forward control. Aside from a few quirks and maybe bugs of course.
Yep I'm sure this is a quirk, maybe even a bug. The default of no variance means that multiple entrance co-ordinates cannot be entered in the most obvious manor, as currently Therion will only take one of them.
There is a way round it, that takes experience, it would be better if the most obvious way of entering it, did what you might assume, which is what I and probably others, especially beginners did/do.
thanks
Andrew
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
The option to use "alias names" for fixes instead of directly numbers would be good, this would allow to ship standards with therion and allow the user to to define custom ones, just like in grade definitions. Why not extend the grades definition to allow specification of fix std deviation there? Btw, I would expect therion to not make assumptions on the fix accuracy unless i state it to do so (dont change status quo). Am 2017-09-10 0:54, schrieb Andrew Atkinson via Therion:
Bruce
Okay I can see your logic, but Im not sure I agree. However, the following is a thought dump, which may not be my final position and partly might just be to argue to check your rohbustness, but hope it helps us all in understanding.
First Therion throws an warning not an error for a multiple fix with no variance, I think this is a big, taking only one result is not useful or intuitive. Maybe the ultimate answer is Therion to throw an error. (I have lots of warnings so dont always notice a new one)
That said, a variance is set to other readings, which can be changed, why treat fix as different. There has never been an exact fix. And yes I can see the arguement for keeping the status quo, but feel there is a strong arguement for changing it to a default no zero variance, as I think most people believe that is what is happening ( yes we should all read the survex manual in more detail, but often we do not.) Now I do think there is an agreement to have whether a variance for read off map or GPS should be set, but maybe some predictive ones a bit like the survey grades is the way to go.
Anyway, I doubt anything will happen, explicitly defining variances will solve the problem and the programmers have more important things to work on, but it has been interesting debate and certainly got my head find it
Thanks
Andrew
On 9 Sep 2017 10:35 pm, "Bruce Mutton via Therion" <therion@speleo.sk [5]> wrote:
Survex manual https://survex.com/docs/manual/datafile.htm [1]
FIX fixes the position of <station> at the given coordinates. … THE STANDARD ERRORS DEFAULT TO ZERO (FIX STATION EXACTLY). CAVERN WILL GIVE AN ERROR IF YOU ATTEMPT TO FIX THE SAME SURVEY STATION TWICE AT DIFFERENT COORDINATES, or a warning if you fix it twice with matching coordinates.
Further reading about fix and cs in the survex manual explains some reasoning and how you can use the implemented behaviour to best effect.
Therion manual
FIX <station> [<x> <y> <z> [<std x> <std y> <std z>]] fix station coordinates (with specified errors—only the units transformation, not calibration, is applied to them).
* As a beginner, years ago, I took it as self-evident (after reading only the Therion manual) that omitting standard errors was tantamount to the user telling the software, ‘I want you to fix this position with no corrections or adjustments’. I expect this would be the usual assumption, for a non-technical user, and the easiest input arrangement. They should expect an error if they accidentally apply two fixes to the same station. This means all the distortion due to loop closure occurs in survey legs. And it means that a user can be confident that they more or less have control over what the software is doing.
* The next step is to realise that applying standard errors to fixed stations allows the distortion to be shared between the survey leg network and the fixed stations. That means fixes for positions of your cave with at least two entrances (and at least 2 fixed stations) can self-adjust to what is perhaps some sort of best fit.
* For users who want to add another level of complication, as I eventually did, the concept of applying multiple coordinates to a single fixed station can be used. Requiring standard errors to be defined explicitly case by case protects newer users from what would usually be unintentional duplication. There are tricks to getting this to work in Therion, as the old forum posts I linked to allude to. (I am not even sure if they are working in my projects, as I have not focused on those areas for a few years – perhaps I should have another look!)
My vote is squarely with the status quo (with any bugs that may remain in step 3 repaired, of course).
Bruce
-----Original Message----- From: Therion [mailto:therion-bounces@speleo.sk [2]] On Behalf Of Andrew Atkinson via Therion On 08/09/17 20:47, Bruce Mutton via Therion wrote:
As above, I think Therion already provides users with straight forward control. Aside from a few quirks and maybe bugs of course.
Yep Im sure this is a quirk, maybe even a bug. The default of no variance means that multiple entrance co-ordinates cannot be entered in the most obvious manor, as currently Therion will only take one of them.
There is a way round it, that takes experience, it would be better if the most obvious way of entering it, did what you might assume, which is what I and probably others, especially beginners did/do.
thanks
Andrew
_______________________________________________ Therion mailing list Therion@speleo.sk [3] https://mailman.speleo.sk/listinfo/therion [4]
Links: ------ [1] https://survex.com/docs/manual/datafile.htm [2] mailto:therion-bounces@speleo.sk [3] mailto:Therion@speleo.sk [4] https://mailman.speleo.sk/listinfo/therion [5] mailto:therion@speleo.sk
Benedikt wrote
The option to use "alias names" for fixes instead of directly numbers would be good, this would allow to ship standards with therion and allow the user to to define custom ones, just like in grade definitions.
Not sure I understand correctly what you mean. We can make alias now, using equate. This is what I usually do for gps fixes. In a cave survey 'index data file'... centreline cs lat long fix gpsEntrance01 <lat> <long> <altitude> [<stderr> etc ] fix gpsEntrance02 <lat> <long> <altitude> etc equate gpsEntrance01 53@<survey1> equate gpsEntrance02 1@<survey14> equate gpsEntrance01 AliasNameCreatedByThisStatement endcentreline ie 53@<survey1>, gpsEntrance01 and AliasNameCreatedByThisStatement are all alias' of each other. They all refer to the same physical point. The last name is created by the equate statement, whereas the others all exist prior to the execution of the equate statements. Or were you meaning something different? Bruce
No, i meant the following: currently one has to give std-dev explicitely: fix 1.2a 0.5 0.5 0.5 it would be nice to use instead: fix 1.2a gps where the term "gps" is some predefined accuracy, like in grade definition Am 2017-09-11 10:08, schrieb Bruce Mutton via Therion:
Benedikt wrote
The option to use "alias names" for fixes instead of directly numbers would be good, this would allow to ship standards with therion and allow the user to to define custom ones, just like in grade definitions.
Not sure I understand correctly what you mean.
We can make alias now, using equate. This is what I usually do for gps fixes.
In a cave survey 'index data file'... centreline cs lat long fix gpsEntrance01 <lat> <long> <altitude> [<stderr> etc ] fix gpsEntrance02 <lat> <long> <altitude> etc
equate gpsEntrance01 53@<survey1> equate gpsEntrance02 1@<survey14> equate gpsEntrance01 AliasNameCreatedByThisStatement endcentreline
ie 53@<survey1>, gpsEntrance01 and AliasNameCreatedByThisStatement are all alias' of each other. They all refer to the same physical point. The last name is created by the equate statement, whereas the others all exist prior to the execution of the equate statements.
Or were you meaning something different?
Bruce
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
One of the problem for a predefined accuracy of gps measures is that it really depends on each measurement. I usually use a stddev of 2 to 3 times the figure of merit (FOM) of the GPS averaging procedure for x and y coordinates and 4 to 5 times for the altitude. This can range from a few meters (this has to be on a plateau with no trees) to 50/100 m for measurements in forests with a few satellites only (there are also often reflections on cliffs that perturb the measure). Xavier Le 11-Sep-17 à 19:10, Benedikt Hallinger via Therion a écrit :
No, i meant the following:
currently one has to give std-dev explicitely: fix 1.2a 0.5 0.5 0.5
it would be nice to use instead: fix 1.2a gps where the term "gps" is some predefined accuracy, like in grade definition
Am 2017-09-11 10:08, schrieb Bruce Mutton via Therion:
Benedikt wrote
The option to use "alias names" for fixes instead of directly numbers would be good, this would allow to ship standards with therion and allow the user to to define custom ones, just like in grade definitions.
Not sure I understand correctly what you mean.
We can make alias now, using equate. This is what I usually do for gps fixes.
In a cave survey 'index data file'... centreline cs lat long fix gpsEntrance01 <lat> <long> <altitude> [<stderr> etc ] fix gpsEntrance02 <lat> <long> <altitude> etc
equate gpsEntrance01 53@<survey1> equate gpsEntrance02 1@<survey14> equate gpsEntrance01 AliasNameCreatedByThisStatement endcentreline
ie 53@<survey1>, gpsEntrance01 and AliasNameCreatedByThisStatement are all alias' of each other. They all refer to the same physical point. The last name is created by the equate statement, whereas the others all exist prior to the execution of the equate statements.
Or were you meaning something different?
Bruce
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
--
------------------------- Xavier Pennec Senior Research Scientist / Directeur de recherche Asclepios project-team, INRIA Sophia-Antipolis 2004 Route des Lucioles, BP93 F-06902 Sophia-Antipolis Cedex, France +33 4 92 38 76 64 +33 6 78 35 16 90 http://www-sop.inria.fr/asclepios/ -------------------------------
There is an application for Android Mobile Topographer (Pro). In Pro version it is 15 EUR? It has many very interesting features to measure and use GPS including calibration on known point etc. There is only one problem with this application. It has no automatic backup of measured data. So only way around is export data to an available format and save it manually. Topographer crashed on my Android tablet and I loose all my GPS points. On other hand the uninstallation and new installation was without any problem. Just to backup a folder with exports before. m.s.
11. 9. 2017 v 20:53, Xavier Pennec via Therion <therion@speleo.sk>:
One of the problem for a predefined accuracy of gps measures is that it really depends on each measurement. I usually use a stddev of 2 to 3 times the figure of merit (FOM) of the GPS averaging procedure for x and y coordinates and 4 to 5 times for the altitude. This can range from a few meters (this has to be on a plateau with no trees) to 50/100 m for measurements in forests with a few satellites only (there are also often reflections on cliffs that perturb the measure).
Xavier
Le 11-Sep-17 à 19:10, Benedikt Hallinger via Therion a écrit :
No, i meant the following:
currently one has to give std-dev explicitely: fix 1.2a 0.5 0.5 0.5
it would be nice to use instead: fix 1.2a gps where the term "gps" is some predefined accuracy, like in grade definition
Am 2017-09-11 10:08, schrieb Bruce Mutton via Therion:
Benedikt wrote
The option to use "alias names" for fixes instead of directly numbers would be good, this would allow to ship standards with therion and allow the user to to define custom ones, just like in grade definitions.
Not sure I understand correctly what you mean.
We can make alias now, using equate. This is what I usually do for gps fixes.
In a cave survey 'index data file'... centreline cs lat long fix gpsEntrance01 <lat> <long> <altitude> [<stderr> etc ] fix gpsEntrance02 <lat> <long> <altitude> etc
equate gpsEntrance01 53@<survey1> equate gpsEntrance02 1@<survey14> equate gpsEntrance01 AliasNameCreatedByThisStatement endcentreline
ie 53@<survey1>, gpsEntrance01 and AliasNameCreatedByThisStatement are all alias' of each other. They all refer to the same physical point. The last name is created by the equate statement, whereas the others all exist prior to the execution of the equate statements.
Or were you meaning something different?
Bruce
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
--
------------------------- Xavier Pennec Senior Research Scientist / Directeur de recherche Asclepios project-team, INRIA Sophia-Antipolis 2004 Route des Lucioles, BP93 F-06902 Sophia-Antipolis Cedex, France +33 4 92 38 76 64 +33 6 78 35 16 90 http://www-sop.inria.fr/asclepios/ -------------------------------
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
The problem, is that you cannot do a calibration fo a GPS since it will depend on the satellite constellation which change all day long even if you don’t move. So calibration of a GPS is a no no! If you use accurate GPS measurements, either baseline measurement, of PPP post processing (but you need a GPS slightly more expensive that the regular handheld ;-) ) you can have an accuracy of a few millimetres. So the std-dev should always be given explicitly for GPS. Phil
On 11 Sep 2017, at 21:24 PM, Martin Sluka via Therion <therion@speleo.sk> wrote:
There is an application for Android Mobile Topographer (Pro). In Pro version it is 15 EUR?
It has many very interesting features to measure and use GPS including calibration on known point etc.
There is only one problem with this application. It has no automatic backup of measured data. So only way around is export data to an available format and save it manually. Topographer crashed on my Android tablet and I loose all my GPS points. On other hand the uninstallation and new installation was without any problem. Just to backup a folder with exports before.
m.s.
11. 9. 2017 v 20:53, Xavier Pennec via Therion <therion@speleo.sk>:
One of the problem for a predefined accuracy of gps measures is that it really depends on each measurement. I usually use a stddev of 2 to 3 times the figure of merit (FOM) of the GPS averaging procedure for x and y coordinates and 4 to 5 times for the altitude. This can range from a few meters (this has to be on a plateau with no trees) to 50/100 m for measurements in forests with a few satellites only (there are also often reflections on cliffs that perturb the measure).
Xavier
Le 11-Sep-17 à 19:10, Benedikt Hallinger via Therion a écrit :
No, i meant the following:
currently one has to give std-dev explicitely: fix 1.2a 0.5 0.5 0.5
it would be nice to use instead: fix 1.2a gps where the term "gps" is some predefined accuracy, like in grade definition
Am 2017-09-11 10:08, schrieb Bruce Mutton via Therion:
Benedikt wrote
The option to use "alias names" for fixes instead of directly numbers would be good, this would allow to ship standards with therion and allow the user to to define custom ones, just like in grade definitions.
Not sure I understand correctly what you mean.
We can make alias now, using equate. This is what I usually do for gps fixes.
In a cave survey 'index data file'... centreline cs lat long fix gpsEntrance01 <lat> <long> <altitude> [<stderr> etc ] fix gpsEntrance02 <lat> <long> <altitude> etc
equate gpsEntrance01 53@<survey1> equate gpsEntrance02 1@<survey14> equate gpsEntrance01 AliasNameCreatedByThisStatement endcentreline
ie 53@<survey1>, gpsEntrance01 and AliasNameCreatedByThisStatement are all alias' of each other. They all refer to the same physical point. The last name is created by the equate statement, whereas the others all exist prior to the execution of the equate statements.
Or were you meaning something different?
Bruce
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
--
------------------------- Xavier Pennec Senior Research Scientist / Directeur de recherche Asclepios project-team, INRIA Sophia-Antipolis 2004 Route des Lucioles, BP93 F-06902 Sophia-Antipolis Cedex, France +33 4 92 38 76 64 +33 6 78 35 16 90 http://www-sop.inria.fr/asclepios/ -------------------------------
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Check that application features and check it in real situations. You’ll be surprised, I’m sure. m.s.
12. 9. 2017 v 8:28, Philippe Vernant via Therion <therion@speleo.sk>:
The problem, is that you cannot do a calibration fo a GPS since it will depend on the satellite constellation which change all day long even if you don’t move. So calibration of a GPS is a no no! If you use accurate GPS measurements, either baseline measurement, of PPP post processing (but you need a GPS slightly more expensive that the regular handheld ;-) ) you can have an accuracy of a few millimetres. So the std-dev should always be given explicitly for GPS.
I will, but I’m using GPS everyday for my job, and I wouldn’t rely to much on a calibration of a handheld device, except if the calibration is in fact some kind of baseline processing on the code signal with data from a broadcasted nearby continuous station. Phil
On 12 Sep 2017, at 9:34 AM, Martin Sluka via Therion <therion@speleo.sk> wrote:
Check that application features and check it in real situations. You’ll be surprised, I’m sure.
m.s.
12. 9. 2017 v 8:28, Philippe Vernant via Therion <therion@speleo.sk>:
The problem, is that you cannot do a calibration fo a GPS since it will depend on the satellite constellation which change all day long even if you don’t move. So calibration of a GPS is a no no! If you use accurate GPS measurements, either baseline measurement, of PPP post processing (but you need a GPS slightly more expensive that the regular handheld ;-) ) you can have an accuracy of a few millimetres. So the std-dev should always be given explicitly for GPS.
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
OK, you are professional. But for normal users it is better solution than only pure GPS in smart mobile, I think. We compared it in forest with pro GPS and differences were not too big (in metres only) Maybe if you'll test it and write here your opinion it could be useful. Martin On Sep 12, 2017, at 11:00 AM, Philippe Vernant via Therion <therion@speleo.sk> wrote: I will, but I’m using GPS everyday for my job, and I wouldn’t rely to much on a calibration of a handheld device, except if the calibration is in fact some kind of baseline processing on the code signal with data from a broadcasted nearby continuous station. Phil On 12 Sep 2017, at 9:34 AM, Martin Sluka via Therion <therion@speleo.sk> wrote: Check that application features and check it in real situations. You’ll be surprised, I’m sure. m.s. 12. 9. 2017 v 8:28, Philippe Vernant via Therion <therion@speleo.sk>: The problem, is that you cannot do a calibration fo a GPS since it will depend on the satellite constellation which change all day long even if you don’t move. So calibration of a GPS is a no no! If you use accurate GPS measurements, either baseline measurement, of PPP post processing (but you need a GPS slightly more expensive that the regular handheld ;-) ) you can have an accuracy of a few millimetres. So the std-dev should always be given explicitly for GPS. _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Andrew I have been doing this for years, and pretty sure it is working fine, no errors or warnings flagged by Therion at least. Although I have not checked that the weighted averaging of the positions appears to be working correctly for about 5 years now, so there is a possibility it has got broken in the meantime. However nothing gross is happening or I would have noticed. There were some issues and work arounds that were discussed on the forum. https://www.mail-archive.com/therion@speleo.sk/msg03747.html Olly on Survex Jan 2012 https://www.mail-archive.com/therion@speleo.sk/msg03750.html Describing the characteristics https://www.mail-archive.com/therion@speleo.sk/msg03751.html Stacho looking into it https://www.mail-archive.com/therion@speleo.sk/msg04327.html Xaviers solution Dec 2013 I vaguely recall that the multiple fixes did start turning up in loop reporting, as Satcho described, but I'm not sure about that - could be imagination. I think it is appropriate functionality for Therion. Over time many position fixes on a station, usually in different surveys, all with their own std errors. Therion as far as I know handles these just fine, averaging appropriately. If it does not, then something is broken. At least two datasets where I do this are still in active use, if I get time I will make sure all is still well. I think it is a topic that deserves a wiki FAQ or Tips and Tricks entry Bruce -----Original Message----- From: Therion [mailto:therion-bounces@speleo.sk] On Behalf Of Andrew Atkinson via Therion Sent: Friday, 8 September 2017 12:08 AM To: List for Therion users <therion@speleo.sk> Cc: Andrew Atkinson <andrew@wotcc.org.uk> Subject: [Therion] Multiple fixes for the same point I'm sure that this has been covered, but I cannot find it anywhere. I have 3 different gps results for a surface point, all taken with the same gps but on different days, so rather then picking one I just used fix on all 3. However, therion appears to be taking only the last one I enter. This does not seem to be the right behaviour! Is there a way for Therion to take all 3 and 'average' them? thanks in advance Andrew _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Hi Bruce, Good that you found my previous post. I knew I wrote something on it but I could not remember when. I also remenber that the therion loop closure algorithm was inducing (sometimes) very large errors while the survex loop closure was working perfectly. I am not sure that it was for this case, but I am personnaly taking care of installing survex for loop closure: the last experience I had without survex installed last November was still showing the problem (coordinates too large to be able to produce the pdf). Xavier Le 07-Sep-17 à 21:42, Bruce Mutton via Therion a écrit :
Andrew I have been doing this for years, and pretty sure it is working fine, no errors or warnings flagged by Therion at least. Although I have not checked that the weighted averaging of the positions appears to be working correctly for about 5 years now, so there is a possibility it has got broken in the meantime. However nothing gross is happening or I would have noticed. There were some issues and work arounds that were discussed on the forum. https://www.mail-archive.com/therion@speleo.sk/msg03747.html Olly on Survex Jan 2012 https://www.mail-archive.com/therion@speleo.sk/msg03750.html Describing the characteristics https://www.mail-archive.com/therion@speleo.sk/msg03751.html Stacho looking into it https://www.mail-archive.com/therion@speleo.sk/msg04327.html Xaviers solution Dec 2013
I vaguely recall that the multiple fixes did start turning up in loop reporting, as Satcho described, but I'm not sure about that - could be imagination.
I think it is appropriate functionality for Therion. Over time many position fixes on a station, usually in different surveys, all with their own std errors. Therion as far as I know handles these just fine, averaging appropriately. If it does not, then something is broken.
At least two datasets where I do this are still in active use, if I get time I will make sure all is still well.
I think it is a topic that deserves a wiki FAQ or Tips and Tricks entry
Bruce
-----Original Message----- From: Therion [mailto:therion-bounces@speleo.sk] On Behalf Of Andrew Atkinson via Therion Sent: Friday, 8 September 2017 12:08 AM To: List for Therion users <therion@speleo.sk> Cc: Andrew Atkinson <andrew@wotcc.org.uk> Subject: [Therion] Multiple fixes for the same point
I'm sure that this has been covered, but I cannot find it anywhere.
I have 3 different gps results for a surface point, all taken with the same gps but on different days, so rather then picking one I just used fix on all 3.
However, therion appears to be taking only the last one I enter. This does not seem to be the right behaviour! Is there a way for Therion to take all 3 and 'average' them?
thanks in advance
Andrew _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
--
------------------------- Xavier Pennec Senior Research Scientist / Directeur de recherche Asclepios project-team, INRIA Sophia-Antipolis 2004 Route des Lucioles, BP93 F-06902 Sophia-Antipolis Cedex, France +33 4 92 38 76 64 +33 6 78 35 16 90 http://www-sop.inria.fr/asclepios/ -------------------------------
Andrew, GPS coordinates should come with uncertainties. If nothing went wrong when you took the coordinates, they should all be within their uncertainties. They could all be very close from each others but still be off the exact coordinates (that is the difference between accuracy and repeatability). If all the coordinates of the entrances were taken with GPS, I would rather use these coordinates and their uncertainties in the processing and pick one of the three sets of coordinates for the surface point. This will be way more accurate that just trying to do some kind of covariance on the three sets of coordinates to make it look more accurate, but which in fact won’t really matter. If you coordinates where taken with handheld GPS, your cave survey for the 9 entrances should be more accurate than the GPS coordinates. Phil
On 07 Sep 2017, at 14:07 PM, Andrew Atkinson via Therion <therion@speleo.sk> wrote:
I'm sure that this has been covered, but I cannot find it anywhere.
I have 3 different gps results for a surface point, all taken with the same gps but on different days, so rather then picking one I just used fix on all 3.
However, therion appears to be taking only the last one I enter. This does not seem to be the right behaviour! Is there a way for Therion to take all 3 and 'average' them?
thanks in advance
Andrew _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
participants (7)
-
Andrew Atkinson -
Benedikt Hallinger -
Bruce Mutton -
Martin Sluka -
Philippe Vernant -
Wookey -
Xavier Pennec