Add stop references to trips and status_changes

[avatarneil]

Explain pull request

Resolves #428 following @jfh01's suggestion to use GeoJSON Foreign Members. Relates pretty closely to the open PR #427, and is dependent on that being merged first.

Is this a breaking change

• No, not breaking

Impacted Spec

• provider

[thekaveman]

Two comments:

1. I know @jfh01 suggested the use of Foreign Members, and I don't see a specific issue there. I just wonder if there is any reason not to extend our existing use of the properties object already present in GeoJSON Features?

2. Regardless of the answer to 1, the schema will need to be updated to handle the additional field.

[ascherkus]

Chiming in ... I'm also a bit hesitant on relying on GeoJSON foreign members vs. properties (similar to the hesitancy mentioned in #441).

Given:

• The GeoJSON spec cautions against it
• We're already using properties
• Other sources of GIS data seen in this space (notably GeoJSON produced from Shapefiles such as Santa Moncia's drop zones) map attributes to properties

... I'm inclined to suggest sticking with properties for Feature-specific metadata, unless @jfh01 has some additional insight/experience into foreign members :)

Alternatively start/end stop ids could be expressed higher in the hierarchy alongside start/end_time -- the tradeoff there would being unable to express a trip that stopped at multiple stops (unclear to me if such a trip would exist, or if that would be represented as two trips with separate start/stop pairs). If I had to pick, I think sticking with Feature properties with schema validation accomplishes the same goal while retaining flexibility vs. adding more named fields at the top-level trips object.

[jfh01]

No particular insight here. I'm happy with either direction. Thanks!

[avatarneil]

Updated the PR to move the stop references to the top level of thetrips and status_changes objects.

[thekaveman]

@rgangopadhya

Hmm, I do think this could be useful, though. I must've missed it on the call but did we agree to remove this?

I think we decided to move it nearer to the geometry, inside the properties object of relevant GeoJSON Feature (status_change.event_location, the first/last point in trip.route). This PR has been updated to reflect the changes for trip.route but it looks like we still need something for status_changes.event_location @avatarneil

[avatarneil]

Hi @thekaveman, I've updated the event_location definition. Sorry for the delay!

[thekaveman]

I rebased on the latest dev to incorporate Reconciliation changes. Let's wait to merge this after #427 so we can update references to Stops in the Provider README.

[schnuerle]

Thanks for these updates everyone.