What's d for? (possibly related to clipping issue?)
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)); 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 if (l > 0) return (int) ((l + DELTA) * (1 << 24)/360); else return (int) ((l - DELTA) * (1 << 24)/360); }
On Fri, Feb 20, 2009 at 12:03:59AM +0000, Mark Burton wrote:
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.
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. ..Steve
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.
Shouldnt this rounding be performed in the constructor of the Coord? Then the rounding gets applied on every Coord, no matter, how it gets constructed.
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.
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.
Sorry for my answer from yesterday, there is a fault in it. I've thought about it again and think your explanation is wrong. In this case the rounding by 0.0001 makes no sense, as the x and y values are already in internal units, not in degrees. So if you want to round the values, you have to add/subtract 0.5!
On Mon, Feb 23, 2009 at 08:49:30AM +0100, Johann Gail wrote:
double d = 0.00001; if (t[0] > 0) ends[0] = new Coord((int) (y0 + t[0] * dy + d), (int) (x0 + t[0] * dx + d));
Sorry for my answer from yesterday, there is a fault in it. I've thought about it again and think your explanation is wrong. In this case the rounding by 0.0001 makes no sense, as the x and y values are already in internal units, not in degrees. So if you want to round the values, you have to add/subtract 0.5!
Ahh, you are right, those things are already in map units. I was thinking they were in lat/long. You should probably ignore everything I said on the subject! ..Steve
Ok, I've created a patch, which should corrects the things, as I understand it. It introduces correct rounding in both cases. Before the patch clipping was a little inaccurate. Some points 2m outside the bounding box gets included in the img. With this patch it works correctly now. I've tested this since some days and up to now found no new failures. Whatever the reason for this small delta was, there should be no bad effects, if one adds a somewhat bigger delta.
participants (3)
-
Johann Gail -
Mark Burton -
Steve Ratcliffe