OptimizeToursResponse

প্রতিটি যানবাহনের অনুসরণ করা রুট, এড়িয়ে যাওয়া চালান এবং সমাধানের সামগ্রিক খরচ সহ একটি ট্যুর অপ্টিমাইজেশন সমস্যা সমাধানের পরে প্রতিক্রিয়া।

JSON উপস্থাপনা 
{
  "routes": [
    {
      object (ShipmentRoute)
    }
  ],
  "requestLabel": string,
  "skippedShipments": [
    {
      object (SkippedShipment)
    }
  ],
  "validationErrors": [
    {
      object (OptimizeToursValidationError)
    }
  ],
  "processedRequest": {
    object (OptimizeToursRequest)
  },
  "metrics": {
    object (Metrics)
  }
}
ক্ষেত্র
routes[]

object ( ShipmentRoute )

প্রতিটি গাড়ির জন্য গণনা করা রুট; i-th রুটটি মডেলের i-th গাড়ির সাথে মিলে যায়।

requestLabel

string

যদি অনুরোধে কোনও লেবেল উল্লেখ করা থাকে, তাহলে OptimizeToursRequest.label এর কপি।

skippedShipments[]

object ( SkippedShipment )

সমস্ত চালানের তালিকা বাদ দেওয়া হয়েছে।

validationErrors[]

object ( OptimizeToursValidationError )

আমরা স্বাধীনভাবে সনাক্ত করতে সক্ষম হয়েছি এমন সমস্ত বৈধতা ত্রুটির তালিকা। OptimizeToursValidationError বার্তার জন্য "MULTIPLE ERRORS" ব্যাখ্যাটি দেখুন। ত্রুটির পরিবর্তে, এতে solvingMode হল DEFAULT_SOLVE ক্ষেত্রে সতর্কতা অন্তর্ভুক্ত থাকবে।

processedRequest

object ( OptimizeToursRequest )

কিছু ক্ষেত্রে আমরা সমাধানের আগে আগত অনুরোধটি পরিবর্তন করি, অর্থাৎ খরচ যোগ করি। যদি solvingMode == TRANSFORM_AND_RETURN_REQUEST হয়, তাহলে পরিবর্তিত অনুরোধটি এখানে ফেরত পাঠানো হবে।

পরীক্ষামূলক: আরও বিস্তারিত জানার জন্য https://developers.google.com/maps/tt/route-optimization/experimental/objectives/make-request দেখুন।

metrics

object ( Metrics )

এই সমাধানের জন্য সময়কাল, দূরত্ব এবং ব্যবহারের মেট্রিক্স।

OptimizeToursValidationError সম্পর্কে

OptimizeToursRequest যাচাই করার সময় সম্মুখীন হওয়া একটি ত্রুটি বা সতর্কতা বর্ণনা করে।

JSON উপস্থাপনা 
{
  "code": integer,
  "displayName": string,
  "fields": [
    {
      object (FieldReference)
    }
  ],
  "errorMessage": string,
  "offendingValues": string
}
ক্ষেত্র
code

integer

একটি বৈধতা ত্রুটি সর্বদা উপস্থিত থাকা জোড়া ( code , displayName ) দ্বারা সংজ্ঞায়িত করা হয়।

এই বিভাগের পরবর্তী ক্ষেত্রগুলি ত্রুটি সম্পর্কে আরও প্রসঙ্গ প্রদান করে।

একাধিক ত্রুটি : যখন একাধিক ত্রুটি থাকে, তখন যাচাইকরণ প্রক্রিয়াটি তাদের মধ্যে বেশ কয়েকটি আউটপুট দেওয়ার চেষ্টা করে। অনেকটা কম্পাইলারের মতো, এটি একটি অসম্পূর্ণ প্রক্রিয়া। কিছু যাচাইকরণ ত্রুটি "মারাত্মক" হবে, যার অর্থ তারা সম্পূর্ণ যাচাইকরণ প্রক্রিয়াটি বন্ধ করে দেয়। এটি displayName="UNSPECIFIED" ত্রুটির ক্ষেত্রে প্রযোজ্য, অন্যান্যগুলির মধ্যে। কিছু ত্রুটি যাচাইকরণ প্রক্রিয়াটিকে অন্যান্য ত্রুটিগুলি এড়িয়ে যেতে পারে।

STABILITY : code এবং displayName খুব স্থিতিশীল হওয়া উচিত। কিন্তু সময়ের সাথে সাথে নতুন কোড এবং প্রদর্শন নাম উপস্থিত হতে পারে, যার ফলে একটি প্রদত্ত (অবৈধ) অনুরোধ থেকে একটি ভিন্ন ( code , displayName ) জোড়া তৈরি হতে পারে কারণ নতুন ত্রুটিটি পুরানোটিকে লুকিয়ে রেখেছিল। উদাহরণস্বরূপ, "একাধিক ত্রুটি" দেখুন।

displayName

string

ত্রুটি প্রদর্শনের নাম।

fields[]

object ( FieldReference )

একটি ত্রুটি প্রসঙ্গে 0, 1 (বেশিরভাগ সময়) বা তার বেশি ক্ষেত্র থাকতে পারে। উদাহরণস্বরূপ, যানবাহন #4 এবং চালান #2 এর প্রথম পিকআপ উল্লেখ করা নিম্নরূপ করা যেতে পারে:

fields { name: "vehicles" index: 4}
fields { name: "shipments" index: 2 subField {name: "pickups" index: 0} }

তবে মনে রাখবেন, প্রদত্ত ত্রুটি কোডের জন্য fields মূলত্ব পরিবর্তন করা উচিত নয়।

errorMessage

string

মানুষের পঠনযোগ্য স্ট্রিং ত্রুটি বর্ণনা করে। code এবং errorMessage এর মধ্যে একটি 1:1 ম্যাপিং আছে (যখন কোড != "UNSPECIFIED")।

স্থিতিশীলতা : স্থিতিশীল নয়: প্রদত্ত code সাথে সম্পর্কিত ত্রুটি বার্তা সময়ের সাথে সাথে পরিবর্তিত হতে পারে (আশা করি এটি স্পষ্ট করার জন্য)। অনুগ্রহ করে displayName এবং code উপর নির্ভর করুন।

offendingValues

string

ক্ষেত্রের মান(গুলি) থাকতে পারে। এটি সর্বদা উপলব্ধ নয়। আপনার এটির উপর নির্ভর করা উচিত নয় এবং এটি শুধুমাত্র ম্যানুয়াল মডেল ডিবাগিংয়ের জন্য ব্যবহার করা উচিত।

ফিল্ডরেফারেন্স

বৈধতা ত্রুটির জন্য একটি প্রসঙ্গ নির্দিষ্ট করে। একটি FieldReference সর্বদা এই ফাইলের একটি প্রদত্ত ক্ষেত্রকে নির্দেশ করে এবং একই শ্রেণিবদ্ধ কাঠামো অনুসরণ করে। উদাহরণস্বরূপ, আমরা নিম্নলিখিতটি ব্যবহার করে গাড়ি #5 এর startTimeWindows এর উপাদান #2 নির্দিষ্ট করতে পারি:

name: "vehicles" index: 5 subField { name: "endTimeWindows" index: 2 }

তবে বার্তার ভিড় এড়াতে আমরা OptimizeToursRequest বা ShipmentModel মতো শীর্ষ-স্তরের সত্তা বাদ দিই।

JSON উপস্থাপনা 
{
  "name": string,
  "subField": {
    object (FieldReference)
  },

  // Union field index_or_key can be only one of the following:
  "index": integer,
  "key": string
  // End of list of possible types for union field index_or_key.
}
ক্ষেত্র
name

string

ক্ষেত্রের নাম, যেমন, "যানবাহন"।

subField

object ( FieldReference )

প্রয়োজনে পুনরাবৃত্তভাবে নেস্টেড সাব-ফিল্ড।

ইউনিয়ন ফিল্ড index_or_key ।

index_or_key নিম্নলিখিতগুলির মধ্যে কেবল একটি হতে পারে:

index

integer

পুনরাবৃত্তি হলে ক্ষেত্রের সূচী।

key

string

ক্ষেত্রটি যদি মানচিত্র হয় তবে কীটি লিখুন।

মেট্রিক্স

সমস্ত রুটের উপর সমন্বিত সামগ্রিক মেট্রিক্স।

JSON উপস্থাপনা 
{
  "aggregatedRouteMetrics": {
    object (AggregatedMetrics)
  },
  "skippedMandatoryShipmentCount": integer,
  "usedVehicleCount": integer,
  "earliestVehicleStartTime": string,
  "latestVehicleEndTime": string,
  "costs": {
    string: number,
    ...
  },
  "totalCost": number
}
ক্ষেত্র
aggregatedRouteMetrics

object ( AggregatedMetrics )

রুটগুলির উপর একত্রিত। প্রতিটি মেট্রিক হল একই নামের সমস্ত ShipmentRoute.metrics ক্ষেত্রের যোগফল (অথবা সর্বোচ্চ, লোডের জন্য)।

skippedMandatoryShipmentCount

integer

বাধ্যতামূলক চালানের সংখ্যা বাদ দেওয়া হয়েছে।

usedVehicleCount

integer

ব্যবহৃত যানবাহনের সংখ্যা। দ্রষ্টব্য: যদি কোনও যানবাহনের রুট খালি থাকে এবং Vehicle.used_if_route_is_empty সত্য হয়, তাহলে যানবাহনটি ব্যবহৃত বলে বিবেচিত হবে।

earliestVehicleStartTime

string ( Timestamp format)

ShipmentRoute.vehicle_start_time এর সমস্ত ব্যবহৃত যানবাহনের সর্বনিম্ন হিসাবে গণনা করা একটি ব্যবহৃত যানবাহনের জন্য সর্বনিম্ন শুরুর সময়।

RFC 3339 ব্যবহার করে, যেখানে উৎপন্ন আউটপুট সর্বদা Z-স্বাভাবিক হবে এবং 0, 3, 6 অথবা 9 ভগ্নাংশ সংখ্যা ব্যবহার করবে। "Z" ব্যতীত অন্যান্য অফসেটগুলিও গ্রহণযোগ্য। উদাহরণ: "2014-10-02T15:01:23Z" , "2014-10-02T15:01:23.045123456Z" অথবা "2014-10-02T15:01:23+05:30" ।

latestVehicleEndTime

string ( Timestamp format)

ShipmentRoute.vehicle_end_time এর সমস্ত ব্যবহৃত যানবাহনের সর্বোচ্চ হিসাবে গণনা করা একটি ব্যবহৃত যানবাহনের সর্বশেষ শেষ সময়।

RFC 3339 ব্যবহার করে, যেখানে উৎপন্ন আউটপুট সর্বদা Z-স্বাভাবিক হবে এবং 0, 3, 6 অথবা 9 ভগ্নাংশ সংখ্যা ব্যবহার করবে। "Z" ব্যতীত অন্যান্য অফসেটগুলিও গ্রহণযোগ্য। উদাহরণ: "2014-10-02T15:01:23Z" , "2014-10-02T15:01:23.045123456Z" অথবা "2014-10-02T15:01:23+05:30" ।

costs

map (key: string, value: number)

সমাধানের খরচ, খরচ-সম্পর্কিত অনুরোধ ক্ষেত্র দ্বারা বিভক্ত। কীগুলি হল প্রোটো পাথ, ইনপুট OptimizeToursRequest এর সাথে সম্পর্কিত, যেমন "model.shipments.pickups.cost", এবং মানগুলি হল সংশ্লিষ্ট খরচ ক্ষেত্র দ্বারা উৎপন্ন মোট খরচ, যা সমগ্র সমাধান জুড়ে একত্রিত করা হয়েছে। অন্য কথায়, costs["model.shipments.pickups.cost"] হল সমাধান জুড়ে সমস্ত পিকআপ খরচের যোগফল। মডেলে সংজ্ঞায়িত সমস্ত খরচ এখানে বিস্তারিতভাবে রিপোর্ট করা হয়েছে, TransitionAttributes সম্পর্কিত খরচ বাদে যা শুধুমাত্র 2022/01 অনুযায়ী সমষ্টিগতভাবে রিপোর্ট করা হয়েছে।

totalCost

number

সমাধানের মোট খরচ। খরচ মানচিত্রে সমস্ত মানের যোগফল।