Discussion What is the most efficient way to crowdsource the 3D system coordinates

Good question. How about this: for distances just increment the CR each time the distance is submitted.
Noted - And what I'm doing atm.

There could be multiple distances for any pair of systems and TGC would output them all.
Yup - TGC can handle that (multiple distances for same pair)

Algorithms should only use the version with the highest CR (if it's a tie then ignore that pair of systems as we have no confidence in the data).
Atm - I'm simply using all of them when doing trilateration.
Sofar it has worked out (writing this I'm suddenly in doubt however.. need to test (again?)...).
I'm also doing a "cube-search" for each candidate found (each point up to 8/32th LY away around the candidate also becomes a candidate - before final culling/verification)

For systems, CR is set to 1 as soon as there are enough distances to calculate a position (using the highest CR distance for each reference star).
Atm I'm setting it to cr=1 as soon as a name is submitted (whether I have coords or not)

Then each time a new set of distances are submitted for that system, if they are consistent with the calculated position then increment the CR.
Agreed.

If they are not consistent with the current position but there is a position that is consistent with all known distances then reset the CR to 1 and change the coordinates.
Atm there is no automated way of changing coords once a set is (confidently) identified.
Future work perhaps.

If there is no position consistent with all known distances then set CR to 0 (which indicates bad or insufficient data and wait for new data to sort it out).
As mentioned above - Atm I'm going with cr=1, for the simple fact that a system name has been identified (entered into the system)

One problem with this implementation would be that it would be relatively easy to pollute with bad data if someone was determined to do so.
True.
But I think that would be true for any automated (non-curated) system.
I'll obviously keep an eye on TGC - And can intervene manually (might make tools down the line) as needed.


(and yes - I'm procrastinating a bit atm :D )

- - - - - Additional Content Posted / Auto Merge - - - - -

If you only want the systems he supplied for beta 3 (755 of them I believe) then I have a spreadsheet I can send you. Or I can make a filtered version of systems.json (tomorrow - I'm about to go to bed). I guess for testing it won't hurt to use the 802.

Yeah for alpha testing I think the 802 will be fine.
I'll take you up on the offer once it's time to seed the DB for real though :)
 
Last edited:
Algorithms should only use the version with the highest CR (if it's a tie then ignore that pair of systems as we have no confidence in the data).
Atm - I'm simply using all of them when doing trilateration.
Sofar it has worked out (writing this I'm suddenly in doubt however.. need to test (again?)...).
I'm also doing a "cube-search" for each candidate found (each point up to 8/32th LY away around the candidate also becomes a candidate - before final culling/verification)

Took a look at the code again.

As it is - it will indeed fail if one of the distances is wrong.

What I'm doing (with the cubesearch) is to generate *a lot* of extra candidates in a cube around the candidate spit out by the trilateration math.

And then I do a RDC (reverse distance check) for each with regards to the ref systems.
And only those that give an RDC of zero will pass (adding up all the RDC's for each ref)

If there's a wrong distance - none will pass...

pro/con:
Pro: Ensures no wrong coords will be calculated (as no candidate will pass)
Con: No coords are calculated... :p

So..
Perhaps instead of simply adding up all the RDC's - aiming for them to add to zero (which works perfectly for correct distances) - I was thinking of relaxing this:
Instead of adding up the RDCs - I would instead count how many refs give a zero error.
If that count is 5 or more (what we have more or less established to be the minimum refs needed to pin down the coords for sure) I'll let it pass - Even if one or more RDC's in fact don't give zero.
This would allow for any number of "bad distances" as long as there's at least five good ones.

Thoughts?
 
Hey all,

I've updated my application a bit, made sure it works ok in Chrome (few buttons are a bit wonky) and I've added a REST API endpoint that allows you to download the solar system grid contents as JSON. I've added documentation for the API as well, although only GETs work at the moment, POST, PUT and DELETE are all disabled for now.

It was updated with RWs dataset earlier today.

The application is mostly functional but could do with more tweaks, by this I mean you can use the editors to update the details for a solar system, then see those changes in the output JSON.

Feel free to check it out and let me know what you think, although please don't hammer it too much, the full dataset is about 400k :)
 
TGC alpha 0.1 is live

API ver:0 (ver=0)

The API docs are not updated yet - But nothing much has changed really.
http://edstarcoordinator.com/api.html

GetSystems and GetDistances takes the same params as before - with GetDistances having the cr option added as well.
You can use the fiddles linked from the api doc pages - Just remember to change the version number (it's 1 in the fiddles - change to 0 and it works. Well 1 "works" as well - you'll just get an error message :))

The output has changed a bit - But basically a bunch of extra fields have been added.
I'll prob add some options to get a less verbose output later.

The most exciting thing is ofc submission of data.

I don't have a working fiddle for that yet I'm afraid (need to get to bed 1:30 here) - But I'll get that done tomorrow + update the API docs

The endpoint for submission of data is "'api.asmx/SubmitDistances'"
Simply switch that in one of the fiddles if you want.

Input looks like
Code:
var data = {
    data: {
      ver: 0,
      commander: "TornSoulåøæêá",
      p0: { name: "Shudun Sector AA-A d142" },
      refs: [
      {
        name: "Ammapa",
        dist: 121.85
      },
      {
        name: "Wanggu",
        dist: 135.45
      },
      {
        name: "Piran",
        dist: 123.51
      },
      {
        name: "Yakan",
        dist: 140.24
      },
      {
        name: "Suraci",
        dist: 113.36
      } ,
      {
        name: "Gera",
        dist: 94.24
      },
      {
        name: "Arin",
        dist: 30.77
      },
      {
        name: "Pollux",
        dist: 31.67
      }
    ]
    }
  }

Pretty straightforward.

The object returned from the browser is VERY verbose, telling what actions have been taken.
Should help a bit figuring out bugs I hope.

Option to toggle all that to be added later.


Just wanted to get it out there.

Let me know how it goes - and what changes/additions you'd like to see


and ofc.. any bugs... let me know
 
Maybe of use.

I parsed through the "Beta2 Occupied System Coords.xls" file and checked/compared the data validity in ED for Beta3.04

This are the Invalids: (coordinates changed or systems dissapeared completly or other special funny things like no real systems)

-31.12 52.35 KEIAN GU -6 36.28125 -19.875
-32.71 73.07 EHLANGAI -11.21875 32.53125 -23.03125
-28.15 0 TRAINING -22 36 1
-28.68 0 DESTINATION -22 37 4
-38.68 0 VACCIMICI -33.21875 37.34375 12.75
-39.33 97.02 BORO KACHARIS -27.125 18.90625 -25.875
-51.23 72.41 MANAMAYA -43.53125 35.03125 -19.15625
-50.85 0 ZHU RONG -39.875 34.9375 -24.1875
-70.02 99.61 KWARASETI -53.5 33.75 -39.875
-77.57 93.11 TAI QING -70.90625 50.75 -4.09375
-75.19 0 NIMBA -71.5625 42.96875 -4.84375
-77.52 0 HARPULO -75.375 40.28125 -0.46875
-84.04 101.71 GRABRI -81.1875 42.28125 -5.1875
-92.15 0 CLOTTI -88.03125 47.1875 -6.15625
-94.81 0 NGURUAI TRIMPASO -84.46875 54.625 -22.375
-100.38 109.81 BANGATI -85.21875 56.28125 -35.125
-98.6 147.04 NYON T'AO WUJIN -81.71875 58.8125 -35.28125
-86.15 77.64 MISTAE -72.34375 56.6875 -24.8125
-85.3 0 TOYOTA -67.0625 52.625 -37.375
-88.56 109.58 CHAPOYO -72.0625 31.84375 -47.53125
-87.37 112.64 FU HAITING -69.46875 32.125 -48.875
-80.96 89.24 JURUA -60.84375 23.84375 -50.75
-81.96 108.29 TAPIPINOUPHINIEN -63.90625 19.84375 -49.1875
-94.87 0 HSINI -81.75 15.59375 -46.78125
-101.71 0 JAOISMONJIN -83.90625 33 -53.5625
-92.14 114.97 ANDJERI -87 28.90625 -28.46875
-79.63 97.97 MOSCAB KUTJA -75.75 25.40625 -23.78125
-90.26 0 KUUNGGATI -85.40625 18.375 -29.53125
-88.08 120.22 CHEMETITANA -83.34375 8.84375 -27.875
-90.01 116.62 VERBONI -82.71875 21.46875 -34.78125
-73.58 0 COQUENCHIS -62.78125 23.09375 -36.4375
-74.88 0 APISHIM -62.71875 20.28125 -39.15625
-71.35 0 SUMI -59.53125 16.4375 -37.6875
-77.99 0 KAMBALUA -62.90625 15.34375 -44.21875
-70.43 65.88 ZOSIA -62.625 25.5625 -30.09375
-75.23 0 TAPARI -66.4375 32.125 -31
-73.33 0 DHARAI -70.9375 32.34375 -14.21875
-81.18 95.13 DJEDET -81.46875 30.5625 -1.1875
-78.37 90.27 PARECO -78.8125 30.34375 2.90625
-83.55 102.02 LAKLUIT -83.875 21.125 -10.0625
-84.01 0 JIEGUAJE -85.25 16.9375 -4
-91.93 102.88 JAITU -92.59375 15.1875 -9.15625
-98.13 96.84 TAURAWA -98.125 21.84375 -13.09375
-108.67 110.17 ALADU KUAN GON -108.75 15.8125 -14.25
-119.87 0 HARAS -118.75 14.40625 -21.40625
-126.38 137.55 CUAGES -124.875 20.03125 -23.78125
-127.85 142.17 WIKMEANG -123.59375 25.875 -33.25
-114.16 0 BA BHUMIANG KU -104.28125 25.0625 -45.25
-110.66 117.68 TSETAN -102.625 19.65625 -41.125
-105.25 104.68 MACOMANELENG MU -101 16.375 -30.65625
-103.52 83.91 KAMCHAULTULTULA -101.09375 11 -24.09375
-112.34 144.87 KILLKE -108 8.5625 -31.15625
-127.81 0 TITICATE -122.5 10.09375 -36.96875
-122.49 0 CHIRICHIANCO -114.0625 8.25 -43.84375
-134.42 142.24 TRING -125.375 9.5 -47.96875
-131.1 118.12 MAIDUBII -115.4375 11.90625 -60.875
-121.54 152.28 KULKANABOSSONGMA -106.125 18.46875 -58.03125
-121.47 118.07 MISTANA -103.125 27.6875 -61.84375
-124.37 119.34 BAGA -107.3125 35.5 -58.84375
-140.97 0 SAN GUARALARU -124.34375 41.8125 -60.71875
-139.75 139.47 XI WANGKALA -133.0625 38.6875 -38.125
-140.45 126.28 BHOTEPA -134.625 33.21875 -38.0625
-142.47 129.16 NGOLOKI ANATEN -135.9375 33.5 -40.5
-132.89 0 LUGIU BEZELANA -126.15625 44.5625 -33.1875
-124.9 144.21 ARABHA -120.75 43.78125 -22.125
-119.06 0 NJIRIKA -117.46875 36.28125 -15.40625
-102.93 88.70 KORUBU -102 36.3125 -7.8125
-102.77 0 REIENE MAORAI -99.75 39.125 -16.84375
-91.07 92.31 PEMEDE -88.90625 22.28125 -21.40625
-116.79 0 PATA THEWI -108.46875 52.0625 -27.34375
-132.7 136.14 MEN SAMIT -120.375 55.6875 -40.6875
-105.63 112.20 TALEACHISHVAKHRUD -96.5625 56.71875 -19.5
-124.21 123.00 POQOMATHI -101.40625 24.65625 -69.5625

Suspect:
-103.46 103.45 ER LO WU DI -83.03125 19.84375 -59.78125
 
Ah. But makeing a printscreen and reading the content out from there is not. lol
It's pointless to forbid such. Someone will do it anyway. If the data is there I see no reason not do it since snooping wont change the client nor disturb it in any other way if you do it right.
There are ways to prevent it or make it very hard or close to impossible if they are so eager to block access to the data. I still don't get why they think it's a good idea to block the data from players.
Player made Tools are useually increasing the attraction of a Game.
 

wolverine2710

Tutorial & Guide Writer
Ah. But makeing a printscreen and reading the content out from there is not. lol
It's pointless to forbid such. Someone will do it anyway. If the data is there I see no reason not do it since snooping wont change the client nor disturb it in any other way if you do it right.
There are ways to prevent it or make it very hard or close to impossible if they are so eager to block access to the data. I still don't get why they think it's a good idea to block the data from players.
Player made Tools are useually increasing the attraction of a Game.

I can understand your desire to discuss this but lets please keep this thread ON Topic. I hoped the OP made this clear.
Please do NOT turn this into another pro vs contra third party (trading) tools thread. Those discussions for me are the equivalent of the trenches war of WWI. Nobody makes progress. If you want to discuss it, the perfect place is "Direct question for Michael Brookes". I hope and trust you respect my wishes.
 
Ah. But makeing a printscreen and reading the content out from there is not. lol
It's pointless to forbid such. Someone will do it anyway. If the data is there I see no reason not do it since snooping wont change the client nor disturb it in any other way if you do it right.
There are ways to prevent it or make it very hard or close to impossible if they are so eager to block access to the data. I still don't get why they think it's a good idea to block the data from players.
Player made Tools are useually increasing the attraction of a Game.

Someone will, but that is beside the point. As long as you provide "official" data and an "official" tool, you have to play by FD rules.

And Wolverine, it is very much on topic, so a more appropriate quote would be the one where Michael Brookes told the community that snooping is not allowed. Most of us where around for that message, however a few where not, so no harm in reminding.
 
Last edited:
a more appropriate quote would be the one where Michael Brookes told the community that snooping is not allowed.

Took a bit of work to get a clickable quote as the thread is closed... (and I had to write something to be allowed to post it...)

We're no longer allowing tools which scrape the data directly from the game or through its communications. We will be considering an external API for future development, but for now these tools are not permitted.

I'm closing this thread pending confirmation that this tool will no longer use these methods. Threads for tools that do not comply will be removed. I'm posting this in here and similar threads so everyone knows what's happening.

Michael
 
Last edited:
I can understand your desire to discuss this but lets please keep this thread ON Topic. I hoped the OP made this clear.

Actually i was about to help you. See I have some ideas too and am looking for ways to get to 3D coords and economie data. But it has to make sense.. and net snooping had made the most sense.

On topic. I am testing a personel coord calculation system. More because of interest in how best you can do it from a mathematical point of view. It seems stable. Not sure what i am going to do with it probabily nothing. But in case you need an alternative calculation I could help out. I seem to get an average 3d position error accuracy of below 0.01 with 4 well selected fix reference systems simulated with the beta2 data (hench the reason why I sorted out the invalids first)

for ocr: i hope you are aware that a lot will use Oculus rift in future or other such VR's.
 
Not using http://en.wikipedia.org/wiki/Trilateration ??

I'd be academically curious to such an alternative.

No. It's custom made.

Actually I have build 2 System.

My first attempt was simple solving this:

Err = Sum of all (sqrt[(x1-x2)^2 + (y1-y2)^2+(z1-z2)^2] -D12) ^2
whereas D12 is the distance of System1 to System 2

And solved that first derivation equation set with newton because it is a non linear set

dErr/dX1 != 0
dErr/dY1 != 0
...

for Newton you have to build the second derivation (functionalmatrix/jacobi matrix)

But it didn't work so well.. it looks like I must have made a mistake in teh second derivation it does not converge well.

However Fro Newton you need good start values and so I thought about how production that and came up with a stable and good solution.

Idea was to get/solve a linear equation set for good start values.

Now that's a bit tricky to explain. Maybe I should send you some drawings and the formula.

But basicly what I do is I always pick 2 reference Systems ot of the N FixReferenceSystems.. well I will build every possible Reference Pair of the N FixSystems

What I then do is to calculate a plane orthogonal on this RefSystem1 to RefSystem2 vector.
So instead of spheres and circle I somewhat reduce the information.
For every pair I get a plane where the System idaly should be on.

with 3 Ref Systems pair you get 3 planes that will cross in 1 point -> the cross point is where the system X is.

For M ref System pairs we say the sum of the distance in square of the System X to the planes should be minimzed

The first derivation of this Err Sum gives you a perfectly linear equation set. Which you can simple solve A*x = b
It's a Matrix of 3X3. (we have 3 coords)

That's what I have running it it looks to produce trouble free and good enough result.
 

wolverine2710

Tutorial & Guide Writer
Actually i was about to help you. See I have some ideas too and am looking for ways to get to 3D coords and economie data. But it has to make sense.. and net snooping had made the most sense.

On topic. I am testing a personel coord calculation system. More because of interest in how best you can do it from a mathematical point of view. It seems stable. Not sure what i am going to do with it probabily nothing. But in case you need an alternative calculation I could help out. I seem to get an average 3d position error accuracy of below 0.01 with 4 well selected fix reference systems simulated with the beta2 data (hench the reason why I sorted out the invalids first)

for ocr: i hope you are aware that a lot will use Oculus rift in future or other such VR's.

I stand corrected by you all. Michael Brookes quote is the one I should have used. Perhaps I'm getting conditioned a bit - a bad thing. I've seen to many threads (including my own ones getting derailed because like I said there are basically two camps, pro and contra. In this thread there were commanders who were against getting coordinates and I didn't want to get their attention again. But it seems I did interpret your post incorrectly and overreacted and for that I sincerely apologize.

The last thing I want to do is to alienate commanders who are willing to help out. So I hope you accept my apologies and its water down the bridge. If you despite my incorrect reaction still want to help: WELCOME ON BOARD COMMANDER. Each and every input/tool is welcomed.

I did ask Michael Brookes if it would be possible to write in a file the system name and its 3D coordinates after leaving a Hyper Space jump. His response: "We're busy with the game features so it's not something we can provide at the moment." This is understandable. There have also been posts by graham.reeds "[SUGGESTION] Multi step solution to trade data" and a commander "Reviving thirdparty (trading) tools using a poor man web-api solution -- ". Also seeing the 3D coordinates in game has been requested by a commander. When FD changed their policy Michael Brookes wrote "They are CONSIDERING a web-api after release". Perhaps the to be released iPhone app uses a web-api to shield/protect itself from changes in the network protocol. Basically at this point we (community) are starving for information and are trying to get information any way we can - in a legal way. The mentioned OCR route/thread being one of them.

I really hope you are still willing to provide us with your method/tool.
 
Last edited:
What I then do is to calculate a plane orthogonal on this RefSystem1 to RefSystem2 vector.
<snip>
For every pair I get a plane where the System idaly should be on.

Uhm.. The p0 system (the one we are trying to find the coords of) won't necessarily be in this plane...

As this plane is not related to the measured distances (as far as I can tell from your explanation) it could be oriented any which way, with relation to p0 (only depends on r1,r2 coords/vector) - And "laterally" (with respect to the vector) it could be position anywhere as well...

Or to put it another way - Where ever this plane is won't change, if I decide to move p0 around - as such it can't be guaranteed to contain p0

So finding the point where all (or just 3 of) the planes cross will just give you a random point, which is only correlated to the _positions_ of the ref stars - and not their distances to p0.

You are saying that it seems to work - so obviously something must be missing in your explanation
 
Last edited:
So..
Perhaps instead of simply adding up all the RDC's - aiming for them to add to zero (which works perfectly for correct distances) - I was thinking of relaxing this:
Instead of adding up the RDCs - I would instead count how many refs give a zero error.
If that count is 5 or more (what we have more or less established to be the minimum refs needed to pin down the coords for sure) I'll let it pass - Even if one or more RDC's in fact don't give zero.
This would allow for any number of "bad distances" as long as there's at least five good ones.

Thoughts?

I think the problem with that is that there could be multiple coordinates that have 5 good distances and 1 bad one, but a different "bad" one..

So, the way I'm thinking about it is that we currently have a method to detect the level of "redundancy" in the data, which I had described before. Basically, to ensure n+1 redundancy for some set of distances (i.e. enough redundancy to detect 1 bad distance), you remove each distance in turn and recalculate the coordinate, and ensure that you are still able to get the same single valid coord with each reduced set of distances. Or for n+2, you would need to iterate over the combinations of subsets of length - 2, etc.

So, using that redundancy measure, we can have a measurable level of confidence in some set of distances.

So, let's say that our goal is to achieve n+1 redundancy before deciding a coordinate is definitely valid. Now, let's say we have some set of distances such that there is no valid coordinate. So, the goal is to find a subset of the distances that have n+1 redundancy.

So something like

Code:
(pseudocode)

for i in 0 to distances.length:
  new_distances = copy(distances).remove(i)
  
  is_redundant = true
  coord = null
  for j in 0 to new_distances.length:
    test_distances = copy(new_distances).remove(j)
    test_coord = find_coord(test_distances)
    if test_coord is null: // no valid coordinate for this set of distances
      is_redundant = false
    else if coord = null:
      coord = test_coord
    else if test_coord != coord:
      is_redundant = false
  if is_redundant:
    print "distance " + i + " is bad"

At the end, if it wasn't able to determine which distance was bad, then there are 2 possibilities:

1. There isn't enough redundancy in the data to detect the bad distance and still have n+1 redundancy after removing the bad distance
2. There are multiple bad distances

The solution for #1 would be to get more distances and rerun the same algorithm.
The solution for #2 would be to run an extended version of the algorithm that iterates over the combinations of subsets of length n-2 (or n-3 for 3 bad distances, etc.) - which might also require more distances.


As a general rule, I think n+1 redundancy should be required before presenting a coordinate for a star, and n+2 (or higher) should be required for verification of that coordinate.
 
Last edited:
@wolverine
Accepted. Don't worry. I didn't take it bad.
~
Uhm.. The p0 system (the one we are trying to find the coords of) won't necessarily be in this plane...

As this plane is not related to the measured distances (as far as I can tell from your explanation) it could be oriented any which way, with relation to p0 (only depends on r1,r2 coords/vector) - And "laterally" (with respect to the vector) it could be position anywhere as well...

Or to put it another way - Where ever this plane is won't change, if I decide to move p0 around - as such it can't be guaranteed to contain p0

So finding the point where all (or just 3 of) the planes cross will just give you a random point, which is only correlated to the _positions_ of the ref stars - and not their distances to p0.

You are saying that it seems to work - so obviously something must be missing in your explanation

For the calculation of the Planes 3 points (systems) are involved:
2 Fix Reference System + The unknown System/point that you call P0.

The plane(s) are calulated with xref1,yref1,zref1,xref2,yref2,zref2 and r1 and r2.

Visual you can picture this like this:

A sphere from RefPoint/System 1 with radius r1 and a sphere of RefPoint/system 2 with radius 2

the intersection-"line" is a circle. Now instead the circle I calculate the plane where this circle is 100% part of or if you want I calculate the plane of this circle.
Instead limiting the possible positions for P0 on this circle I limit it on the plane of this circle. I throw away information for the benefit to convert it into a linear system.
something with planes is mostly linear a circle mostly not.

I guess I will have to prepare something so you can better see it.

I have to check what I can send you.. I wasn't really prepared to present it. But nice to see there is interest. :)
 
Last edited:
you remove each distance in turn and recalculate the coordinate, and ensure that you are still able to get the same single valid coord with each reduced set of distances.
The actual coordinate calculation - Only includes 3 of the ref systems (p1-p3), so there is nothing to "remove" to do a recalculation to find a pair of candidates.
(and this is done for any combination of 3 refs)

Determining which one from the pair to use, is what involves the rest of the ref systems.
And this is where things could go "wrong" (with bad distances), as each remaining ref is then used as a "p4" to see which candidate is the correct one

And here is where one could "remove" one or more refs (r-refs), to see if all other refs (o-refs) check out when the r-refs are removed - more or less as per your suggestion.

What I'm suggesting is a bit of a shortcut, that covers all your possible combinations in one go.
(some systems have 15+ distances logged - running all combo's for all combos of 3 combos, starts to become a lot of combos :D)

The shortcut being - Simply assume that there is at least 5 good ones, and if they check out we are good (every other ref can be good/bad we don't care)

With your algo, we would end up in precisely that situation, if you remove enough refs anyhow.

That's as much a question as a statement ;)
 
@TornSoul:

Added 2 file in my dropbox containing the math:

https://www.dropbox.com/sh/9g15l3um92vu0x3/AACldLmEAPC_2JzM4K_wtT02a?dl=0

but I guess I will have to explain them in graphical form. I also used completly different names for r1,r2,p0

.wxm is wxMaxima. A free software clone from mathematica

quick legend:
DM1 -> is r1 (Distance P0 to reference(system) point M1)
DM2 -> is r2 (Distance P0 to reference(system) point M2)
DMM -> Distance M1 to M2
k-> Factor where the plane is ancored on the vector M1M2 (I believe k=0.0 is on M1 and k=1.0 is on M2 note that k can also be larger than 1 or negative!)
X,Y,Z: Thecoords of P0 that we search
M1X -> X coord of ref M1
M1Y -> Y coord of ref M1
M1Z -> Z coord of ref M1
w -> a system wighteing factor. not used at the moment set it to 1.0 Idea is to give a wight for the systems so you can wight thos you know are correct higher than thos calulated later

a,b,c,d -> the coefficients of the HNF Plane:
a*X+ b*Y+c*Z + d = 0
 
Last edited:
Back
Top Bottom