Skip to content

Add precision, height and signal strenght to the wip version#25

Merged
albertoramosmonagas merged 7 commits intomainfrom
update/functional-enhancements
Jul 8, 2025
Merged

Add precision, height and signal strenght to the wip version#25
albertoramosmonagas merged 7 commits intomainfrom
update/functional-enhancements

Conversation

@albertoramosmonagas
Copy link
Contributor

@albertoramosmonagas albertoramosmonagas commented Jul 1, 2025

What type of PR is this?

Add one of the following kinds:

  • enhancement/feature

What this PR does / why we need it:

The PR includes:

  • Allow output to include Signal Strength (Allow output to include Signal Strength (in addition to Service Level) #8): Enables the API to return Signal Strength (e.g., dBm) in addition to Service Level, either by default or via an optional parameter. This improves flexibility for applications requiring more detailed connectivity metrics and aligns the output structure with the Population Density Data API.
  • Support precision as an input parameter (Support precision as an input parameter #7): Adds an optional precision input to let clients define the granularity (in meters or discrete levels) of the prediction results, reducing unnecessary computation and improving efficiency.
  • Support height as an input parameter (Support height as an input parameter #6): Introduces an optional height (altitude) parameter for 3D predictions, supporting use cases like drones, multi-story buildings, and urban air mobility.

Which issue(s) this PR fixes:

Fixes #6, #7, #8, #17

Special notes for reviewers:

Added changes commented on the first wip version of the API - PR#20

Changelog input

 release-note
- Added the option to include Signal Strength (e.g., dBm) in the API response in addition to Service Level. Clients can request Service Level, Signal Strength, or both, improving flexibility and alignment with other CAMARA APIs (e.g., Population Density Data).
- Introduced an optional precision input parameter to let clients define the prediction granularity (in meters or discrete levels), reducing unnecessary data processing and over-fetching.
- Added optional height (altitude) input to support vertical mobility use cases such as drones, multi-story buildings, and urban air mobility. This enables 3D geolocation-aware predictions.

Additional documentation

This section can be blank.

docs

@albertoramosmonagas
Copy link
Contributor Author

albertoramosmonagas commented Jul 1, 2025 •
edited
Loading

Hi @eric-murray ,

This PR includes the changes we discussed in the WIP version. When you have a chance, it would be great if you could review the implementation of the height, precision, and signal strength solutions. We’re a bit behind schedule for M3, so merging this soon would help us move forward and prepare the Release Candidate.

Also, I am not able to solve the error that the lint gives, in case you are able to see it.

Thanks a lot for your support!

@github-actions
Copy link

github-actions bot commented Jul 1, 2025 •
edited
Loading

🦙 MegaLinter status: ✅ SUCCESS

Descriptor Linter Files Fixed Errors Elapsed time
✅ ACTION actionlint 2 0 0.02s
✅ REPOSITORY git_diff yes no 0.01s
✅ REPOSITORY secretlint yes no 0.57s
✅ YAML yamllint 1 0 0.37s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by OX Security

@albertoramosmonagas
Copy link
Contributor Author

albertoramosmonagas commented Jul 2, 2025

Hi @eric-murray

We have temporarily disabled Spectral linting both in the dedicated workflow and in MegaLinter.

Spectral has an internal issue handling null values in arrays, which causes errors when running rules that expect strings or numbers.

Example triggering the problem:

layerSignalStrengths:

  • -85.5
  • -84.0
  • -83.0
  • -82.0
  • -81.0
  • null
  • null
  • null

This is a known Spectral limitation (see Spectral issue #2139).

It doesn’t make sense to modify the API spec just to bypass this, since null is a valid OpenAPI value.

What we did?
• Disabled OPENAPI_SPECTRAL in MegaLinter.
• Other linters remain active.

Next step: We will open an issue for Raphal to review and address this in the next iteration.

Could you please review this PR to confirm if the implementations are correct and let us know if we need to adjust anything?

We’re a bit tight on time with M3, so it’s important to ensure everything is aligned before merging.

Thanks!

@albertoramosmonagas
Copy link
Contributor Author

albertoramosmonagas commented Jul 4, 2025

@eric-murray Hi! have you had time to take a look at the PR?

@eric-murray
Copy link
Contributor

eric-murray commented Jul 8, 2025

OK, this is fine. I'll approve now.

Main issue I have is that there is no way to request only the signal strength data. I'd propose to add a "null" service level with no specific service level requirements - let's call it "BEST_EFFORT". So the API will still give a service level for a best effort service (GC, MC, NC, ND - these being somewhat more subjective service levels now) , and optionally raw signal strength data if requested and supported.

Anyway, let's discuss during the meeting today

@albertoramosmonagas albertoramosmonagas merged commit e2a17db into main Jul 8, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@eric-murray eric-murray eric-murray approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Support height as an input parameter

2 participants

@albertoramosmonagas @eric-murray