googollee/eviltransform

wgtochina_lb and gpsHeight

Artoria2e5 opened this issue · 0 comments

Looking into the comment area in coolypf's article, it looks like the author omitted these two lines after applying the nonlinear deltas:

// variables renamed for readability. original: wg_heit, wg_time
dx += ((int) gpsHeight) * 0.001 + sin(((int) gpsWeekTime) * pi / 180) + random_yj();
dy += ((int) gpsHeight) * 0.001 + sin(((int) gpsWeekTime) * pi / 180) + random_yj();
// random_yj(): double rand [0,1)

The original code also branched away when gpsHeight > 5000:

if ((int) gpsHeight > 5000) { return null; }

But in getEncryPoint it was omitted. However, getEncryPoint shows a rather different variable name style, so I guess this might be added by someone else who has decompiled the code and wanted to try the thing out using this and the main function.

So here is the problem: is there any observable derivation in the current wgs2gcj implementation that approximately match the landscape of China for areas with alt <= 5000? If so, can we figure out what unit gpsHeight is supposed be in (derivations of 5 deg max sounds impossible to me, so there has to be another unit involved, like km)? This might not help this library (since the difference sounds small), but this helps with documenting the whole coord system.


// Linear Congruential Generator for real random numbers in the range [0,1)
// D. Rapaport, The Art of Molecular Dynamics Simulation, Cambridge, 2004
protected double random_yj()
{
    me.casm_rr = 314159269 /* a */ * me.casm_rr + 453806245 /* c */;
    me.casm_rr %= 2.0;
    me.casm_rr /= 2.0;
    return (me.casm_rr);
}
// see also: IniCasm, wgtochina_lb:branch[wg_flag == 0]