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 বার্তাটির জন্য "একাধিক ত্রুটি" ব্যাখ্যাটি দেখুন৷ ত্রুটির পরিবর্তে, এতে সতর্কতা অন্তর্ভুক্ত থাকবে যে ক্ষেত্রে 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" ত্রুটির ক্ষেত্রে এটি। কিছু ত্রুটির কারণে বৈধকরণ প্রক্রিয়া অন্যান্য ত্রুটিগুলি এড়িয়ে যেতে পারে৷

স্থিতিশীলতা : 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 ম্যাপিং আছে (যখন কোড!= "অনির্দিষ্ট")।

স্থিতিশীলতা : স্থিতিশীল নয়: একটি প্রদত্ত 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", এবং মানগুলি হল সংশ্লিষ্ট খরচ ক্ষেত্রের দ্বারা উত্পন্ন মোট খরচ, সমগ্র সমাধানের উপর একত্রিত৷ অন্য কথায়, খরচ ["model.shipments.pickups.cost"] হল সমাধানের সমস্ত পিকআপ খরচের সমষ্টি। মডেলে সংজ্ঞায়িত সমস্ত খরচ এখানে বিস্তারিতভাবে রিপোর্ট করা হয়েছে ট্রানজিশন অ্যাট্রিবিউটের সাথে সম্পর্কিত খরচগুলি বাদ দিয়ে যেগুলি শুধুমাত্র 2022/01 হিসাবে সমষ্টিগতভাবে রিপোর্ট করা হয়েছে।

totalCost

number

সমাধানের মোট খরচ। খরচ ম্যাপে সমস্ত মানের সমষ্টি।