Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KML Track disappears when zooming to zoomlevel 15 and higher #68

Open
GoogleCodeExporter opened this issue Apr 6, 2015 · 5 comments
Open

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1.Create a MapView
2.Display KML file like in tutorial_4
3.Zoom to zoom level 17 and higher

What is the expected output? What do you see instead?

This is what i see in output-log:

06-10 12:26:30.705  11293-11293/de.example.spessartbiken.app 
I/o*.o*.t*.MapTileProvid*﹕ rescale tile cache from 16 to 17
06-10 12:26:30.925  11293-11293/de.example.spessartbiken.app 
I/o*.o*.t*.MapTileProvid*﹕ Finished rescale in 221ms
06-10 12:26:30.965  11293-11293/de.example.spessartbiken.app 
W/OpenGLRenderer﹕ Path too large to be rendered into a texture
06-10 12:26:30.975  11293-11293/de.example.spessartbiken.app 
W/OpenGLRenderer﹕ Path too large to be rendered into a texture
06-10 12:26:30.985  11293-11293/de.example.spessartbiken.app 
W/OpenGLRenderer﹕ Path too large to be rendered into a texture

What version of the products are you using (Android SDK, osmdroid,
OSMBonusPack)?

I'm using Android Studio 0.59, OsmDroid 4.2 and OsmBonusPack 4.5


Please provide any additional information below.

One solution that worked for me was enforcing software rendering with 
mapView.setLayerType(View.LAYER_TYPE_SOFTWARE, null); as it was recommended in 
another issue.

I attached one KML file where i have this problem. But there are 18 more 
similar files with the same issue.

Original issue reported on code.google.com by [email protected] on 10 Jun 2014 at 10:35

Attachments:

@GoogleCodeExporter
Copy link
Author

OK. This is equivalent to osmdroid issue 454 
(https://code.google.com/p/osmdroid/issues/detail?id=454). 

There is no "good" solution in osmdroid for it yet. 

So your workaround (disabling HW acceleration at view level) is probably the 
best solution for now. 
An alternative is to target an SDK < 3.0 (no HW acceleration). 

Original comment by [email protected] on 10 Jun 2014 at 11:46

@GoogleCodeExporter
Copy link
Author

Well, in fact, there is now a solution for this issue from osmdroid 4.2: the 
"NonAcceleratedOverlay". 

I changed Polyline and Polygon to inherit from it. This means that on an 
SDK>=3.0, rendering will be HW-accelerated, except for Polyline and Polygon. 

The source is commited, and the osmbonuspack_snapshot.jar is available in the 
Downloads. 

You can try (removing mapView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);) 
and see if it solves your issue. 

Original comment by [email protected] on 11 Jun 2014 at 8:24

@GoogleCodeExporter
Copy link
Author

So i tried out the osmbonuspack_snapshot.jar and the kml track was shown in all 
zoom states, so it solved this particular problem. 
But loading, panning and zooming the map becomes incredibly slow and it throws 
some of those errors in the log: "E/dalvikvm-heap﹕ Out of memory on a 
262160-byte allocation."

So the workaraound mentioned above is the best solution for me, as it works 
flawlessly and the performance also is very good.

Original comment by [email protected] on 22 Jun 2014 at 4:28

@GoogleCodeExporter
Copy link
Author

Bad news. I cancel my change. 
This will need further investigation on why it became slow with 
NonAcceleratedOverlay. 

Original comment by [email protected] on 23 Jun 2014 at 9:09

@GoogleCodeExporter
Copy link
Author

Issue 16 has been merged into this issue.

Original comment by [email protected] on 25 Jul 2014 at 4:22

GoogleCodeExporter pushed a commit that referenced this issue Apr 6, 2015
Polygon, Polyline: back to standard Overlay (see issue #68)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant