Why does the line clipper add a tiddly amount (d) in these expressions?
double d = 0.00001; if (t[0] > 0) ends[0] = new Coord((int) (y0 + t[0] * dy + d), (int) (x0 + t[0] * dx + d));
if (t[1] < 1) ends[1] = new Coord((int)(y0 + t[1] * dy + d), (int) (x0 + t[1] * dx + d));
It for rounding to the nearest map unit. I remember I was just adjusting it until I got something that worked, but can't quite remember what the problem I was solving was.
If I'd thought about it more I would have said that the correct value would be:
360/(2 * 2^24)
which comes to 0.000010728, so perhaps close enough.
So I have replaced d=0.00001 it with the exact expression 360.0D / (1 << 24) / 2;
On a similar note, why have the non-zero DELTA here?
public static int toMapUnit(double l) { double DELTA = 0.000001; // TODO check if we really mean this
That is a much smaller delta and is just protecting against floating point numbers that are intended to be an exact value but are just a bit less. It is not trying to round to the closest map unit one in this case.
It may not be needed but it is the rouding of the areas in the TDB file that was affected if I remember correctly, so if you want to experiment without it, or think it is causing trouble elsewhere we need to check the TDB areas.
I dont fully understand you. Floating points are in this case never intended to be 'exact' values. They are lat/lon values. I have just discovered, that the missing rounding in this place leads to a small loss in precision. This means that the LineClipping class includes nods and creates end nodes slightly outside the bounding box. As far as I can see it, this should not cause any problems, but it was a little irritating to found nodes included, which are 2m outside the bounding box. So I've replaced d=0.0000001 too with the same expression 360.0D / (1 << 24) / 2; Now clipping works as expected.