Street View Data Platforms Compared: Global, Regional, Open and Survey-Grade Sources

Street-level imagery projects usually begin with a map. Someone opens a platform, sees imagery on the streets they care about, and concludes the data exists. Visible imagery and obtainable imagery are different things, and the gap between them has ended more street-view projects than any technical problem.

This guide covers ten platforms across five families, because almost no serious study area is served well by one of them alone. It is deliberately organised around what you can do with each platform rather than around image quality, since quality is rarely the constraint that decides a project — access, licence and coverage are.

Ask three separate questions about every platform

Most confusion comes from collapsing three independent things into one word, "access". A platform can be generous on one and closed on the others, and a comparison that does not separate them will mislead you.

1. Display interface: can you show the imagery to a user inside the platform's own component? Almost always yes, and this tells you nothing about whether you can process the pixels.
2. Data interface: is there a documented endpoint that returns image files and structured metadata to your own code, at a volume that suits your study area?
3. Licence and reuse: what may you store, for how long, what may you publish, and what must you attribute? This is decided by terms, not by whether a download technically succeeds.

Coverage is a fourth question, but it is the one people already ask. The first three are the ones that get skipped.

It also helps to name the three kinds of interface separately, because vendors use the word "API" for all of them. A viewer or display API embeds the vendor's own component in your page and hands you pixels only on screen. A static-image or data API returns image files and structured records to your code, within a documented quota. A commercially licensed feed is a contract that permits bulk delivery of imagery or derived layers, usually with a defined area, term and use. Being able to display imagery says nothing about being able to export it in bulk, and most disappointment in this field comes from treating the first as if it were the third.

Five families of street-level platform

Platforms behave far more like their family than like each other's marketing. Once you know which family a source belongs to, you can predict most of what matters about it before reading a line of documentation.

• Global vendor fleets: Google Street View and Apple Look Around. Purpose-built camera cars, systematic road-network capture across many countries, and terms written for a very large developer base. Google exposes image and metadata endpoints; Apple exposes a viewer.
• Mainland China platforms: Baidu Panorama and Tencent Street View. The practical sources inside mainland China, each with its own coordinate system, developer account and quota regime, and each documenting a panorama static-image service.
• Regional incumbents: Yandex Panoramas, Kakao Roadview and NAVER Street View. Strong local products in their home markets whose public developer surface is a player or SDK, so they belong in a project as display and verification layers unless you negotiate something else.
• Open crowdsourced platforms: Mapillary and KartaView. Contributor-uploaded imagery with real developer APIs and open or attribution-based licences, which makes redistribution possible and coverage unpredictable.
• Survey-grade providers: Cyclomedia and comparable firms. Calibrated capture with LiDAR and depth data, sold under contract for defined areas, aimed at measurement rather than at cheap global breadth.

The selection table

Read the third column as the decisive one. It describes the character of the third-party interface — viewer, image or data API, or licensed feed — rather than whether imagery exists.

Platform by platform

Google Street View — the widest documented image surface

The default starting point for many projects outside mainland China, because it combines broad road coverage with two separate documented image interfaces. The Street View Static API takes a location or a panorama id and returns a flat perspective JPEG, with heading, pitch and field of view under your control. Multiple fixed headings can describe the surroundings of a sample point for measurement, but this endpoint does not hand you a raw equirectangular panorama for export. Its companion metadata endpoint answers whether imagery exists at all, free of charge and without consuming image quota, which is what makes a coverage audit affordable before you commit budget.

Fewer teams know about the second surface. The Maps Tile API includes a Street View Tiles endpoint group, which is the closest thing Google documents to panorama-level access. You open a session with the map type set to street view, then resolve panorama ids, then fetch imagery. Its bulk-resolution method accepts a list of coordinates — up to a maximum of one hundred locations per request, with an optional search radius — and returns one panorama id per location, or an empty string where nothing was found. That single limit sets the shape of any large sampling job: a hundred thousand sample points is at least a thousand requests before a single pixel is fetched.

• The tiles method returns individual panorama tiles across six zoom levels, from a single 512-pixel tile up to a full-size panorama divided into tiles. A viewer is needed to stitch them back together.
• The thumbnail method returns a non-tiled JPEG for a panorama id with your own heading, pitch, dimensions and field of view. Google documents its dimensions as ranging from 16 pixels up to 250 pixels high and 600 pixels wide, so it is a preview surface rather than an analysis-resolution one.
• The metadata method accepts either a panorama id or a coordinate pair with a radius, and returns capture date as year and month when available, panorama dimensions, camera heading, tilt and roll, imagery type, address components, links to adjacent panoramas and the copyright string.
• Google states that panorama ids are transient and should not be relied on beyond a single user session, and that the copyright text from the metadata response must be displayed with every panorama. Both constraints belong in your schema and your UI, not in a footnote.

Apple Look Around — excellent to look at, not a data source

Apple's street-level product is strong in the cities it covers, and since WWDC25 it is available to the web: MapKit JS gained a Look Around view a user can pan and move through, and a Look Around preview element that renders a still frame linking into the full experience. Both are display surfaces, designed to put Apple's imagery in front of a person inside Apple's own component.

Baidu Panorama — mainland China, first source

Google has essentially no street-level coverage inside mainland China, so the domestic platforms are the practical sources there, and Baidu is usually the first one a team reaches for. It documents a panorama static-image service that returns a rendered view for a location or a scene id, which is the interface a sampling pipeline actually calls.

Two things need planning around. Coordinates use the BD-09 system rather than WGS 84, so every sample point needs converting on the way in and every result converting back; a project that skips this lands its points tens of metres off, which is enough to attribute a façade to the wrong side of the street. Second, access runs through a mainland developer account with its own verification and quota rules, and the API catalogue has changed more than once. Confirm the current service, its parameters, your daily and per-second quota, and the applicable terms at scoping time rather than assuming last year's setup still applies.

Historical vintages are also far less consistently retrievable than on Google's surfaces. Change-over-time work in mainland China should be scoped against what the platform actually returns for your specific districts, verified by sampling, and not promised in advance.

Tencent Street View — mainland China, second source

Tencent Location Service still documents a street-view static-image API alongside Baidu's, and the pair is more useful than either alone. The image endpoint takes a size, a location or a scene id, and optional heading and pitch, and returns a rendered JPEG; the documented size ceiling is 960 pixels wide by 640 pixels high, so treat it as a sampling and indicator surface rather than a source of high-resolution façade imagery.

The more interesting endpoint for pipeline work is the scene-point snapping call, getpano. Given a coordinate and a radius — documented with a maximum and default of 200 metres — it returns the nearest scene id, its snapped coordinates and a short description such as the road name. That is the mainland equivalent of a coverage probe: it tells you whether a sample point has imagery, and where the camera actually stood, before you spend an image request. Coordinates are in Tencent's own system, so the same conversion discipline as Baidu applies, with its own transformation.

Yandex Panoramas — the regional incumbent

For Russia and parts of the neighbouring region, Yandex is the platform with meaningful street-level and aerial panorama coverage. What it documents publicly is a player: the JavaScript Panoramas API provides a locate call that takes a coordinate, searches for the nearest panorama and resolves to a panorama object carrying metadata — name, ground or aerial type, bound coordinates, geometry and tile information — and a Player class that embeds that panorama into a DOM element. Yandex notes that Panoramas API requests are fee-based.

That combination makes Yandex genuinely useful for two jobs and unsuitable for a third. It is good for embedding a regional street view in a product, and good for point-by-point coverage verification, because a locate call that resolves to nothing is a real answer about your sample point. It is not a documented bulk imagery export, so do not scope one against it.

Kakao Roadview — South Korea, by agreement

Kakao Roadview is one of the two established street-level products in South Korea. Its Maps SDK lets you request a Roadview either by panorama id or by coordinate, with a look-at position, pan and tilt, and a two-stage search radius: the documentation gives a default search range of 100 metres, extended to 400 metres when nothing is found closer. A successful request returns the panorama id, its position, and a list of Roadview entries by date — which is the mechanism through which a Korean project reaches earlier captures of the same location.

The important line is in the documentation itself: Roadview use requires a separate agreement. Treat Kakao as a display and partnership source. It is a strong choice for a Korean-market product or for date-by-date visual inspection once terms are agreed, and it is not an open bulk download surface.

NAVER Street View — South Korea, viewer-first

NAVER's Maps API, delivered through Naver Cloud Platform, exposes street-level and aerial panoramas through a panorama sub-module you load alongside the map. Applications authenticate with Naver Cloud credentials and register the domains that may call the service. As with Kakao, the official path is a viewer: you position a panorama, the user navigates it, and the imagery stays inside NAVER's component.

For a Korean study area, the honest plan is to use NAVER and Kakao for verification and presentation, cover any processing need from open imagery or your own capture, and raise licensing with the vendor early if the deliverable genuinely requires their pixels. Confirm the current module names, authentication model and quota in the Naver Cloud documentation at scoping time; this is an actively maintained platform and its surface moves.

Mapillary — open coverage with a real API

Mapillary is contributor-uploaded street-level imagery with a proper developer API. The Graph API is queryable by bounding box and returns image ids, sequence membership, capture timestamps, compass angle, geometry and thumbnail URLs at several resolutions, along with platform-computed features such as detections and map features. Coverage and vector tiles let you draw or audit where imagery exists without pulling image records one by one. For a study area with active contributors it is the easiest platform in this comparison to work with programmatically.

# Mapillary Graph API: bounding-box query for imagery metadata.
# The token identifies the application. Review Mapillary's current terms and
# keep the required attribution with any image or extracted data you publish.
curl -G "https://graph.mapillary.com/images" \
  --data-urlencode "access_token=$MAPILLARY_TOKEN" \
  --data-urlencode "bbox=-73.9860,40.7500,-73.9750,40.7570" \
  --data-urlencode "fields=id,sequence,captured_at,compass_angle,geometry,thumb_2048_url" \
  --data-urlencode "limit=500"

Licensing is the reason many research projects prefer it: Mapillary imagery is generally made available under a Creative Commons attribution-and-share-alike licence, which permits redistribution provided attribution is kept. What exactly the share-alike condition reaches in your case — the images you republish, a derived indicator table, a trained model — is a question to settle against Mapillary's current terms and, where the deliverable is commercial, with legal advice. It is not safe to assume every derived product must carry the same licence, and it is equally unsafe to assume none of them do.

The practical caveats are about the contributors rather than the API. Coverage follows where people actually went, so it is dense along commuter routes and mapping-party areas and empty two streets away. Capture devices vary from phones held at a windscreen to calibrated 360° rigs, which changes resolution, lens geometry, exposure and mounting height between images that sit metres apart. Timestamps are per image and can span years within one neighbourhood. Every one of those three has to become a filter and a recorded field in your pipeline, not a footnote in the report.

KartaView — tracks, frames and an open front door

KartaView, formerly OpenStreetCam, is the other open platform: geotagged tracks uploaded by contributors, with endpoints over sequences and their ordered frames. Its imagery is published under Creative Commons Attribution-ShareAlike 4.0, so redistribution is possible with attribution and the share-alike condition carried forward. Because the imagery follows whatever routes contributors drove or cycled, coverage is uneven in a way vendor fleets are not — a single well-covered corridor can sit beside a district with nothing at all.

Access is unusually low-friction. KartaView's FAQ states that most endpoints are publicly accessible without authentication, and that a token is needed for uploading, for profile and content management, and for the higher rate limit — documented as 1,000 requests per hour with a token against 100 without one. Check the current figures in the FAQ before you size a job, but plan around the shape: a token turns a slow reconnaissance script into a workable city-scale harvest, and a rate limit measured per hour means your scheduler, not your bandwidth, sets the pace.

The compensating advantage is that a track is a genuine sequence. Frames arrive ordered and timestamped along a line, which can suit corridor inventory and repeated-route comparison better than a platform's snapped panorama grid. Frame spacing still has to be measured rather than assumed: it depends entirely on the contributor's device and capture run.

Cyclomedia — survey-grade capture, sold under contract

Everything above is consumer-derived imagery repurposed for analysis. Cyclomedia belongs to a different category: a survey company whose vehicles capture calibrated 360° imagery together with LiDAR, aimed at organisations that need to measure from a photograph rather than merely look at one. Its Street Smart viewer brings the 360° imagery, the LiDAR data, map and GIS layers and a depth map into one browser workspace, with measurement tools for linear distance, area, height and clearance, corridor-style navigation along a route, GIS overlays, and shareable views and exports for reporting.

For integration work there is a documented developer surface, all of it behind credentials issued under contract. A coverage web feature service, published as an OGC WFS with bounding-box and distance filters and GML or GeoJSON output, tells you which areas have been recorded and when; a recording-locations service gives the capture positions themselves; and a panorama rendering API delivers imagery into an application. Historical recordings are part of the value proposition, but which capture years exist for your area is a contractual and coverage question to confirm with the vendor, not something to assume.

Choose this family when the deliverable is an asset inventory a municipality will act on, an engineering measurement someone signs off, or an insurance or public-safety review that has to withstand challenge. Do not choose it when you need low-cost breadth across many countries: that is not what it is priced or scoped for.

Bing Streetside: legacy only

Bing Streetside still appears in older tutorials, and its imagery-metadata approach to retrieving Streetside tiles is still documented, which is why proposals occasionally include it. Microsoft's own documentation now carries a retirement notice: Bing Maps for Enterprise is deprecated and has been retired for free (Basic) account customers, while enterprise account customers can continue using it until 30 June 2028, by which point REST APIs and SDKs are expected to move to Azure Maps.

Coverage and history are separate properties

A platform can cover a street today and have no usable record of it three years ago, and the second property is what most change studies actually need. Treat current coverage and historical depth as two columns, never one. Note also that the historical column below describes what is reachable through third-party interfaces — a consumer app that lets a person scroll back through captures is not the same as an endpoint that enumerates them for your pipeline.

The licence decides more than the API does

• Platform imagery obtained through a commercial API is typically governed by terms that restrict caching, storage duration and redistribution. Your deliverable is then usually derived measurements plus a manifest, not an image library.
• Open-licensed imagery under a Creative Commons attribution-and-share-alike licence may be redistributed, but attribution must survive into your outputs, and how far the share-alike condition reaches into derived data is a question to settle explicitly rather than assume in either direction.
• Viewer-only platforms — Apple, Yandex, NAVER, and Kakao without an agreement — can legitimately be embedded and used for verification. Extraction is a separate conversation with the vendor, and it either concludes with a licence or it concludes with a different source.
• Survey-grade providers sell a contract, not an API key. The scope, area, term and permitted use are negotiated, which is slower to start and much clearer to comply with.
• Imagery you capture yourself removes both problems and fixes the capture date to a moment you chose. For a single corridor it is often cheaper than negotiating rights.
• Whatever the source, record the licence per image in a manifest. A dataset whose provenance cannot be reconstructed later cannot be published later either.

Running several sources in one project

Most real study areas need more than one source, and combining them is a legitimate design rather than a compromise. What breaks an analysis is letting sources blend silently: different cameras, mounting heights, resolutions and capture months shift indicators by more than many of the differences you are trying to detect. The fix is structural. Normalise everything that can be normalised, record everything that cannot, and then treat the platform itself as a variable you can control for.

1. Normalise geometry to one coordinate reference system, usually WGS 84, converting BD-09 and Tencent coordinates on the way in and out, and store both the sample point and the platform's snapped camera position.
2. Fix the sampling geometry across sources: the same headings relative to the road, the same pitch, the same field of view, the same output dimensions. An indicator computed at 90° field of view is not comparable to one computed at 120°.
3. Carry a per-image record of source platform, native image or panorama id, capture date, licence, and the retrieval timestamp. Ids from some platforms are explicitly transient, so store them as provenance rather than as a stable key.
4. Add a quality grade per image — resolution band, occlusion, exposure, whether the camera was a phone or a calibrated rig — and use it as a filter before it becomes a hidden bias.
5. Put source and quality into the model or the comparison as control variables, and re-run your headline result with them included. If a conclusion only holds when the mix is ignored, it is a conclusion about the mix.

Three combinations account for most of the work we see. Outside mainland China, a vendor fleet for systematic coverage plus Mapillary or KartaView to fill the corridors the fleet missed or last visited too long ago. Inside mainland China, Baidu and Tencent run as two independent probes over the same sample frame, which turns a single platform's blind spots into a measurable disagreement rather than an invisible gap. In Korea, Russia and other viewer-first markets, the domestic platform for verification and presentation, with processing supplied by open imagery, a negotiated licence, or your own capture along the corridors that matter most.

A short decision rule

1. Study area in mainland China: Baidu and Tencent together, with coordinate conversion and a two-source cross-check planned in from the start.
2. Cross-country comparison outside mainland China: Google, scoped against its terms and billing model, with the free metadata endpoint used for the audit first.
3. Redistribution of imagery required: assess Mapillary or KartaView under their current terms, attribution rules and the licence attached to the specific material.
4. Measurement someone will sign off — asset dimensions, clearances, condition: budget for a survey-grade provider such as Cyclomedia, or capture the corridor yourself with known camera geometry.
5. Korea, Russia or another viewer-first market: use the domestic platform for verification and embedding, and source processable imagery separately.
6. Look Around specifically requested: confirm what your project is licensed to do before scoping, and line up a fallback source for the same area.
7. A legacy system built on Bing Streetside: document it, then plan the migration; there is no like-for-like successor.
8. Any corridor every platform has missed, or last visited too long ago for your question: capture it yourself.

Any platform that has the imagery, we can collect it

The comparison above is a map of the market, not a list of things we cannot do. Google, Apple, Baidu, Tencent, Yandex, Kakao, NAVER, Mapillary, KartaView, Cyclomedia, and any other street-level platform a client names: if the imagery already exists on that platform, we can retrieve it to the specification you send us — headings, dates, density, city-wide or worldwide.

• Every platform above, and others as needed. You name the source and the area; we return the frames and the metadata that source actually holds for that area.
• City-scale collection as a default, not a stretch goal: a whole metro sampled on a regular grid or along the road network, with quality control and a per-image manifest.
• Global-scale campaigns when the study area is a country, a set of countries, or a worldwide sample of cities. The pipeline is the same; the volume is not.
• Cost stays low at volume. Large street-view jobs are priced as production work, not as a pile of retail API calls, which is why a city or a global sample is usually cheaper than teams expect once they have tried to do it themselves.