Partager via


Directly accessing the Bing Maps tiles

Note

Bing Maps Get Imagery Metadata API retirement

Bing Maps Get Imagery Metadata API is deprecated and will be retired. Free (Basic) account customers can continue to use Bing Maps Get Imagery Metadata API until June 30th, 2025. Enterprise account customers can continue to use Bing Maps Get Imagery Metadata API until June 30th, 2028. To avoid service disruptions, all implementations using Bing Maps Get Imagery Metadata API will need to be updated to use Azure Maps Get Map Tile API by the retirement date that applies to your Bing Maps for Enterprise account type. For detailed migration guidance, see Migrate Bing Maps Get Imagery Metadata API.

Azure Maps is Microsoft's next-generation maps and geospatial services for developers. Azure Maps has many of the same features as Bing Maps for Enterprise, and more. To get started with Azure Maps, create a free Azure subscription and an Azure Maps account. For more information about azure Maps, see Azure Maps Documentation. For migration guidance, see Bing Maps Migration Overview.

Adding Bing Maps as a tile layer in a non-Bing Maps control can be done as outlined in this document. It should be noted that the tile URLs for Bing Maps change regularly and as such directly accessing tiles from a hardcoded URL is not allowed. It should also be noted that Bing Maps data cannot be integrated with competing mapping platforms as noted in the terms of use.

In order to access the Bing Maps tiles in a supported way you will first need to get the current tile URLs from the Bing Maps Imagery REST service every time your application starts. The main purpose of this is to ensure your application is using the latest tile URLs, which helps to prevent your application from breaking, and also provides a way to track the usage of the service in such a way that aligns with the Bing Maps terms of use. The Bing Maps REST Imagery Medata service can be used to get the current tile URLs. If you need to use this service from .NET, see the Using the REST Services with .NET document. Making a request to the imagery service like this:

http://dev.virtualearth.net/REST/V1/Imagery/Metadata/RoadOnDemand?output=json&include=ImageryProviders&key={BingMapsKey}

This will return a response that contains an Image URL property. This URL will look something like this:

http://ak.dynamic.{subdomain}.tiles.virtualearth.net/comp/ch/{quadkey}?mkt=en-US&it=G,L&shading=hill&og=2390&n=z

You can then replace the different parts of the URL to request each tile as needed. The imageUrlSubdomains property in the imagery metadata response provides a list of valid subdomain that can be used in the tile URL. Using a different one for each tile request you can increase performance by get around browser URL request limits i.e. many browsers allow up to 8 concurrent requests to the same domain. Using subdomains allows up to 8 requests per subdomain. The culture value can be any value listed in the Supported Culture Codes document. The quadkey value can be calculated based on the zoom level and the tile you wish to render. Information on the tile system along with some useful code can be found here:

In addition to this, the query will also return information on the imagery providers and copyright information which should be displayed with the imagery to align with the requirments of the terms of use.

Licensing queries can be sent here.