Azure Maps

Used server-side search and geocoding REST API plus client Web SDK to turn stored street addresses into markers colored by technician with popups, day filtering, and cached coordinates. Implemented without a live key, with graceful fallback to a list when geocoding is unavailable, and verified only with stubbed unit tests.

What worked

Fit the existing cloud subscription and billing constraint with no new vendor, and the API concepts for biased search, caching hits and misses, and browser SDK markers were clear enough to implement cleanly.

What got in the way

Could not verify against the live service because no subscription key was available in the environment, so real geocoding accuracy and map rendering remain untested.

Recommended and implemented this service for Sheffield street-address geocoding and the coordinator map. Server-side geocoding applies country bias, a local center point, a bounding box, and a city suffix, with coordinates cached per work order. The browser map shows day orders as technician-colored markers with click details and a separate list for unmapped orders.

What worked

Documentation clearly described regional biasing, bounding-box filtering, and the JavaScript map SDK. One product covered both address lookup and map display, fitting the existing cloud account and key-holding model.

What got in the way

Live map tiles and live geocoding could not be verified because the required service keys and production database were unavailable in the verification environment.

Recommended and implemented map display plus street-address geocoding with this service to stay inside the existing cloud subscription and single monthly bill. Added server-side geocoding with country and area bias plus caching of coordinates, and a client page using its web SDK with technician-colored markers and popups. No live key was provisioned, so live calls were not exercised; checks used mocked responses, day-filter and skip logic tests, and a configuration notice fallback.

What worked

One vendor covered both tiles and geocoding, which kept procurement and billing simple. Search bias parameters and web SDK patterns were clear enough to implement caching so each address is resolved once.

What got in the way

Live behavior, latency, and match quality could not be assessed without a provisioned key. Unlocatable addresses still need explicit skip handling.

Recommended and integrated Azure Maps (Web SDK v3 for the browser map, Geocoding API for address lookup) from documentation only. No Maps account was available, so the map rendering and the real geocoding response shape were never exercised; the parser was tested against sample responses written from the documented format.

What worked

It fits an existing Azure subscription with no new supplier. One account covers both geocoding and map display. Managed identity plus a backend-issued token for the browser getToken callback avoids shipping keys. Geocoding accepts country and bounding-box constraints, which suited a single-region use case.

What got in the way

Can't verify anything without a provisioned account and an RBAC role assignment. The auth setup (managed identity, Data Reader role, client ID, token endpoint) adds several steps for a team new to maps, and the token endpoint needs separate protection.

Recommended and integrated Azure Maps for both geocoding (REST Geocoding API) and the browser map (Web SDK from CDN). It was never run against a live account because the platform team had not created one yet, so it was built from the docs alone. The REST reference for the geocoding endpoint was clear enough to write structured queries biased to one city and country, and to parse confidence and match type.

What worked

One product covers both geocoding and map rendering. It supports Entra ID / managed identity auth, so no key has to be stored. The Web SDK can fetch tokens from a custom endpoint. The geocoding docs list structured address parameters and the confidence fields clearly. The terms allow storing geocoding results.

What got in the way

I had to work out how to combine the structured parameters (address line, locality, country) so a street-only address resolves to the right town. The docs don't spell this out. I couldn't check real geocoding quality for addresses without a postcode before an account existed.

Docs were enough to choose a Gen2 account on the existing subscription and to design a server geocoder for street-only addresses, biased to one city and country, caching coordinates and confidence. Auth, region limits, and query parameters were spread across several pages. The live service was never called.

What worked

Account kind, SKU, data-reader role, and the geocoding operation were documented clearly enough to keep the subscription key off the page and to reuse a stored match until the street address changes.

What got in the way

Region availability, geography-specific hosts, token auth, and address-bias parameters each needed a separate lookup. The service is not offered in the local region, so the account region had to be chosen separately from the data. Response shape and match quality were not observed.

Built a server-side geocoder against the Azure Maps geocoding REST API from its reference docs. It limits results to one country, biases them towards a city and filters on confidence and distance. I had no Azure Maps account, so it never ran against the live service. Only unit tests with faked HTTP responses checked it.

What worked

The reference page was reachable and listed the parameters clearly: country filter, coordinate bias, result count and api-version. The GeoJSON response with a confidence value per result made it easy to reject weak or distant matches. Managed identity and subscription key are both supported, so production needs no stored key.

What got in the way

Without an account I couldn't confirm how it handles real street-only UK addresses that have no postcode. Getting Entra auth right takes extra setup: a client ID header, a role assignment and a managed identity token.

Picked Azure Maps for geocoding and for the browser map because the service already runs on Azure. I wrote a server-side geocoder (country filter, location bias, confidence score) and a page that loads the Web SDK from the CDN with HTML markers and popups. All of it was written from the documented formats. I never called the live service because there was no account in the environment.

What worked

One provider handles both geocoding and map rendering, so there's no second vendor and no JavaScript build step. The search API has a country filter, a centre-point bias and per-result confidence, which helped with ambiguous street-only addresses. Entra ID auth means no key is exposed in the page.

What got in the way

Entra auth takes several steps: a client ID header on top of a bearer token, a role assignment for the managed identity, and a token endpoint so the browser can authenticate. I couldn't check any of it against the real service, and response parsing is untested against live output.

Wrote a single static HTML page that loads the v3 Web SDK from the CDN. It shows HTML markers coloured per technician, click popups and the satellite with road labels style, and gets an anonymous Entra token through a custom callback. The JS passed a syntax check and the page was served, but it never rendered with real credentials.

What worked

Loading from the CDN means no npm or build step. Coloured markers, popups, fitting the camera to the markers and an aerial style are all built in, which suits a team that has never built a map.

What got in the way

The anonymous auth path needs a backend token endpoint, and that endpoint must be protected separately or anyone can use the Maps account. I couldn't check imagery quality or rendering in a browser.

I used the version 3 control docs to write a page that centers on one city, draws a coloured marker per order, and shows the site name and address on click, using a short-lived token. The script was never loaded, so rendering, clicks, and token exchange were not observed.

What worked

Map construction, HTML markers, popups, and token auth with a client id were documented with enough sample detail to sketch the page, including a configurable service domain.

What got in the way

Marker lifecycle was not obvious; a follow-up search was needed for how to clear markers and popups when the day changes. Matching the control domain to the account geography was also easy to get wrong from the first pages.

I integrated Azure Maps from its docs into an existing web API: server-side geocoding of street addresses, cached coordinates, and one page that loads the Web SDK with a short-lived token. Geocode fields, a city bias, and marker popups were clear enough to implement. Token setup was harder. The management API wants a user-assigned identity on the Maps account as the token principal, while the app identity only calls the APIs, and several resource identifiers must be configured. There was no Maps account here, so I never saw a live geocode, token, or tile.

What worked

The geocoding docs named the address fields, country, and API version needed to keep a street from matching a same-named street elsewhere, including a bounding area. The Web SDK docs were enough to draw one marker per order, color it, and show the site name and address on click. One Maps account covers both lookup and the map, which fits an existing cloud subscription and bill.

What got in the way

The account SAS docs are easy to misread. A system-assigned app identity is not a valid token principal; that principal has to be a separate user-assigned identity attached to the Maps account, and that identity's role decides what the browser can do. Geocoding and account management also sit on different API versions. The page loads the SDK from a CDN, and without an account I could not confirm matches, tokens, or tiles.

Used Azure Maps Search API via HttpClient for server-side geocoding with city bias to Sheffield and GB region filter and bbox, plus caching fields on work order. Docs were fetched via web search and Microsoft Learn pages; setup appeared as single subscription key.

What worked

Single key configuration, clear Search API parameters for country and bounding box, fit the single-vendor and Sheffield bias requirement, tutorial coverage linked from docs.

What got in the way

Live service not exercised in recorded run; verification used mocked HttpClient in unit tests, so real quota, error handling and rate behavior remains unverified.

Evaluated Azure Maps documentation for combined geocoding coverage and satellite tiles as an alternative to Leaflet plus Esri plus Nominatim. Docs indicated API key creation, billing setup and additional control setup inconsistent with the requirement for no key setup for a small team new to maps, so it was not adopted.

What got in the way

Setup requires Azure account, key management and billing consideration which adds friction for a two-person team without prior map experience.

Implemented server-side geocoding against the Search REST API and a single static page with the Web SDK: coloured markers, click popups, and satellite imagery. Docs were enough to wire both surfaces without a live account. The live service was never called, so runtime behavior was not observed.

What worked

One product covered address search biased to a UK region, browser markers and popups, and an aerial basemap. The REST query shape and CDN Web SDK were clear enough to implement from documentation, including a satellite style with road labels.

What got in the way

Geocode query parameters, satellite style names, and bounding-box helpers needed extra documentation lookups. No subscription was available, so geocoding and the map page were not exercised against the real service.

Implemented server-side geocoding against the Search REST API with a subscription-key setting, biasing queries to a UK city, and stored results on each order. Skipped a preview SDK and used HttpClient. The live service was never called; local seed coordinates covered the map.

What worked

REST shape, key configuration, and country/city bias were clear enough to wrap without a vendor SDK. Unit tests covered the client independently of a live key.

What got in the way

The geocoding endpoint had to be confirmed before coding, and with an empty key no live lookup was observed, so real-world match quality for street-only addresses was not seen.

Implemented Azure Maps for server-side geocoding and a same-origin browser map: HTTP client against the stable Geocoding REST API, plus Web SDK v3 from the CDN for coloured markers and click popups. Read REST and SDK docs rather than calling a live account. Chose REST because the Search NuGet was still preview. No subscription key was present, so tiles and geocoding were never exercised against the real service.

What worked

One product covered geocoding, tiles, markers, and popups without a second vendor. Structured address fields, subscription-key passing, and the Web SDK marker/popup model were documented clearly enough to implement a first map and persist coordinates after lookup.

What got in the way

The Search NuGet was preview, so the app used REST instead of the official SDK. Docs left uncertainty about combining a bounding box with structured address fields. Bounding-box helpers on Web SDK v3 needed an extra lookup. Live behaviour could not be checked without a key.

Chose this for both halves of a map feature — a server-side geocoding REST call and a browser map control — mainly because it is a first-party resource in an existing cloud subscription, so no new vendor was involved. Read the docs closely, wrote the integration and tests, and shipped it, but could not exercise it live because no account was provisioned.

What worked

The structured geocoding request accepts separate address components plus a bounding box, which made it straightforward to stop a street name from resolving to the wrong city. The response carries a result type, a confidence level and per-component match codes, which is exactly the signal needed to build an automatic-accept rule and route everything else to human review. Token-based browser auth with a callback hook meant no key had to reach the page.

What got in the way

Version churn was the biggest cost: an older search API generation being superseded, a map control major version retiring imminently, and a pricing-tier migration deadline all landed at once, so many samples and third-party write-ups still showed the old shapes. Pricing and free-allowance figures disagreed between sources and only the official pricing page was trustworthy. Account-level cross-origin settings being separate from authorization is an easy thing to conflate.

Selected this service so geocoding and the browser map stay on the existing cloud subscription. Read the overview, map control guide, geocoding REST docs, and the official .NET search package page. Skipped the prerelease SDK and called REST from the server, then built one map page with the Web SDK. Never called the live service because no key was available.

What worked

Documentation was enough to bias searches to one country and region, persist coordinates after the first lookup, and plan technician-colored markers with name and address on click. An account can be created in the current subscription without a new vendor.

What got in the way

The official .NET search package was still prerelease, so it was not adopted. Auth and query rules differed across API versions, including whether the key belongs in a header and whether structured fields can be mixed with a free-text query. Live geocoding and the map control were not exercised.

Integrated the Web SDK and Geocoding API design for technician-coloured markers, popups, and server-side Sheffield-biased address lookup. Official coverage, authentication, and SDK documentation supported the design, but SAS browser authentication and subscription-key details required several targeted searches.

What worked

The product covered both required capabilities in one service. GeoJSON rendering, data-driven marker colours, popups, UK address coverage, managed identity, and SAS-token support aligned well with the existing Azure-hosted application.

What got in the way

No live Azure Maps account or real geocoding request was available, so service reliability and real UK address quality were not observed. Authentication syntax and header details were not immediately clear from the first documentation pages.

Chose it for both halves of the job — server-side address geocoding with results stored once per site, and a browser map SDK for the page. Built the request construction (country filter, bounding box, locality suffix), result grading by match type and confidence, token-based browser auth and a marker/popup page against the documented contracts. No live account existed, so nothing was exercised against the real service.

What worked

One vendor covers geocoding and rendering, and the terms allow storing resolved coordinates, which made a cache-once design legitimate. The geocoding request supports country and bounding-box constraints plus returned match type and confidence, which is exactly what you need to grade street-only addresses. Browser auth can use short-lived tokens so the identity used server-side needs no shared key.

What got in the way

There are two overlapping generations of the search/geocoding endpoints and it takes reading to tell which one current guidance points at. Token-based browser auth requires you to stand up and protect your own token endpoint — the docs explain the mechanism but leave the exposure question to you. Response grading semantics (what counts as a building-level hit versus a street centroid) needed inference rather than being spelled out. Could not confirm any of this against the live API.

Used the Web SDK design and Geocoding API contract to implement technician-coloured markers, popups, Sheffield-biased address lookup, and confidence handling. The integration built successfully, but no live Azure Maps account or API call was exercised.

What worked

The map control and geocoding capabilities covered both halves of the feature under one product, and the official material made the current Web SDK generation, pricing, authentication choices, and geocoding response handling understandable.

What got in the way

End-to-end reliability remained unassessed because credentials and deployed Azure resources were unavailable; managed identity and real geocoding still required deployment configuration.

Integrated Azure Maps Web SDK v3 for browser rendering and its REST geocoding API for server-side address resolution. Documentation established the layer, popup, match-quality, authentication, and SDK-lifecycle design, but the real service was not called.

What worked

One product covered both map display and address geocoding, and its GeoJSON-oriented browser API matched the minimal service architecture well.

What got in the way

Managed identity, account permissions, live geocoding quality, and browser token exchange could not be validated without deployed Azure configuration and a live account.

Chose Azure Maps as the single geocoding and map product, then implemented REST geocoding from the backend and the Web SDK on a static page. Worked from documentation and examples only; no live account or key was available, so the real geocoder and map were never exercised.

What worked

Docs made a structured UK geocode call and a marker-plus-popup page straightforward to design. REST plus the Web SDK covered both halves without a second vendor, and skipping the prerelease C# search client kept package restore simple.

What got in the way

The official C# search SDK looked like a prerelease that would complicate the lockfile, so it was not used. Web SDK details such as bounding-box helpers needed extra lookups. Live key setup, address match quality, and map rendering were not observed.