gnss: handle longitude <=-180 or >=360#1290
Conversation
+ objects/gnss.py: add `_set_longitude_range()` to handle the longitude data range - ensure longitude is within (-180, 360) - could specify the data range format, in either [0, 360) or (-180, 180] via `lon_range` arg + call `_set_longitude_range()` in all the child class of GNSS This error is happending for the GNSS_UNR sites in Japan, where the longitude of G073 can be -229, resulting in NaN value for inc/az_angle extration from the geometry file, in the old code.
Reviewer's Guide by SourceryThis PR introduces a new longitude handling mechanism in the GNSS module to properly handle longitude values that fall outside the standard ranges. The implementation adds a new utility function Class diagram for GNSS longitude handling updateclassDiagram
class GNSS {
+_set_longitude_range(lon, lon_range)
}
class GNSSChild1 {
+get_site_lat_lon(print_msg)
}
class GNSSChild2 {
+get_site_lat_lon(print_msg)
}
class GNSSChild3 {
+get_site_lat_lon(print_msg)
}
GNSS <|-- GNSSChild1
GNSS <|-- GNSSChild2
GNSS <|-- GNSSChild3
note for GNSS "New method _set_longitude_range added to handle longitude normalization"
note for GNSSChild1 "Updated to use _set_longitude_range for longitude normalization"
note for GNSSChild2 "Updated to use _set_longitude_range for longitude normalization"
note for GNSSChild3 "Updated to use _set_longitude_range for longitude normalization"
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
PR summaryThis Pull Request addresses a bug in the GNSS module related to handling longitude values that fall outside the typical range, specifically for GNSS_UNR sites in Japan. The changes introduce a new function, SuggestionConsider adding unit tests for the Disclaimer: This comment was entirely generated using AI. Be aware that the information provided may be incorrect. Current plan usage: 0.00% Have feedback or need help? |
There was a problem hiding this comment.
Hey @yunjunz - I've reviewed your changes and they look great!
Here's what I looked at during the review
- 🟡 General issues: 1 issue found
- 🟢 Security: all looks good
- 🟢 Testing: all looks good
- 🟡 Complexity: 1 issue found
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
+ rename `_set_longitude_range()` to `standardize_longitude()` + move the function from objects/gnss.py to utils/utils0.py
+ `utils.utils0.py`: add `standardize_longitude()` to handle the longitude data range - ensure longitude is within (-180, 360) - could specify the data range format, in either [0, 360) or (-180, 180] via `lon_range` arg + `objects.gnss.py`: call `ut.standardize_longitude()` in all the child class of GNSS This error occurs for the GNSS_UNR sites in Japan, where the longitude of G073 can be -229. In the old code, this results in a NaN value for inc/az_angle extraction from the geometry file.
Description of proposed changes
utils/utils0.py: addstandardize_longitude()to handle the longitude data rangelon_rangeargobjects/gnss.py: callut.standardize_longitude()in all the child class of GNSSThis error occurs for the GNSS_UNR sites in Japan, where the longitude of G073 can be -229. In the old code, this results in a NaN value for inc/az_angle extraction from the geometry file.
Reminders
Summary by Sourcery
Ensure longitude values are correctly handled within the GNSS module by introducing a function to set longitude ranges, preventing errors in data processing.
Bug Fixes:
Enhancements:
_set_longitude_range()to standardize longitude values across GNSS data processing.