Replies: 1 comment 1 reply
-
Hi @amixpal , Can we connect sometime on Monday (18th March'24), to discuss this further? I believe what you are trying to achieve can be done using the same mobility specification. Thanks |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I am currently working on developing an interoperable journey planner and booking platform that aims to offer comprehensive itineraries across multiple transport modes, including bus, train, walking, ride-hailing, and more. Our goal is to provide users with detailed, multi-leg itineraries (BPPs) that can seamlessly integrate various transport services into a single, coherent journey plan.
Our platform utilizes a specific API structure for search requests and responses to convey complex journey planning data, including multiple legs, transport modes, and relevant metadata for each leg of the journey. Below is an example of our current search API request structure:
Our Response structure (Currently Aligned with Tomp Standard and Open trip planner), which includes detailed options for multi-leg journeys, each leg potentially utilizing different transport modes, along with pricing, conditions, geometry, and other relevant data:
I am looking for recommendations on how to effectively map our search requests and responses to the Beckn protocol? Specifically, we're looking for advice on handling complex itineraries that include multiple legs and modes of transport, and how to structure this data within Beckn's framework.
Beta Was this translation helpful? Give feedback.
All reactions