GTFS প্রয়োজনীয়তা, GTFS প্রয়োজনীয়তা, GTFS প্রয়োজনীয়তা

পার্টনারকে এমন একটি GTFS ফিড প্রদান করতে হবে যা সমস্ত স্ট্যান্ডার্ড স্পেসিফিকেশন এবং নিচে তালিকাভুক্ত স্পেসিফিকেশনগুলো পূরণ করে। এই ফিডটিতে পার্টনারের প্রদর্শন করতে চাওয়া সমস্ত ভ্রমণপথ অন্তর্ভুক্ত থাকতে হবে। এই তথ্য প্রদান করলে গুগল-এ সময়সূচী এবং রুটের তথ্য প্রদর্শিত হবে। উল্লেখ্য যে, পার্টনার চাইলে প্রদত্ত ফিডের কিছু বা সমস্ত ভ্রমণপথের জন্য অতিরিক্ত মূল্য এবং প্রাপ্যতার তথ্য প্রকাশ করতে পারেন।

ডিফল্ট প্রয়োজনীয়তা

স্থির GTFS রেফারেন্স - সকল ডিফল্ট আবশ্যকতা প্রযোজ্য।

জিটিএফএস-এর সর্বোত্তম অনুশীলনসমূহ - অনুগ্রহ করে সর্বোত্তম অনুশীলনগুলো এমনভাবে অনুসরণ করুন যেন সেগুলো বাধ্যতামূলক।

GTFS ফিড আপলোড করা - অনুগ্রহ করে GTFS ফিড আপলোড করার জন্য এই প্রক্রিয়াটি অনুসরণ করুন।

আপডেট: মনে রাখবেন, একবার ফিড আপলোড হয়ে গেলে, এখানে বর্ণিত পদ্ধতি অনুসরণ করে সেগুলি আপডেট করা যাবে। সাধারণত এই ফিড আপডেটগুলি সম্পূর্ণরূপে কার্যকর হতে ২-৩ দিন সময় লাগতে পারে।

অতিরিক্ত প্রয়োজনীয়তা

পরিধি

• একটি একক GTFS ফিড অবশ্যই একটি দেশ বা দেশের একটি অংশকে অন্তর্ভুক্ত করবে। যে ট্রিপগুলো দেশের সীমানা অতিক্রম করে, সেগুলো অবশ্যই আলাদা মহাদেশব্যাপী ফিডে প্রদান করতে হবে। যদি কোনো GTFS ফিড একটি দেশের চেয়ে বড় কিছু অন্তর্ভুক্ত করে, তাহলে অনুগ্রহ করে ট্র্যাভেল ট্রান্সপোর্ট টিমের সাথে যোগাযোগ করুন।
  • GTFS জিপ ফাইলের ভেতরের ফাইলগুলোর সাইজ ৪ জিবির চেয়ে ছোট হওয়া উচিত। এর চেয়ে বড় ফাইল সাধারণত কিছু ভুল পদ্ধতির লক্ষণ, যেমন frequencies.txt বা এই জাতীয় ফিচারের কম্প্রেশন অপশনগুলো উপেক্ষা করা। এর ফলে প্রসেসিংয়ের সময় সমস্যা হতে পারে। আপনার যদি মনে হয় যে ৪ জিবির চেয়ে বড় ফাইলের প্রয়োজন, তাহলে অনুগ্রহ করে [e-mail] এই ঠিকানায় ট্র্যাভেল ট্রান্সপোর্ট টিমের সাথে যোগাযোগ করুন।
  • একটি GTFS ফিডের অন্তর্গত পরিষেবাগুলোর ভবিষ্যৎ কার্যকালের সম্পূর্ণ তথ্য, GTFS ডেটার প্রতিটি আপডেটের সাথে প্রদান করতে হবে। বিভিন্ন সময়কাল অনুসারে পরিষেবাগুলোর বিভাজন গ্রহণযোগ্য নয়।
• একজন নির্দিষ্ট অপারেটরের সমস্ত তারিখ একটিমাত্র ফিডে অন্তর্ভুক্ত থাকতে হবে।

অনুবাদ

• translations.txt ব্যবহার করে অনুবাদ প্রদান করা যাবে এবং নিম্নলিখিত দেশগুলিতে এর প্রয়োজন হবে:
  • ব্যবহারকারীদের তথ্য বিভিন্ন লিপিতে, অথবা ল্যাটিন ছাড়া অন্য লিপিতে প্রদান করা হতে পারে।
  • ব্যবহারকারীদের একাধিক ভাষায় তথ্য প্রদান করা হতে পারে, অথবা প্রতিষ্ঠানগুলো সেই ভাষাগুলোতে ভিন্ন ভিন্ন নামকরণ ব্যবহার করতে পারে (যেমন Brussels/Brussel/Bruxelles)।
• অনুবাদ করার জন্য সত্তা
  • এজেন্সি/স্টপ/রুটের নাম
  • যাত্রা/থামার সংকেত

রুটের নাম, ভ্রমণের সংক্ষিপ্ত নাম এবং হেডসাইন

• সমস্ত ট্রিপের জন্য হেডসাইন অবশ্যই প্রদান করতে হবে, হয় trips.txt ফাইলে (যদি হেডসাইনটি পুরো ট্রিপ জুড়ে একই থাকে) অথবা stop_times.txt ফাইলে (যদি ট্রিপের বিভিন্ন পর্যায়ে হেডসাইন পরিবর্তিত হয়)।
• হেডসাইনগুলো মাটিতে থাকা তথ্যের সাথে মিলতে হবে। উদাহরণস্বরূপ, যানবাহনে বা সাইনবোর্ডে প্রদর্শিত হেডসাইন।
• যখন কোনো রুটের নাম থাকে, তখন সেটি routes.txt ফাইলে long_name হিসেবে অবশ্যই প্রদান করতে হবে।
• যখন কোনো রুটের একটি নির্দিষ্ট নম্বর বা আলফানিউমেরিক আইডেন্টিফায়ার থাকে যা সেই রুটের সমস্ত ট্রিপের জন্য এবং উভয় দিকেই প্রযোজ্য, তখন সেটি routes.txt ফাইলে short_name হিসেবে অবশ্যই প্রদান করতে হবে।
• রুটের অন্তর্ভুক্ত ট্রিপগুলোর যদি স্বতন্ত্র শনাক্তকারী থাকে (যেমন, ট্রেন নম্বর), তবে সেই শনাক্তকারীগুলোকে ট্রিপের সংক্ষিপ্ত নাম হিসেবে প্রদান করতে হবে।
• যেসব দূরপাল্লার পরিষেবার রুট নম্বর বা নাম নেই, সেগুলোর ক্ষেত্রে রুটের নাম নির্বাচন করা সমস্যাজনক হয়ে ওঠে। এই ধরনের পরিস্থিতিতে সাধারণ নির্দেশিকা হলো, রুটের নাম এবং হেডসাইনের একটি সমন্বয় ব্যবহারকারীকে যানবাহনটি দ্ব্যর্থহীনভাবে শনাক্ত করতে সাহায্য করবে। উদাহরণস্বরূপ, পরিচালনাকারী সংস্থার নাম রুটের নাম হিসেবে ব্যবহার করা যেতে পারে, এবং যাত্রার গন্তব্য (যদি যানবাহনে প্রদর্শিত থাকে) ট্রিপ হেডসাইন হিসেবে ব্যবহার করা উচিত।

উদাহরণ

• ভারতীয় রেলের কামায়নী এক্সপ্রেস ট্রেন ১১০৭১, মুম্বাই থেকে বারাণসীগামী। দ্রষ্টব্য: ১১০৭১ নম্বরটি মুম্বাই থেকে বারাণসী পর্যন্ত একটি নির্দিষ্ট ট্রেন যাত্রাকে নির্দেশ করে, পুরো রুটটিকে নয়।
  • routes.txt:
    • সংক্ষিপ্ত নাম: <খালি>
    • দীর্ঘ নাম: কামায়ানি এক্সপ্রেস
  • trips.txt:
    • ভ্রমণের সংক্ষিপ্ত নাম: ১১০৭১
    • মাথাচিহ্ন: বারাণসী
• শেভ্যালিয়ার বাস দ্বারা পরিচালিত বুয়েনস আইরেস থেকে কর্ডোবাগামী একটি বাস। দ্রষ্টব্য: যে বাসটি এই পরিষেবাটি পরিচালনা করে, তাতে কোনো নির্দিষ্ট রুটের নাম প্রদর্শিত হয় না। পরিবর্তে, এতে এর পরিচালনাকারী সংস্থার নাম এবং গন্তব্য স্পষ্টভাবে প্রদর্শিত হয়। এই নির্দিষ্ট ট্রিপটির কোনো স্বতন্ত্র নম্বর/শনাক্তকারী নেই যা এটিকে একই সংস্থা দ্বারা পরিচালিত বা একই রুটে চলাচলকারী অন্যান্য ট্রিপ থেকে আলাদা করে। সেক্ষেত্রে, এজেন্সির নাম ( agencies.txt ফাইলে) এবং রুটের পূর্ণ নাম ( routes.txt ফাইলে) উভয় ক্ষেত্রেই "শেভ্যালিয়ার" ব্যবহার করা গ্রহণযোগ্য। হেডসাইনের জন্য গন্তব্য ব্যবহার করতে হবে। ট্রিপের সংক্ষিপ্ত নাম খালি রাখতে হবে।
  • routes.txt:
    • সংক্ষিপ্ত নাম: <খালি>
    • দীর্ঘ নাম: শেভালিয়ার
  • trips.txt:
    • trip_short_name: <খালি>
    • হেডসাইন: কর্ডোবা

থামার সময়

stop_times.txt ফাইলে arrival_time এবং departure_time উভয়ই অবশ্যই প্রদান করতে হবে।

ভ্রমণের কাঠামো

• একাধিক শহর/এলাকা সংযোগকারী দূরপাল্লার ট্রিপগুলো কোনো বিভাজন ছাড়াই শুরু থেকে শেষ পর্যন্ত প্রদান করা উচিত (যেমন A->B->C, [A->B,A->C,B->C] নয়), যেখানে A, B, C হলো শহরের এলাকা। উদাহরণস্বরূপ, বুয়েনস আইরেস থেকে কর্ডোবাগামী একটি দূরপাল্লার বাস, যার মাঝে রোজারিওতে একটি স্টপ আছে, সেটিকে এই তিনটি শহরে স্টপসহ একটি ট্রিপ হিসেবে উপস্থাপন করা উচিত, তিনটি ট্রিপ হিসেবে নয়: “বুয়েনস আইরেস - রোজারিও”, “বুয়েনস আইরেস - কর্ডোবা” এবং “রোজারিও - কর্ডোবা”।
• যেসব ক্ষেত্রে ডেটা সরবরাহকারী সঠিক ট্রিপ কাঠামো সম্পর্কে তথ্য সংগ্রহ করতে অক্ষম হন, সেক্ষেত্রে ক্ষেত্রবিশেষে শহর-থেকে-শহর ট্রিপগুলোকে খণ্ডিত আকারে প্রদান করা যেতে পারে। যদি এই ধরনের শহর-থেকে-শহর ট্রিপের ক্ষেত্রে একটি শহরের (শহর এলাকার) মধ্যে একাধিক পিক-আপ বা ড্রপ-অফ পয়েন্ট থাকে, তবে স্টপ-টু-স্টপ বিভাজনের অনুমতি নেই — সমস্ত পিক-আপ পয়েন্ট এবং সমস্ত ড্রপ-অফ পয়েন্ট একটি একক ট্রিপের অন্তর্ভুক্ত করতে হবে।

স্টেশন কাঠামো

একাধিক প্ল্যাটফর্ম/বে থাকা বড় স্টেশনগুলির ক্ষেত্রে, ফিডে স্টেশন-প্ল্যাটফর্মের সম্পর্ক অবশ্যই নির্দিষ্ট করতে হবে এবং stops.txt ফাইলের platform_code ফিল্ডের মাধ্যমে নির্দিষ্ট বে/প্ল্যাটফর্ম শনাক্ত করতে হবে। যে যানবাহনগুলি ধারাবাহিকভাবে একটি নির্দিষ্ট বে বা প্ল্যাটফর্ম থেকে ছাড়ে বা সেখানে পৌঁছায়, সেগুলিকে GTFS ফিডে সেই বে বা প্ল্যাটফর্মের সাথে লিঙ্ক করতে হবে। যদি বিভিন্ন প্রস্থানের দিন/সময়ে প্রস্থান বা আগমনের প্ল্যাটফর্ম বা বে পরিবর্তিত হয়, তবে এই তথ্য GTFS-এ রিয়েলটাইমে সরবরাহ করা যেতে পারে।

স্টেশন/স্টপের অবস্থান

• একাধিক প্ল্যাটফর্ম বা বে-যুক্ত বড় স্টেশনগুলির ক্ষেত্রে, স্টেশনের অবস্থানটি এর সবচেয়ে সুস্পষ্ট পথচারী প্রবেশপথের অবস্থানে (যদি স্টেশনটিতে কোনো ভবন বা কাঠামো থাকে) অথবা যাত্রী অপেক্ষার স্থানের অবস্থানে (খোলা জায়গার স্টেশনগুলির জন্য) নির্ধারণ করা উচিত।
• রাস্তার পাশে ছোট স্টপগুলোর ক্ষেত্রে, বাস পোল শনাক্ত করা গেলে স্টপের অবস্থানটি সেটির অবস্থানে নির্ধারণ করা উচিত। যখন কোনো নির্দিষ্ট বাস পোল শনাক্ত করা সম্ভব হয় না, তখন অবস্থানটি রাস্তার সঠিক পাশে এবং রাস্তা বরাবর যানবাহনটি যেখানে থামে তার প্রকৃত অবস্থানের কাছাকাছি (আদর্শগতভাবে, ১০ মিটারের মধ্যে) স্থাপন করা উচিত।

অতিরিক্ত GTFS এক্সটেনশন

শুধুমাত্র সেইসব পার্টনারদের জন্য প্রয়োজন, যারা পার্টনার এপিআই (API) প্রয়োগ করে মূল্য/প্রাপ্যতা সংক্রান্ত তথ্য প্রদর্শন করতে চান।

গুগল ট্রানজিট টিকেটিং এক্সটেনশন

• অংশীদারদের গুগল ট্রানজিট টিকেটিং এক্সটেনশন স্পেসিফিকেশনটি বাস্তবায়ন করা উচিত, যা জিটিএফএস-টিকেটিং এক্সটেনশনের একটি উপসেট।
• আমরা টিকেটিং আইডিগুলোর উপর নিম্নলিখিত শর্তাবলী আরোপ করি:
  • টিকেটিং আইডি স্থিতিশীল হওয়া উচিত (অর্থাৎ, সঙ্গত কারণে মাঝে মাঝে পরিবর্তনের অনুমতি থাকবে)। টিকেটিং আইডি পরিবর্তনের ক্ষেত্রে, পূর্ববর্তী সংস্করণের সাথে সামঞ্জস্যতা (ব্যাকওয়ার্ড কম্প্যাটিবিলিটি) বজায় রাখতে হবে (ন্যূনতম ১ সপ্তাহের জন্য)।
  • এপিআই অনুরোধে SegmentKey-এর প্যারামিটার নির্ধারণ করতে, ticketing_trip_id ( trips.txt ফাইলে) এবং ticketing_stop_id ( ticketing_identifiers.txt ফাইলে) আবশ্যক । stop_sequence এর ফলব্যাক সমর্থিত নয় , কারণ এটি স্থিতিশীল নয়।

GTFS-ভাড়া v1

স্ট্যাটিক জিটিএফএস রেফারেন্সে ঐচ্ছিক fare_attributes.txt এবং fare_rules.txt ফাইলগুলোর কথা উল্লেখ করা আছে। যদি কোনো পার্টনার পার্টনার এপিআই-এর সাথে ইন্টিগ্রেট করে, তবে এই ফাইলগুলো সরবরাহ করার প্রয়োজন নেই।