Cones geometry (slope) is wrong

[ghost]

Issues in the slope of cones:

1. Cones geometry (slope) varies significantly between unprojected and projected representation, which is not expected this is the unprojected view, look at Urumqi (left) slopes with the other cities of mainland China; the ratio is about 1 to 5 (which still is short of the theoretical 7.5) Now the same view with equirectangular projection; the ration is close to one to 3

2. measurement with the ruler shows inconsistency between visual ratio and theroretical speed ratio (see point 1)

[ghost]

This is how it should look like with the ratio of 7.5: the blue line should be 7.5 times longer that red line (beware ratio on figure is wrong)

[ghost]

I have checked the values computed for alphas,they are all correct. Road generates and alpha of 1.437 rad (100 kph) while HST generate a alpha of 1.23 rad (250 kph) So the error is after this step of computation: this._edgesAndTranspModes = networkFromCities(transportModeCode, cities, transportNetwork); The image below is beautiful, but unfortunately wrong :( HST are red as in Beijing cone, the rest is road:

[ghost]

the computation of ratios ratio.pdf

[bilLkarkariy]

Very interesting, since the last update of @kaktus40, by canceling the angle of the correction while the azimuth difference is big and by setting coneStep to 1:

[ghost]

new problem, observed in newest verion including PR #78 and #80 : when resizing browser window, slopes change !! depth (am) remain the same while horizontal length change (ab)!!!

[bilLkarkariy]

Ok I will fix it today!

[ghost]

a new idea of the issue, I made a video of China from unprojected to projected view: https://timespace.hypotheses.org/files/2019/10/cone_slope_bug.mp4 the problem is that the height of cones remain identical while radius changes in the transformation. As cones are gessting more distant, this generatesa new slope. What do you think of that @kaktus40 ?

[ghost]

another insight for solving the bug for @CodeInLight

• when modifying height of cones from the console, the behavior is expected in non projected, no modification of slopes occurs
• but when doing the same in the projected situation, modifying the height also affects the radius of cones and also the slope; with values of shriveling.configuration.intrudedHeightRatio=0.9 the geometry is becoming crazy!

[ghost]

summarizing exchanges by email and phone and Skype with @kaktus40 and @CodeInLight Diagnostic: geographical projections are designed to deal with the earth surface but are not designed to convert three-dimensional objects, which causes probably the issue Pathways to solve the bug:

• radical solution 1 : rewrite projection algorithms to run in three-d = complex solution
• radical solution 2 : compute all geometries for each new projected situation
• patch-like solution 1 proposed by @CodeInLight
  • a constant is applied on z
  • works for Germany_22 but not on other sets
  • to parametrize this constant, it would depend on lattitude and each projection, not viable
• patch-like solution 2 : correct the slopes once the projection has been applied by:
  1. for each "clock" computing the "graphical alpha" by reading the xyz coordinates and the cone summit (city) xy (with z=0)
  2. compare this "graphical alpha" to the "theoretical alpha" indicated by the ratio of speeds on the networks
  3. adjust the "z" of the "clock" to equalize "graphical alpha" and "theoretical alpha"

if this proves costly in computing time, this solution could be only applied when a projection is at 100% applied and not during the transition between projections. Attention: this idea can bring additional complexity in the code, so trade-off must be devised

[alainlhostis]

Here comes an explanation of the bug, inspired by repeating the transformation between un-projected and projected and back: All is said in the graphic, now let's find the solution to the issue!