[uss_qualifier] Add EGM2008 support on uspace/netrid/msl#1302
[uss_qualifier] Add EGM2008 support on uspace/netrid/msl#1302BenjaminPelletier merged 1 commit intointeruss:mainfrom
Conversation
38d0e83 to
32797bc
Compare
|
|
||
| if not pyproj.network.is_network_enabled(): # pyright:ignore[reportAttributeAccessIssue] | ||
| raise Exception(""" | ||
| To enable EGM2008 conversions, you must allow pyproj to download files to do the conversion. For that, please set PROJ_NETWORK=TRUE in your environment variables. |
There was a problem hiding this comment.
How large are those? Is it realistic to have them in the CI so that we can add unit tests covering this?
There was a problem hiding this comment.
If my understanding is correct, I think it's on the order of 150MB which technically we could have in the CI, but I would probably recommend against since it's a rare feature that would consume resources disproportionate to its importance. But, in the absence of CI involvement, we need some kind of indication for why we're confident a change is correct -- in this case, I'd expect some kind of statement like "I temporarily changed mock_uss to report EGM2008 altitudes and the netrid_v22a test configuration passed locally" in the PR description.
There was a problem hiding this comment.
Yes, the files for the original implementations are in that order ( https://earth-info.nga.mil/index.php?dir=wgs84&action=wgs84 )
It does seems that pyproj's version is around 80M ( https://cdn.proj.org/ , search for EPSG:3855), but that still 10 times actual size of the monitoring's code folder.
For testing, I did a different approach (switched to EGM2008 as reference but still returning EGM98, to ensure it failed as altitudes should be different), but I will do a 'positive' run.
There was a problem hiding this comment.
I updated the description of the PR with manual tests results. Note that I did ran the uspace configuration, as the netrid_v22a is not running scenarios.uspace.netrid.msl.MSLAltitude. Is that expected?
There was a problem hiding this comment.
Ah, right -- yes, MSLAltitude is a special requirement for U-space and isn't an ASTM requirement, so running in the uspace scenario and not running in netrid_v22a is expected (with hindsight).
Add support for EGM2008, fixing #1288.
As EGM2008 data is quite big, we do use pyproj and its download feature to download on the fly required data.
Download is opt-in and explained in an error message with explanations if that not the case. I can also make it the default.
Manual testing:
Mock USS returning wrong reference datum:
->
Mock USS returning EGM2008 altitudes:
->