I have built a custom TileProvider from a map image, but the original image does not cover the required map area for the resolution corresponding to the highest zoom level.
By default, the provider returns no tiles if I do not create images for the corresponding zoom levels. Is it possible to zoom on the existing tile rather? I could create zoomed tiles these which would be basically stretched and cut versions of the highest resolution I have, but this seems redundant and would take unnecessary disk space/processing.
Is there a way to stretch tiles when none is available for a high zoom level, rather than creating those tiles explicitly? I could always set the maxZoom property on the map, but I have different overlays with different resolutions. I could also add some smart processing in the provider to return a subsampled version of a tile at lower resolution on the fly, but I am hoping there is a built in way to do this.
You cannot stretch the tiles per zoom level (automatically) but you can instead wrap your URL Tile provider with one that allows you to customize the behaviour. For example I've done (some years ago) a custom tile provider whose cached the tiles in a specific folder of the phone (better and longer caching than gmaps one), but could also be possibile to check the zoom (z) and if it is higher than a specific value, you can retrieve the tile for a lower zoom and split by 4 (no zoom but cut and zoom.
The result will be very poor, and honestly I find better to create them on server side (are you using a WMS provider maybe?).
I have tiles downloaded from Mobac tool, with the source being Openstreet mapQuest.
Given that we may not have tiles for all positions at a higher zoom level, when we scroll, areas that are missing tiles result in a null grid or stretched images of lower zoom-level tiles.
How can I restrict scrolling to only a given bounding box and zoom level?
Implementing MapListener interface, I overrode the OnZoom function. Depending upon current zoomlevel and the points visible on screen, the scrollable boundingbox can be set by calling mapView.setScrollableAreaLimit.
I´m using the code provided by Stephen Potell for displaying WMS tiles in osmdroid. (https://groups.google.com/forum/?fromgroups=#!topic/osmdroid/WtRrQCIfYVk)
At first it seems like the tiles are displayed correct. After adding a my location overlay or an path overlay the tiles or the overlays are displayed incorrect. Assuming the overlays are correct it may seem like the tiles are either one zoom level wrong or the tiles are displayed "one tile off in y-direction".
When enabling multitouchControls in OSMDroid and barely zoom in (just one slight touch) and "hold the zoom" the tiles and overlays are in right location. If going one zoom level in or out the overlays are again positioned wrong.
I have tried playing around with values in WMSMapTileSource but with no luck.
Any help would be appreciated.
Ole T.
I have a Google Map application. When we zoom out to the highest level, the map
is not visible. Only some grey lines are seen as shown in the figure. This happens only in ice cream sandwitch. This doesn't' happen in Froyo.
This is because there isn't enough map information left to still fill the screen. You're at the point where the MapView would be showing the entire globe. You're getting the magnifying glasses with the (-) inside because the image data is not available for that zoom.
You have 1 of 2 options, 1, create a zoom checker... if the person zooms lower than (x) (5 or 4 would probably be a good zoomLevel), then reset the zoom level to (x). OR if you still need to show the entire world map, you can change your application to use landscape rather than portrait views. This same thing is happening with an application I'm developing, and I went with solution 1.
I'm using OSMdroid to implement a mapping application.
I have implemented a custom MapTileProvider that uses a tile source that allows zoom levels up to 22.
The default MAPNIK provider only allows zooms to level 18.
The problem is that any PathOverlay instances draw perfectly until zoom level 19, but then
are not drawn properly at zoom level 20-22. it looks like someone's rubbed out the path with an eraser over 90% of the path length (see screenshots below).
I've stepped through the draw() method of PathOverlay and exerything seems to be calculating correctly (the intermediate points appear correct for ZoomLevel 22, and then the XY projections are dividing by 22-ZoomLevel to get current screen coordinates).
Can anyone provide some insight as to what the problem is, and how to resolve it?
The same thing happens if I invoke the MapView using Cloudmade small tiles, which allows zooms up until level 20 and is a 'built-in' osmDroid tile provider class.
//mMapTileProvider = new HighResMapTileProvider(this);
mMapTileProvider = new MapTileProviderBasic(this,TileSourceFactory.CLOUDMADESMALLTILES);
mMapView = new MapView(this, 256, mResourceProxy,mMapTileProvider);
So the problem does not appear to be with the tile source or provider but with the canvas drawing method. Any ideas on how to resolve this?
At zoomLevel 19 I can see my paths nicely:
But here is that same path at the next zoom level:
I've found a workaround. It's not ideal, but it does work.
Firstly, if I add a
canvas.drawCircle(screenPoint1.x, screenPoint1.y, 5, cpaint);
to PathOverlay's draw() method I see this, so I know the co-ordinates are at least being calculated correctly.
So the problem seems to be related to the underlying line draw method in Android.
After some trial and error, I found that setting the STROKE WIDTH to 0.0 for the PathOverlay's Paint object fixes the problem, but the line is obviously only 1 pixel wide.
Adding a check for the current zoom level in PathOverlay.draw() to set the stroke width will keep the current behaviour for levels <20 and draw a hairline path for higher zoom levels.
Some other things I noticed:
The circles become squares at zoom level 21&22. This strongly suggests that there's some floating point precision issues when passing very large (x,y) co-ordinates to Path.lineTo / canvas.drawCircle etc, e.g. mPath.lineTo(131000001,38000001)
Setting stroke width to say, 5 sort-of works up to zoom level 21, but the same problem crops up at level 22 again
Update: This has been fixed in osmdroid 3.0.9.
Original Answer:
This issue appears to be rooted in Android. I believe it is due to a rounding error that happens when you scroll a view to a large offset (possibly due to use of SKScalar). This bug can be isolated by creating a new android project with an activity and a view:
Begin with the view at the origin with no scroll offset yet.
Draw a circle on the canvas: canvas.drawCircle(screenCenterX, screenCenterY, 100, mPaint)
Scroll the view to a large number: mainView.scrollTo(536870912, 536870912)
Draw a circle on the canvas: canvas.drawCircle(newScreenCenterX, newScreenCenterY, 100, mPaint)
The first circle draws ok, the second one draws distorted. For further evidence, try to draw your path near 0 lat/0 long and zoom in - notice the distortion no longer appears.
I will update the osmdroid ticket with some possible solutions workarounds.
I am fairly sure this is because the default PathOverlay only draws the line between points in the view. If a the point is outside of the curent view the line segment is not drawen. At lower zoom levels you just don't see that the bit of the line going off the view is not showen as all the sections are small.
I think you have 2 options.
The easy but maybe not the best is to put more points into the path, then at least the problem will be less noticable. If this is a good idea or not will depend how many points you already have.
The corect solution will be to extend the class and do your own draw method then clip the line segmet that gose off the view to the view edge. Idealy you would contribute your code back to the source.
I have the same problem and I posted a bug on OSMDroid here:
http://code.google.com/p/osmdroid/issues/detail?can=2&start=0&num=100&q=221&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&groupby=&sort=&id=221
I'm not sure if it's a problem of OSMDroid or just a problem of too big canvas.
Other workaround would be drawing on a new, smaller canvas (size of current visible mapView) and using drawBitmap in the top left corner of a big canvas. Just remember not to create new bitmap each draw - because it's expensive.
All shapes are drawn perfectly fine but Im struggling with other problem with not smooth panning in levels > 18. You can see that when you pan the map it is not moving every pixel as it is in levels < 18, but it jumps over few pixels.
I agree that this is OSMDROID related bug because I got the same working DrawPath function (Zoom level 21 & 22) using Google MapView. I hope they will be able to address this issue.
To solve this problem, we need to implement the line clipping algorithm.
By clipping with the map viewport, the path is adding more vertexes.
Thus it will be drawed correctly at big zoom level.