feat(amazon-location-service): Updated Amazon Location Service plugin to v1.1.0 - #250
feat(amazon-location-service): Updated Amazon Location Service plugin to v1.1.0#250conniescl wants to merge 2 commits into
Conversation
theagenticguy
left a comment
theagenticguy
left a comment
There was a problem hiding this comment.
Review: content verified against the published service models, AWS docs, and third-party sources
We checked every Amazon Location operation, field, and enum in this PR against the machine-readable service models in aws/api-models-aws (geo-places / geo-routes / geo-maps / location), the AWS API Reference & Developer Guide, and the relevant third-party sources (Google Maps SDK docs, MapLibre docs/source, CocoaPods trunk, Maven Central, npm).
The core change is solid. The address-verification rewrite around the Jobs API (StartJob + ValidateAddress) verified clean end-to-end: operations, job statuses, Parquet limits, the geo.amazonaws.com trust policy, S3 permissions + bucket versioning, output column names, enums, and country coverage all match the model and docs. Same for the SKILL.md restructure and the Geocode-vs-Jobs framing. Nice work on that.
The three new Google-migration guides are where the problems are. The Amazon-side concepts are right, but the installation, auth, imports, and "Before" Google code don't match the current SDKs, and several samples won't compile, won't authenticate, or return wrong data. Details are in the inline comments; the headline items:
- iOS: CocoaPods instructions reference pods that don't exist (SPM is the only distribution channel for the Swift SDK and auth SDK);
import Mapboxfails on the pinned MapLibre 6.x;GMSGeocoder.geocodeAddressString/GMSDirectionsService/GMSDistanceMatrixServicedon't exist in Google's iOS SDK; every multi-argument Swift init passes labels in the wrong order (generated inits are alphabetical); two nonexistent type names. - Android: API key passed as a SigV4 access key (fails auth — the supported path is
AuthHelper.withApiKeyfrom software.amazon.location:auth); Mapbox's private Maven repo instructed where Maven Central suffices; missing annotation-plugin dependency and missing mandatoryMapLibre.getInstance(); a dependency-removal instruction the file's own later code contradicts. - Both mobile guides: a hand-rolled Google-Polyline5 decoder presented for route geometry that Amazon Location returns as FlexiblePolyline by default — aws-geospatial/polyline is the official codec and should replace it.
- Web:
MaxDistance→QueryRadius;Walking→Pedestrian; TRANSIT is supported by the Migration SDK's DirectionsService;MigrationEncoding/MigrationPolyaren't importable from the published package; "Simple (the default)" — FlexiblePolyline is the observed default. - Smaller files: category filter applied to SearchText where the API only supports it on SearchNearby; a response-structure example with
TravelStepsat the wrong nesting level and a v1-onlyRouteBBoxfield; an EventBridge pattern thatPutRulerejects; aVerifyDevicePositionsample missing two required fields; a samples link that 404s.
Items flagged as author's-discretion / not fully verified
LegGeometryFormatdefault: the current API Reference doesn't print an explicit "Default value" line for CalculateRoutes (it does for the isoline and snap-to-roads equivalents, both FlexiblePolyline). Our evidence is behavioral: the developer guide's own example omits the parameter and gets FlexiblePolyline back. If you have confirmation that Simple is the default anywhere, we'd take the pointer — but the docs as published point the other way, and this PR's calculate-routes.md defaults table agrees with us.- Category ID casing in the iOS
includeCategories: ["Restaurant"]sample — docs list lowercase IDs; not runtime-verified. GMSPlacesClient.findAutocompletePredictions→ Autocomplete mapping: AmazonSuggestis arguably the closer equivalent for POI/query predictions (Autocomplete is address-oriented). Judgment call, not flagged inline.- dynamic-map.md's MapLibre
main-branch line-number links: behavior verified correct, anchors already drifted; pinning to a tag is a style choice. - plugin.json vs marketplace.json version sync: two other plugins also mismatch, so possibly intentional — flagged, not asserted.
- Pre-existing, not introduced here (fix optional): address-input.md L137 reads
item.Place?.PlaceId, but Autocomplete result items carryPlaceIdat the top level, so the suggestion click handler storesundefined.
Happy to re-review quickly once the migration guides are updated — the fixes are mechanical (correct install/auth/import blocks from the aws-geospatial READMEs plus the one-line API corrections above), not a rewrite.
| pod 'MapLibre', '~> 6.0' | ||
|
|
||
| # AWS SDK for Swift | ||
| pod 'AWSGeoPlaces' |
There was a problem hiding this comment.
Blocker — these CocoaPods don't exist. AmazonLocationiOSAuthSDK, AWSGeoPlaces, AWSGeoRoutes, and AWSGeoMaps all return "No pod found" on CocoaPods trunk. The AWSLocation pod that does exist is the legacy v2 Objective-C SDK (2.4x), a different API from the Swift LocationClient this guide's code uses.
The AWS SDK for Swift and the auth SDK are distributed via Swift Package Manager only. Suggested replacement for this section: instruct SPM setup instead —
- https://github.com/awslabs/aws-sdk-swift (products: AWSGeoPlaces, AWSGeoRoutes, AWSGeoMaps, AWSLocation)
- https://github.com/aws-geospatial/amazon-location-mobile-auth-sdk-ios/ (AmazonLocationiOSAuthSDK)
which matches the auth SDK's own README. The SPM instructions elsewhere in this file are correct — the CocoaPods path should be removed rather than fixed.
|
|
||
| ```xml | ||
| <!-- Remove this --> | ||
| <key>GMSServicesApiKey</key> |
There was a problem hiding this comment.
Minor — GMSServicesApiKey in Info.plist isn't a real Google Maps mechanism. The Google Maps SDK for iOS takes its key via GMSServices.provideAPIKey(_:) in the AppDelegate (Set up an Xcode project), and the comparison table at line 27 of this file says exactly that ("API Key in AppDelegate"). Suggest replacing this Info.plist removal step with "remove the GMSServices.provideAPIKey call from AppDelegate".
| let input = SearchTextInput( | ||
| queryText: "coffee shops", | ||
| biasPosition: [-97.7431, 30.2747] | ||
| ) |
There was a problem hiding this comment.
Blocker (systematic) — Swift labeled arguments must appear in declaration order, and the generated inits are alphabetical. From AWSGeoPlaces/Models.swift: SearchTextInput.init(additionalFeatures:biasPosition:filter:...queryText:travelMode:). So this call must be:
let input = SearchTextInput(
biasPosition: [-97.7431, 30.2747],
queryText: "coffee shops"
)The same reorder is needed in every multi-argument input in this file: SearchNearbyInput(filter:maxResults:queryPosition:) (~L243), GeocodeInput(maxResults:queryText:) (~L286), CalculateRoutesInput(destination:legAdditionalFeatures:origin:travelMode:) (~L332), AutocompleteInput(maxResults:queryText:) (~L592). The auth SDK's README writes SearchTextInput(biasPosition:queryText:) — alphabetical.
| let input = SearchNearbyInput( | ||
| queryPosition: deviceLocation, | ||
| maxResults: 20, | ||
| filter: SearchNearbyInputFilter( |
There was a problem hiding this comment.
Blocker — SearchNearbyInputFilter is not a type. The Swift SDK type is GeoPlacesClientTypes.SearchNearbyFilter (zero occurrences of SearchNearbyInputFilter in the generated Models.swift). Also worth checking: category IDs in the docs are lowercase ("restaurant"), so ["Restaurant"] may not match — author to verify casing against https://docs.aws.amazon.com/location/latest/developerguide/places-filtering.html#place-categories
| import GoogleMaps | ||
|
|
||
| let geocoder = GMSGeocoder() | ||
| geocoder.geocodeAddressString("Austin, TX") { response, error in |
There was a problem hiding this comment.
Blocker — GMSGeocoder.geocodeAddressString() doesn't exist. Google's GMSGeocoder exposes only reverse geocoding, and Google's docs state: "The Maps SDK for iOS does not directly support Geocoding. We recommend that applications use the Geocoding API." This "Before" sample won't compile. Suggest showing the real before-state: an HTTP call to https://maps.googleapis.com/maps/api/geocode/json (which also makes the migration story stronger — Amazon Location gives you a native SDK call where Google required a raw web request). The table row at L262 needs the same fix, and GeocodeCommand/ReverseGeocodeCommand in that table are JS SDK names — the Swift surface is geocode(input:) / reverseGeocode(input:).
| SampleTime: new Date().toISOString(), | ||
| Accuracy: { Horizontal: 10.0 }, // meters, optional but recommended | ||
| PositionProperties: { | ||
| // up to 3 key-value pairs |
There was a problem hiding this comment.
Minor — the limit is 4, not 3. PositionProperties (PositionPropertyMap) allows up to 4 entries in the model; the 3-entry limit belongs to geofence properties (PropertyMap), which zone-alerts.md states correctly. Same fix needed in Best Practices at L285.
|
|
||
| ### `map.loaded()` goes false after `addSource` — causing hangs | ||
|
|
||
| Calling `map.addSource()` or `map.addLayer()` inside a `"load"` callback sets internal dirty flags, making `loaded()` temporarily return `false`. The `"load"` event will **not** re-fire because the map tracks that it already fired once ([`map.ts#L3680`](https://github.com/maplibre/maplibre-gl-js/blob/main/src/ui/map.ts#L3680)). |
There was a problem hiding this comment.
Minor / author's discretion — these main-branch line links have already drifted. map.ts#L3680 currently lands inside setGlyphs and #L3705 (L266) inside addSprite; the described behavior (which we verified is correct) lives near L4193 (loaded()), L4325 (one-shot load fire), and L4349 (idle). Pinning to a release tag (e.g. blob/v5.x.y/src/ui/map.ts#L...) would stop the drift — or drop the line anchors and cite the file only.
| - [Amazon Location Service Developer Guide](https://docs.aws.amazon.com/location/latest/developerguide/) | ||
| - [Amazon Location Service API Reference](https://docs.aws.amazon.com/location/latest/APIReference/) | ||
| - [Amazon Location Service Samples](https://github.com/aws-geospatial) | ||
| - [Amazon Location Service Samples Repository](https://github.com/aws-geospatial/amazon-location-samples) |
There was a problem hiding this comment.
Major — this link 404s. aws-geospatial/amazon-location-samples doesn't exist; the org's sample repos are amazon-location-samples-js, -android, -ios, -react. The pre-PR link (org root) worked.
| - [Amazon Location Service Samples Repository](https://github.com/aws-geospatial/amazon-location-samples) | |
| - [Amazon Location Service Samples](https://github.com/aws-geospatial/amazon-location-samples-js) (also [-android](https://github.com/aws-geospatial/amazon-location-samples-android), [-ios](https://github.com/aws-geospatial/amazon-location-samples-ios), [-react](https://github.com/aws-geospatial/amazon-location-samples-react)) |
|
|
||
| Create effective address input forms with type-ahead completion that improves input speed and accuracy using Amazon Location Service Places APIs. | ||
|
|
||
| **Distinction from Address Verification**: This reference covers the interactive UI/UX of collecting a single address from a user (autocomplete, type-ahead, and resolving a typed address to coordinates). It is NOT postal address validation. To verify and standardize addresses against authoritative postal data — producing a match-confidence verdict and per-component status — use the asynchronous Jobs API (`StartJob` with Action `ValidateAddress`); see the address-verification reference. Geocode returns coordinates and a matched label, not a validation verdict. |
There was a problem hiding this comment.
Author's discretion — slight overstatement that creates cross-file tension. "Geocode returns coordinates and a matched label, not a validation verdict" undersells it: Geocode does return MatchScores (overall + per-component) and AddressNumberCorrected with no opt-in — which address-verification.md L9 and SKILL.md L104 (both in this PR) say explicitly. The real dividing line, as those files put it, is the postal-authority verdict (ValidationGranularity, Mailable/Locatable, per-component StatusDetail). Suggest aligning this sentence to "not a postal-deliverability verdict" so the three files agree.
| "name": "amazon-location-service", | ||
| "repository": "https://github.com/awslabs/agent-plugins", | ||
| "version": "1.0.0" | ||
| "version": "1.1.0" |
There was a problem hiding this comment.
Minor / author's discretion — version sync. plugin.json moves to 1.1.0 but .claude-plugin/marketplace.json still lists this plugin at 1.0.0. Six of the eight plugins keep the two in sync (codebase-documentor is the other outlier), so this may just be an oversight — if marketplace.json is the surface /plugin marketplace add reads, the bump won't be visible to users until it's updated too.
2 participants
feat: Update amazon-location-service plugin to v1.1.0
Updates the Amazon Location Service plugin content to correct address validation guidance.
What changed
Rewrote the Address Verification reference to use the asynchronous Jobs API (
StartJobwith ActionValidateAddress, plusGetJob/ListJobs/CancelJob) instead of Geocode. Key changes:geo.amazonaws.com)MatchScorescapability for single-address ad-hoc checksTesting
Ran
mise run buildlocally — all checks passed.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.