Include sections in UnprocessedTrips
#1141
Conversation
To be consistent with processed trips, and so we can use them in the same way, unprocessed trips should have the 'sections' property. Unprocessed trips / 'draft' trips are assumed to be unimodal, so we can fairly easily reconstruct a section spanning the entirety of the trip and include that as the only section. In doing so, I modified points2TripProps. I realized that many of the props will actually be the same between the trip and the section. So I did a bit of refactoring; to construct the unprocessed trip I first construct baseProps (which are used in both the section and the trip); then I construct the section; then finally I construct the trip in the return statement. Something else I noticed is that all the trip props are computed in points2TripProps except the start_loc and end_loc which were computed in the outer function transitionTrip2TripObj. Since we already have variables for the start and end coordinates in the points2TripProps function, it seems more logical to handle start_loc and end_loc there with the rest of the trip props. Then we can declare the return type of points2TripProps as UnprocessedTrip; it has all the required properties now.
The main thing I was doing in this commit was adding 'sections' to the type signature of `UnprocessedTrip`. But I also noticed some other things amiss. `UnprocessedTrip` was missing some other properties; end_ts and start_fmt_time "LocationCoord" is not needed as it's the same as `Point` from 'geojson'. `SectionData` was missing a bunch of properties. Once those are filled in, the 'sections' property in `CompositeTrip` and `UnprocessedTrip` can be typed as `SectionData[]`
After a bunch of refactoring, I think these functions could use a naming update. I always found this part of the codebase fairly opaque anyway and I think it can now be made more easily comprehensible. 'points2TripProps' now returns a full UnprocessedTrip object so it is renamed 'points2UnprocessedTrip' And 'transitions2Trips' is renamed 'transitions2TripTransitions' because it doesn't really return trip objects; it returns pairs of transitions that represent trips. To follow suit, 'transitionTrip2TripObj' is renamed 'tripTransitions2UnprocessedTrip'. Added a bit of JSDoc to help clarify what these functions do.
Filled in more trip object types, and specifically some literal types that define unprocessed trips. (like "source" will always be 'unprocessed'). CompTripLocations changed from `number[]` for coordinates to geojson's `Position`, since that is more descriptive. Renamed CompTripLocations to CompositeTripLocation (this type represents only 1 location). Used the CompositeTripLocation type in timelineHelper. in locations2GeojsonTrajectory, the return type needed `properties` for it to be considered a Geojson `Feature`. formattedSectionProperties types as the return type of the function
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1141 +/- ##
==========================================
+ Coverage 77.49% 77.50% +0.01%
==========================================
Files 29 29
Lines 1693 1694 +1
Branches 370 370
==========================================
+ Hits 1312 1313 +1
Misses 381 381
Flags with carried forward coverage won't be shown. Click here to find out more.
|
| origin_key: 'UNPROCESSED_trip'; | ||
| sections: SectionData[]; | ||
| source: 'unprocessed'; | ||
| start_fmt_time: string; |
There was a problem hiding this comment.
Just curious! Is there any specific reason why key and origin_key are a combination of uppercase and lowercase letters? It seems unfamiliar.
There was a problem hiding this comment.
That is just how unprocessed trips have always been represented.
This isn't a "real" key because it doesn't come from the server. It's a client-side construction of something similar to a composite_trip object, but it wouldn't really be accurate to call it a de facto composite_trip. So it doesn't get the analysis/composite_trip key.
Somewhere else in the codebase, we identify draft trips by seeing if the key includes 'UNPROCESSED'.
Oh I found this one! e-mission/e-mission-docs#234 (comment) |
I don't have a lot of written resources on hand, but if you have questions about how unprocessed trips work I can answer them in our 1:1 meeting (and summarize the answers here) |
In doing this, I did a bunch of refactoring and expanded the type definitions we have for unprocessed trips, composite trips, and adjacent types.