Araç nitelikleri

RouteQ’de siparişlerin teslimatı hem sıradan araçlarla hem de yaya olarak veya toplu taşıma araçlarıyla seyahat eden kuryeler tarafından gerçekleştirilebilir. Araç ve kurye ortak bir dizi özelliği paylaşır.

vehicles sorgu alanı araç veya kuryeyi tanımlamak için kullanılır.

Araç veya kurye tanımlayıcısı

Bir araç veya kuryenin zorunlu bir niteliği, id’de ayarlanan benzersiz bir sayısal veya dize tanımlayıcısıdır. Tanımlayıcı tek bir hizmet talebi içinde benzersiz olmalıdır. İzleme sistemi’ne aktarıldığında, bu tanımlayıcı kurye kullanıcı girişi olarak kullanılacaktır.

Ek olarak, hesap sisteminizden aracın veya kuryenin sayısal veya dizgi tanımlayıcısını ref alanına girebilir ve kurye ile Takip üzerinden iletişime geçmek için onun cep telefonu numarasını phone alanına girebilirsiniz.

Taşıma şekli

Varsayılan değer rotalar oluşturulurken, kuryenin teslimat için bir binek araç (2,5 tondan az taşıma kapasitesi) kullandığı öngörülür. Gönderilerin yürüyerek, kamyonla veya toplu taşıma araçlarıyla teslimatı vehicle.routing_mode parametresi kullanılarak gösterilebilir. Tüm kuryeler teslimatları aynı şekilde yapıyorsa, options.routing_mode yönlendirme seçeneği kullanılabilir.

Olası değerler:

• driving – varsayılan yöntem, 2,5 tondan daha az taşıma kapasitesine sahip araçlar için rotalama;

• truck – varsayılan olarak – 2,5 ton üstü taşıma kapasitesine sahip kamyonlar için rotalama. Ek parametreler araç özellikleri bölümünde belirtilebilir. Bu taşıma şeklini kullanarak planlama yaparken, Moskova için kamyon kasası dahil olmak üzere kamyon trafiğini kısıtlayan yol işaretleri dikkate alınır;

• walking – yaya profiline sahip bir rota. Rotada sadece yayanın yürüyebileceği yollar kullanılır;

• transit – toplu taşıma araçlarını kullanarak ve otobüs durağından teslimat noktasına yürüyerek hareketi öngörülen rota.

Örnek 1

Aşağıdaki örnekte tüm kuryeler için transit taşıma şekli kullanılmaktadır. Sonuç olarak, kuryeler teslimatları toplu taşıma araçlarında yapıyor ve siparişler onlar için en uygun şekilde dağıtılmıştır.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 2

Aşağıdaki örnekte bir kurye için transit ve başka bir kurye için de driving taşıma şekli kullanılmaktadır. Siparişler kuryelere tahsis edilir, böylece araç toplu taşıma duraklarından veya birbirlerinden daha uzak noktalara teslimat yapar.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Araç veya kurye kapasitesi

RouteQ, bir aracın/kuryenin tek bir rotada taşıyabileceği maksimum ağırlığı veya gönderi miktarını belirlemek için araç kapasitesi tanımını destekler.

Araç veya kuryenin kapasitesini tanımlamak için capacity alanını kullanın (seçeneklerden birini belirtmek yeterlidir):

• capacity.units – paket sayısı (palet, kutu, fıçı).

• capacity.weight_kg – kilogram cinsinden ağırlık veya hacimsel ağırlık.

• capacity.volume – metreküp cinsinden ölçülen ve ölçümlerin çarpımı olarak verilen hacim:

  • capacity.volume.width_m – metre cinsinden genişlik.

  • capacity.volume.depth_m – metre cinsinden derinlik.

  • capacity.volume.height_m – metre cinsinden yükseklik.

  Ölçümler bilinmiyorsa, bir alanda hacim değerini ayarlayın ve diğer alanlarda 1 belirtin veya capacity.volume_cbm kullanın.

• capacity.volume_cbm – metreküp olarak verilen hacim.

Bir aracın hem metrik boyutları hem de hacmi belirtilmişse, bu durumda capacity.volume boyutları tanımlar ve capacity.volume_cbm kapasitesini tanımlar.

Buna ek olarak, maksimum araç yükünün, belirtilen taşıma kapasitesinin bir yüzdesi olarak belirlenmesi mümkündür. Bunun için limits sorgu alanı kullanılır:

• limits.volume_perc – capacity.volume.width_m * capacity.volume.depth_m * capacity.volume.height_m’de ayarlanan değerin yüzdesi.

• limits.weight_perc – capacity.weight_kg’de ayarlanan değerin yüzdesi.

• limits.unit_perc – capacity.units’de ayarlanan değerin yüzdesi.

Ayarlanan değere göre aşırı yükleme olasılığını belirtmek için 100’den büyük bir değer belirtin. Örneğin sipariş boyutu tahminindeki olası yanlışlıklar için bir yük kapasitesi marjı bırakmak için 100’den küçük bir değer belirtin. Örneğin, 110 değeri %10 aşırı yüke izin verirken, 90 değeri belirtilen kapasitenin %90’ı kadar maksimum yüke izin verir.

Araç kapasitesi (limits dahil) ihlal edilmeyecek katı bir sınırdır. Araç yüklemesi hesaplanırken teslim alınacak ve teslim edilecek siparişler dikkate alınır. Daha fazla bilgi için lütfen Teslim alma ve teslimat bölümüne bakın.

Örnek

1,5 tonluk (Araç 1) ve 3 tonluk (Araç 2) iki araç ve 1 tonluk, 1,2 tonluk ve 1,4 tonluk üç teslimat siparişi verilmiştir.

Rota optimizasyonunda, 1,2 ton ağırlığındaki bir sipariş Araç 1’e, 1 ve 1,4 ton ağırlığındaki iki sipariş ise Araç 2’ye yerleştirilecektir.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Kullanıcı tarafından tanımlı kapasite birimleri

Kullanıcı tanımlı ölçü birimi’ne göre taşıma aracının kapasitesi.

Kullanıcı ölçü birimi iki parametre ile belirtilir:

• capacity.custom.<seri numarası>.name – kullanıcı ölçü biriminin adı;

• capacity.custom.<seri numarası>.size – kullanıcı ölçü birimine göre aracın kapasitesi.

Varsayılan değer, kapasite capacity.custom.<seri numarası>.size parametresi ile sınırlı değildir.

Birden fazla kullanıcı ölçü birimi belirtilebilir ve bunlara istediğiniz adı verebilirsiniz.

Kullanıcı parametresi price (sipariş tutarı) için Excel dosya sayfalarını doldurma örneği:

Örnek 1

Bu örnekte, gönderi birimlerinin ağırlığı, hacmi ve sayısı belirtilmiştir. Ayrıca sırasıyla location.shipment_size.custom ve vehicle.capacity.custom parametrelerini kullanarak taşınan siparişlerin toplam tutarı üzerinden sipariş tutarı ve araç başına limiti ayarlanmıştır.

Ağırlık, hacim ve paket sayısına göre kullanımları küçük olmasına rağmen, her biri 1 sipariş taşıyan 2 araç olduğu görülüyor, bunun nedeni bu siparişlerin tutarının araç için belirlenen limite yakın olmasıdır.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 2

Bu örnekte Örnek 1 ile aynı veriler kullanılmaktadır, ancak ek olarak bir kuryenin taşıyabileceği maksimum sipariş sayısı belirtilmiştir. Limit location.shipment_size.custom.1 ve vehicle.capacity.custom.1 parametreleri kullanılarak tanımlanır. Her araç artık en fazla 5 sipariş taşıyabilir.

Üç araçtaki sipariş sayısının değiştiği görülüyor. Artık 1 siparişi yalnızca 1 araba taşıyor ve toplam tutar limiti nedeniyle siparişler artık eklenemiyor. Geri kalan araçlarda toplam tutar açısından maksimum kullanım elde edildi fakat sipariş sayısındaki sınırlamaya uyumak da mümkün oldu.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Araç için minimum sipariş ağırlığı

Ağır bir kamyonun hafif bir siparişi şehrin diğer tarafına götürmesini önlemek için min_stop_weight parametresini kullanın. Bu parametre ile aracın bir noktaya teslim edeceği minimum toplam ağırlığı belirleyebilirsiniz. Farklı tonajlı araçlarla yük taşımacılığının planlanması durumunda geçerlidir.

Yumuşak kısıtlama: algoritma onu ihlal edebilir. Cezalar aşağıdaki alanlarda belirlenir:

• penalty.min_stop_weight.fixed – bir noktadaki tüm siparişlerin minimum toplam ağırlığının ihlali için ceza (varsayılan 1000);

• penalty.min_stop_weight.kg – bir noktaya teslim edilen siparişlerin toplam ağırlığındaki her eksik kilogram için ceza (varsayılan 50).

Örnek 1

1500 ve 10000 kg taşıma kapasitesine sahip iki araç 100, 500, 900 ve 9000 kg ağırlığındaki siparişleri teslim ediyor. Büyük araca hem hafif hem de ağır siparişler düşer.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 2

10000 kg taşıma kapasitesine sahip bir araç için min_stop_weight parametresi 1000 değeriyle belirtilir. Sonuç olarak, büyük otomobil yalnızca 9000 kg’lık bir sipariş alıyor.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Araç özellikleri

Araç özellikleri vehicle.specs alanından ayarlanabilir. Aşağıdaki parametreleri içerebilir:

• width – aracın metre cinsinden genişliği;

• height – aracın metre cinsinden yüksekliği;

• length – aracın metre cinsinden uzunluğu;

• max_weight – aracın ton cinsinden maksimum ağırlığı;

• max_weight_kg – aracın kilogram cinsinden maksimum ağırlığı (planlama işlemleri sırasında tona yuvarlanır).

Listelenen tüm özellikler için minimum değer 0’dır.

Kamyon kapasitesini hesaplamak için 21 sınıf kullanılır, bunun için bkz. spesifikasyon. Algoritma, her aracın boyutlarını ve taşıma kapasitesini dikkate alır ve tüm özellikleri araca eşit veya araçtan daha büyük olan spesifikasyondan en yakın sınıfı seçer. Aracın özelliklerinden en az birinin tanımlanan maksimum değerleri aşması halinde, araca truck_N21 sınıfı atanır. Çözümde en fazla 5 sınıf kullanılabilir. Eğer planlama sırasında daha fazla sınıf varsa, küçük sınıflar çözümden eşit olarak çıkarılır ve araçlar kalanlardan en yakın büyük sınıfı alır.

Çözümde hangi sınıfların kullanıldığını görmek için matrix_statistics API yanıt dizisine bakılabilir.

Sınıf özellikleri

Araç özellikleri kaydı options.enable_vehicle_classes seçeneği ile etkinleştirilir. Varsayılan değer enable_vehicle_classes = true – bu durumda algoritma araçları özelliklerine göre sınıflandırır. Özelliklerinin kaydı enable_vehicle_classes = false ayarı ile devre dışı bırakılabilir.

Örnek 1.1

Bir kamyon ve bir binek otomobil olmak üzere iki araç 10 siparişi teslim ediyor. 2 adres, araçlar için 2,5 metre yükseklik sınırlaması olan Cherkizovskaya geçidinin yanında yer almaktadır. Bu adresler arasındaki en kısa yol buradan geçer.

Algoritma 2 rota oluşturacaktır, çünkü kamyon karşıya geçemeyecek kadar yüksektir. Yakınında bulunan siparişler, kısıtlayıcı özellikleri olmayan bir binek aracı taşıyacaktır. Kamyonun yüksekliği specs.height = 3 olduğundan, spesifikasyon’a göre ona truck_N13 sınıfı atanır.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 1.2

Planlamaya, örnek 1.1’de olduğu gibi aynı siparişler ve araçlar dahildir, ancak vehicle.specs kamyonu özellikleri belirtilmemiştir, bu nedenle kamyona herhangi bir sınıf atanmamıştır.

Algoritma herhangi bir geçiş kısıtlaması bulamaz ve kamyonun geçit üzerinden izleyeceği yolu planlar.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 2.1

Kurye, MKAD dışında kalan 2 siparişi teslim etmelidir. Sipariş noktaları birbirinin zıttı yöndedir. Aracın maksimum ağırlığı specs.max_weight belirtilmemiştir, bu nedenle algoritma MKAD boyunca hareketi kısıtlama olmaksızın hesaplar. Özelliklerin vehicle.specs eksikliği nedeniyle kamyona herhangi bir sınıf atanmamıştır.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 2.2

Her şey örnek 2.1’de olduğu gibi, ancak bu sefer araç için specs.max_weight = 12 olarak belirtilmiştir. Spesifikasyona göre, kamyona truck_N12 sınıfı atanmıştır. Algoritma, araç MKAD boyunca hareket edemediği için kilometreyi 3,5 kat daha fazla planladı.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 2.3

Her şey örnek 2.2’de olduğu gibi, ancak max_weight yerine max_weight_kg parametresi kullanılmıştır ve değer kg cinsinden belirtilmiştir. Kamyona aynı truck_N12 sınıfı atanmıştır. Algoritma aynı şekilde, araç MKAD’da gidemeyeceği için etrafından dolaşacağı bir rota planladı.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Araç etiketleri

RouteQ sorgusunda bir araç veya kuryeyi tanımlarken, siparişlerle uyumluluk kuralları (veya etiketler) atayabilirsiniz.

Uyumluluk kuralları, bir aracın belirli bir siparişi yerine getirmek için gerekli özel donanıma sahip olması durumunda gerekli olabilir – örneğin, gıda taşımak için ısı yalıtımlı bir kapalı kasa araç.

Araç ve sipariş uyumluluk kuralları (araç etiketleri) aşağıdaki alanlarda ayarlanır:

• vehicle.tags alanı – siparişin öngördüğü özelliklerle kısmen örtüşebilen aracın özellikleri.

• vehicle.excluded_tags alanı – sipariş öngördüğü özelliklerle eşleşmemesi gereken araç özellikleri.

Sipariş etiketlerini belirlemek için location.required_tags sorgu alanı kullanılır.

Araç etiketleri satırlar veya düzenli ifadeler olarak tanımlanabilir. Satırlarda etiketler virgülle ayrılmış olarak listelenebilir. Bu durumda, listelenen araç etiketlerinden en az biri sipariş etiketi ile eşleşiyorsa veya siparişin etiketi yoksa araç siparişi teslim edebilecektir. Düzenli ifadeler, araçlar ve siparişler arasında daha karmaşık mantık ve uyumluluk kurallarını tanımlamanın bir yoludur.

RouteQ düzenli ifade sözdizimini kullanır POSIX Extended. Düzenli ifadeleri test etmek için Regex101 hizmeti kullanılabilir.

Gerçek örneklerini kullanarak etiketlerin nasıl uygulanabileceğine bir göz atalım.

Örnek 1

Bir nakliye şirketinin küçük miktarlarda yiyecek ve içecek teslimatı yaptığı bir senaryo düşünün. Bazı gıda maddelerinin kesinlikle ısı yalıtımlı kamyonlarla teslim edilmesi gerekmektedir. Aynı zamanda, tüm içecekler ve gıda grubundan bazı ürünler buzdolapsız olarak teslim edilebilir. Buna ek olarak, bazı müşteriler yalnızca araçlarda bir su kasası varsa gönderi kabul edebilmektedir.

Bu tür sipariş kısıtlamalarını tanımlamak için, location.required_tags alanında aşağıdaki etiketleri belirteceğiz:

• TAIL_LIFT – araç su kasası ile donatılmışsa boşaltılabilecek siparişler için.

• ISOTHERMAL_TRUCK – sıcaklık kontrollü taşıma gerektiren malları içeren siparişler için.

• NORMAL_TRUCK – özel taşıma koşullarına sahip malları olmayan siparişler için.

Araçların yeteneklerini tanımlamak için vehicle.tags alanında aşağıdaki etiketleri kullanırız:

• TAIL_LIFT – su kasası ile donatılmış araçlar için.

• ISOTHERMAL_TRUCK – ısı yalıtımlı kasa ile donatılmış araçlar için.

• NORMAL_TRUCK – ısı yalıtımlu kasası olmayan geleneksel araçlar için.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 2

Boşaltma bölgelerinin farklı yükseklikleri nedeniyle bazı siparişlerin bir araç için gövde yüksekliği sınırı olduğu bir senaryo değerlendirelim.

Örneğin, 2 metre, 2,3 metre ve 2,5 metre gövde yüksekliği sınırı olan siparişler vardır. Bu durumda, uygun etiketlere sahip olmalıdırlar: Max_200, Max_230, Max_250.

Araçlarda etiketlerin daha karmaşık bir şekilde basılması gerekir, çünkü 2 metre yüksekliğe kadar olan bir araç her siparişi teslim edebilirken, 2,8 metre yüksekliğindeki bir araç tüm siparişleri teslim edemez. Yani yalnızca tags kullanılırsa, aracın yüksekliği durumunda:

• 2 metreye kadar – sahada vehicle.tags tüm değerler yer alacaktır Max_200, Max_230, Max_250;

• 2 ila 2,3 metre arasında – vehicle.tags alanında Max_230, Max_250 değerlerini içerecektir;

• 2,3 ila 2,5 metre arasında – vehicle.tags alanında Max_250 değeri olacaktır;

• 2,5 metreden fazla – vehicle.tags alanı boş olacaktır.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 3

Bazı siparişlerin belirli bir taşıma kapasitesine sahip araçların gelişine ilişkin bir sınırı olduğu bir senaryo düşünün (uygun araçlardan herhangi biri uygun olduğunda bir VEYA koşulu yürürlüktedir).

Örneğin, farklı yük taşıma kapasitelerine sahip araçlar vardır: 1, 3, 9 ve 15 ton. Bu özellikleri vehicle.tags etiketlerini kullanarak sabitleyelim. Siparişleri tanımlarken bu etiketlerin birleştirilmesi gerekeceğinden, bunları düzenli ifadeler kullanarak ayarlayalım: .*##1TON##.*``.*##3TON##.*, .*##9TON##.* ve .*##15TON##.* (.* – “herhangi bir alt dize” anlamına gelir).

Bazı siparişler için araç kapasitesi sınırı 1 ila 15 ton, 3 ila 9 ton ve 1 ila 3 tondur. Bu kısıtlama, eşleşen tüm makinelerin etiketlerini içeren düzenli ifadeli bir dize ile bir sipariş için ayarlanır. Yani, location.required_tags alanında gerekli yük kapasitesi durumunda aşağıdaki düzenli ifadeler yer alacaktır:

• 1 ila 15 ton – ##1TON##3TON##9TON##15TON##;
• 3 ila 9 ton – ##3TON##9TON##;
• 1 ila 3 ton – ##1TON##3TON##.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

İsteğe bağlı etiketler

Bazen planlamanın, belirli siparişler için hangi araçların kullanılmasının (veya kullanılmamasının) istendiğini dikkate alması gerekir. Örneğin, VIP siparişleri özel eğitimli kuryelere teslim ettirmek daha iyidir.

Bu tür isteğe bağlı gereksinimler için, isteğe bağlı etiketler öngörülmekte ve bunlar location.optional_tags alanında sıralanmaktadır. Belirlenen bir tercihin karşılanamaması durumunda (örneğin ağırlık veya teslimat süresi kısıtlamaları nedeniyle) bu tercihin ihlal edilmesine izin verilebilir. İsteğe bağlı etiketlerin araç gerekli özellikleri’nden farkı budur.

Tercih önceliği location.optional_tags.value etiketinin ağırlığı kullanılarak ayarlanır. Değeri pozitif ya da negatif olabilir. Planlama sırasında, isteğe bağlı etiket, siparişin yürütüldüğü aracın etiketleri ile karşılaştırılır. Eğer location.optional_tags’den etiket listedeki araç etiketiyle eşleşiyorsa:

• vehicle.tags, bu durumda value rota ücretinden düşülür;

• vehicle.excluded_tags, bu durumda value rota ücretine eklenir.

İsteğe bağlı etiketleri rota ücretine ekleyen değer result.routes.metrics.total_optional_tags_cost alanına döndürülür (negatif olabilir).

Örnek

Bazıları aşağıdaki isteğe bağlı etiketlere sahip 10 siparişin teslim edilmesi gerekiyor:

• vip – 6 siparişte, farklı noktalardaki etiket ağırlığı 100 ila 350 arasında değişmektedir;
• morning – 3 siparişte, etiket ağırlığı tüm noktalarda aynıdır, 500.

Araçlardan birinin vip ve morning etiketleri vehicle.excluded_tags alanında tanımlanmıştır. Bu nedenle, bu kuryeye vip etiketli siparişlerin yanı sıra rotanın geç başlama zamanı nedeniyle morning etiketli siparişlerin atanmamasının daha iyi olduğu belirtilmektedir.

Sonuç olarak, çoğu durumda gereklilikler ihlal edilmemiştir: altı vip siparişinden beşi vip etiketi kısıtlaması olmaksızın kurye ile teslim edilmiştir, morning etiketine göre ihlal yoktur.

Ancak bir vip sipariş, kapasite sınırlamaları nedeniyle vip’de excluded_tags ile etiketlenmiş bir araç için planlanmıştı. Bu rotanın total_optional_tags_cost alanına 100 değeri döndürür: “istenmeyen” bir aracın kullanılması ücreti 100 birim artırmıştır. En düşük ağırlığı location.optional_tags.value olan sipariş için tercih ihlal edilmiştir.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Araçtaki siparişlerin uyumsuzluğu

Siparişler uyumsuz tiplere sahip olabilir, bunlar aşağıdaki parametreler kullanılarak belirtilir:

• options.incompatible_load_types – tüm araçlar için aynı şekilde sipariş uyumsuzluğunu ayarlar. Ayrıntılar için Sipariş uyumsuzluğu bölümüne bakın.

• vehicle.incompatible_load_types – belirli bir araç için siparişlerin uyumsuzluğunu belirtir, yani aracın özelliklerini dikkate almanızı sağlar.

• vehicle.onboard_incompatible_load_types – false (varsayılan) olarak ayarlandığında, sipariş uyumsuzluğu tüm sefer için geçerlidir; true olarak ayarlandığında ise, yalnızca siparişler araçtayken geçerlidir.

Örneğin, süt ve dondurmanın taşınması farklı sıcaklık rejimleri gerektirir. Aracın bir bölmesi varsa, ya süt ya da dondurma taşıyacaktır. Aracın farklı sıcaklık aralıklarına sahip iki bölmesi varsa, süt ve dondurmayı aynı anda farklı bölmelerde taşıyabilir. Bu durumda, tek bölmeli araçlar için vehicle.incompatible_load_types sipariş uyumsuzluğunu belirtmek yeterlidir. İki bölmeli araçlar için bu parametreye gerek yoktur ve genel olarak siparişler için options.incompatible_load_types uyumsuz tiplerin belirtilmesine de gerek yoktur.

Sipariş uyumsuzluğu araç özellikleri dışındaki nedenlerden kaynaklanıyorsa, vehicle.onboard_incompatible_load_types = true parametresini kullanın. Örneğin, rakiplerin siparişlerini aynı anda taşımak mümkün değilse, kurye depoya gitmeden her şirketin siparişlerini ayrı ayrı alacak ve teslim edecektir. Bu, kilometre ve rota süresini azaltacaktır.

Örnek 1

Teslimat aşağıdaki sipariş tipleri ile 4 adresten oluşmaktadır:

• sipariş 1 (id = 1) – flowers;

• sipariş 2 (id = 2) – flowers;

• sipariş 3 (id = 3) – flowers, sweets;

• sipariş 4 (id = 4) – flowers, ice-cream.

Bununla birlikte flowers ve sweets aynı araçta teslimat için uyumsuzdur. Ayrıca, araç 2’de flowers ve ice-cream’nin aynı anda teslimatı yasaktır, ancak flowers ve sweets’nin teslimatına izin verilmektedir. Bu durumda çözüm, ilk araçta 2 ve 4 numaralı siparişlerin, ikinci araçta ise 1 ve 3 numaralı siparişlerin teslim edilmesini içerecektir.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 2.1

Farklı şirketlerin 3 siparişinin alınması ve teslim edilmesi gerekiyor. 1 ve 2, 2 ve 3 numaralı siparişler rakip firmalara ait olduğu için birlikte teslim edilememektedir.

Planlama, kuryenin 1 ve 3 numaralı siparişleri alıp teslim etmesi ve ardından yeni bir seferde 2 numaralı siparişi yüklemek ve teslim etmek için depoya dönmesiyle sonuçlanır.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 2.2

Örnek 2.1’deki ile aynıdır, ancak vehicle.onboard_incompatible_load_types = true.

Planlama, kuryenin 2 numaralı siparişi alıp teslim etmesi ve ardından depoya gitmeden 1 ve 3 numaralı siparişleri alıp teslim etmesiyle sonuçlanır. Kat edilen mesafe ve rota süresi azaldı.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Coğrafi çitler

Araçlar için teslimat bölgesi kısıtlamaları belirlenebilir. Aracın siparişleri teslim edebileceği bölgeler vehicles.allowed_zones parametresi tarafından ayarlanır:

• araç, allowed_zones parametresinde belirtilen herhangi bir bölgedeki siparişleri yerine getirebilir;

• herhangi bir erişim bölgesi ayarlanmamışsa, araç siparişleri kısıtlama olmaksızın yerine getirebilir;

• tüm araçların erişilebilirlik bölgeleri varsa ve sipariş noktası bunlardan herhangi birine denk gelmiyorsa bir sipariş yerine getirilemez.

Teslimat için yasaklanmış bölgeler vehicle.forbidden_zones parametresi ile belirtilir. Araç, forbidden_zones parametresinde belirtilen bölgelerden hiçbirine sipariş teslim edemez.

Siparişler dağıtılırken hem atanan genel seçenek hem bireysel kuryeler için tanımlanan coğrafi bölgelerin uygunsuzluğu dikkate alınır. Ayrıca planlama sırasında coğrafi bölgeler ile ilgili tüm sınırlamalar iptal edilebilir.

Örnek

Örnekte, 4 sipariş ve 2 araç vardır, arayüzde ayarlanmıştır 4 coğrafi bölge. Siparişlerin coğrafi bölgelere aidiyeti koordinatlara göre otomatik olarak belirlenir:

• Sipariş 1 – aynı anda zone1 ve zone2 bölgelerinde;

• Sipariş 2 – zone1 bölgesinde;

• Sipariş 3 – aynı anda zone2 ve zone3 bölgelerinde;

• Sipariş 4 – zone4 bölgesinde.

Araçlar için coğrafi bölge erişilebilirliği belirlenmiştir:

Sonuç olarak, Araç 1 Sipariş 1 ve 2’yi, Araç 2 ise Sipariş 4’ü teslim eder. Sipariş 3 ise adresi her iki araç için de yasaklanmış bölgelerde olduğu için tahsis edilmemiştir.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

İsteğe bağlı coğrafi bölgeler

İsteğe bağlı coğrafi bölgeler, ziyaret için bir bonus veya ceza verilen siparişleri araçlar arasında dağıtmak için kullanılabilir. Her araca bu coğrafi bölgelerden bir veya daha fazlası atanabilir.

İsteğe bağlı coğrafi bölgeler, katı olmayan bir kısıtlamadır. Onların sayesinde ziyareti tercih edilen bölgeleri (öncelikli ve öncelikli olmayan bölgeler) ayarlamak için kullanılabilir.

İsteğe bağlı coğrafi bölgeler vehicle.optional_zones dizisi kullanılarak belirtilir:

• optional_zones.N.zone – coğrafi bölge adı;
• optional_zones.N.value – eğer parametrenin değeri 0’dan büyükse, araç belirtilen coğrafi bölgeyi ziyaret ettiği için bir bonus alır (bu parametrenin değeri rota ücretinden düşülür) ve 0’dan küçükse – bir ceza alır (değer rota ücretine eklenir).

Örnek 1

İki araçla 10 sipariş teslim edilmesi gerekiyor. Bir araç için South isteğe bağlı bir coğrafi bölge, diğeri için ise North isteğe bağlı coğrafi bölge ayarlanmıştır. Bu coğrafi bölgeleri ziyaret etmek için 1000 birim bonus belirlenmiştir. Sonuç olarak, araçlardan biri güneydeki, diğeri ise kuzeydeki siparişleri teslim ediyor. Sipariş 5 bir istisna olmuştur, South bölgesindeydi, ancak araç ile teslim edilmiştir Courier north.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 2

4 kuryenin 27 siparişi teslim etmesi gerekiyor. Kuryeler için şehir 4 isteğe bağlı coğrafi bölgeye ayrılmıştır: Northwest, Northeast, Southwest ve Southeast. Her kuryeye bonus alacağı bir öncelikli bölge, iki öncelikli olmayan bölge ve ceza alacağı bir bölge belirlenmiştir. Planlama, kuryeler siparişleri öncelikli bölgelerine teslim etmesiyle sonuçlanır. Araç kapasitesi sınırlamaları nedeniyle 18, 20 ve 23 numaralı siparişler istisna olmuştur.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Uyumsuz coğrafi bölgeler

Farklı teslimat bölgelerine ait siparişlerin aynı kurye seferine verilmesini engellemek için coğrafi bölge uyumsuzluğu tanımlayabilirsiniz.

Bu tür bölgelerin listesi yalnızca tüm çözüm için değil, aynı zamanda belirli bir kurye için de vehicles.incompatible_zones parametresi ile ayarlanabilir. Kurye için tanımlanan uyumsuz bölgeler, global olarak tanımlanan bölgelere göre önceliklidir. Kuryenin options.incompatible_zones global kısıtlamaya tabi olmasını önlemek için, onun için vehicles.incompatible_zones alanında boş bir liste belirleyin.

Örnek

Üç kuryenin her biri şehrin farklı bölgelerine 4 sipariş teslim etmek zorundadır: kuzeybatı, güneybatı, kuzeydoğu ve güneydoğu. Bu alanlar planlama sırasında coğrafi bölgelerle tanımlanmıştır: Northwest, Southwest, Northeast, Southeast.

Coğrafi bölge uyumsuzluğu global olarak tanımlanmıştır: güney bölgeleri (Southwest ve Southeast) kuzey bölgeleri (Northwest ve Northeast) ile uyumsuzdur. İki kurye için bir de vehicles.incompatible_zones parametresi tanımlanmıştır: ilk kurye için boş bir liste içermekte ve ikinci kurye için ise batı bölgelerinin (Northwest ve Southwest) doğu bölgeleri ile uyumsuz olduğu tanımlanmıştır (Northeast ve Southeast).

Planlamanın bir sonucu olarak:

• ilk kurye Courier 1 global uyumsuzluk kısıtlamasına tabi değildir ve ona farklı bölgelerden gelen 4 sipariş tek seferde atanır;
• ikinci kurye için, vehicles.incompatible_zones parametresinde tanımlanmış olan bölge uyumsuzluğu kısıtlamaları Courier 2 çalışıyor: doğu bölgelerine giden siparişler bir sefere, batı bölgelerine giden siparişler ise diğerine düşer;
• üçüncü kurye Courier 3 global kısıtlamalara tabidir: güney bölgelerine ve kuzey bölgelerine verilen siparişler farklı seferlere ayrılmıştır.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Aracın hareket süresinin düzeltilmesi

Yandex Haritalar trafik sıkışıklığı verileri ve talepte belirtilen hız, bir rota oluştururken aracın hızını hesaplamak için kullanılır. Bununla birlikte, kamyonların trafikte daha yavaş hareket ettiği ve bazı sürücülerin daha agresif araç kullandığı ve tahmin edilenden daha erken vardığı sıklıkla görülen bir durumdur.

Bu tür sapmaları telafi etmek için RouteQ’de, kesirli bir değer belirleyebileceğiniz travel_time_multiplier seçeneği var. Değeri 1 olduğunda hesaplama, beklenen ortalama hıza sahip araç için yapılacaktır. Daha küçük değerler için (örn. 0,8) hesaplama daha hızlı araçlar için, daha büyük değerler durumda ise (örn. 1,2) daha yavaş araçlar için yapılacaktır.

Örnek 1

Aşağıdaki örnekte, rota oluşturma talebi seyahat süresi düzeltilmeden gönderilmektedir. Sonuç olarak, araç teslimatı 4 saat 20 dakikada gerçekleştiriyor ve bunun 3 saat 40 dakikası noktalar arasında seyahat etmek için harcanıyor.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 2

Örnek 1 ile aynıdır, ancak travel_time_multiplier parametresi 0,5’e eşit olarak eklenmiştir. Oluşturulan rotada kurye teslimatı 2 saat 25 dakikada gerçekleştiriyor, bunun 1 saat 45 dakikası noktalar arasında seyahat etmek için harcanıyor. Bununla birlikte park edilmesi ve malların aktarılması için harcanan süre değişmiyor.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 3

Örnek 1 ile aynıdır, ancak travel_time_multiplier parametresi 2’ye eşit olarak eklenmiştir. Oluşturulan rotada kurye teslimatı 7 saat 58 dakikada gerçekleştiriyor ve bunun 7 saat 18 dakikası noktalar arasında seyahat etmek için harcanıyor. Örnek 1’deki rotadan yaklaşık iki kat daha uzun sürer çünkü inşa edilen rotanın bir kısmı trafiğin yoğun olduğu saatlere denk gelir ve araç maksimum hızını kullanamaz. Park etme ve gönderilerin aktarılması için harcanan süre değişmez.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Hizmet süresinin düzeltilmesi

Kuryenin siparişi teslim ederken, teslim etmek için zaman ayırması gerekir. Buna park etme, asansör ile yukarı çıkma, kargonun teslimi ve evrak işleri dahildir. RouteQ’de bu, service_duration ve shared_service_duration alanları tarafından siparişlerde sağlanır. Ancak, bazı kuryeler gönderileri diğerlerinden daha hızlı teslim eder. Örneğin:

• Araçlar ve toplu taşıma araçlarını kullanan kuryeler için eş zamanlı planlama sırasında, toplu taşıma araçlarıyla seyahat eden kuryeler park etmek için zaman kaybetmez. Sonuç olarak, teslimat işlemleri için daha az zamana ihtiyaç duyarlar.

• Kuryeler farklı beceri seviyelerine sahip olabilirler. Deneyimli kuryeler genellikle siparişi teslim etmek için daha az zaman harcarlar.

Kuryelerin hizmet süreleri arasındaki farkı telafi etmek için RouteQ’de, belirli bir kuryenin hizmet süresini etkileyen service_duration_multiplier ve shared_service_duration_multiplier seçenekleri mevcuttur. 1 değeri söz konusu olduğunda, hizmet süresi service_duration veya shared_service_duration alanında belirtilenle aynı olacaktır, 1’den küçük değerlerde hizmet süresi daha kısa olacaktır ve 1’den büyük değerlerde hizmet süresi daha uzun olacaktır.

Örnek 1

Aşağıdaki örnekte, rota oluşturma isteği hizmet süresi düzeltilmeden gönderilmiştir.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 2

Aşağıdaki örnekte, rota oluşturma için Örnek 1’dekiyle aynı istek gönderilmiştir, ancak parametre service_duration_multiplier değeri 0,5’tir. Hesaplamada siparişlerin hizmet süresi Örnek 1’e kıyasla yarısı kadar zaman alıyor.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 3

Aşağıdaki örnekte, rota oluşturma için Örnek 1’dekiyle aynı istek gönderilmiştir, ancak parametre service_duration_multiplier değeri 2’dir. Hizmet, örnek 1’dekinden iki kat daha uzun sürmektedir.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Mümkün olan en kısa sürede teslimat

Optimum bir rota oluşturmak için algoritma, rota noktaları arasındaki beklemeyi en aza indirir. Ancak teslimatı daha erken bir zamana kaydırmanın yararlı olduğu zamanlar vardır. Örneğin:

• geç kalma riskini en aza indirmeniz gerekir;
• kurye gündüz saatlerinde daha rahat seyahat eder.

Siparişlerin mümkün olduğunca erken teslim edilmesini sağlamak için iki parametreden oluşan penalty.arrival_after_start’yi kullanın:

• average_h – zaman aralığının başlangıcından sonraki ortalama varış süresi için ceza miktarını ayarlar. Seçeneği kullanırken her zaman bu değerin belirtilmesi önerilir.
• as_soon_as_possible – rotaya mümkün olduğunca erken başlanıp başlanmayacağını belirler. Parametre true veya false (varsayılan) değerini alır. average_h’e ek olarak belirtilir.

Eğer penalty.arrival_after_start cezası kullanılmazsa, rota noktalar arasında minimum bekleme süresi ve depodan maksimum geç başlama süresi ile oluşturulacaktır.

Bir ceza kullanılırsa, algoritma kaliteyi düşürmüyorsa, daha erken başlayacak rotalar oluşturacaktır.

Rotanın mümkün olduğunca erken başlatılması isteniyorsa (bu ek bekleme süresine neden olsa bile), penalty.arrival_after_start.as_soon_as_possible = true belirtin.

Örnek 1

Rota, farklı zaman aralıklarına sahip 4 siparişten oluşmaktadır. Sipariş 5 için zaman aralığının en erken başlangıcı 08.00’dir. Kurye depodan 11.02’de yola çıkıyor ve ilk sipariş için 11.40’ta varıyor. 5 numaralı sipariş 12.59’da teslim ediliyor.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 2

Örnek 1’deki aynı veriler kullanılıyor, ancak zaman aralığının başlangıcından sonraki ortalama varış süresi için penalty.arrival_after_start.average_h parametresi kullanılarak bir ceza atanmıştır. Bununla birlikte kurye depodan 06.59’da yola çıkar, 8 dakika bekler ve en erken siparişi (sipariş 5) 08.00’de teslim eder.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Örnek 3

Örnek 2’deki aynı veriler kullanılır, ancak ek olarak penalty.arrival_after_start.as_soon_as_possible = true parametresi belirlenmiştir. Bu durumda kurye depodan 06.00’da yola çıkar, 1 saat 7 dakika bekler ve en erken siparişi (sipariş 5) 08.00’de teslim eder.

API isteği (JSON) ⋅ API yanıtı ⋅ Haritada aç

Eklentiler

Eklenti, treylerli bir kamyondur (çekici). Siparişler çekiciye ve treylere yüklenebilir ve bununla birlikte bir sipariş kısmen çekiciye ve kısmen de treylere yüklenebilir.

Treyleri tanımlamak için trailer nesnesini kullanın.

Sorgudaki treyler tanımlama örneği:

{
    "trailer": {
        "capacity": {
            "weight_kg": 10000,
            "units": 200
        },
        "max_capacity_difference": {
            "units": 10,
            "weight_kg": 0
        },
        "cost": {
            "fixed": 1000,
            "km": 10
        },
        "decoupling_time_s": 300,
        "coupling_time_s": 300,
        "rolling_time": {
            "fixed_time_s": 3000
        }
    }
}

Çekicinin treylerle kullanımı hakkında ayrıntılar için Treyler kullanımı bölümüne bakın.