Provide a robust way to draw Polygon Overlays on the map

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Currently it is possible to draw polygon overlays on the map by using a 
PathOverlay and a self-closing path. For example, the following method can be 
used: 
    private void AddPolygon() {
    int diff=1000;

    GeoPoint pt1=new GeoPoint(13.002798, 77.580000);
    GeoPoint pt2= new GeoPoint(pt1.getLatitudeE6()+diff, pt1.getLongitudeE6());
    GeoPoint pt3= new GeoPoint(pt1.getLatitudeE6()+diff, pt1.getLongitudeE6()+diff);
    GeoPoint pt4= new GeoPoint(pt1.getLatitudeE6(), pt1.getLongitudeE6()+diff);
    GeoPoint pt5= new GeoPoint(pt1);

    PathOverlay myOverlay= new PathOverlay(Color.RED, this);
    myOverlay.getPaint().setStyle(Paint.Style.FILL);

    myOverlay.addPoint(pt1);
    myOverlay.addPoint(pt2);
    myOverlay.addPoint(pt3);
    myOverlay.addPoint(pt4);
    myOverlay.addPoint(pt5);

    map.getOverlays().add(myOverlay);
    }

What is the expected output? What do you see instead?
The Overlay is correctly drawn, when all the vertices are in the current map 
bounds. But If you pan or zoom, so that some of the vertices go off the screen, 
then the polygon losses that vertex, and it is not drawn.

See the attached Images

What version of the product are you using? On what operating system?
OsmDroid 3.0.8 & Android 2.3.6

Please provide any additional information below.
This is occurring due to the line 157 of the PathOverlay.java file, where those 
vertices outside the current extent are not projected and drawn.

Original issue reported on code.google.com by dev...@gmail.com on 7 Jan 2013 at 9:34

Attachments:

• correct.png
• problem.png

[GoogleCodeExporter]

Agree the behaviour is exacly as described above and if it can be fixed that 
will be fab.

Original comment by ose...@gmail.com on 4 Mar 2013 at 10:54

[GoogleCodeExporter]

Issue 302 has been merged into this issue.

Original comment by kurtzm...@gmail.com on 5 Mar 2013 at 6:14

[GoogleCodeExporter]

The problem is lines 212-217. It tries to optimize drawing by not drawing 
points outside of the screenrect, but as you can see that doesn't work.

Can someone try removing those lines and trying it out and making sure 
everything else still works. I can't understand how anyone uses the PathOverlay 
with this glaring bug in it so maybe I am missing something.

Original comment by kurtzm...@gmail.com on 5 Mar 2013 at 6:15

[GoogleCodeExporter]

I did try removing the lines, and testing it out. It does not work, because 
somewhere else, the vertices of the line are being projected from the real 
world units to screen units. This is a problem since no position is returned in 
screen units, for when the point is outside the viewable Map.

Original comment by dev...@gmail.com on 6 Mar 2013 at 2:53

[GoogleCodeExporter]

The way "off-screen" optimization should work for polygons is that it tests 
whether *none* of the points are on the screen. If none of the points are on 
the screen it can skip drawing the entire polygon, otherwise it should draw all 
points. I think it might be acceptable to skip individual line segments of the 
polygon if *both* points of the segment are outside the viewable area, but at 
that point if you're drawing some points to the screen there is little benefit 
to skipping a few line segments.

Also calling fromPixelsToProjected (line 201) adds a significant amount of 
error if you are at a high zoom level. It takes a low-resolution plane and 
upscales it to a higher plane which loses "fine" resolution and is not a good 
representation of the current screen bounds - in essence the clip bounds will 
be slightly over- or under-sized. (this may not really be a problem - but it is 
suspect)

It also appears to do the "too close to previous point" in the higher 
resolution plane rather than at the real zoom-level. So this probably skips no 
points.

This overlay probably needs a re-write and modernization. It should use the 
SafeDrawingOverlay, and it should simplify the drawing method. It would be more 
performant to convert the lat/long to projected points in the addPoint() method 
rather than in the drawing method. I don't know if I personally will have time 
to do this so if anyone wants to contribute then post a patch or an updated 
overlay.

Original comment by kurtzm...@gmail.com on 6 Mar 2013 at 3:02

[GoogleCodeExporter]

Actually, to do polygon clipping testing we should get the rectangle that 
encloses all points in the polygon and then see if that intersects with the 
screen rectangle. If so, draw the whole thing. If not, we can safely skip 
drawing.

Testing for individual points that are outside the screen is insufficient. If 
you want to get fancy like that, you'd have to ensure that the line segment the 
two points make doesn't intercept the screen rectangle.

Original comment by kurtzm...@gmail.com on 6 Mar 2013 at 8:01

[GoogleCodeExporter]

I created my own class, a copy of the PathOverlay and commented lines 157-162:

157: if (!Rect.intersects(clipBounds, mLineBounds)) {
158: // skip this line, move to next point
159: projectedPoint0 = projectedPoint1;
160: screenPoint0 = null;
161: continue;
162: }

 The problem has been solved.

Original comment by vladisla...@gmail.com on 11 Jul 2013 at 3:16

[GoogleCodeExporter]

If anyone is interested, I have a highly optimized PathOverlay for rendering 
database backed paths with >1 million points with asynchronous db access. It 
renders smoothly while zooming in, out, and scrolling by keeping two point 
containers in memory, using one for rendering while async loading the other.

Original comment by vit.hrad...@gmail.com on 27 Jul 2013 at 9:52

[GoogleCodeExporter]

Hi vit it would be great if you share the file with me. 

Original comment by akram10....@gmail.com on 29 Jul 2013 at 5:00

[GoogleCodeExporter]

I to am interested in Vit's PathOverlay class - colin.grant [at] gmail.com

Original comment by colin.gr...@gmail.com on 9 Aug 2013 at 5:16

[GoogleCodeExporter]

My opinion is that using PathOverlay for drawing polygons is just a hack. 
We should have 2 different overlays: 
- path (or polyline) overlay, 
- and polygon overlay. 
This would clear issues related to incompatible optimizations, allow defining 2 
paints for polygons: the outline paint, and the fill color/style. 

BTW, Vit, we are all interested by your optimized PathOverlay... 

Original comment by mathieu....@gmail.com on 21 Oct 2013 at 9:20

[GoogleCodeExporter]

OSMBonusPack provides a robust PolygonOverlay, which mimics Google Maps API v2 
Polygon. 

Original comment by mathieu....@gmail.com on 26 Oct 2013 at 7:49

[GoogleCodeExporter]

Hi vit it would be great if you share the file with me.

Original comment by Gilbert9...@gmail.com on 16 Jan 2014 at 12:15

[GoogleCodeExporter]

Issue 529 has been merged into this issue.

Original comment by kurtzm...@gmail.com on 20 Feb 2014 at 3:14

[GoogleCodeExporter]

Ok since my issue has been merged into what seems to be the same issue, I see 
that there seem to be hacks/alternatives. May I ask what the official status 
is, and when this is going to be fixed in the library itself?

Original comment by carsten....@bitz.it on 20 Feb 2014 at 3:22

[GoogleCodeExporter]

I would suggest taking a look at OSMBonusPack to see if their PolygonOverlay 
will meet your needs. Or you could write your own Overlay that constructs and 
draws a Path (which is not that difficult). I don't think anyone is working on 
osm's PathOverlay at this time.

Original comment by kurtzm...@gmail.com on 20 Feb 2014 at 3:26

[GoogleCodeExporter]

Unfortunately I'm pretty deeply wired into a regular PathOverlay 
implementation, I don't think I can switch that easily now. Since paths are 
somewhat important, I would really appreciate if someone experienced in this 
project could mak a fix for an official release.

Other than that I will probably try to do my own drawing, like already 
suggested in this thread. Thanks so far!

Original comment by carsten....@bitz.it on 20 Feb 2014 at 3:32

[GoogleCodeExporter]

I was able to find the cause in my case and now simply avoid the option causing 
the paths to disappear. I'm not 100% happy with it, but not deep enough into 
the code to find a real fix. I tested a Polyline overlay from the BonusPack, 
and had the same issues!

To make the paths "nice", I took the Paint-object and modified it:
    Paint mPaint = pathOverlay.getPaint();
    mPaint.setStrokeWidth(13);
    mPaint.setPathEffect(new CornerPathEffect(10));
    mPaint.setAntiAlias(true);
    pathOverlay.setPaint(mPaint);

The problem is caused the CornerPathEffect! AntiAlias is fine, but the 
PathEffect makes the path disappear in some cases. The path looks way sharper 
now of course, which is why I'm not 100% happy, but at least it's not 
disappearing. Maybe someone familiar with the drawing can find an easy fix for 
this?

Original comment by carsten....@bitz.it on 21 Feb 2014 at 10:06

[GoogleCodeExporter]

Vit, I would apprechiate, if you share the file with me too... 
Thanks! 

Original comment by TobiSc...@gmail.com on 11 Mar 2014 at 12:40

[GoogleCodeExporter]

Has anybody received the file from Vit?

Original comment by TobiSc...@gmail.com on 12 Mar 2014 at 2:56

[GoogleCodeExporter]

Hi Vit!!!Can you share your file with me too?thanks!! :)

Original comment by giamp...@gmail.com on 17 May 2014 at 9:42