Small circles on low zoom level render incomplete

[moving-bits]

Depending on zoom level, circles drawn with JTS CircleDrawable have a small missing part in their perimeter line between 11 and 12'o'clock:

For specific zoom levels, see screenshots 2 and 3, zoom level in screenshot 1 is ok:

..

All circles have a radius of 161m.

[devemux86]

I have not seen it in Cruiser's no-go area circles.

Try CircleDrawable.HIGH_QUALITY or more.

You can also try the other circle implementation demonstrated in VectorLayerActivity example.

[SammysHP]

Looks like a rounding / off-by-one error. The circle is divided into segments, but these segments don't fully close the circle. Either the algorithms stops early or it detects an overflow for the last segments and then stops the rendering.

[moving-bits]

I've tried both HIGH_QUALITY and/or setting the loop condition in CircleDrawable to <= instead of <, but that did not help. (Actually toPolygon() internally calls ring() already, which to my understanding makes sure, that the last point is equal to the first, thus closing the ring. But for some reason, this is not what gets drawn in certain zoom levels.)

VectorLayerActivity seems to use PointDrawable to draw "circles" - but how can the size/radius of such a point/"circle" be set?

[devemux86]

@moving-bits A small code sample would help reproduce the report.

For example, the following code sample seems to work:

vectorLayer.add(new CircleDrawable(new GeoPoint(0, 0), .161, Style.builder()
        .fillAlpha(1)
        .fillColor(0x80ff0000)
        .strokeColor(0xffff0000)
        .strokeWidth(4)
        .build()));

You can also try dropDistance(0) in the Style.

[devemux86]

@moving-bits @eddiemuc The problem is the large dropDistance simplification you use.

Set dropDistance(0).

dropDistance(20)	dropDistance(0)

[SammysHP]

dropDistance() should probably not drop the last point, though. 😉

[devemux86]

@SammysHP Contributions are always welcome. 🙂

[SammysHP]

Yeah, I already expected a response like then when I wrote my comment. 😅 Can absolutely relate to you.

It's in here, right?

vtm/vtm/src/org/oscim/renderer/bucket/LineBucket.java

Line 373 in 174474e

if (a < mMinDist) {

[devemux86]

• Please see and test LineBucket: skip two vertex segments except end, fix #1271 #1272

[moving-bits]

Thanks for looking into this issue. I can test, but won't be able to so before the weekend.

[SammysHP]

I noticed something else:

Before starting the loop, the first two vertices are read:

vtm/vtm/src/org/oscim/renderer/bucket/LineBucket.java

Lines 253 to 258 in 174474e

	int ipos = start;
	curX = points[ipos++];
	curY = points[ipos++];
	nextX = points[ipos++];
	nextY = points[ipos++];

When entering the loop, the pointers are advanced again:

vtm/vtm/src/org/oscim/renderer/bucket/LineBucket.java

Lines 357 to 359 in 174474e

	if (ipos < end) {
	nextX = points[ipos++];
	nextY = points[ipos++];

Not sure if this is related. I just wondered why the first line segment is shorter than the rest.