It can be because for some reason the user agent isn't set properly.
OSM / MAPNIK demand the user agent to have a meaningful value - like, the package name of your app.
By default, the user agent is supposedly initialized to context.getPackageName() (cf. DefaultConfigurationProvider).
If you skipped some steps in the tutorial, perhaps your user agent is not correctly set, which will cause the rejection by OSM of your tile download requests and therefore an empty map.
The solution is to give a correct value to your user agent:
Configuration.getInstance().setUserAgentValue(context.getPackageName());It might be because in Android 9+, http (and not httpS) URLs are not permitted by default, and some tile providers don't have https URLs. You therefore have to whitelist the URLs of the tile providers you're using.
Create a file named network_security_config.xml in res/xml, and configure here the sites to be whitelisted:
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<domain-config cleartextTrafficPermitted="true">
<domain includeSubdomains="true">openptmap.org</domain>
</domain-config>
</network-security-config>In AndroidManifest.xml, add a reference to the new network_security_config.xml file:
<application
android:icon="@drawable/icon"
android:networkSecurityConfig="@xml/network_security_config"
...
/>I try to set the zoom and center of my MapView in Activity.onCreate or Fragment.onCreateView but it doesn't seem to work
At this stage of the lifecycle, the MapView is not 100% initialized yet; it may not even have a width or a height. The correct way is to use the View.post syntax.
It's generally a good practice to try the post syntax when confronted with a bad positioning issue at init time. (e.g. issue #608)
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// ...
mMapView = (MapView) findViewById(R.id.map);
mMapView.post(
new Runnable() {
@Override
public void run() {
mMapView.zoomToBoundingBox(new BoundingBox(48, -2, 46, 5), false);
}
});
}For Fragments you should put your own map manipulation code into the function onViewCreated().
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup parent, Bundle savedInstanceState) {
// just the inflate code
return inflater.inflate(R.layout.your_fragment, parent, false);
}
@Override
public void onViewCreated(View view, Bundle savedInstanceState) {
// put your own code here
mMapView = (MapView) getActivity().findViewById(R.id.map);
mMapView.post(
new Runnable() {
@Override
public void run() {
mMapView.zoomToBoundingBox(new BoundingBox(48, -2, 46, 5), false);
}
}
);
}Update: as of v5.6 this should never be an issue. On the first load of the app with osmdroid, the largest writable partition is auto selected (even with permission denial) so the caching of tiles that were downloaded should function in all conditions. That said, you, as the app developer, would probably want to give your users the option to put the cache elsewhere. See the [Update Guide] for more details and the sample app.
Make sure your AndroidManifest.xml file has the android.permission.INTERNET permission. See Prerequisites.
Aug 2016 - someone managed to get the default user agent used by osmdroid banned from Open Street Maps tile servers. This can also be a reason for tiles failing to load (usually with an access denied, bad request or other similar HTTP error message). To fix, set your user agent to something unique for your app. The User Agent is set via org.osmdroid.tileprovider.constants.OpenStreetMapTileProviderConstants class.
If you're on an API23+ device, make sure the app has sufficient runtime permissions (user granted).
Also, if for some reason Environment.getExternalStorage() returns a read only mount point, maps tiles will also not be loaded. To overcome this, set the OpenStreetMapTileProviderConstants.setCachePath(new File("/sdcard/osmdroid2/").getAbsolutePath()); or to some path that you know has write access. This will be revised with osmdroid 5.6 to automatically select the best available path on start up.
Make sure you don't set the MapView to be "clickable". If you are using xml layouts make sure you don't have android:clickable="true" or if you are creating your MapView programmatically make sure you don't have mMapView.setClickable(true);. This should no longer be necessary starting with osmdroid-3.0.11.
Turn off hardware acceleration in your manifest. See Prerequisites.
Update, turning off hardware acceleration is generally not required unless you have specific problems with a given device
This condition can also occur if you somehow manage to change the screen resolution of your android device or virtual machine and do not reboot before launching osmdroid.
osmdroid, since v5.0, has support for inverting the color scheme of map tiles to have a more user friendly experience at night. Your mileage may vary based on map sources. Lighter map sources, such as TOPO or road maps, will appear darker at night. Satellite based tile sources may actually appear brighter at night.
this.mMapView.getController().setInvertedTiles(true);
Starting with 5.1, the API has changed a bit for this. See the change log.
Update: as of v5.6, as long as application private storage is writable, the map should load and cache tiles appropriately.
Yes. osmdroid downloads and caches map data on device and it needs to be stored on some writable medium. We use Environment.getExternalStorage and if that doesn't return a writable location (which happens some devices) then the cache won't be available, which well lead to significantly increased data usage (or osmdroid just won't work at all). The location can be overridden to use application private storage or whatever.
As of 5.6, this was updated to automatically select the largest writable storage directory on start up. The sample application has some logic that you'll definitely want to look at it.
Rather small, at just over 2000 methods.
v5.6 and newer use the IConfiguration interface for all configuration items. Use Configuration.getInstance().set... to configure everything
v5.5 use the following
Yes! Both of these settings are in the following class
OpenStreetMapTileProviderConstants.setCachePath(...)
OpenStreetMapTileProviderConstants.setCacheSizes(...)
OpenStreetMapTileProviderConstants.setOfflineMapsPath(...)
OpenStreetMapTileProviderConstants.setUserAgentValue(...)
UPDATE! This should be fixed for version 5.6 (fixed meaning the icons and graphics won't disappear at zoom 20-22.
Yup, it's a known issue. See the following issues.
https://github.com/osmdroid/osmdroid/issues/416
https://github.com/osmdroid/osmdroid/issues/329
https://github.com/osmdroid/osmdroid/issues/230
https://github.com/osmdroid/osmdroid/issues/114
https://github.com/osmdroid/osmdroid/issues/46
The root cause is that we're using Android's "View" class to map pixel x,y integer coordinates to lat,long (double). As you zoom in, the size of world in pixels increases exponentially and causes integer overflows at zoom levels above 20 towards the extremes of the planet and nearly everywhere by zoom 22. As such, zoom 20 is really the highest that's supported, although osmdroid doesn't restrict you from going to the extremes.
Behaviors to expect when at zoom > 20
- double tapping to zoom in can cause the map to fling towards the other side of the planet
- lines and polygons can disappear
v6.0.0 and up, 29 is supported. Prior to that Zoom 22.
This is because osmdroid uses a number of graphics (Android drawables) that represent things like current device location, zoom in/out buttons, etc. These are not included with osmdroid because it's distributed as a JAR file (versions =< 4.3). You have two options:
- Implement your own version of "ResourceProxy"
- Pull in the osmdroid example application's drawable files into your own application.
This process is detailed here How-to-use-the-osmdroid-library#create-a-custom-resource-proxy
This gets asked a lot. Here's the most common reasons for it not to work
- Does your device have GPS?
- Does your device have GPS service enabled?
- osmdroid only adds the GPS location service by default (in certain versions), you may need to add the Network Location server to the list of sensors that the overlay queries for.
- Are you outside and have a GPS signal?
- Do you have permissions granted in the manifest? (mandatory)
- If targeting API23+, have you asked the user for runtime permissions? (also mandatory)