Skip to content

Add Sync26 new changes (Geohashlist)#50

Open
albertoramosmonagas wants to merge 1 commit into
mainfrom
sync26-new-changes
Open

Add Sync26 new changes (Geohashlist)#50
albertoramosmonagas wants to merge 1 commit into
mainfrom
sync26-new-changes

Conversation

@albertoramosmonagas
Copy link
Copy Markdown
Contributor

What type of PR is this?

Add one of the following kinds:

  • enhancement/feature

What this PR does / why we need it:

This change extends Predictive Connectivity Data with optional GEOHASHLIST area support, following the same model introduced in Population Density Data to keep both sister APIs aligned and consistent in their area modelling.

It adds reusable GeohashList and Geohash schemas with geohash validation, restricts the precision field to POLYGON requests only, and clarifies that using precision together with GEOHASHLIST returns 400 INVALID_ARGUMENT. It also introduces new 422 errors for valid but unsupported request values:

  • PREDICTIVE_CONNECTIVITY_DATA.UNSUPPORTED_AREA_TYPE
  • PREDICTIVE_CONNECTIVITY_DATA.UNSUPPORTED_SERVICE_LEVEL

Additionally, CellConnectivityData.geohash is refactored to reuse the common Geohash schema, and the API description is updated to clarify GEOHASHLIST behaviour, including mixed precision levels, non-contiguous geohashes, partial out-of-coverage results using NO_DATA, and full out-of-coverage responses using AREA_NOT_SUPPORTED.

Precision handling is clarified: values outside the schema range 1–12 return 400 INVALID_ARGUMENT, while values within the valid schema range but unsupported by the MNO return 422 PREDICTIVE_CONNECTIVITY_DATA.UNSUPPORTED_PRECISION.

Which issue(s) this PR fixes:

Fixes #38, #39

Special notes for reviewers:

This change intentionally mirrors the GEOHASHLIST modelling introduced in Population Density Data (camaraproject/PopulationDensityData#110) to preserve consistency between both APIs.

Changelog input

 release-note
Added optional `GEOHASHLIST` area support with reusable geohash schemas, clarified precision and service-level error handling, and introduced `PREDICTIVE_CONNECTIVITY_DATA.UNSUPPORTED_AREA_TYPE` and `PREDICTIVE_CONNECTIVITY_DATA.UNSUPPORTED_SERVICE_LEVEL` for valid but unsupported request values.

Additional documentation

This section can be blank.

docs

@camara-validation
Copy link
Copy Markdown

CAMARA Validation — PASS

0 errors, 14 warnings, 5 hints | Profile: standard

View full results

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Align asynchronous response with CloudEvents format to ensure compliance with Commonalities r3.3

1 participant