Might be related to Issue 5123

I have also come across this bug, also on relatively jittery data recorded while standing still, or walking back and forth in a 1-2m area.

Additional info:
- The artefact (bug) line always appears to leave my drawn route heading due North, East, South or West. Direction can switch based on zoom.
- The artefact only appears when the zoom is pushed to quite high (approx 2 highest) levels, but will then remain for considerable zoom out actions before eventually disappearing again.
- Seen on HTC Desire, Android v2.2

http://stackoverflow.com/questions/16740262/its-a-bug-or-something-wronggoogle-map-v2-for-android

I have also come across this, I don't think its just when you zoom in, I have found that it happens with different amounts of data and also different zoom levels (about 11 and 8) how ever it can be reproduced by going in to the same position and zoom level, you can also follow line line for quite some time and then it disappears 

	working.png 306 KB   View   Download

	Screenshot_2013-07-02-21-29-07.png 353 KB   View   Download

	Screenshot_2013-07-02-21-29-14.png 411 KB   View   Download

	Screenshot_2013-07-02-21-33-06.png 342 KB   View   Download

	Screenshot_2013-07-02-21-33-43.png 324 KB   View   Download

This was on a Samsung Galaxy Nexus running 4.2.2

I have implemented a filter to skip points closer than 1 metre, and that seems to have eradicated the problem. I haven't adjusted the threshold to see if it works on less. It is extra processing I'd rather not be doing.

Has anyone found any other work arounds?

Is that what causes it? When there is a abundance of points in one place?

Is there any resolution for this issue?  I'm having some of the same issues, particularly at screen/projection edges.

http://stackoverflow.com/questions/17422314/polylines-appearing-on-map-where-they-shouldnt


You have to filter out lines that are too close to each other. 

I could track it down to a very simple case with only 4 points. (Indeed the last point is not even needed).
See:
http://stackoverflow.com/questions/21361069/cant-draw-an-arrow-using-polyline-in-googlemap-v2
In this case it has nothing to do with points being very near, but just with the fact, that the same segment is drawn once to west and then back to east. And it only happens if the segment goes absolutely straight towards west and east. The same code works, if the segment goes only a bit towards north or south in addition.

Just wanted to add the example code also here.
Resulting shape should be a kind of arrow, but the horizontal line extends to infinity.

PolylineOptions po = new PolylineOptions();
    LatLng p1 = new LatLng(49.4, 8.45);
    LatLng p2 = new LatLng(49.3, 8.6);
    LatLng p3 = new LatLng(49.3, 8.5);
    LatLng p4 = new LatLng(49.35, 8.6);

    po.add(p1);
    po.add(p2);
    po.add(p3);
    po.add(p2);
    po.add(p4);
    map.addPolyline(po);

It seems to be when a path crosses back over itself.  For me it happens when a user needs to make a u-turn.  My attempt to work around the issue has lead me to introduce a bit a randomization to the polyline:

  Random rand = new Random();
  foreach (var vertice in path)
  {
    double lat = vertice[0];
    double lng = vertice[1];

    lat = lat + rand.NextDouble() / 10000;
    lng = lng + rand.NextDouble() / 10000;
....

Not perfect, but seems to be working.

(No comment was entered for this change.)

Stumbled with this issue when requesting small route too GoogleDirectionsApi. Any workaround still? Already like one year past.

Same here.
I've tried to filter points too close to each other, but the problem still occurs.
The only things that makes sense is that it happens when the polyline makes a u-turn.
Bu I cannot add randomization. I need to put the points exacly where they are.

A not so beautiful workaround that worked for us: alter the similar coordinates with a value less than you position error tolarence, so that they won't be exactly the same. For us a value like 0.000001 worked fine. So the example in comment #11 would look like:

PolylineOptions po = new PolylineOptions();
    LatLng p1 = new LatLng(49.4, 8.45);
    LatLng p2 = new LatLng(49.300001, 8.600001);
    LatLng p3 = new LatLng(49.3, 8.5);
    LatLng p4 = new LatLng(49.35, 8.6);

    po.add(p1);
    po.add(p2);
    po.add(p3);
    po.add(p2);
    po.add(p4);
    map.addPolyline(po);

This way the lines will look the same on screen, but you won't encounter the problem. Of course, this needs a little extra logic, to determine the points that have the sam e coordinates.

I'm working on a tablet with xhdpi density screen and I'm discarding from my dataset the points with the same latitude and longitude of the previous one.
The bug occurs when two points making a u-turn (horizontal or vertical) have a distance of 0.000001. 
So the solution suggested in #17 won't work, or at least should consider to add an offset proportional to the screen density.
But keep in mind that, for me, neither the solution of computing the distance from the last point and discard the closest one ( < 1 meter) worked.
I think it's not a problem of distance. In other situations, where there are two points very close but not u-turning, the issue is not occurring. 

Is there any solid fix for this bug now?

 Issue 8010  has been merged into this issue.

 Issue 8166  has been merged into this issue.

 Issue 7483  has been merged into this issue.

Up

having this same problem on Nexus 6 running 6.0.1

I managed to reproduce this error for the last 2 years, on several phones.  The smallest way to reproduce this is:

        LatLng p1 = new LatLng(32.084, 34.806);
        LatLng p2 = new LatLng(32.086, 34.806);
        LatLng p3 = new LatLng(32.086, 34.807);

        polyline.add(p1);
        polyline.add(p2);
        polyline.add(p1); // this one messes up
        polyline.add(p3);

        LatLngBounds.Builder bounds = new LatLngBounds.Builder();
        bounds.include(p1).include(p2).include(p3);
        mGoogleMap.moveCamera(CameraUpdateFactory.newLatLngBounds(bounds.build(), 100));

Again, the workaround is to remove some points from my line. In my case the tolerance is 0.001. I am not happy about "not displaying" the correct data (even though I know the points are bellow the GPS accuracy, so ignoring them is not a bad idea anyway).

Up. Same on Galaxy Google Nexus.