Repository navigation
Report a pyproj CRS projection as a string - #17
Merged
Merged
Conversation
A TrajectoryCollection built from a GeoDataFrame keeps a pyproj CRS, one built from x/y the string it was given. The analyzer passed the CRS into its result, json.dumps rejected it, and the event handler's fail-safe wrote `[]` instead of the statistics. On master since 2026-09-23 for every App that hands on such a collection; on develop for every Python App after `move2_loc to MovingPandas`, which builds its points as a GeoDataFrame since link-r-python v2.2.1. Not gzip: an uncompressed pickle fails alike. The test applies the handler's JSON encoding. Comparing the CRS with 'EPSG:4326' would pass regardless, as pyproj.CRS equals its string. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
annescharf
approved these changes
Oct 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A
TrajectoryCollectionbuilt from a GeoDataFrame keeps apyproj.CRS; one built fromx/ykeeps the string it was given. The analyzer putget_crs()into its result unchanged,json.dumpsrejected the CRS, and the event handler's fail-safe wrote[]instead of the statistics. The traceback only reached the container log, which disappears with the execution pod.projectionnow reportscrs.srsfor a CRS (e.g.'EPSG:4326') and passes a string through unchanged, so results for existing pickles stay identical.Impact
[]python cargo result since 2026-09-23 (7 of 7) reproduces thisTypeErrorwithv2.2.0and yields full statistics with this branch. One of them is an uncompressed pickle — the failure is not related to gzip.move2_loc to MovingPandas, which builds its points as a GeoDataFrame since link-r-python v2.2.1 (#1419). The translator's own cargo result is affected as well.A
[]result for amoving_pandas_trajectory_collectionoutput is always this fail-safe; a genuinely empty collection reports[{"n": ["empty-result"]}].Test
The new test builds a collection from a GeoDataFrame, writes it as SDK v3 does (gzip), and runs the result through the same JSON encoding as the handler. Asserting
projection == 'EPSG:4326'on the raw result would pass with the bug, becausepyproj.CRScompares equal to its string.v2.2.0image's environment and viatest/Dockerfilemain.pywith the watchdog handler on the four develop outputs —[]before, full results afterAfter merge
Tag
v2.2.1, then raisegroundcontrol.pilot.base-image-name.cargo-agent.pythonin groundcontrol.