kno10
commented
7 years ago Can you provide a test case? Much of the code could use better unit tests. But I have not noticed any negative distances. I have seen near-zero negative results in other distances, because of numerical instability. Given that we used the code to produce the figures (in particular the textured overlays), I would not expect there is an as obvious bug in there, it would cause larger artifacts.
From a quick look,
double lngW = rmaxlng - plng; // we keep this negative!
...
if(lngE <= -lngW) {the comment indicates that this was a deliberate choice, not an accident, to use the negative difference here. The following if statement then compares to the negative value, so that looks consistent to me. But I do not remember why this seemed beneficial.
When the pseudocode says "mod360", this of course will usually be implemented as a modulo 2pi in radians etc. - pseudocode is about the idea, and mod360 = "handle the wrap-around here if necessary". Whether you use radians or degree is up to you; insert conversions as necessary. Rather than just trying to translate the pseudocode into code, I recommend to try to understand the logic. It's not very difficult; there are nine cases, and the paper illustrates this with figures. We could be inside the rectangle, north, south, closest to the four corners, or it might be best to choose the optimal bearing to "fly" to the east or west side of the rectangle. Much of the code which you are referring to are simply case distinctions whether it is faster to fly east, or to fly west.
Java does benefit from some careful optimization of functions that are in hot loops such as distance computations. Unfortunately, Java for example does not have a sincos function, and in Java, -1.5 % Math.PI == -1.5. This behavior makes sense too (and in fact a popular pitfall when using % in Java with negative numbers - see MathUtil.normAngle), but is likely different from what you were expecting. Your code indicates you did not understand how we implemented the modulo in Java (knowing that we won't see an angle like 12345, for which we would need to call normAngle, and the code does not support rectangles crossing the date line - some simple translation could be used to handle this.)
Haversine: sin(x)^2 = sin(-x)^2, isn't it? Where do you think it needs an absolute value?
So: do you know any input where it does not work right?
If I have time, I will try to revisit the negative-lngW decision, and there may be some low-hanging optimization potential with MathUtil.normAngle, too, to make ELKI faster.
ghost
1) I understand that here you can just compare the coordinates, because the north and south edges of rectangle are parallels which are perpendicular to meridians and the shortest distance is equal to the length of the meridian arc starting at point Q and ending at point lying on the northern or southern edge. The length of the meridian of the arc can be calculated as R (deltaLatitude), where R is the radius of Earth. This is what i have done in the first condition in my code. In pseudocode you use circumference of Earth which is defined if i am not wrong as c=2 PI R and in pseudocode the resulting distance is computed as c (deltaLatitude) / 360, but that is the same formula i used,because
formula in text is (2 PI R deltaLatitude ) / 360
conversion to rad: 1 degree = PI / 180 means we multiply above by 180/PI
[(2 PI R deltaLatitude) / 360 ] (180/PI) = (2 R deltalatitude) / 2 = R * deltaLatitude
You will help me,if you tell me if your pseudocode in text is correct. Shouldn´t the signs when determining the north/south corner from the middle of MBR be the same as when comparing to the line?
Based on the test cases i was able to find mistake in the pseudocode from the text and i provide my code which works now. The sign was inconsistent with the formula you derived which says that point lies to north if
Hello,
i was reading your paper "Geodetic Distance Queries on R-Trees for Indexing Geographic Data" and i wasn´t sure what did you mean by all those subscript 360 functions, so i checked your code for that defined here https://github.com/elki-project/elki/blob/e8f3c6fdf54e1e0aa8444b94ad5374ad518dfc0c/elki-core-math/src/main/java/de/lmu/ifi/dbs/elki/math/geodesy/SphereUtil.java, it doesn´t follow the pseudocode. For instance lines 806-813
where i think you meant to do
Also my theory is that 360 subscript means we are working in radians, not degrees. In fact when i followed your pseudocode in paper exactly it is working for me in C++, but i am still not sure what you meant by sentence "In order to distinguish the other cases, we first need to test whether we are on the left or on the right side by rotating the mean longitude of the rectangle by 180◦ – the meridian opposite of the rectangle." . Do i understand correctly, that you wanted to do modulo 360(2 PI) to normalize the angle to range 0-360 [0..2 PI]?
Also i have found out,that the haversine formula should use absolute difference of latitudes and longitudes. Correct me if i am wrong,but if you dont use absolute values there,you may get negative distances. I attach my version of the algorithm including the Haversine formula
The last thing i dont understand why in pseudocode you are returning c (rminlat-plat)/360 for the N/S case when i think it should be c (rminlat-plat) , because you say in text we are calculating length of meridian arc, where c is radius of earth.
Thank you for your answer.