I am trying to study Magnet Tools GPS+ module.
Whenever you load a rinex file the software creates a GPS observation vector (from point ---> to point). Magnet sometimes reverses the "from pt" with the "to pt". I first load the base gps rinex file and load the rover files after. But still Magnet reverses the order of a vector and because of this, one of the rover becomes a base and vice-versa.
I have been trying to find how you can reverse the "to point" and "from point".
Can you point me how to do this?
?ÿ
Not a Magnet user, but in other software the from->to vector direction is dependent on which point is set to "Control" or "Reference."
Yes, there is a Control tick box with options - None, Vertical, Horizontal, Both. For rovers I select None and for Base I selected Both. Still the vector won't reverse from Rover--->Base.
I know I am missing something here bit this is the 1st time I am using Topcon Magnet v5.
Hmm. In Leica world you could also right click the vector and reverse the direction... Hopefully a Magnet user will chime in soon.
When importing RINEX data you are processing STATIC data, not RTK. Therefore there is no base/rover relationship. The software is processing vectors between each observation. Why are you concerned with direction of the vector? I think the direction of the vector may be relative to the time the receiver was started.
Whether static data or RTK, a vector is being processed between a point of known position and one of unknown position. I think the OP is concerned that the software is holding the the autonomous value of the unknown point as known and thereby corrupting the positions of both points. It could certainly happen that way in some software suites, where direction (meaning hierarchical reliance) certainly does matter.
Static baselines are just delta 3D vectors - there is no "from" or "to", only a difference in XYZ between two points. The assumption is that an adjustment will be performed using one or more constraints that are input by the user, hence the term "relative positioning". Direction is irrelevant, at least it should be, in most software packages.
Static files store an autonomous location that is used by the post-processing software to build the a priori - that is, approximate - coordinates of the network. Import order usually doesn't matter, as long as the user eventually inputs control coordinates for one of the positions and constrains to them during adjustment. Some software builds off the first point imported for the a priori coordinates, others have a heirarchy, and some require user input. It all depends on your software suite.
There *might* be a problem if a static file happens to have an autonomous coordinate in the header that is drastically off, as in thousands of feet or more. This is rare, but it can happen. Sometimes it will take a few more iterations to solve for the network positions - other times a solution is not possible. The closer those a priori coordinates are to the true values, the easier it is to find a solution.
Some users speak in terms of "bases" (receivers logging data throughout the entire campaign) and "rovers" (receivers that are being moved around and logging at shorter intervals while the bases continue to log), and insist that the base files must be imported first. This is not necessarily the case.
As others said, in static there really is no base/rover difference. The only difference it would make is POSSIBLY in the quality of the starting coordinate. I always process the network using whatever positions are available (might be C/A code, RTX, published, etc). Then I fix one or more points, run an adjustment, and then reprocess everything using the updated coordinates. That way all stations have good starting coordinates. I prefer to use ITRF coordinates to do this, one way is to submit a file to OPUS or RTX and then use that coordinate as a seed.?ÿ This is known as coordinate seeding. I think that TBC predecessors TGO or GPSurvey (I don't remember which one) seemed to do a much better job at seeding, it would go from known coordinate through the network in sequence, always using a "known" coordinate for each baseline if possible. It seems like TBC does not do this quite as well.?ÿ
I will add that with the relatively accurate C/A code positions it hardly makes a difference unless the baselines are long or the network covers a large area. I still always do the two step processing (process-adjust-process) anyway.?ÿ
I mostly agree with your characterization; that is, that baselines are really just a computed difference between two points. However, inherent in the word vector is the concept of direction as well as magnitude. Even though you and I both know that a baseline is not really "starting" at one point and "ending" at another, some software uses direction as a way of assigning "reference" or "control" status to one point or the other (whether during baseline processing or during least squares adjustment). It is not completely artificial to speak of bases and rovers, especially since surveyors are generally in the business of relative positioning.
-
1.MATHEMATICS•PHYSICSa quantity having direction as well as magnitude, especially as determining the position of one point in space relative to another.
I can assure you that Magnet Tools does not use "direction as a way of assigning "reference" or "control" status to one point or the other". We use 6 or more GNSS receivers in a static network session, therefore no need to know the direction of the vector and the is no Base. At times I often constrain only one point.?ÿ
I think the OP maybe confusing RTK with Static (Magnet Tools can process both), while FrozenNorth making this complex than it really is.
So back to my original question, anyone using Magnet Tools here who has a solution on how to reverse a from pt---->to point vector?
Can you point me to the setting within Magnet Tools?
Thank you.
?ÿ
In addition to the Leica tip from earlier, Trimble Geomatics Office handled it this way (p. 51 of the TGO manual here https://kb.unavco.org/kb/assets/609/TGOuserguide.pdf ).?ÿ I know this doesn't solve the Topcon-specific software clicks, but the principle you are pursuing is sound.?ÿ Hopefully someone can say how to do it in Topcon.
Reversing the Direction of Observations
GPS and terrestrial observations flow out in the direction in which the baseline was observed. For RTK observations, the direction will be from the base to the rover. The direction of postprocessed Static and FastStatic baselines is based on the positional qualities of the from and to points. The direction is applied from the point with the higher quality to the point with the lower quality. For terrestrial observations, the direction will be from the instrument point to the target point. A recomputation applies the observation in the direction that is stored in the project. For more information, see Chapter 6, Recomputation. You can reverse the direction of an observation so that a recomputation applies the observation in the opposite direction??this
may change the calculated coordinates and qualities of the point.
To reverse the direction of a GPS baseline, select the GPS observation and then Edit / Reverse Observation flowout.?ÿ When the edits to the survey data could change the coordinates for a point in the database, the Recompute icon appears in the status bar.?ÿ The recomputation reapplies the observation to flow out from the opposite point.
?ÿ
It make sense that the vector is based upon accuracy as you describe in Leica, and perhaps Topcon does use this method. But why does is matter? Why does one want to reverse the direction of a vector? In Tools you can perform a loop closure of a network, also can inverse in any direction?ÿ
As mentioned already it doesn't matter (at least not in Topcon Tools). Import your data files then process>GPS+ Post processing, then set your control points to the correct values, set in point properties box as control Horz vert or both, then process>adjust.
This is the way the Topcon manual describes the process.
I want to reverse a vector direction because there are several rover data that need to be processed. All have a single base from which they are referenced. Having a solution where the rover uses an autonomous coordinate that I don't know where or how it got it would result in that rover having an error position relative to other observed points.
All rover GPS positions should be referenced from a base with known or averaged position ( if you don't need absolute positions). Even so, all GPS observed points should be correctly positioned relative to all other rovers and base.?ÿ
I don't understand. Your process still sounds like RTK, not Static. If you truly have static, then there is no base / rover relationship and no reason to reverse a vector.
Found the reason for the direction assignment. The rover rinex file has values assigned during the rinex conversion process for the?ÿ APPROX POSITION XYZ . After I changed it to 0000 0000 0000 and imported it into Magnet, I was able to process the vector properly. Thank you.
Found the reason for the direction assignment. The rover rinex file has values assigned during the rinex conversion process for the?ÿ APPROX POSITION XYZ . After I changed it to 0000 0000 0000 and imported it into Magnet, I was able to process the vector properly. Thank you.
That's great you have figured out how to do something unnecessary but have you actually learned anything about post processing from those that have tried to help you?
What do you mean something unnecessary? This is not my 1st time to PP gps data. I have been doing this since using Topcon's TGPS, Ashtech Locus Processor, Ashtech Solutions, GNSS Solutions, Topcon Tools, Magnet Tools and RTKLib if that is what you wanted to know. And all of those software except for the Magnet Tools have options to set base & rover gps data, reverse processing sequence and set priority of stations. This is the 1st time that I have encountered such problems. I tried to email support but they have not yet responded as of last week hence I tried to ask it here.
The fact that a lot of you are confused about GPS processing using a base or reference point of known coordinates as take off point is a bit?ÿ confusing. All those software that I mentioned has the option where you select the base (or if you want to call it a reference station) and assign to it absolute XYZ coordinates from which all other points are referenced from in order to get their absolute positions.
If you are not concerned with absolute positions then you just let the software decide what point it wants to use as its reference point. Most of the time it gets it correctly usually by selecting the point with the longest observation time that encompasses most of the other points' observation time. GPS post processing is the same as traverse computation. You need to have a starting point for T0 from which T1, T2 .... Txx will refer its coordinates. You can't have coordinates for T0 as assumed 20000, 20000, 100 and as you are processing the line, T7 will then have it's own XYZ without any connection to T0, T1...T6.
What make and model receiver were you using, that caused this hiccup?
