You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Acting as an independent amenity available for self-directed activities (e.g., a trail running through a national park)
Supporting other activities planned around and depending upon its existence (e.g., regularly scheduled running clubs, one-off seasonal events such as treasure hunts)
The question, then, is of how Opportunities and Routes should relate to support these two cases.
The proposal would be that Routes should be available as a standalone datatype (so that one might have, e.g., an RPDE feed of Routes); but that a route attribute ought to be added to the Opportunity Event type, which takes a Route as its value, whether directly or via a URL.
The text was updated successfully, but these errors were encountered:
Initially, I agree with this, with an exception on the last part. I would propose that the attribute is always a URL (pointer) to a Route, as opposed to mixing the types (Route or URL). This would keep it simple for both publisher and consumer - the publisher only needs a string value to populate and the consumer only has to ingest the URL and can then process that part of the data at their time of choosing. It also helps to maintain the separation of Route from Opportunity Event for CRUD operations.
Routes appear to support two use-cases:
The question, then, is of how Opportunities and Routes should relate to support these two cases.
The proposal would be that Routes should be available as a standalone datatype (so that one might have, e.g., an RPDE feed of Routes); but that a
route
attribute ought to be added to the Opportunity Event type, which takes a Route as its value, whether directly or via a URL.The text was updated successfully, but these errors were encountered: