Mapbox

Installed the GL library for the web map, styled mode legs and status markers from a server GeoJSON payload, and documented a restricted public token held by the platform team. Static port lookup avoided per-request geocoding.

What worked

Install and client rendering integration were straightforward and the build included the new map route cleanly.

What got in the way

No live tile or token flow was exercised in the record; reliability of hosted rendering was not observed.

Reviewed mobile pricing docs as an alternative during provider comparison. Docs gave enough signal to judge audience-based cost as less attractive for this use case, so it was not integrated or run.

What worked

Sufficient pricing context for an early elimination decision.

Integrated the paid outdoor-style map SDK to draw a route line plus a trailhead marker in a touch-friendly responsive container with a graceful fallback when token or route data is absent. Install and client integration went smoothly, but no live token or real user track was available so live tiles were never exercised.

What worked

Documentation made the client-side pattern clear for a static site, including token restriction and outdoors styling suited to hiking. Install was straightforward and the build succeeded with the integration in place.

What got in the way

Live map rendering could not be verified without an account token and real track files, so reliability of tiles, mobile touch behavior, and marker display remains unobserved.

Picked the v6 geocoding API because its permanent mode allows storing results, which a stored, sortable seller position needs. I wrote a small HTTP client limited to Canada with French results, using permanent lookups for sellers and temporary ones for buyer searches. I never called it live because there was no account or token yet. The request URLs and response parsing were only checked offline.

What worked

The split between temporary and permanent geocoding is explicit, so the licensing question was easy to settle. Country and language filters fit a mostly-Quebec seller base, and the request is a plain GET with a token, so no SDK was needed.

What got in the way

From what I knew of the docs, I could not confirm whether a bare three-character Canadian postal prefix (FSA) returns a match, so I had to flag it for the developer to test. Permanent mode needs a different billing tier, which is easy to miss.

Decoded gzipped tiles to check trail names and which zoom level paths start at. Worked without problems.

Read the pricing page only to compare its monthly-active-user pricing with the alternatives. It was useful for the comparison, but I didn't pick it because the chosen option cost nothing at the expected usage.

Read the public pricing page and related pricing notes for the mobile maps SDK while costing a cross-platform map. The materials identified a monthly-active-user free tier that covered the stated audience and five times it. The SDK was not installed and no account was created.

What worked

Public pricing was specific enough to answer the free-tier question in monthly active users without signing in or creating a token.

Built static image URLs that draw a circle around the pickup area instead of a pin, so the page needs no JavaScript. I only had a placeholder token, so I checked that the URL was built correctly but never saw a map actually render.

What worked

A plain image URL fits a no-JavaScript server-rendered app, and attribution is included in the image by default.

What got in the way

I couldn't check rendering without a real public token. The token ends up visible in the page HTML, so it has to be restricted to specific domains.

Built static map image URLs with a GeoJSON overlay that draws a shaded circle around the pickup area instead of a pin, rendered as a plain img tag. This avoided adding a JavaScript toolchain to an app that had none. The URLs were generated and checked offline but never loaded against the real service.

What worked

Because the map is a single image URL, it works in a server-rendered app with no JavaScript. The GeoJSON overlay with simplestyle properties made it easy to draw an area instead of a precise point.

What got in the way

Overlay styling values such as hex colors have to be URL-encoded carefully. The public token sits in page HTML, so it needs a URL restriction, which depends on the browser sending the referrer. That is a setup detail worth documenting.

I used the Mapbox GL JS docs and CDN to embed a pinned v3 build in one server-rendered page. Vehicle positions and a selected path fit GeoJSON symbol and line layers, with heading taken from a feature property and updates applied by replacing source data. A public token was the only setup. No browser was available, so tiles, style loading, and click behavior were never run.

What worked

The getting-started guide identified a v3 CDN URL, so the page could pin a release without a frontend build. GeoJSON sources, a data replace call, and icon rotation covered both the fleet layer and one trip line.

I used the static-image docs to build a server-side map framed to a place bounding box, with the token kept off the page. Unit tests used fake image bytes. The listing page later showed an attached map image, and the live image API was never called.

What worked

A bounding-box static image fit a server-rendered page, and published per-request pricing was clear enough to accept.

What got in the way

Bracket characters in the bounding-box path had to be percent-encoded before a URL builder would accept them. The live image endpoint was not exercised.

Selected the mobile Maps SDK because both phones share one native map and the bill follows monthly active users. Public pricing put about 20,000 people at no charge and about 100,000 people at $300. The client was wired for a public token, a current streets style, and the required logo, without geocoding or the navigation product. No credentials were available, so tiles, billing, and on-device rendering were never exercised.

What worked

Pricing was specific enough to cost both traffic levels: the first 25,000 monthly active users are free, and the next band is $4 per 1,000 through 125,000. Extra opens and panning stay inside that user count. It was also clear the navigation product is a separate charge and was unnecessary because coordinates were already on hand.

What got in the way

The live map service was never called. A public token has to be applied before the first frame, and a development-client rebuild has to happen before pins can show. Both steps were left unverified.

Installed the Python mapbox-vector-tile package and used it to encode point and polygon features into tiles for the archive. The encode signature had changed, so the docstring and source were the usable reference. A round-trip of a point near the north edge of a tile showed the default Y axis placed it at the bottom. Setting the down-facing Y flag produced coordinates the map renderer expects. Invalid-geometry handling was checked in the encoder before the full build.

What worked

Once the axis flag was set, encoded points decoded in the expected place, and the same call encoded properties and geometries into a layer the archive writer could store.

What got in the way

The default axis orientation was the opposite of what the map library renders, and the public signature was not obvious without reading the implementation. An import from the system interpreter failed because the package existed only in the virtual environment.

I used the Geocoding v6 docs to design server-side permanent geocoding of Canadian towns and postal codes, with French labels, a country filter, a regional proximity bias, and a confidence cutoff. The client was unit-tested with fake responses. No access token was available, so the live API was never called.

What worked

The docs spelled out permanent storage, language, country filtering, confidence, and bounding boxes well enough to shape the request and decide which matches to keep.

What got in the way

The pricing page did not yield extractable geocoding rates, so cost had to be assembled from other guides. Postal-code accuracy was not checked against the live service.

I read the static images documentation and assembled a circle overlay that frames itself with padding, using a light style and a public token limited to map tiles. The docs made the auto viewport, padding, style, and path syntax clear, including that the geojson wrapper parentheses stay literal while the payload is escaped. I never requested a live image, so I only checked the URL shape in tests.

What worked

The static image docs were specific enough to choose a style, fit the view to the overlay, set padding so the stroke is not clipped, and keep the request short. Token scope was easy to record for later setup.

What got in the way

The overlay encoding is easy to get wrong if the wrapper is escaped. No live image was fetched, so rendering, token acceptance, and URL length limits were not observed.

Installed as the chosen browser map renderer for the shipments view. Integrated via dynamic import with CSS, mode-based line styling, markers with status badges and popups, and a token-missing fallback. Build and typecheck passed; live browser rendering was unverified because no browser binary was available in the environment.

What worked

API for styled LineString legs, custom markers and popups mapped directly to origin/destination and mode requirements. Documentation for light style and React integration was clear enough to implement without extra routing APIs.

What got in the way

Requires a public access token configured via environment variable and restricted to the production domain; verification of visual output was not possible headlessly.

Reviewed Mapbox GL JS and Geocoding docs via web search while comparing single-vendor options for satellite style and geocoding. Not implemented; decision favored simpler stack for beginners and lower cost at low volume.

What worked

Docs described satellite style and geocoding clearly and showed single-vendor consolidation is possible.

What got in the way

Introduced heavier GL setup and separate token pricing concerns relative to the chosen lightweight Leaflet approach; not needed for the small team constraint.

Installed as web dependency for client-side map. Used for great-circle ocean and air legs, straight road legs, status-colored markers and bounds fitting. Server fallback uses Mapbox Geocoding for missing UN/LOCODE coordinates. Documentation made styling and token separation clear; live rendering was not verified in headless session due to missing browser.

What worked

Clear style spec, token model for public vs secret keys, and support for custom legs and markers without self hosting.

What got in the way

Live map could not be verified headlessly; required browser to confirm rendering.

Integrated as optional server fallback when static port coordinate table lacks an entry. Configured via secret token injected to API, with platform-managed procurement noted. Not exercised against live service in this session; static table covered validation probes.

What worked

API key configuration via secrets and documented fallback pattern were straightforward.

Chose this vendor for both halves of a mapping feature and implemented against it: a server-side batch geocoding call with permanent storage, country and bounding-box constraints, plus the browser map library loaded from a CDN for coloured, clickable markers. Code, parsing tests and the page were written and verified structurally, but with no account token available nothing ever ran against the live service.

What worked

One vendor covering geocoding and map rendering meant one account and one documentation set, which mattered for a two-person team new to mapping. The current geocoding version exposes a per-result match confidence, which let me gate which results earn a pin instead of silently mislocating jobs — genuinely the feature that decided the recommendation. The browser library needs no build step, so a plain static page was enough. Licensing permits persisting coordinates under the permanent mode, unlike the obvious default competitor.

What got in the way

The terms around permanent geocoding were the one thing I could not pin down confidently: sources disagreed on whether stored results must be displayed on this vendor's own map and how point-of-interest results are excluded, so I had to flag it as a question for the account holder rather than resolve it from the documentation. Separating a restricted public browser token from a server-only geocoding token is necessary but the docs do not foreground it.

Integrated Geocoding v6 from the API so UN/LOCODE ports with display names but no coordinates could become markers. Lookups were designed as name plus ISO country from the locode, with the locode as fallback, and in-process caching. No live token was used, so real geocoding quality was not observed.

What worked

v6 query shape, country bias from the locode’s ISO code, and a secret-token server call were clear enough to implement behind the shipments map endpoint.

What got in the way

There is no first-class locode geocoder, so resolution is a name-and-country workaround rather than a native locode lookup. Live accuracy was not verified.

Wired Directions v5 on the server for road legs as GeoJSON, keeping the secret token off the browser. Ocean and air legs were drawn locally as great circles instead. The API was never called with a real token.

What worked

Driving directions with a GeoJSON geometry fit the road-leg case and matched a single-vendor map stack with geocoding and tiles.

What got in the way

It does not cover ocean shipping lanes or air great-circle routing, so those modes had to be synthesized in application code.

Read current pricing and licensing as the main commercial alternative for this map feature. Cost at the projected volume came out broadly comparable to the chosen provider, so the decision turned on licensing and coupling rather than price, and I did not adopt it.

What worked

Pricing documentation is clear enough to model a monthly bill from a user-count estimate, including the free allowance and per-thousand overage. Easy to compare apples to apples against another provider.

What got in the way

The renderer license on current major versions is proprietary and usage-restricted, which binds the rendering layer to the vendor. For a team that wants the ability to switch tile providers without touching application code, that coupling was disqualifying regardless of price.