GPS Tabanlı Taksi Gönderme ve İzleme Sisteminin Tasarımı ve Uygulanması

Küresel Konumlandırma Sisteminin (GPS) popülerliği ve yaygın kullanımıyla, taksi endüstrisinde aracın enlem ve boylamını gerçek zamanlı olarak elde etmek için GPS'e güvenmek ve bunu bir aracın gerçek zamanlı olarak uygulamak için temel olarak kullanmak mümkün hale geldi. planlama ve izleme sistemi. Ülke ekonomisinin hızla geliştiği çağda, şehir içi ulaşımın önemli bir parçası olan taksi sektörü de hızlı bir gelişme sürecine girmiştir. Sürekli gelişim sürecinden kaynaklanan çeşitli yönetim sorunları da taksi sektörünü ve taksi şirketlerinin yönetimini yöneten hükümet birimlerinin önüne kondu. Taksi sektörü, doğrudan kamuoyuna dönük bir hizmet endüstrisidir. Taşıtlar, toplum üzerinde geniş bir etkiye sahip olan ve geniş bir yelpazeyi kapsayan şehrin çeşitli bölgelerine dağılmış durumda. İşletmelerin sürekli büyümesiyle, taksi kapasitesinin dağılımının rasyonel bir şekilde nasıl planlanacağı ve taksi kapasitesinin nasıl güçlendirileceği Güvenlik yönetimi, sürücü ve taksilerin kurumsal denetiminin güçlendirilmesi, araç boş kilometresinin azaltılması, yakıt tüketiminin azaltılması, kaynak israfının azaltılması ve yolculara daha hızlı ulaşım sağlanması ve onları desteklemek için daha gelişmiş sistemler gerektiren pratik sorunları çözmek için daha yüksek kaliteli hizmetler vb. Sektörün sağlıklı ve istikrarlı bir şekilde gelişmesini sağlamak ve şirketin kendisinin sektörde daha rekabetçi ve daha hızlı karar verme reaksiyonu olmasını sağlamak için işbirliği yapmak. Devlet yönetimi açısından bakıldığında, bir GPS-based systemihtiyaç vardır. Hükümet denetiminin kapsamlılığını ve eşitliğini en geniş ölçüde tatmin edebilecek eksiksiz bir sistem nasıl tasarlanır ve oluşturulur; işletme yönetiminin bilimsel ve ileriye dönük doğası; sistemin kendisinin ölçeklenebilirliği ve sağlamlığı; aynı zamanda, GPS tabanlı taksi sevk ve izleme sisteminin tasarımında dikkate alınması ve çözülmesi gereken bir sorun olan sürücüler ve Yolculara pratik yardım ve faydalar sağlayabilir.

1

Roadragon' ın asıl işi  olan
1. Tasarım taksi sevk gereksinimlerinin tam anlayışa dayalı bir taksi sevk ve izleme sistemi ve destekler çoklu kullanım olduğunu olaya dayalı sistem tasarımı ve büyük eşzamanlı veri iletimini gerçekleştirmek. Amaç,
tüm
2. Sistem uygulama sürecinde, taksiler ve sistem arasında çok sayıda veri bağlantısı önerin ve çözün ve veri aktarımının bütünlüğünü ve güvenilirliğini sağlayın. Amaç, daha ekonomik sunucu kaynakları ile sistemin daha yükseğe ulaşmasını sağlamaktır
. Veri aktarımının verimliliği ve güvenilirliği.
3. Sistem gerçekleştirme sürecinde karmaşık yol koşullarında sevk edilebilir araçların doğru şekilde aranması sorununu önerin ve çözün. Amaç, daha doğru araç aramasıyla aracın boş kilometresini daha da azaltmak ve aracın yakıt tüketimini azaltmaktır.
Yolcunun biniş noktasına daha hızlı ulaşın.
4. Sistem uygulama sürecinde çok büyük verilerin hızlı ve verimli depolanması ve geri alınması sorununu önerin ve çözün. Ve sistemi günlük olarak açıklamak için proje uygulama sürecinde karşılaşılan gerçek sorunlara çözümlerin analizi ile birlikte
Yönetimin gerçek rolü. Amaç, gerçek zamanlı araç izleme ve yönetimi için hızlı ve doğru veri desteği sağlamaktır.
Yukarıdaki analize göre, sistem aşağıdaki bölümlere ayrılabilir:
1. Temel bilgi bakım alt sistemi: Temel olarak, operatörlerin temel bilgilerinin, araçların temel bilgilerinin, sürücülerin temel bilgilerinin ve temel harita verilerinin bakımından bakımından sorumludur.
2. Yolcu araba rezervasyon siparişi bakım alt sistemi: Esas olarak çağrı merkezi ile veri arayüzünden ve yolcu siparişlerinin bakımından sorumludur ve araç rezervasyon bilgilerini arka plan gönderim sistemine gönderir.
3. Otomatik sipariş gönderme alt sistemi: Temel olarak aracın temel gerçek zamanlı bilgilerinin muhafaza edilmesinden ve aracın alınan sipariş bilgilerine göre eşleştirilmesinden sorumludur. Mesaj ağ geçidi ile mesaj etkileşimi.
4. Mesaj ağ geçidi alt sistemi: Sistem içindeki mesaj formatı ile terminal ve sistem arasında tanımlanan mesaj arasındaki dönüştürme ve iletimden esas olarak sorumludur.
5. Harita izleme sistemi : Esas olarak sevk alt sistemi ile veri etkileşiminden ve araçların harita gösterimi ve gerçek zamanlı dinamik görüntülemesinden sorumludur. Ve araca kontrol komutları gönderin.
Aşağıdan yukarıya veri akışı şu şekildedir: 1. Araç, gerçek zamanlı verileri mesaj ağ geçidi alt sistemine gönderir; 2. Mesaj ağ geçidi, ayrıştırılan verileri gönderme alt sistemine iletir; 3. Otomatik gönderim alt sistemi siparişe bağlıdır
. Araç, aracın enlem ve boylamına göre taranır; 4. Otomatik sevkiyat alt sistemi, aracın gerçek zamanlı bilgileri ve aracın durumu gibi ek bilgileri harita hizmeti alt sistemine gönderir; 5. Harita hizmeti alt sistemi, aracın geçmiş verilerini kaydeder ve bunu, harita izleme istemcisinin Gerçek zamanlı ekranına gönderir.
Yukarıdan aşağıya veri akışı iki ana bölüme ayrılmıştır:
1. Sevk alt sistemi tarafından başlatılan veri akışı: 1. Sevk eden müşteri, araç kullanımı talebini alır ve bunu otomatik dağıtım alt sistemine gönderir; 2. Otomatik sevkiyat alt sistemi, gerçek duruma bağlı olarak uygun bir araç bulur.
Mesaj ağ geçidi alt sistemi üzerinden uygun araçlar ve araç kullanım taleplerini bu araçlara göndermek; 3. Mesaj ağ geçidi alt sistemi mesajı aldıktan sonra, mesaj protokolünü dönüştürür ve bunu belirli araca gönderir.
2. Harita izleme istemcisi tarafından başlatılan veri akışı: 1. İzleme istemcisi, harita sunucusuna bir izleme isteği başlatır; 2. Bir harita sunucusu, bunu gönderme sunucusu aracılığıyla mesaj ağ geçidine iletir; 3. Mesaj ağ geçidi, protokolü dönüştürür ve bunu belirli bir araca iletir.
Üst ve alt veri akışlarından, alt sistemlerin analizi esas olarak başlatılan taleplerin mesajlar yoluyla birbirlerine bildirilmesidir. Sistemin karşılık gelen zamanını ve yüksek veri eşzamanlılığını hesaba katarak, sistemin tasarım sürecindeki her bir alt sistem, genel tasarım için temel olarak "üretim-tüketim" modelini benimser, bunlardan en önemlisi gözlemci modelini kullanmaktır. ayırmak. Bu modun amacı, verileri eşzamansız olarak işlemek için farklı iş parçacığı gruplarından gelen istekleri kesmektir. "Üretici", işlenmesi gereken istekleri üreten iş parçacığı ve "tüketici" de bu istekleri kabul eden ve onlara yanıt veren iş parçacığıdır. Avantajı, dişlerin daha iyi tasarlanması ve gevşek kaplin tasarım felsefesine daha uygun olması için net bir ayrım sağlamasıdır. Ayrıca, geliştiricilerin gerçek kullanım sırasında ortaya çıkan sorunları bulmalarına ve çözmelerine yardımcı olur. Sistemin modüler tasarımı ve uygulaması, sistemin bakımı ve genişletilmesi için de elverişlidir. Aynı zamanda, modüler tasarım ve uygulama, her modülün bağımsız birim testinin ekip içindeki paralel gelişimi iyileştirmesine yardımcı olur ve ayrıca sistemin sonraki yeniden yapılandırma riskleri için yeterli garantiye sahiptir. Her bir alt sistem tasarımının ana işlevleri aşağıdaki gibidir:
1. Mesaj ağ geçidi alt sistemi: Mesajların alınması ve iletilmesinden ve mesaj protokollerinin dönüştürülmesinden esas olarak sorumludur. Mesajların alınması ve iletilmesi, büyük eşzamanlılık durumlarında bağlantı bakımını ve uygulama katmanının ağ tıkanıklığı altında gönderilecek verilerin bütünlüğünü nasıl sağlayabileceğini dikkate almalıdır. Terminal ile sistem arasındaki ayrıştırma, protokol dönüşümü ile sağlanır. Terminal sağlayıcının gönderme ve izleme sistemi değiştirilse bile, bütünlük garanti edilebilir ve sadece ağ geçidi alt sisteminin protokol dönüştürme modülünün değiştirilmesi gerekir.
2. Otomatik gönderim alt sistemi: Binek araçların temel bilgileri ve şehrin yollarının temel bilgileri ile birlikte araçların konum ve durum bilgilerine göre hangi araçların yolcular için uygun olduğuna otomatik olarak karar vermekten sorumludur. Ana modüller arasında mesaj alma ve gönderme modülü, mesaj ve görev (Görev) dönüştürme modülü, iş parçacığı havuzu modülü bulunur. Alt sistemdeki ayrıştırmanın anahtar kısmı, mesaj ve görev dönüştürme modülüdür. Bu modül aracılığıyla, farklı mesajlar bir veya daha fazla bağımsız göreve dönüştürülür ve görevler işlenmek üzere farklı iş parçacığı havuzlarına gönderilir.
3. Harita sunucusu alt sistemi: gerçek zamanlı araçları izleyin ve geçmiş analiz için araçların gerçek zamanlı verilerini kaydedin.
Genel sistem mimarisinin tasarımı
Bu sistem, geliştirme dili olarak Java'yı kullanır. Tasarım sürecinde, tüm sistem modüler tasarımla birkaç alt sisteme bölünmüştür ve Soket, sistem ile sistem arasındaki veri etkileşimi için kullanılır. Alt sistem, görevler ve işlemler arasındaki ayrıştırmayı gerçekleştirmek için esas olarak üretim ve tüketim modunu benimser ve sistemin eşzamanlı işleme kapasitesini iyileştirmek için çok iş parçacığı teknolojisini daha esnek bir şekilde kullanır. Her bir alt sistem arasındaki ortak işlevsel modüller için (ağ bağlantı yönetimi ve bakım modülü, iş parçacığı havuzu modülü vb.) Sistem tasarımı için, alt sistemler içinde gereksiz tekrarlayan gelişmeleri önlemek için süreçte önceden genel ve bağımsız işlevsel modüller tasarlanır. Alt sistem yalnızca gerçek iş mantığıyla yüzleşir.
Üretim ve tüketim modunun tasarımı ve gerçekleştirilmesi
Alt sistem ile alt sistem arasındaki mesaj etkileşimini ve alt sistem içindeki görev sisteminin eşzamanlı işleme gereksinimlerini dikkate alarak, tasarım sürecindeki sistemin en temelini benimsemektir. üretim ve tüketim modeli. Bu modun tanıtımı bu makalede tüketilmeyecek. Bu makale esas olarak bu sistemdeki üretim ve tüketim modunun tasarım yapısını, taksi sevk siparişinin iş sürecinin ayrıntılı analizi ve üretim ve tüketim modunun özel uygulamasıyla birlikte tanıtmaktadır. Bu sistemdeki üretim ve tüketim modunun genel tasarım yapısı, iş parçacığı havuzuna ve görev nesnelerine dayanmaktadır. İş parçacığı havuzu tarafından sağlanan ana işlevler, iş parçacığı bakımı ve yönetimi ile arabellek kuyruğu bakımı ve yönetimini içerir.
Üretim ve tüketim modelinde daha önemli olan iplik havuzunun tasarımıdır. Örneğin, OrderThreadPool, özel bir sıralama düzenine göre yürütmeyi sağlamaktır. Operatörün tür olarak sınıflandırıldığını ve Yeni Order_Task işlem nesnesi olduğunu varsayarsak, OrderThreadPool her operatörün görevlerine göre sırayla çalıştırılacak ve iş parçacığı havuzunda her operatör için yalnızca bir New Order_Task yürütülmesini sağlayacaktır. Tasarımın ilkesi, iki HashMap'i sürdürmektir, bir HashMap, sınıflandırma standardı ile karşılık gelen Görev arasındaki yönetimi sürdürmek için kullanılır, anahtar sınıflandırma türü ve değer LinkedList görev listesidir. Bu kategorinin görevini sürdürmek için kullanılan başka bir HashMap yürütülüyor. GetTask sırasında aynı türde bir görevin yürütüldüğüne karar verildiğinde, elde edilen görev devam etmeyen ve yürütülmek üzere iş parçacığı havuzuna döndürülen bir görev türü olana kadar karşılaştırma için başka bir görev türü seçilir. Aynı zamanda sistem, 1.5'ten beri Java tarafından sağlanan yüksek performanslı eşzamanlılık araçlarının kullanımına da odaklanmaktadır, örneğin: okuma-yazma kilitleri, semaforlar, eşleştirilmiş değişimler için iş parçacığı senkronizasyonu, vb.
Esas olarak araç izleme ve gönderme sistemi olmasına rağmen Yalnızca araç sevkiyat departmanını içerir, çünkü sistem ile araç arasındaki doğrudan bağlantıyı gerçekleştirir, gerçek zamanlı temel araç verilerini elde etme yeteneği, şirketin rafine yönetimi için sağlam bir temel oluşturmuştur. Bu nedenle, tasarım sürecinde, işletmenin üst yönetiminin yönetim fikirlerini tam olarak dikkate almak ve esnek yönetim fikirlerini nispeten sabit bir zamanlama sistemi ile birleştirmek de gereklidir. Araç planlama ve izleme sisteminin gerçekten kurumsal bilgi inşasının öncüsü olmasına ve kendi stratejik yönünü gerçekleştirmek için işletme ile işbirliği yapmasına izin verin.
Araç geçmiş verilerinin bakımı

2

Aracın geçmiş verilerini korumak, aracı analiz etmenin ve izlemenin anahtarıdır. Aracın geçmiş verileri, esas olarak aracın geçmiş yörünge dosyası bilgilerini, aracın geçmiş çalışma verilerini vb. İçerir. Aracın geçmiş yörünge verileri, çoğunlukla yolcu şikayetlerini çözmek, trafik kazalarını analiz etmek ve yolcuların kayıp eşyalarını bulmak için kullanılan aracın geçmiş sürüş rotasını bulmak için kullanılır. Fiili başvuru sürecinde, aracın yörüngesinin harita üzerinde sorunsuz bir şekilde çizilebilmesi için aracın enlem ve boylam yörünge noktalarının rapor sıklığının yeterince yoğun olduğundan emin olunması gerekmektedir. Bir araç her 10 saniyede bir pozisyon raporu yüklerse, günde 8640 olacaktır. Konum raporu verileri, konum raporu verilerinin bir parçası olarak hesaplanır [4 bayt araç tanımlama numarası + 8 bayt enlem ve boylam + 4 bayt süre + 1 bayt hız + 1 bayt (yön, konumlandırma) + 1 bayt araç durumu + 4 bayt alarm tipi] a toplam 23 bayt, günde bir Aracın iz verileri 194K'ya kadar. Günde on bin araç 1G veriye ulaşabilir. Bu veriler nasıl saklanır? Kullanıcılara kolay ve hızlı sorgulama nasıl sağlanır? Yönetim için yeni fikirler sağlamak için bu verilere dayalı olarak yararlı bilgiler nasıl analiz edilir? Bu konular sistem tasarımı ve uygulama sürecinde dikkate alınmalıdır. Araçların geçmiş işletim verileri esas olarak her aracın günlük gelirini analiz etmektir. Gelir verilerinin analizi, yönetimin mevcut ücretlerin makul olup olmadığını, kapasite girdisinin doymuş olup olmadığını ve diğer yönetim verilerini analiz etmesine yardımcı olur. İşletme verileri temel olarak plaka numarası, araç kimlik numarası, başlangıç ​​saati, bitiş saati, çalışma mesafesi, çalışma miktarı vb. Gibi temel verileri içerir. Araç başına günde 80 işlem ile günde 10.000 aracın 800.000 kaydını analiz edin. İşletim verilerinin bütünlüğünün nasıl sağlanacağı, işletim verilerinin depolanması ve analizi ve bu temel işletim verilerinden yönetim analizi için yararlı verilerin nasıl çıkarılacağı, böylece kullanıcıların bunları rahat ve hızlı bir şekilde kullanabilmesi için dikkate alınması gereken hususların tümü, sistem tasarım süreci.
 GPS Vehicle historical data
According to the implementation of the system, the system is implemented in JAVA programming language, deployed on the server of the Linux operating system, and the database uses Oracle11g. Regarding the massive amount of data and the operating frequency of the data, the system is stored in two ways: file disk storage and database storage. For the vehicle trajectory file, a data system with a high upload frequency, it mainly uses file disk storage to store basic data. For vehicle operating data, data that is relatively infrequently uploaded, is stored in the form of database storage. The following will introduce solutions for processing two kinds of data. The main purpose of the vehicle trajectory file is to trace the historical driving situation of the vehicle and to statistically analyze the number of historical vehicles in each time period in different areas.
Scenarios for retrospecting the historical driving situation of the vehicle include: 1) Lost and found by passengers: Passengers left their belongings in the vehicle, but cannot provide specific vehicle information, and can only provide a certain place during a certain period of time. The system needs to find out all the vehicles that have passed the locations recalled by the passengers based on the historical trajectory information of all vehicles in a certain period of time for investigation. 2) Passenger detour complaints: Passengers provide information about the vehicle they are in, and the system queries the vehicle's driving route during the service period to determine whether the vehicle is detouring illegally. 3) Vehicle statistics for each time period in different areas: Generally used to monitor whether the number of vehicles in the area is abnormal, so as to determine whether the vehicles in the area have stopped or went on strike. In practical applications, the monitored city needs to be divided into multiple monitoring areas, and the number of vehicles in the area is counted according to the 24 hours a day. The number of vehicles in the area is divided into 24 hours a day to form weekly averages, monthly averages and other reference data, combined with the real-time number of vehicles on the day The situation is compared to draw a reference conclusion whether there is any abnormality. According to the above three common scenarios in the actual business process, it can be found that the main analysis and query conditions for vehicle historical trajectory data are: time, latitude and longitude, and specific vehicle. According to the analysis in the previous question, the number of trajectories of a car in a day can reach up to 8,640, and the amount of data can reach 194K, so it is not an ideal solution to store these data in a database. Because each vehicle reports a position in 10 seconds, 10,000 vehicles will have 1,000 database insertions in one second. Frequent database table operations will definitely affect the performance of the system. From the perspective of query analysis, a car has a maximum of 8,640 position report data a day, and 10,000 cars equals 864 million position report data. Even if the database partition table or sub-table is used and the key fields are indexed, if the vehicle trajectory is used The playback operation query will generate various I/O waits at the database level, leading to a sharp drop in system performance. Therefore, when the system is designed, the storage of the vehicle trajectory file adopts the file disk for direct storage. Choose the file storage structure. According to the actual business reference analysis and the determined storage method, the system design needs to consider how to store it to be more efficient. The most common is to use the storage structure of the hash file. Hashing files is similar to the Hash table in the data structure, that is, according to the characteristics of the keywords in the file, a hash function and a method to handle conflicts are designed to hash the records on the storage device. The difference from the Hash table is for the file , File records on the disk are usually stored in groups. Several records form a storage unit, which is also called a "bucket". Since our development language is Java, we can find from the HashMap structure implemented in the Java language API that the data structure of the hash table is composed of an object array and multiple object linked lists. The object array is similar to the concept of "bucket". Each bucket is identified by a hash value. If there are objects with the same hash value, they are stored in the object linked list of the "bucket". The search time of the data structure hash table is complicated. The ideal situation can reach O(1), that is, each "bucket" has only one object, and the worst may be only one "bucket". All data is put into the object list of this "bucket", so the worst The search time complexity will reach O(n). Of course, in the HashMap implementation process, there is a function of judging the total number of objects and the number of "buckets" and regenerating the correspondence between the new distribution "buckets" and objects. Understanding the data structure implementation of an actual hash table structure helps us design our own hash file based on the hash table data structure. Hash distribution of trace files. According to the use of the trajectory file and the attributes of the file itself, the system divides the file into storage levels according to the hierarchical structure of year, month, day, and vehicle license plate. Considering the scalability of the system, it is convenient to access more vehicles in the future. Use the last character of the license plate number for hash processing.
The principle and design of dispatching to find a car

4

GPS tabanlı taksi sevk ve izleme sisteminde, sistemin nasıl gerçekleştirileceği otomatik olarak yolculara fikir ve tasarım şemaları sağlamak için uygun araçları bulur. Sistemin sevk fonksiyonunun amacı, yolculara en zamanında araçları sağlamak ve taksilere en yakın yolcularla sağlanarak sürücünün kilometresini azaltarak enerji tasarrufu ve emisyon azaltma hedefine ulaşmaktır. Sürücüler için para tasarrufu sağlar ve yolcular için kolaylık sağlar.

Sevk için araç bulma tasarım sürecinde dikkate alınması gereken ilk iki hedef: hızlı ve doğru. Öncelikle, bir araba talebini sağlamak için arayan bir yolcunun temel özelliklerini anlayalım. 1) Yolcunun aradığı telefon numarası; 2) Yolcunun aracı kullandığı saat; 3) Yolcunun araca bineceği yer. Bu üç temel özelliğin telefon numarası doğrudan çağrı sistemi üzerinden elde edilebiliyor ve eğer araç birisi adına rezerve edilmişse yolcunun telefon numarasını geri araması istenerek elde edilebiliyor. Yolcular ayrıca sevk memuruna arabanın saatini bildirmek için inisiyatif alacaktır. Anahtar, biniş yerinin üçüncü noktasıdır. Yolcular genellikle sadece aşağıdaki gibi fiziksel bir adres söyler: belirli bir yola hangi yolun yakın olduğu ve diğer metinsel açıklamalar. Sevk sistemi için, sistemin araçları bulmak için metinsel yol durumu bilgilerini belirli enlem ve boylam bilgilerine dönüştürmesi ve sevkiyat için uygun araçların olup olmadığını belirlemek için enlem ve boylam bilgilerini kullanması gerekir. Bu nedenle doğru araç araması için en temel çalışma, yolcu biniş lokasyonunun enlem ve boylam bilgilerinin nasıl elde edileceğidir.

Alım noktasının enlem ve boylam bilgilerini koruyun

Teslim alma noktasının enlem ve boylam bilgilerini korumak, şehrin yol kütüphanesi bilgilerini korumaktır. Temel olarak şunları içerir: yol kavşak enlem ve boylam verileri, dönüm noktası bina enlem ve boylam verileri, ev numarası bölüm enlem ve boylam verileri, vb. Farklı şehirlerin yol özelliklerine göre, enlem ve boylamın kaynağını göndermek için farklı veriler kullanılabilir. toplama noktasının verileri. Örneğin, Şangay gibi standartlaştırılmış ve olgun ev numaralarına sahip şehirler, araç biniş noktasının enlem ve boylam verilerinin kaynağı olarak bina numarası segmentinin enlem ve boylamını tercih edebilir. Bazı küçük şehirlerde, simgesel yapıların enlem ve boylamı, yolcu biniş noktasının enlem ve boylamının kaynağı olarak kullanılabilir. Genel şehir, yolcu biniş noktasının enlem ve boylamının kaynağı olarak yol kavşağının enlem ve boylamına daha uygundur.

Bu yöntemlerin her birinin sayı bölümüne, simgesel yapılara ve yol kavşaklarına göre avantajları ve dezavantajları vardır. Genellikle gerçek uygulama sırasında kombinasyon halinde kullanılır. Bina numarası segmentinin nispeten küçük bir uygulama aralığı vardır ve şehrin bina numarası dağılımı standartlaştırılmış ve sürekli olmalıdır. Ancak kapı numarası segmentinin yolu, yolcu biniş yerinin enlem ve boylamını hızlı ve doğru bir şekilde bulabilir. Prensip şu şekildedir: bina numarasına göre bir yolu birkaç küçük yola bölün ve küçük yolları boylam ve enlem noktaları olarak kullanın. Kaç tane kapı numarasının bir bölüme ayrıldığına gelince, yol bilgilerini toplayan personel yolun gerçek koşullarına göre karar verir. Kapı numarası segmentinin enlem ve boylamını toplamak, toplayıcının belirli bir yolun kapı numarası segmentine girmesi ve en doğru yol boylamı ve enlem verilerini elde etmek için GPS cihazı aracılığıyla enlem ve boylamı yüklediği yol olabilir. Sistemin fiili kullanımında, yolcunun araç telefonunu arayıp biniş yeri yol ve bina numarasını bildirmesi durumunda, sistem yol ve bina numarasına göre bina numarasının ait olduğu ev bölümünü bulup, ev bölümünde karşılık gelen numara. Boylam ve enlem bilgileri, örneğin, bir yolcu arayıp arabanın adresinin No. 10 Zhongshan Yolu olduğunu söylediğinde, sistem No. 10 Zhongshan Yolu'nun No. 2 ila No. 50 Zhongshan Yolu aralığında olduğunu bulacaktır. , böylece sistem 2 No.lu Zhongshan Yolu'na dönecek. Yol bölümüne karşılık gelen enlem ve boylam bilgileri yolcu biniş noktasının enlem ve boylam bilgisi olarak kullanılır. Biniş konumunun enlem ve boylamını elde etmenin bu yöntemi nispeten doğrudur ve hata 500 metreyi geçmeyecektir. Dezavantajı ise, bina numarası verilerini edinmenin nispeten büyük iş yükünün, erken aşamada zorlu ve ayrıntılı bir temel veri toplama süreci gerektirmesidir. Dahası, şehir evi sayılarının standardizasyon derecesi nispeten yüksektir. Bir şehir yolunun enlem ve boylamını elde etmenin ana yolu, şehrin harita verilerinin analizi yoluyla kesişen yolun enlem ve boylam bilgilerini elde etmektir. Yolcu aradığında, biniş noktasının yaklaşık enlem ve boylamını elde etmek için belirli yolun belirli yola yakın olduğu belirtilir. Bu enlem ve boylam elde etme yöntemi daha uygundur, ancak dezavantajı, konumlandırmanın doğruluğunun garanti edilememesidir. Yolcu, yolun birkaç kilometre yakınında kavşak olmaksızın uzun bir yolda olduğunda, sistem, yolcunun enlem ve boylam bilgilerine dayalı olarak yolcunun doğru biniş enlem ve boylamını doğru bir şekilde elde edemeyecektir.

Bir araba bulma planlaması

3

Yolcu biniş noktasının boylam ve enlem verilerinin bakımı, araçları bulmak üzere araçları otomatik olarak göndermek için sistem için sağlam bir veri temeli sağlar. Araba bulmanın gerçekleştirilmesinin, yerel şehrin yol özellikleri ve sevkıyata katılan taksilerin sayısı ile birlikte değerlendirilmesi gerekmektedir.
Doğrusal enlem ve boylam mesafesine göre bir araba bulun
Bu araba bulma yöntemi nispeten uygun ve uygulanması pratiktir ve en sık olarak pratik uygulamalarda kullanılır. Gerçekleştirme prensibi: Daire içindeki araç sevk görevlisinin aradığı araç olduğu sürece, yarıçap olarak arabanın arama mesafesinin merkezi olarak yolcu biniş noktasının enlem ve boylamını içeren bir daire çizin. Araç bulunana veya yarıçap sistem tarafından ayarlanan maksimum değere ulaşıncaya kadar araç bir seferde araç ile belirli bir aralığa göre yarıçap karşılaştırılmaya devam edilecektir. Bu yöntemin uygulanması nispeten basittir, ancak verimlilik çok yüksek değildir, çünkü tüm araçlar ile dairenin merkezi arasındaki mesafeyi hesaplamak gerekir. Bilimsel ve verimli değildir. Bir arabayı arayan 10.000 aracın olduğu bir platformda bir yolcuyu hayal edin. Aslında yolcu biniş noktası çevresinde 20'den fazla araç olmayacak ve yolculara sadece bir araç sağlanacak. Ancak platformdaki 10.000 aracın tamamı için mesafeyi hesaplamamız gerekiyor. Temel olarak 9.980 hesaplama gereksiz hesaplamalardır. O halde fiili kullanımda, mevcut sunucu performansının sürekli iyileştirilmesi nedeniyle, bu yöntemi 10.000'den fazla araç içeren bir taksi sevk platformunda kullanmak hala hızlı ve doğru bir uygulama yöntemidir. Özellikle Şangay gibi makul yol planlaması olan bir şehirde, yolcu almak için geri dönmek için yolcu biniş noktasından önce aracın uzun bir mesafe kat etmesi gerektiği olgusunu dikkate almaya gerek yoktur. Boylam ve enlemin doğrusal mesafesine göre bir araba bulmanın getirdiği devasa gereksiz hesaplamaları dikkate alan sistem tasarımının daha fazla optimizasyon yönü vardır.
Grid araba araması
Izgara araması, bir arabayı düz hat mesafesinde bulma sürecinde büyük ve gereksiz hesaplamalardan kaçınmak ve arama sürecinin performansını optimize etmektir. İlke şudur: İlki, şehir enlem ve boylama göre ızgaralara bölünmüştür; ikinci olarak aracın ızgaradaki konumu, aracın gerçek zamanlı enlem ve boylamına göre kaydedilir. Yolcu biniş noktasının konumuna göre, çevredeki ızgaradaki araçlar elde edilir ve bu ızgaralardaki araçlar ile yolcuların biniş enlem ve boylamları arasındaki mesafe, yolculara en uygun aracı elde etmek için karşılaştırılır.
Doğru bir araba bulmak için GPS Harita verileri

5

En ilkel düz çizgi araba araması mı yoksa daha fazla ızgara araması mı olduğuna bakılmaksızın, en temel ilke, yolcunun boylamı ve enlemi arasındaki karşılaştırmaya dayalı olarak arabanın alternatif bir sevk aracı olarak uygun olup olmadığına karar vermektir. biniş ve aracın düz mesafesi. Kesin araç bulmayı elde etmek için yol verilerinin nasıl birleştirileceği mevcut sevkıyat sisteminde yaygın değildir. Bunun nedeni, genellikle şehir içi karayolu ağı yapılı araçların dönmesinin daha uygun olmasıdır. Yüksek otoyollara sahip büyük şehirler de boş araçların kaldırılmasına izin verilmemesini şart koşuyor. Bu nedenle Çin'de yolcu biniş noktası ile aracın enlem ve boylam noktaları arasındaki düz hat mesafesinden araba bulmak müşterilerin temel ihtiyaçlarını karşılamak için yeterlidir.
Ama Endonezya'daki Cakarta gibi bazı özel şehirler. Bu şehrin yollarındaki araçların geri dönmek için genellikle birkaç kilometre veya daha fazla sürmesi gerekir. Endonezya depreme yatkın bir bölgede yer aldığından, şehrin metrosu yok, bu nedenle hızlı otobüsleri sürmek için yolun ortasında iki özel yol açılıyor. Gerçek şu ki, ayrılmış araçlar hiç dönemez. Böylesine sakıncalı bir şehirde, bir araba bulmak için yolcu biniş noktasının enlem ve boylamı ile aracın enlem ve boylamı karşılaştırılırsa, kişi ve araç farklı taraflarda olacaktır veya yolcunun konumu sürülür, bu nedenle aracın geniş bir alanda dolaşması gerekebilir. Daire yolcuları almak için geri gelebilir. Bu, GPS dağıtım sisteminin sürücülerin yakıt tüketiminden tasarruf etme konusundaki ilk niyetiyle çelişiyor. Bu çelişkiyi çözmek için sistem, araç ile yolcu biniş arasındaki mesafeyi ve uygun bir aracı bulmak için yol bilgilerini kullanmayı düşünmelidir.
Tasarım fikri: Haritada çizilen yollar genellikle "segmentler" ile temsil edilir. Bir yol, sürekli "bölümlere" ayrılmıştır. Ve her bölümün genişliğine göre bir "bant" oluşturur. Bu şekilde haritada tam bir yol deseni görüntülenebilir. Her kavşağın dönüp dönmeyeceğine, yolun tek yönlü olup olmadığına vb. Göre, yol bilgisi önce yönlendirilmiş bir grafikte birleştirilir. Daha sonra araç arama mesafesine göre yolcu biniş noktasına en uzak yol noktasının neresi olduğu hesaplanarak yol enlem ve boylam verileri elde edilir. Yola yönelik grafikten elde edilen yol enlem ve boylam çizgisi verilerine göre artı yolun her bölümünün genişliği yolun "kuşak" enlem ve boylam aralığını elde eder. Ardından aracın gerçek enlem ve boylamı ile aracın yolda "kayış" olup olmadığına karar verin. Aracın enlem ve boylamı yol "kemeri" aralığında ise bu, aracın nitelikli bir yolda gittiği anlamına gelir. Her ne kadar grafik geçişi ve maksimum çapraz geçiş mesafesi kombinasyonu araçların aranmasını, yol "haritasında" başlangıç ​​noktasının nasıl ayarlanacağını, yani yolcuların biniş noktasının yola nasıl düşeceğini, sonuçta, Çok sayıda yolcunun araca bindiği yol konumu değil Sistem tarafından tutulan yolda olmalı ve ayrıca enlem ve boylamın sadece topluluk içinde olması da mümkündür. Çok ayrıntılı şehir enlem ve boylam verileri olmadan bu durumla başa çıkmak zordur, çünkü yolcunun enlem ve boylamını yolcunun biniş enlem ve boylamı olarak basitçe kaydıramazsınız, çünkü yolcunun topluluk içinde olması çok muhtemeldir. , yolcuyu en yakın enlem ve boylam ile araca bindirmek için bırakarak Yol, topluluk duvarı ile ayrılmıştır. En yakın yolu yargılamak için çok detaylı harita verileri gereklidir ve topluluk kapısına kadar doğru olması gerekir. Projeye yapılan yatırımı azaltmak için sistem, ancak yolcu biniş noktasının enlem ve boylamının yolun enlem ve boylamına bağlı olması konusunda anlaşabilir.
Temel yol kütüphanesi veri işleminde, yol kütüphanesi verilerinin gerçek yola yerleştirilmesi gerekir. Sistemin bir yolcunun biniş enlemini ve boylamını aldığı ve sistemin şehir içi yol verilerinden yolcu biniş enlem ve boylamının bulunduğu yol "segmentine" hızlı bir şekilde geçmesi gereken bir senaryo hayal edin. Ve bu yol "bölümüne" göre yol "bölümüne" bağlı yol "kesiti" ni elde etmek için, elbette, arabanın sadece boylam ve enlem doğrusal mesafesini elde etmemiz gerekiyor, bir araba bulmak için belirtilen maksimum mesafeden daha az araba, çünkü iki nokta arasındaki doğrusal mesafe en kısadır, Düz çizgi mesafesi bir araba bulma maksimum mesafesini aştıysa, yolun gerçek viraj mesafesi kesinlikle bir araba bulma maksimum mesafesini aşacaktır. Araç bulmak için maksimum mesafeyi karşılayan ve yolcuların araca bindikleri yol yönüyle bağlantılı bulunan tüm yol "bölümlerine" göre, her yol "bölümü" tarafından tanımlanan yol genişliğine göre yol "kuşak" elde edilir. . Bu nedenle, uygulama sürecindeki ana çalışma, bir yol modeli oluşturmak ve biniş yapan yolcuların boylam ve enlemleri ile bağlantılı yolun hızlı bir şekilde nasıl elde edileceğidir. Yol verisi yapısı için, önce gerçek bir yol verilerini "segmentlere" bölmeyi düşünün. En uzun “bölüm” ün 1 km uzunluğa bölündüğü varsayılırsa, tüm Şanghay şehri örnek alınır. Şanghay otoyollarının toplam uzunluğu yaklaşık 11.000 kilometre ve şehir içi yolların toplam uzunluğu yaklaşık 4.400 kilometredir. Yol bölümünün veri hacmi 1 km'ye bölünse bile, yol "bölümü" dikkate alındığında küçük bir büyüklük sırasının önemli bir özelliğidir.
Sonuç
Araç planlamasının en temel ve en kritik işlevi, doğru aracı hızlı ve doğru bir şekilde bulmaktır. Bu bölüm, araba bulmanın temel ilkelerini ve çeşitli araba bulma yöntemlerinin gerçekleştirilmesini, avantajlarını ve dezavantajlarını tanıtmakta ve analiz etmektedir. En yaygın mesafeden bir arabayı bulmak için bir ızgaraya, bir araba bulmak için ve nihayet kesin araç aramanın tasarımını ve uygulamasını kentsel yol bilgileriyle birleştirin. Kesin araba bulma tasarım sürecinde yol bilgileriyle birleştirilmiş kentsel temel yol verilerinin büyük miktarda sıkıcı bakımı ve yönetimi olmasına rağmen, bu araba bulma yöntemi yol bilgileri ve müşterilerin gereksinimleri ile gittikçe daha mükemmel hale gelecektir. gönderim doğruluğu gittikçe artıyor. Sonuçta, bir araba araması ne kadar doğru olursa, aracın boş kilometresini o kadar azaltabilir ve gereksiz yakıt tüketimini azaltabilir ve sürücünün coşkusu daha da artacaktır. Yol coğrafi bilgileriyle birlikte hassas araba bulma ile birlikte araba bulmanın zamanlama yöntemi, gelecekte giderek daha yaygın bir şekilde kullanılacaktır.
Veri analizi ve uygulama
Taksi park sorunu

6

Çeşitli yerlerdeki ulaştırma büroları için en sıkıntılı şey, yetki alanlarındaki taksilerin grev yapması ve trafik olaylarını durdurmasıdır. Sadece vatandaşların seyahatlerini etkilemekle kalmaz, daha büyük bir sebep de kötü etki kapsamının toplumun istikrarını ve birliğini büyük ölçüde etkilemesidir. Taşımacılık Bürosu için istikrarı sağlamak için taksilerin askıya alınmasının en büyük önceliği olduğu söylenebilir. Son yıllarda çeşitli nedenlerle zaman zaman taksi grevleri ve askıya alma olayları yaşanmaktadır. Taksi askıya alma işlemlerini çözmenin yolu temelde hükümetin idari müdahale yöntemidir ve GPS izleme platformu temelde bir kaza durumunda yardımcı rol üstlenir. Taksi durağı sorununu çözme sürecine göre analiz edin. Hükümet genellikle taksi şirketlerini bastırma yöntemini benimsiyor ve bazı şirketler sürücülerin ideolojik işlerini yapmak için öne çıkıyor. Sürücülerin sürüşü bırakmasının temel nedeni, düşük gelir ve aşırı iş yoğunluğundan başka bir şey değildir. GPS sistemi yalnızca izleme rolünün bir bölümünü oynamaktadır ve hükümetin hala ziyaret etmek için çok sayıda personeli göndermesi gerekmektedir. Bununla birlikte, GPS tabanlı taksi gönderme ve izleme platformu izleme rolünün yalnızca bir bölümünü oynayabilir mi? Analiz ve düşünmeden sonra, pratik ve teorik analiz. GPS tabanlı taksi sevk ve izleme sistemi, tam önleme, ön hatırlatma, olay sırasında izleme ve olay sonrası özetleme yeteneğine sahiptir.
Önceden önleyin
Yerli taksi sektörünün hükümetten şoföre genel yapısı temelde aynıdır. Temel olarak, hükümetin kendi yetki alanı dahilindeki taksi şirketlerinin işleyişini yönetme yetkisi vardır; taksi şirketleri, her ay sürücüye belirli bir yönetim ücreti talep ederek taksileri çalıştırma ve taksilerin günlük işleyişini sürücüye aktarma hakkına sahiptir; sürücü, sürüşten sorumludur. Yakıt masrafları, onarım masrafları ve kural ve yönetmelik ihlalleri nedeniyle para cezaları temelde sürücü tarafından karşılanır. Bir taksi şirketine ödenen yönetim ücreti, temelde sürücünün aylık gelirinin yaklaşık 2 / 3'ünü oluşturur. Hükümet personeli ile iletişim ve taksi şoförünün birkaç olayın askıya alınması sürecini anlaması sayesinde, taksinin askıya alınmasının kabaca iki nedeni olduğu görülmüştür:

Sürücünün geliri çok düşük;
2. Teşvik edilen liderler ve organizasyon var. Durma olayının nedenini GPS tabanlı taksi sevk ve izleme sisteminin gerçek durumu ile birleştirerek, sistem ilgili departmanlara önceden bir hatırlatma verebilir. Gerçek durumu analiz edelim: Taksiler şehrin sokaklarında ve sokaklarında çalışıyor. Tam da yönetim karmaşıklığını getiren hareket kabiliyetinden kaynaklanmaktadır. Taksinin içindeki en önemli cihaz, sürücünün her bir işyerinin detaylı bilgilerini kaydeden sayaçtır. Miktar, başlangıç ​​ve bitiş zamanı, kilometre vb. Dahil olmak üzere, taksiye takılan GPS terminali, terminaldeki kablosuz iletişim yoluyla araçtaki taksi ve taksimetre ile sistem arasında gerçek zamanlı bir bağlantı kurar. Yöneticiler bu taksileri kontrol edebilir ve yönetebilir. Terminal üzerinde bulunan haberleşme modülü sistemi sayesinde her aracın sayaç kaydını ve günlük geliri kavrayabilirsiniz. Bu iki endeks sistemi sayesinde, her sürücünün aylık temel geliri analiz edilebilir. Aylık gelire göre, hangi sürücülerin kışkırtılacağına karar verilebilir ve yönetim departmanı, gizli tehlikeleri ve tomurcuklanmayı ortadan kaldırmak için çeşitli önlemler alabilir. Örneğin, şirketler, düşük gelirli sürücülerle çalışanlarını önemseyecekleri, sürücülerin zorluklarını zaman içinde öğrenebilecekleri ve belirli zorluklara sübvansiyonlar sağlayabilecekleri şekilde mülakat yapabilirler veya iyi iş deneyimi kazandırarak sürücülerin gerçek gelirini artırabilirler. Önlem fikri açıktı: sürücünün durma olasılığının olup olmadığını belirlemek için sürücünün gerçek gelirinin istatistiksel analizi yoluyla. Düşük gelirli sürücülerle önceden yüz yüze iletişim ve diğer yöntemlerle, sürücülerin gerçek zorluklarını çözmeye çalışın, düşük gelirli sürücülere özen gösterin ve sorunları onlardan önce önleme etkisini elde etmek için şirketin sürücülere gösterdiği özeni gösterin. meydana gelir. Bu süreçte sistem, görüşülen kişiyi önceden doğru bir şekilde değerlendirmede, şirketin amaçsızlığından kaçınmada ve şirketin işini daha amaçlı ve etkili hale getirmede rol oynar. Gerçekleştirme yöntemi için ana veri temeli, taksideki taksimetrenin gelir verileri ve taksi sayaç kaydıdır. Bu nedenle, sayaç, GPS araç terminaline bir veri arayüzü sağlamalıdır ve veriler, her hizmetten sonra araç terminaline "aktarılabilir". Verileri aldıktan sonra, araca monteli terminal onaylar ve sayaca bir onay geri bildirim mesajı gönderir. Araca monteli terminal, sayaç verilerini kablosuz iletişim modülü aracılığıyla sisteme yükler. Sistem veriyi aldıktan sonra, veri tabanında depolar ve araca monteli terminale alındığını teyit eden bir geri bildirim mesajı gönderir. Teorik olarak, verilerin bütünlüğünün bir onay geri bildirim mesajı gönderilerek teslim edilmesi garanti edilir. Öte yandan, verilerin "güvenilir" olup olmadığını belirlemek için, yüklenen veriler ile gerçek durum arasındaki sapma derecesini belirlemek için sistemin çeşitli yerlerde mevcut duruma göre çeşitli veri eşikleri ayarlaması gerekir. Örneğin, günlük ortalama "ölçüm" sayısının, tek farkın maksimum çalışma miktarının, vb. Ayarlanması. Sistem, yöneticilerin karar vermesi için çeşitli ayarlanmış veri eşiklerine göre karşılaştırma sonuçları üretir.
Taksilerin gelir verilerindeki büyük miktardaki verileri hesaba katarak, 10.000 aracın günlük işletme veri kayıtlarını hesaplamak için araç başına günlük 80 gelir verisi 800.000'dir. Tasarım sürecini gerçekleştirmek için bölüm tablosunu kullanmayı düşünün. Yani, ayda bir bölüm tablosu. Bölüm tablosu ve bölüm tablosu anahtarı olarak yüklenen işletim verilerinin gerçek oluşum zamanını alın. Her bir aracın toplam günlük gelirinin yanı sıra günlük ölçüm, çalışma mesafesi ve boş sürüş kilometresi sayısını hesaplamak için günde bir kez otomatik istatistikler yapılır. Sürücünün gelirinin fiili duruma uygun olup olmadığını belirlemek için sayaç sayısı kullanılır ve boş kilometreyi azaltarak yakıt tüketimi hedefinden tasarruf edilip edilemeyeceğini belirlemek için çalışma kilometre ve boş kilometre karşılaştırılır.
Önceden
hatırlatın Sürücü toplama olayını durdurduğunda, yönetime mümkün olan en kısa sürede nasıl hatırlatılır ve yönetime gerçek durumu anlayıp bir çözüm planı yapması için yeterli zaman verilir? Bu aynı zamanda yönetim departmanının büyük önem verdiği bir işlevdir. Sürücünün taksi durağı olayındaki amacı sosyal etkiyi genişletmek ve ilgili departmanların dikkatini çekmek ve taleplerini dinlemektir. Bu nedenle, bir taksi durağı olması durumunda, araçlar şehrin çeşitli etkili noktalarında toplanacaktır. Bu nedenle, sistem, durma ve toplanmayı tasarlarken ve değerlendirirken iki yöntemi benimseyebilir: 1) Gerçek zamanlı araç sayısını ve alandaki araç durumunu belirlemek için izleme alanını önceden ayarlayın; 2) İzleme alanını önceden ayarlamayın ve şehir sınırlarına tamamen uyun. Rafine alan, araçların toplanıp toplanmadığını belirlemek için kullanılır. Bu iki yöntem genellikle birinci yönteme ve ek olarak ikinci yönteme dayanmaktadır. Önceden ayarlanmış izleme alanının tasarımı ve uygulaması şu şekildedir: harita üzerinde poligon, daire ve diğer farklı şekiller olabilen alanı önceden ayarlayın. Sistem, ayarlanan şekil türüne ve enlem ve boylam noktalarına göre arka planda alan nesneleri oluşturur. Gerçek zamanlı olarak yüklenen enlem ve boylam, aracın bölgede olup olmadığını belirler. Örneğin, poligon izleme alanında, sistem, haritada kullanıcı tarafından seçilen poligonun noktalarına göre Poligon poligon nesneler oluşturur ve her aracın enlem ve boylam bilgilerine göre aracın bölgede olup olmadığına karar verir. Araçlar belirli bir mesafeden daha fazla bir alanda bulunduklarında, sistem bu araçların toplandığından şüphelenildiğine karar verir. Bir izleme alanındaki araç sayısı, yönetim personeli tarafından belirlenen eşiği aştığında, sistem alarm vermeye başlayacak ve ilgili personeli, cep telefonu metin mesajları ve izleme harita açılır pencereleri yoluyla dikkat etmesi için bilgilendirecektir. Sistem ayrıca kilit izleme alanındaki araçlar hakkında Şirket, sürücünün adı vb. Gibi ayrıntılı bilgiler de sağlar. Gerçek bir toplanma olayının gerçekleştiği belirlenirse, ilgili departmanlar araçların bölgede toplanmaya devam etmek ve aynı zamanda sistem tarafından sağlanan araç firmasına göre işletmeye denetim emri vermesi vb., işletmeden sorumlu kişinin birbirini yerinde geri çağırmasını sağlamak İş sürücüleri ve araçlar. Kısacası amaç, durumu genişlemeden önce halletmek için zamanı değerlendirmek ve durumun genişlemesinden kaçınmaya çalışmaktır.
Bir bölgedeki araç sayısını rastgele izleme fikri, şehrin herhangi bir kilometresindeki araç sayısının belirli bir eşiği aşıp aşmadığını belirlemektir. Yargılanacak alan keyfi bir kombinasyon olduğu için, sistemin uygulama sürecinde küçük alanları geniş alanlara birleştirerek istatistiksel yargılarda bulunması gerekmektedir. Örneğin 1 kilometrelik alan 100 metrelik 9 küçük alana bölünmüştür. 1 kilometrelik alandaki araçların eşiği 30 ise, her 100 metrelik alandaki araç sayısı 4'ü aşarsa, 100 metre alandaki toplam araç sayısı 30 araç eşiğini bulabilir. Böylece sistemin izleme aralığı 100 metrelik küçük bir alanda izlemeye dönüştürülür. Rastgele izleme alanının tasarımı ve uygulaması şu şekildedir: sistem, şehrin konumuna ve coğrafi enlem ve boylam aralığına göre tüm şehri her 100 metrede bir alanlara ayırır. Alt bölümlere ayrılmış alan, araç sayısı için eşiği belirler. Sistem, küçük bir alandaki araçların sayısına göre karar verir ve eşiğe ulaşıldığında, çevredeki toplam araç sayısının izlenen araç sayısı için alarm eşiğine ulaşıp ulaşmadığını değerlendirir. Taksi sürücülerinin GPS terminallerini daha iyi anlamasıyla birlikte, izleme platformunun anormal GPS veri yüklemesi konusunda erken uyarı vermesi gerekiyor. Örneğin, araç iletişim anormalliklerinin sayısı bir süre içinde keskin bir şekilde artmıştır ve izleme haritasındaki araç sayısı, konumlandırma için keskin bir şekilde artmıştır, vb., Aynı zamanda yönetim departmanının dikkatli olması gereken veri göstergeleridir.
Olay içi izleme
Olayların durdurulması ve toplanması sürecinde, sistem üzerinden izleme alanı belirlenebilir, bölgedeki araç sayısı ve aracın sürücüsü ve şoförü gibi temel bilgiler gerçek zamanlı olarak sayılabilir. . İşletmeler aracılığıyla sürücüleri geri çağırın.
Daha sonra özet
Toplama askıya alma işlemi genellikle birkaç gün veya hatta bir haftadan fazla sürer. Daha sonra, toplanmaya dahil olan sürücüler ve birimler hakkında istatistiksel analiz yapmak gerekir. Sistem, sürücünün parka katılımının derinliğini belirlemek için aracın geçmiş yörünge bilgilerine dayalı olarak toplam park süresi boyunca park alanında biriken kalış süresini hesaplayabilir. Toplam durma süresi boyunca aracın on-line oranının istatistiklerini toplayarak aracın araç üstü terminalin iletişimini kesintiye uğratıp kesmediğini yargılayabilir. Askıya alma olayını düzenleyenleri bulmaları ve bir araya getirmeleri için hükümet ve işletmeler için veri desteği sağlayın.
Kentsel istikrar bakımının odağı olan taksi durağı ve toplanma pek çok şehrin ilgisini çekmiştir. GPS tabanlı taksi gönderme ve izleme platformundaki izleme işlevi, esas olarak, durma sürüşü toplama olaylarının önlem ve ön uyarı işlevlerini sağlar. Durma-sürüş toplama olaylarının meydana gelmesine dayanan çatışmanın ana nedeni, GPS gönderme işlevi aracılığıyla sürücünün boş sürüş oranını da azaltabilir, sürücünün boş sürüş yakıt tüketimini azaltabilir ve sürücünün yardım sağlamak için yaptığı harcamayı azaltabilir.
Yol tıkanıklığını ve yakıt tüketimini azaltın
Yurtiçi ekonominin hızlı gelişimi ile, çeşitli şehirlerdeki trafik sıkışıklığı giderek daha ciddi hale geldi. Pekin, Şanghay ve Guangzhou gibi yerel birinci kademe şehirlerdeki trafik sıkışıklığının neden olduğu çelişkiler giderek daha belirgin hale geldi. Daha da ciddi olanı, kentsel trafik sıkışıklığının birinci kademe şehirlerden ikinci ve üçüncü kademe şehirlere yayılmasıdır. Pek çok büyük şehir, Pekin'in tek ve çift sayısı, Şangay'ın plaka müzayedesi ve benzeri gibi kentsel yol tıkanıklığını hafifletme amacına ulaşmak için araç seyahatini azaltmak için bazı kısıtlayıcı önlemleri keşfetmeye başlamış olsa da. Hatta bazı şehirler, kentsel trafik sıkışıklığı ücretlerini tahsil etmeyi planlamaya bile başladı. Ancak, kentsel trafik sıkışıklığı olgusu henüz iyileştirilmemiştir. Aksine, ülke ekonomisinin gelişmesi ve insanların yaşam standartlarının iyileştirilmesiyle birlikte, insanların otomobil satın alma talebi güçlenmiş, şehir içi yol tıkanıklığı çelişkisi daha da öne çıkmıştır. Yol tıkanıklığını azaltmaya yardımcı olmanın yolu, araç planlaması yoluyla yol kenarı taksi çağırma yöntemini kademeli olarak değiştirmeyi düşünmektir. İstatistiklere göre, Şangay'ı örnek alırsak, taksilerin boş kilometresi toplam kilometrenin% 40'ından fazlasını oluşturuyor. Yani
taksilerdeki petrolün neredeyse yarısının bir günde boşa harcandığı ve arabaların yarısına yakınının yolda gittiği söyleniyor. Bu sadece gaz parasını boşa harcamakla kalmaz, sürücülerin emek yoğunluğunu da artırır, aynı zamanda değerli kentsel yol kaynaklarını da alır. Mevcut yurt içi taksi çağırma sistemi, halka açık bir aramadan bir telefon çağırma gönderme yöntemine değiştirilirse, taksi yolcu yokken dinlenir, yani gaz tasarrufu sağlar ve işgücü yoğunluğunu azaltır ve şehrin yol kaynakları. Bir kavramın değişimi aşamalı bir süreçtir. Taksi yol kenarı işe alımı, taksi sektörünün başlangıcından itibaren oluşturulmuş bir model olup, yurtiçi ve yurtdışına yaygın bir iş modeli olmuştur. İşe alımdan telefonla göndermeye kademeli geçiş, yalnızca sürücülerin çalışma alışkanlıklarını değil, daha da önemlisi yolcuların düşünme alışkanlıklarını değiştirmeyi gerektirir. Şu anda, yerel ve bazı şehirler Wuxi, Nanchang, Wenzhou ve benzeri gibi kentsel tabanlı taksi dağıtım platformları kurmaya başladı. Ve bir ödemeler dengesi elde etmek ve devlet finansmanını en aza indirmek için taksilere LED reklam ekranları kurarak. Dahası, Wuxi ve Nanchang gibi şehirlerdeki kentsel düzeyde taksi gönderme platformları, temelde personelden sistem bakımına kadar kendi kendine yeterliliği sağlayabilir. Bu açıdan bakıldığında, şehir düzeyinde taksi sevk platformu sermaye yatırımı açısından tamamen ulaşılabilir. Örnek olarak Wuxi'yi ele alalım. Wuxi'de yaklaşık 4.000 taksi var. Sevk platformu iki yıl önce inşa edildi. Günde düzinelerce yolcunun taksi çağırmak için ilk çağrısından 2010'un sonuna kadar günde ortalama 6.000'den fazla başarılı sevkiyat gerçekleşti. 8000'den fazla. Sadece Wuxi vatandaşlarının seyahatini büyük ölçüde kolaylaştırmakla kalmıyor, daha da önemlisi, telefon görüşmesine izin veriyor
Arabanın yeni araba selamlama modeli kök salmaya başlıyor. Telefon görüşmelerinin sayısındaki ve başarılı gönderimlerin sayısındaki artış gönderilebilir
Bir otomobilin mevcut arama modu halk tarafından kabul edilebilir ve sürücüler işbirliği yapmaya isteklidir.
Taksilerin kapasitesinin veri analizi yoluyla makul bir şekilde nasıl dağıtılacağı, taksilerin işe alımdan ESC'ye dönüştürülmesini aşamalı olarak gerçekleştirmenin tek yoludur. Taksiler ağırlıklı olarak ESC'lere dayanıyorsa, bu da yolda boş sürüşü azaltmak anlamına gelirse, aynı zamanda bir çelişki de ortaya çıkaracak, yani sürücünün yolcuları görme imkânı azalacak ve sürücünün geliri azalacaktır. Taksi, aracın kullanıldığı bölgede nasıl tutulur, yani boş kilometreyi azaltmak için sevk merkezinden sipariş aldıktan sonra en kısa sürede yolcu biniş pozisyonuna gelebilir ve aracı sürücünün kullanması gerektiğini düşünür. yolculara Yeni iş gönderdikten sonra beklemek için o alana. Kısacası, sürücünün transferinden ESC moduna bu geçişi başarmak için, önce sürücünün iki sorunu çözülmelidir: 1) Belirli bir miktarda taksi ESC işi nasıl sağlanır; 2) Aracın normal park alanı nasıl makul bir şekilde bölünür. Bu iki sorun çözülmezse, iş modeli dönüşümü hedefine ulaşmak imkansızdır. Şangay, Volkswagen, Jinjiang ve Otobüs'deki üç taksi şirketinin istatistiksel veri analizine dayanarak, araç başına 2'den fazla işlem içeren bir günlük sevkiyat işi yapabilen otobüsler dışında, ortalama başarılı sevkiyat sayısının Volkswagen ve Jinjiang için operasyonlar sadece Yaklaşık 1 kalemdir. Volkswagen için bir günde yapılan başarılı gönderim sayısı yaklaşık 12.000, Jinjiang yaklaşık 4.000 ve otobüsler 8.000'e ulaşabilir. Üç şirkete karşılık gelen araç sayısına bölündüğünde, mevcut ESC hizmet sayısının sürücülerin günlük iş göstergelerini karşılayamadığı görülebilir. Sürücülerin yine de ana çalışma modu olarak işe almayı seçeceklerinin temel nedeni budur. Dahası, bu üç taksi şirketinin ESC işi beş yıldan fazla bir süredir faaliyettedir. Bu ESC işinin hızına bağlı olarak, temelde öngörülebilir bir durumdur ki, eğer herhangi bir idari müdahale yoksa, işe alımdan ESC'ye otomatik olarak geçiş mümkün olmayacaktır. İş modeli ortaya çıktı. Peki, GPS tabanlı bir taksi gönderme platformu bu iş modelinin dönüşümünü desteklemek için ne yapabilir?
Platformun veri analizi avantajları sayesinde, platformun sürücülerin kalbini derinleştirme hedefine ulaşmak için sürücülere makul araç kullanım alanları ve sürücülere yardımcı olacak diğer yollar sağlayabiliriz. Yani, sistem sadece yönetim perspektifinden sevk ve izleme rolünü oynamakla kalmaz, aynı zamanda sürücünün bakış açısından analiz ve rehberlik rolünü de oynamalıdır; sürücünün geliri ve sürücünün güvenliğini sağlamak. Yolcunun biniş noktası ve biniş süresinin veri analizi ile sürücü, bu zaman dilimlerinde binek araç hacminin nispeten yüksek olduğu alanları belirtir ve her alanda kullanılan geçmiş araç sayısı ve zaman dilimi günlük bir tarihi oluşturur. veri karşılaştırması. Fiili operasyon sürecinde bu bölgedeki taksi araç sayısı bu sürelerde belli bir yüzdeyi aşarsa sistem alarm vererek tüm araçlara mesaj göndererek araçların doyduğunu bölgeye hatırlatabilir ve araçlar gitmeyi düşünebilirler. boş sürüşü önlemek için diğer alanlara. Alanın ve zaman periyodunun geçmiş verilerine ve gün içindeki araçların sayısına dayanarak, hangi alanların hala araç sıkıntısı durumunda olduğuna karar verilir ve sürücüye mesajlar gönderilerek yönlendirilir. yakındaki araçlar. Sürücünün bakış açısından analiz ve rehberlik sayesinde, sevkıyat platformunun güveni ve prestiji, sürücüler arasında kademeli olarak kurulur, böylece sürücü, sevkıyat platformuna güvenmek için şüpheden güvene döner. Yerleşik terminal, aracı ve sistemi yakından ilişkilendirdi. Yönetim, sürücünün fikirlerini anlamak için sürücüden daha fazla iletişim kurduğu ve yönetim açısından makul çözümler ve yönetim yöntemleri önerdiği sürece, sürücünün pratik faydalar elde etmek için platformda olduğuna inanıyorum. Aynı zamanda, işletmelerin ve hükümetlerin yatırımı da somut bir şekilde ödüllendirilebilir. Günde araba başına 2'den az işlem içeren mevcut ESC işi, erken aşamada bina sistemlerine yoğun bir şekilde yatırım yapan şirketler için yüksek değildir. Taksi gönderimi yoluyla şehir içi yol tıkanıklığını ve yakıt tüketimini azaltmak, yapılacak uzun bir yoldur. Zorluk, alışılmış çalışma yöntemlerinin ve hala yönetim ve pratik uygulama yeteneğine sahip olmayan yeni çalışma yöntemlerinin dönüştürülmesinde yatmaktadır. Savunuculuğa dayalı eski çalışma biçiminin yerini alabileceğini kanıtlayın. Bununla birlikte, sistem sürücünün boş sürüşünü azaltmada ve yakıt tüketimini azaltmada yine de belirli bir rol oynayabilir. Şangay, Wuxi, Nanchang ve Wenzhou gibi yerel şehirlerdeki ESC verilerinin analizinden Yang Zhao'nun konumu şu anda ESC ile değiştirilemese de, ESC yöntemi yolcular ve sürücüler tarafından yavaş yavaş kabul edilmeye başlanıyor. Yolcuları çekmenin ana yolu Yang Zhao'yu daha da genişletmek ve değiştirmek için hala uzun bir yol var.
GPS-based taxi dispatching and monitoring system  technology is not a new set of technologies. As an application in the taxi industry, it has slowly begun to enter the use stage on a large scale. The realization of a taxi dispatch and monitoring platform has gradually become a must on the road of enterprise and government management and information construction.
Today, the number of vehicles connected to the platform is increasing, and the function of calculating the degree of road congestion can be gradually achieved through the platform. The investment in calculating whether the city road traffic is congested is very expensive. Taking the speed measuring coil laid on the high-speed driving road as an example, not only the investment is huge, but the maintenance workload is also huge. Through the real-time running speed of the taxis connected to the platform and the road where the latitude and longitude are located, as long as the connected vehicles reach a certain proportion, it can be used to achieve the basis of real-time road conditions of urban roads. This technology that relies on the basic data of the taxi dispatching and monitoring platform to access vehicles to determine the real-time road conditions of urban roads is currently in the research and preliminary use stage. It is believed that the application of this technology will be more perfect and popular in the future. Of course, this kind of road condition analysis also has certain limitations. After all, the distribution of taxis on urban roads does not reach the various roads of the city. Therefore, the data of road congestion analysis cannot be complete, but it is an economical The basic data source method of road analysis, the data source and analysis of GPS-based taxi dispatch and monitoring system are still trustworthy and cannot be ignored.
In the future with the continuous development and improvement of mobile communication technology, GPS-based taxi dispatch and monitoring systems can achieve many things that are currently desired but cannot be achieved through high-speed and high-bandwidth wireless communication networks. For example, real-time monitoring of the actual situation in the car, real-time monitoring of the actual situation in the car, and other tasks that require network bandwidth. At present, the monitoring of the situation in the car basically uses a camera to take pictures, such as taking pictures when passengers get in the car, take pictures when passengers get off, and take pictures when the vehicle is alarmed. And transmitted to the server through the wireless communication network. Due to the limitation of bandwidth, the sharpness of photos taken will be limited. If a 4G network is adopted, the network bandwidth will be able to withstand the upload of video surveillance data, and the system can achieve real-time viewing of every move in the car. With the continuous development of smart phones, it is very common for mobile phones to support GPS positioning. The GPS-based taxi dispatch system can even be developed in the direction of online car booking. Passengers can directly use a mobile phone with GPS positioning function to book a vehicle, the system can directly obtain GPS positioning data on the passenger's mobile phone, and generate passenger car orders, which can more accurately obtain passengers' boarding latitude and longitude.


Gönderme zamanı: Eylül-04-2020