GPS-il põhineva taksode saatmise ja jälgimise süsteemi väljatöötamine ja juurutamine

Ülemaailmse positsioneerimissüsteemi (GPS) populaarsuse ja laialdase kasutamise tõttu on taksotööstuses saanud võimalikuks tugineda GPS-ile, et saada reaalajas sõiduki laius- ja pikkuskraad ning kasutada seda sõiduki reaalajas rakendamiseks. sõiduplaani koostamise ja jälgimise süsteem. Rahvamajanduse kiire arengu ajastul on taksotööstus, oluline osa linnatranspordist, jõudnud ka kiire arengu perioodi. Taksotööstust juhtivate valitsusüksuste ja taksofirmade juhtimise ette on seatud ka erinevad pidevast arenguprotsessist tulenevad juhtimisküsimused. Taksotööstus on otseselt avalikkusele suunatud teenindussektor. Sõidukid on hajutatud linna erinevates piirkondades, millel on ühiskonnale suur mõju ja mis hõlmab laia valikut. Ettevõtete pideva kasvu korral saab taksotranspordi jaotust ratsionaalselt planeerida ja takso läbilaskevõimet tugevdada. Ohutuse korraldamine, juhtide ja taksode ettevõtte järelevalve tugevdamine, sõidukite tühimõõtude vähendamine, kütusekulu vähendamine, ressursside raiskamine ja reisijatele kiirema liikluse tagamine ja kvaliteetsemad teenused jne, et lahendada praktilisi probleeme, mis nõuavad nende toetamiseks rohkem arenenud süsteeme. Teha koostööd, et saavutada tööstuse tervislik ja stabiilne areng ning tagada, et ettevõte ise oleks konkurentsivõimelisem ja kiiremini reageeriks otsuste tegemisel tööstuses. Valitsuse juhtimise seisukohast a GPS-põhine süsteem  on vajalik linnaliikluse ülekoormuse lahendamiseks, sõidukite kütusekulu ja õhusaaste vähendamiseks ning taksode valitsuse järelevalve tugevdamiseks. Kuidas kujundada ja üles ehitada terviklik süsteem, mis suudaks kõige enam rahuldada valitsuse järelevalve terviklikkust ja ühtlust; ettevõtte juhtimise teaduslik ja tulevikku suunatud olemus; süsteemi enda mastaapsus ja töökindlus; samal ajal võib see pakkuda autojuhtidele ja reisijatele praktilist abi ja kasu, mis on probleem, mida tuleb GPS-põhise taksode lähetamise ja jälgimise süsteemi väljatöötamisel arvestada ja lahendada.

1

Roadragoni põhiülesanne  on
1. Kujundada takso saatmise ja jälgimise süsteem, mis põhineb taksode lähetamise nõuete täielikul mõistmisel, ja realiseerida sündmustel põhinev süsteemi ülesehitus, mis toetab mitmikeermelist ja suurt samaaegset andmeedastust. Selle eesmärk on lasta
kõigil
2. Süsteemi juurutamise käigus tehke ettepanek ja lahendage suur hulk taksode ja süsteemi vahelisi andmeühendusi ning tagage andmeedastuse terviklikkus ja usaldusväärsus. Eesmärk on muuta süsteem jõudma kõrgemale ökonoomsemate serveriressursside
abil. Andmeedastuse tõhusus ja usaldusväärsus.
3. Tehke ettepanek ja lahendage probleem, kuidas süsteemi realiseerimise käigus keerulistes teeoludes täpselt otsida laialivalitavaid sõidukeid. Eesmärk on täpsema sõidukiotsingu abil veelgi vähendada sõiduki tühja läbisõitu ja vähendada sõiduki kütusekulu.
Jõudke reisija pardapunkti kiiremini.
4. Tehke ettepanek ja lahendage massiivsete andmete kiire ja tõhusa salvestamise ja otsimise probleem süsteemi juurutamise käigus. Ja koos projekti rakendamise käigus tekkinud tegelike probleemide lahenduste analüüsiga, et süsteemi igapäevaselt selgitada.
Juhtimise tegelik roll. Eesmärk on pakkuda kiiret ja täpset andmetuge sõidukite reaalajas jälgimiseks ja haldamiseks.
Vastavalt ülaltoodud analüüsile võib süsteemi jagada järgmiselt:
1. Põhiinfo hoolduse allsüsteem: Vastutab peamiselt operaatorite põhiteabe, sõidukite põhiteabe, juhtide põhiteabe ja põhikaardi andmete hooldamise eest.
2. Sõiduautode broneerimistellimuste hooldamise allsüsteem: vastutab peamiselt kõnekeskuse andmeside liidese ja reisijate tellimuste hooldamise eest ning saadab auto broneerimise teabe taustadispetšessisüsteemi.
3. Tellimuste automaatse saatmise allsüsteem: vastutab peamiselt sõiduki reaalajas põhiteabe säilitamise ja sõiduki sobitamise kohta vastavalt saadud tellimusteabele. Sõnumi suhtlus sõnumilüüsiga.
4. Sõnumilüüsi alamsüsteem: Põhiliselt vastutab süsteemisisese sõnumivormingu ning terminali ja süsteemi vahel määratletud teate vahelise teisendamise ja edastamise eest.
5. Kaardiseiresüsteem : vastutab peamiselt andmete vastastikuse toimimise eest lähetamise allsüsteemiga ning vastutab sõidukite kaardinäidise ja reaalajas dünaamilise kuvamise eest. Ja saatke sõidukile juhtkäsklused.
Alt ülespoole kulgev andmevoog on: 1. sõiduk saadab reaalajas andmeid sõnumilüüsi allsüsteemile; 2. Sõnumilüüs edastab parsitud andmed saatmise alamsüsteemile; 3. Automaatse saatmise allsüsteem põhineb tellimusel
. Sõidukit kontrollitakse sõiduki laius- ja pikkuskraadi järgi; 4. Automaatse saatmise allsüsteem saadab kaarditeenuste allsüsteemile lisateavet, näiteks sõiduki reaalajas teavet ja sõiduki olekut; 5. Kaarditeenuste allsüsteem salvestab sõiduki ajaloolised andmed ja saadab need kaardiseire kliendi reaalajas kuvamisele.
Ülalt-alla andmevoog jaguneb kaheks põhiosaks:
1. Dispetšeerimise alamsüsteemi algatatud andmevoog: 1. Dispetšeeriv klient võtab vastu autokasutuse taotluse ja saadab selle automaatse dispetšingu alamsüsteemi; 2. Automaatse saatmise allsüsteem leiab tegeliku olukorra põhjal sobiva sõiduki.
Sobivad sõidukid ja saatke nendele sõidukitele sõnumilüüsi allsüsteemi kaudu sõidukitaotlusi; 3. Pärast sõnumilüüsi alamsüsteemi teate vastuvõtmist teisendab see sõnumiprotokolli ja saadab selle konkreetsele sõidukile.
2. Kaardiseire kliendi algatatud andmevoog: 1. Järelevalveklient algatab kaardiserverisse seiretaotluse; 2. Kaardiserver edastab selle dispetšeriserveri kaudu sõnumiväravale; 3. Sõnumilüüs teisendab protokolli ja edastab selle konkreetsele sõidukile.
Alumistest ja madalamatest andmevoogudest lähtuvalt on alamsüsteemide analüüs põhiline selleks, et teavitada üksteist algatatud taotlustest sõnumite kaudu. Võttes arvesse süsteemi vastavat ajakohasust ja andmete kõrget samaaegsust, võtab iga süsteemi allsüsteem projekti kavandamisel peamiselt üldise disaini jaoks kasutusele mudeli "tootmine-tarbimine", millest kõige olulisem on vaatleja mudeli kasutamine lahutada. Selle režiimi idee on lõigata erinevatest lõimerühmadest päringuid andmete asünkroonseks töötlemiseks. "Tootja" on niit, mis genereerib töötlemist vajavad päringud, ja "tarbija" on lõim, mis võtab need taotlused vastu ja vastab neile. Eeliseks on see, et see tagab selge eraldatuse, nii et niite saab paremini kujundada ja need võivad olla rohkem kooskõlas lahtise haakeseadise disainifilosoofiaga. Samuti aitab see arendajatel leida ja lahendada probleeme, mis ilmnevad tegeliku kasutamise ajal. Süsteemi modulaarne projekteerimine ja rakendamine soodustab ka süsteemi hooldamist ja laiendamist. Samal ajal aitavad moodulikujundus ja -rakendus ka iga mooduli sõltumatut üksuste testimist meeskonna paralleelse arengu parandamiseks ning sellel on ka piisav garantii süsteemi järgnevatele ümberseadistamise riskidele. Iga alamsüsteemi ülesehituse põhifunktsioonid on järgmised:
1. Sõnumilüüsi allsüsteem: vastutab peamiselt sõnumite vastuvõtu ja edastamise ning sõnumiprotokollide teisendamise eest. Sõnumite vastuvõtmisel ja edastamisel tuleb arvestada ühenduse hooldusega suurtes samaaegsetes olukordades ja seda, kuidas rakenduskiht saab tagada võrgu ülekoormuse korral saadetavate andmete terviklikkuse. Terminali ja süsteemi lahtiühendamine tagatakse protokolli teisendamise kaudu. Isegi kui terminali pakkuja dispetšer- ja jälgimissüsteem asendatakse, saab terviklikkuse tagada ja modifitseerida tuleb ainult lüüsi alamsüsteemi protokolli teisendamise moodulit.
2. Automaatne saatmise allsüsteem: vastutab sõidukite asukoha ja oleku teabe, sõiduautode põhiteabe ja linna teede põhiteabe põhjal, otsustades automaatselt, millised sõidukid sobivad reisijatele. Põhimoodulid hõlmavad sõnumite vastuvõtmise ja saatmise moodulit, sõnumi ja ülesande (ülesande) teisendusmoodulit, lõimupooli moodulit. Alamsüsteemi lahtisidumise peamine osa on sõnumite ja ülesannete teisendamise moodul. Selle mooduli kaudu teisendatakse erinevad sõnumid üheks või mitmeks iseseisvaks ülesandeks ja ülesanded saadetakse töötlemiseks erinevatele lõimupoolidele.
3. Kaardiserveri alamsüsteem: jälgige reaalajas sõidukeid ja registreerige sõidukite reaalajas andmeid ajalooliseks analüüsiks.
Süsteemi üldise arhitektuuri kujundamine
See süsteem võtab Java arenduskeelena kasutusele. Projekteerimisprotsessis on kogu süsteem jaotatud modulaarse disainiga mitmeks alamsüsteemiks ning Socketit kasutatakse süsteemi ja süsteemi vaheliste andmete interaktsiooniks. Alamsüsteem võtab põhiliselt tootmis- ja tarbimisrežiimi ülesannete ja toimingute vahelise lahususe mõistmiseks ning kasutab süsteemi samaaegse töötlemise võime parandamiseks paindlikumalt mitmekeermelist tehnoloogiat. Iga alamsüsteemi vaheliste ühiste funktsionaalsete moodulite (näiteks võrguühenduse haldus- ja hooldusmoodul, keermeühenduse moodul jne) süsteemide väljatöötamise jaoks on avalikud ja sõltumatud funktsionaalsed moodulid juba protsessi käigus ette nähtud, et vältida tarbetut korduvat arendamist alamsüsteemides. Alamsüsteem seisab silmitsi ainult tegeliku äriloogikaga.
Tootmis- ja tarbimisrežiimi kavandamine ja realiseerimine
Võttes arvesse allsüsteemi ja allsüsteemi sõnumite vastastikust mõju, samuti allsüsteemi ülesandesüsteemi samaaegseid töötlemisnõudeid, on süsteemi põhiprojekt projekteerimisprotsessis kasutusele võtta tootmise ja tarbimise mudel. Selles režiimis ei ammendata selle režiimi kasutuselevõttu. Selles artiklis tutvustatakse peamiselt selles süsteemis tootmise ja tarbimise režiimi kujundusstruktuuri koos taksotranspordi tellimuse äriprotsessi üksikasjaliku analüüsiga ning tootmis- ja tarbimisrežiimi konkreetset rakendamist. Selle süsteemi tootmis- ja tarbimisrežiimi üldine disainistruktuur põhineb niidipoolil ja ülesande objektidel. Keermepaki pakutavad põhifunktsioonid hõlmavad niidi hooldamist ja haldamist ning puhvrijärjekorra hooldust ja haldamist.
Tootmis- ja tarbimismudelis on olulisem niidipooli kujundus. Näiteks OrderThreadPool peab saavutama täitmise vastavalt kohandatud sortimiskorrale. Eeldades, et operaator on liigitatud tüübiks ja töötlemisobjektiks on New Order_Task, käivitatakse OrderThreadPool järjekorras vastavalt iga operaatori ülesannetele, tagades, et lõimepargis täidetakse iga operaatori jaoks ainult üks New Order_Task. Kujunduse põhimõte on säilitada kaks HashMapsi, ühte HashMapi kasutatakse klassifikatsioonistandardi ja vastava Ülesande vahelise halduse haldamiseks, võti on klassifikatsiooni tüüp ja väärtus on LinkedList ülesandeloend. Teine kategooria ülesande säilitamiseks kasutatav HashMap on käivitamisel. Kui on otsustatud, et getTask-i ajal käivitatakse sama tüüpi ülesanne, valitakse võrdlemiseks mõni teine ​​tüüpi ülesanne, kuni saadud ülesanne on sellist tüüpi ülesanne, mis pole pooleli ja tagastatakse täitmiseks lõimikogumisse. Samal ajal keskendub süsteem ka Java poolt alates 1.5 pakutavate suure jõudlusega samaaegsuse tööriistade kasutamisele, näiteks: lugemis-kirjutuslukud, semaforid, lõimide sünkroniseerimine paaritatud vahetuste jaoks jne.
Ehkki sõiduki jälgimise ja saatmise süsteem põhiliselt hõlmab ainult sõidukite saatmise osakonda, sest see realiseerib süsteemi ja sõiduki vahelise otsese ühenduse, võime hankida reaalajas sõiduki põhiandmeid on ettevõtte rafineeritud juhtimisele kindla aluse pannud. Seetõttu on projekteerimisprotsessis vaja ka täielikult arvestada ettevõtte kõrgema juhtkonna juhtimisideedega ning ühendada paindlikud juhtimisideed suhteliselt kindla sõiduplaani süsteemiga. Las sõidukite sõiduplaani- ja seiresüsteem saab tõepoolest ettevõtte teabe ehitamise esirinnas ning teeb ettevõttega koostööd oma strateegilise suuna saavutamiseks.
Sõidukite varasemate andmete säilitamine

2

Sõiduki ajalooliste andmete säilitamine on sõiduki analüüsimise ja jälgimise võti. Sõiduki ajaloolised andmed sisaldavad peamiselt sõiduki ajaloolise trajektoorifaili teavet, sõiduki ajaloolisi käitamisandmeid jne. Sõiduki ajaloolisi trajektoori andmeid kasutatakse peamiselt sõiduki ajaloolise sõidutee leidmiseks, mida kasutatakse reisijate kaebuste lahendamiseks, liiklusõnnetuste analüüsimiseks ja reisijate kaotatud vara leidmiseks. Tegelikus rakendamisprotsessis on vaja tagada sõiduki trajektoori sujuv kaardile joonistamine, tagada, et sõiduki laius- ja pikkuskraadi trajektooripunktide teatamissagedus oleks piisavalt tihe. Kui sõiduk laadib asukoha aruande üles iga 10 sekundi järel, on päevas 8640. Asukohaaruande andmed arvutatakse asukoha aruande andmetena [4-baidine sõiduki identifitseerimisnumber + 8-baidine laius- ja pikkuskraad + 4-baidine aeg + 1-baidine kiirus + 1-bait (suund, positsioneerimine) + 1-baidine sõiduki olek + 4-baidine alarmi tüüp] a kokku 23 baiti, üks päevas Auto andmed rajal on kuni 194K. Kümme tuhat sõidukit päevas võib jõuda 1G andmemahuni. Kuidas neid andmeid säilitada? Kuidas pakkuda kasutajatele mugavat ja kiiret päringut? Kuidas nende andmete põhjal kasulikku teavet analüüsida, et pakkuda uusi ideid juhtimiseks? Neid küsimusi tuleb süsteemi kujundamisel ja juurutamisel arvestada. Sõidukite ajaloolised kasutusandmed on peamiselt iga sõiduki igapäevase tulu analüüsimiseks. Tulude andmete analüüs aitab juhtkonnal analüüsida, kas praegused tasud on mõistlikud, kas võimsuse sisend on küllastunud, ja muid juhtimisandmeid. Käitusandmed sisaldavad põhimõtteliselt selliseid põhiandmeid nagu numbrimärk, sõiduki identifitseerimisnumber, algusaeg, lõpuaeg, läbisõit, töömaht jne. Analüüsige 800 000 arvestust 10 000 sõiduki kohta päevas, tehes 80 tehingut sõiduki kohta päevas. Kuidas tagada põhiandmete terviklikkus, tööandmete salvestamine ja analüüs ning kuidas nendest põhitegevusandmetest juhtimisanalüüsiks kasulikke andmeid välja kaevata, et kasutajad saaksid neid mugavalt ja kiiresti kasutada, on kõik küsimused, mida tuleb süsteemi kujundamise protsess.
 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-põhises takso saatmise ja jälgimise süsteemis leiab süsteemi realiseerimine automaatselt sobivad sõidukid, et pakkuda reisijatele ideid ja disainiskeeme. Süsteemi saatmisfunktsiooni eesmärk on pakkuda reisijatele kõige õigeaegsemaid sõidukeid ja pakkuda taksodele lähimaid reisijaid, et vähendada juhi läbisõitu energiasäästu ja heitkoguste vähendamise eesmärgi saavutamiseks. See säästab autojuhtidele raha ja pakub reisijatele mugavust.

Esimesed kaks eesmärki, mida tuleb autode leidmise projekteerimisel arvesse võtta: kiire ja täpne. Kõigepealt mõistame autojõudluse rahuldamiseks helistava reisija põhilisi omadusi. 1) telefoninumber, mille reisija valis; 2) aeg, millal reisija autot kasutas; 3) koht, kus reisija kavatses autosse istuda. Nende kolme põhiatribuudi telefoninumbri saab otse kõnesüsteemi kaudu ja kui auto broneeritakse kellegi nimel, saate selle paluda reisijal telefoninumbrile tagasi helistada. Ka reisijad võtavad initsiatiivi, et teavitada dispetšerit auto ajast. Võti on pardale mineku asukoha kolmas punkt. Reisijad ütlevad tavaliselt ainult sellise füüsilise aadressi nagu: milline tee on kindla tee lähedal ja muud tekstikirjeldused. Lähetussüsteemi jaoks peab süsteem sõidukite leidmiseks teisendama tekstilise teeolukorra teabe spetsiifiliseks pikkus- ja laiuskraadide teabeks ning kasutama pikkus- ja laiuskraadide teavet, et teha kindlaks, kas ümber saatmiseks on sobivaid sõidukeid. Seetõttu on sõiduki täpseks otsimiseks kõige elementaarsem töö see, kuidas saada teavet reisijate pardale mineku asukoha pikkus- ja laiuskraadide kohta.

Säilitage vastuvõtupunkti laius- ja pikkuskraadide teave

Vastuvõtupunkti pikkus- ja laiuskraadide teabe säilitamine on linna teekonna teabe säilitamine. Peamiselt sisaldavad: tee ristumiskoha laius- ja pikkuskraadi andmed, maamärgi hoone laius- ja pikkuskraadi andmed, maja numbriosa laius- ja pikkuskraadi andmed jne. Vastavalt erinevate linnade teeomadustele saab laiuse ja pikkuse allika edastamiseks kasutada erinevaid andmeid vastuvõtupunkti andmed. Näiteks võivad standardiseeritud ja küpsete majanumbritega linnad, nagu Shanghai, eelistada maja numbrisegmendi laius- ja pikkuskraadi kui sõiduki pardapunkti pikkus- ja laiuskraadiandmete allikat. Mõnes väikeses linnas saab maamärgiga hoonete laius- ja pikkuskraade kasutada reisijate pardapunkti pikkus- ja laiuskraadide allikana. Üldine linn sobib paremini ristmiku laius- ja pikkuskraadide jaoks kui reisijate pardale mineku punkti pikkus- ja laiuskraadi allikaks.

Kõigil neil meetoditel on eeliseid ja puudusi vastavalt arvulõigule, vaatamisväärsustele ja tee ristmikele. Tavaliselt kasutatakse seda tegeliku kasutamise ajal kombineeritult. Majade segmendi rakendusala on suhteliselt väike ning linna majanumbrite jaotus peab olema standardiseeritud ja pidev. Kuid majanumbrite segmendi abil saab kiiresti ja täpselt leida reisijate pardale mineku koha pikkus- ja laiuskraadi. Põhimõte on järgmine: jagage tee maja numbri järgi mitmeks väikeseks teeks ning kasutage väikseid teid pikkus- ja laiuskraadidena. Mis puudutab seda, kui palju uksenumbreid jagatakse ühele lõigule, siis teeinfot koguvad töötajad otsustavad ise tee tegelike tingimuste järgi. Ukse numbri segmendi pikkus- ja laiuskraadide kogumine võib olla viis, kuidas kollektor sõidab kindla tee ukse numbri segmenti ning laadib GPS-seadme kaudu üles pikkus- ja laiuskraadi, et saada kõige täpsemaid tee pikkus- ja laiuskraadide andmeid. Süsteemi tegelikus kasutuses võib süsteem, kui reisija helistab autotelefonile ning teavitab pardale mineku kohast tee ja maja numbrit, süsteem vastavalt tee ja majanumbrile üles leida majaosa, kuhu majanumber kuulub, ning hankida majaosas vastav number. Pikkus- ja laiuskraadide teave, näiteks kui reisija helistab ja ütleb, et auto aadress on Zhongshan Road nr 10, leiab süsteem, et Zhongshan Road nr 10 jääb vahemikku 2 kuni 50 Zhongshan Road , nii et süsteem naaseb nr 2 Zhongshani teele nr 50. Teelõigule vastavat pikkus- ja laiuskraaditeavet kasutatakse reisijate pardapunkti pikkus- ja laiuskraadina. See pardalemineku asukoha laius- ja pikkuskraadi saamiseks on suhteliselt täpne meetod ja viga ei ületa 500 meetrit. Puuduseks on see, et majanumbriandmete hankimise suhteliselt suur töökoormus nõuab varajases etapis rasket ja üksikasjalikku põhiandmete kogumist. Pealegi on linnamajade arvu standardiseerimine suhteliselt kõrge. Peamine viis linnatee laius- ja pikkuskraadi saamiseks on ristuva tee laius- ja pikkuskraadide teabe saamine linna kaardiandmete analüüsi kaudu. Reisija helistamisel öeldakse, et pardaleminekupunkti ligikaudse laius- ja pikkuskraadi saamiseks on kindel tee kindla tee lähedal. See laius- ja pikkuskraadi saamise meetod on mugavam, kuid puuduseks on see, et positsioneerimise täpsust ei saa tagada. Kui reisija on mõne kilomeetri kaugusel teest pikal teel ilma ristmikuta, ei suuda süsteem ristmiku pikkus- ja laiuskraadide põhjal reisija täpset pardalemineku pikkust ja pikkust täpselt saada.

Auto leidmise ajastamine

3

Reisijate pardapunkti pikkus- ja laiuskraadide andmete säilitamine annab süsteemile kindla andmekogumi, et sõidukid saaksid automaatselt sõidukeid leida. Autode leidmise teostamist tuleb veel kaaluda koos kohaliku linna teeomadustega ja lähetuses osalevate taksode arvuga.
Auto leidmine vastavalt laius- ja pikkuskraadi lineaarsele kaugusele
Seda auto leidmise meetodit on suhteliselt mugav ja otstarbekas rakendada ning seda kasutatakse kõige sagedamini praktilistes rakendustes. Teostuspõhimõte: joonistage ring, mille raadiusena on autootsingu kauguse keskpunktiks sõitjate pardale mineku punkti pikkus- ja laiuskraad, kui ringi sees olev sõiduk on sõiduk, mida dispetšer otsib, kui seda pole. sõidukit korraga, võrreldakse raadiust sõidukiga vastavalt teatud vahemikule. Kuni sõiduk leitakse või raadius saavutab süsteemi määratud maksimaalse väärtuse. Seda meetodit on suhteliselt lihtne rakendada, kuid efektiivsus pole eriti kõrge, sest on vaja arvutada kõigi sõidukite ja ringi keskpunkti vaheline kaugus. See pole teaduslik ja tõhus. Kujutage ette, et 10 000 sõidukiga platvormil sõitja nõuab autot. Reisijate pardapunkti ümber ei ole tegelikult rohkem kui 20 sõidukit ja reisijatele antakse ainult üks sõiduk. Siiski peame arvutama kõigi 10 000 platvormil oleva sõiduki vahemaa. Põhimõtteliselt on 9 980 arvutused kasutud arvutused. Tegelikus kasutuses on tänu praeguse serveri jõudluse pidevale paranemisele selle meetodi kasutamine enam kui 10 000 sõidukiga taksode lähetamise platvormil siiski kiire ja täpne rakendusmeetod. Eriti mõistliku teeplaaniga linnas nagu Shanghai ei ole vaja arvestada nähtusega, et sõiduk peab enne reisijate pardalemineku asukohta sõitma pikki vahemaid, et reisijate pealevõtmiseks ümber pöörata. Võttes arvesse tohutuid kasutuid arvutusi, mis on saadud auto leidmisel vastavalt pikkus- ja laiuskraadi sirgjoonelisele kaugusele, on süsteemi ülesehitusel veelgi optimeerimissuund.
Võrgusõiduautode otsing
Võrguotsingu eesmärk on vältida tohutult kasutuid arvutusi sirgjooneliselt auto leidmisel ja optimeerida otsinguprotsessi toimivust. Põhimõte on: esiteks on linn jagatud laius- ja pikkuskraadide järgi võrkudeks; teiseks registreeritakse sõiduki asukoht võrgus vastavalt sõiduki reaalajas laiusele ja pikkusele. Reisijate pardapunkti asukoha järgi saadakse ümbritsevas võrgus olevad sõidukid ning võrreldakse nendes võrkudes olevate sõidukite ning sõitjate pardale mineku laius- ja pikkuskraadi vahelist kaugust, et saada reisijatele kõige sobivam sõiduk.
GPS-kaardi andmed auto täpseks leidmiseks

5

Sõltumata sellest, kas tegemist on kõige primitiivsema sirgjoonelise autootsingu või edasise võrguotsinguga, on kõige põhilisem põhimõte ikkagi otsustada, kas auto sobib alternatiivse lähetussõidukina, lähtudes sõitja pikkus- ja laiuskraadide võrdlusest pardaleminek ja sõiduki sirgjoon. Kuidas kombineerida teeandmeid autode täpse leidmise saavutamiseks, pole praeguses lähetussüsteemis tavaline. Põhjus on see, et kodumaiste linnade teedevõrgu ehitussõidukitel on üldiselt mugavam ümber pöörata. Suured linnad, kus on kõrgendatud maanteed, näevad ette ka seda, et tühje sõidukeid ei tohi tõsta. Seetõttu on Hiinas klientide põhivajaduste rahuldamiseks auto leidmine reisijate pardale mineku punkti ja sõiduki pikkus- ja laiuskraadi vahelise sirgjoonelise vahemaa kaudu.
Kuid mõned erilised linnad, näiteks Jakarta Indoneesias. Selle linna teedel olevad sõidukid peavad ümber pööramiseks sõitma sageli mitu kilomeetrit või rohkem. Kuna Indoneesia asub maavärinat tekitavas piirkonnas, pole linnal metroot, mistõttu kiirete busside sõitmiseks avatakse keset teed kaks spetsiaalset teed. Tõsi on see, et eraldatud sõidukid ei saa üldse ümber pöörata. Kui sellises ebamugavas linnas võrreldakse auto leidmiseks sõitjate pardale mineku punkti pikkust ja laiust sõiduki pikkus- ja laiuskraadiga, siis on inimene ja sõiduk erinevates külgedes või on reisija positsioon just olnud sõidetud, nii et sõidukil võib tekkida vajadus suurel alal ringi sõita. Ring võib tulla tagasi reisijaid peale võtma. See on vastuolus GPS-i lähetussüsteemi algse kavatsusega säästa autojuhtide kütusekulu. Selle vastuolu lahendamiseks peab süsteem sobiva sõiduki leidmiseks kaaluma sõiduki ja sõitjate pardale mineku vahemaa ja teeinfo kasutamist.
Kujundusidee: kaardil joonistatud teed on üldjuhul kujutatud "segmentidena". Tee on jagatud pidevateks "segmentideks". Ja vastavalt iga sektsiooni laiusele, moodustades "riba". Nii saab kaardil kuvada täieliku teemustri. Vastavalt sellele, kas iga ristmik võib pöörata, kas tee on ühesuunaline jne, ühendatakse teeinfo kõigepealt suunatud graafiks. Seejärel arvutatakse auto otsimise kauguse järgi see, kus asub reisijate pardapunkti kõige kaugemal asuv teepunkt, saades seeläbi tee laius- ja pikkuskraadi andmed. Vastavalt tee laiuskraadilt saadud maantee laius- ja pikkuskraadi andmetele, millele lisandub iga teelõigu laius, et saada tee "vöö" laius- ja pikkuskraadivahemik. Seejärel otsustage sõiduki tegeliku pikkus- ja pikkuskraadi põhjal, kas sõiduk on teel "vöö". Kui sõiduki laius- ja pikkuskraad jäävad tee "vöö" vahemikku, tähendab see, et sõiduk liigub kvalifitseeritud teel. Ehkki graafiku läbimise ja läbimise maksimaalse vahemaa kombinatsioon võib realiseerida sõidukite otsimise, kuidas ikkagi määrata tee alguspunkt teekaardile ehk kuidas panna sõitjad pardaleminekuteele teele kukkuma? tee asukoht, kus paljud reisijad sõidukisse ei asu. See peab asuma süsteemi hooldatud teel ning on ka võimalik, et laius- ja pikkuskraadid asuvad lihtsalt kogukonnas. Ilma väga üksikasjalike linna- ja pikkuskraadiandmeteta on seda olukorda keeruline lahendada, sest te ei saa lihtsalt panoraamida teele nii, et reisija laius- ja pikkuskraad oleks sama pikk kui reisija pardale mineku laius- ja pikkuskraad, sest on väga tõenäoline, et reisija on kogukonnas , jättes reisija pardale lähima laius- ja pikkuskraadi järgi. Tee on lihtsalt eraldatud kogukonna seinaga. Lähima tee hindamiseks on vaja väga üksikasjalikke kaardiandmeid ja need peavad olema kogukonna väravani täpsed. Projektisse tehtavate investeeringute vähendamiseks saab süsteem kokku leppida ainult selles, et reisijate pardapunkti pikkus- ja laiuskraad põhinevad tee pikkus- ja laiuskraadil.
Maanteede põhiandmete protsessis tuleb teekonna andmed paigutada tegelikule teele. Kujutage ette stsenaariumi, kus süsteem võtab vastu reisija pardale mineku laius- ja pikkuskraadi ning süsteem peab kiiresti liikuma linnateede andmetest tee "segmenti", kus asuvad reisijate pardale mineku laius- ja pikkuskraadid. Selle tee „lõigu” kohaselt on tee „lõiguga” ühendatud tee „lõigu” saamiseks loomulikult vaja saada ainult auto pikkus- ja laiuskraadi lineaarne kaugus, mis on väiksem kui auto, sest lineaarne kaugus kahe punkti vahel on kõige lühem. Kui sirgjooneline kaugus on ületanud auto leidmise maksimaalse kauguse, ületab tee tegelik kõvera kaugus kindlasti auto leidmise maksimaalse kauguse. Kõigi leitud teeosade järgi, mis vastavad auto leidmise maksimaalsele kaugusele ja on seotud tee suunaga, kus sõitjad sõidukisse istusid, saadakse tee "vöö" vastavalt iga tee "lõigu" määratletud tee laiusele . Seetõttu on rakendusprotsessi peamine töö teemudeli loomine ja see, kuidas kiiresti saada reisijate pardale mineku pikkus- ja laiuskraadiga seotud teed. Teeandmete struktuuri puhul kaaluge kõigepealt tegelike teeandmete jagamist segmentideks. Eeldades, et pikim “lõik” jagatakse 1 km pikkusega, võetakse eeskujuks kogu Shanghai linn. Shanghai maanteede kogupikkus on umbes 11 000 kilomeetrit ja linnateede kogupikkus umbes 4400 kilomeetrit. Isegi kui teelõigu andmemaht jagatakse 1 km-ga, on see maantee "segmenti" arvestades oluline suurusjärgu oluline atribuut.
Kokkuvõte
Sõiduki sõiduplaani koostamise kõige põhilisem ja kriitilisem funktsioon on leida õige sõiduk kiiresti ja täpselt. Selles peatükis tutvustatakse ja analüüsitakse auto leidmise aluspõhimõtteid ning mitme auto leidmise meetodi realiseerimist, eeliseid ja puudusi. Alates kõige tavalisemast kaugusest, et leida auto, kuni võrguni, et auto leida, ja lõpuks ühendage täpse autootsingu kujundus ja teostus linnateede teabega. Ehkki täpse autode leidmise projekteerimisprotsessis koos teeteabega on suurel hulgal vaevatud linna põhiliste teeandmete hooldamine ja haldamine, saab see auto leidmise meetod teeteabe ja klientide nõuetega üha täiuslikumaks. saatmise täpsus muutub üha suuremaks. Lõppude lõpuks, mida täpsem on auto otsimine, seda rohkem võib see vähendada sõiduki tühja läbisõitu ja tarbetut kütusekulu ning juhi entusiasm muutub järjest suuremaks. Autode leidmise ajakava koos täpse auto leidmisega koos maantee geograafilise teabega kasutatakse tulevikus üha laiemalt.
Andmete analüüs ja rakendus
Takso parkimise probleem

6

Transpordibüroode jaoks on erinevates kohtades kõige tülikam see, et nende jurisdiktsiooni alla kuuluvad taksod saadavad streike ja lõpetavad juhtumite juhtimise. See mitte ainult ei mõjuta kodanike reisimist, vaid suurem põhjus on see, et halb mõjuvõim mõjutab suuresti ühiskonna stabiilsust ja ühtsust. Võib öelda, et taksode peatamine on transpordibüroo peamine prioriteet stabiilsuse säilitamiseks. Viimastel aastatel on erinevatel põhjustel aeg-ajalt toimunud taksolööke ja peatamisi. Taksopeatuste lahendamise viis on põhimõtteliselt valitsuse administratiivne sekkumismeetod ja GPS-jälgimisplatvorm on õnnetuse korral põhimõtteliselt abirollis. Analüüsige vastavalt taksopeatuse probleemi lahendamise protsessile. Valitsus saab üldjuhul kasutada ainult taksofirmade mahasurumise meetodit ja mõned ettevõtted astuvad üles juhtide ideoloogilist tööd tegema. Peamine põhjus, miks juhid autojuhtimise lõpetavad, pole midagi muud kui madal sissetulek ja liigne tööintensiivsus. GPS-süsteem mängib vaid osa jälgimisest ja valitsus peab ikkagi saatma arvukalt töötajaid külla. Kas GPS-põhine takso saatmise ja jälgimise platvorm võib siiski mängida ainult osa jälgimisrollist? Pärast analüüsi ja mõtlemist praktiline ja teoreetiline analüüs. GPS-põhine taksode saatmise ja jälgimise süsteem on täielikult võimeline ennetamiseks, eel meeldetuletamiseks, sündmuse ajal jälgimiseks ja sündmuse järgseks kokkuvõtteks.
Eelnevalt ennetage
Kodumaise taksotööstuse üldine struktuur valitsusest juhini on põhimõtteliselt sama. Põhimõtteliselt on valitsusel haldusvolitused oma jurisdiktsiooni alla kuuluvate taksofirmade tegevuse juhtimiseks; taksofirmadel on õigus taksosid käitada ja taksode igapäevane töö juhile üle anda, nõudes juhilt iga kuu teatud haldustasu; juht vastutab juhtimise eest. Kütusekulud, remondikulud ja trahvid reeglite ja eeskirjade rikkumise eest kannab põhiliselt juht. Taksofirmale makstav haldustasu moodustab põhimõtteliselt umbes 2/3 juhi igakuisest tulust. Läbi suhtluse valitsuse töötajatega ja taksojuhi mõistmise mitme juhtumi peatamise menetlemisel leiti, et takso peatamisel on umbes kaks põhjust:

Juhi sissetulek on liiga madal;
2. Seal on juhte, keda õhutatakse ja organisatsioon. Kombineerides seiskamise põhjuse ja GPS-põhise takso saatmise ja jälgimise süsteemi tegeliku olukorra, võib süsteem asjaomastele osakondadele eelnevalt meeldetuletuse anda. Analüüsime tegelikku olukorda: taksod sõidavad linna tänavatel ja alleedel. Just selle liikuvuse tõttu on juhtimine keerukas. Taksos on kõige olulisem seade arvesti, mis salvestab juhi iga ettevõtte üksikasjaliku teabe. Sealhulgas summa, algus- ja lõppaeg, läbisõit jne. Taksole paigaldatud GPS-terminal loob reaalajas ühenduse takso ja autos oleva taksomeetri ning süsteemi kaudu juhtmevaba ühenduse kaudu terminalis. Juhid saavad neid taksosid kontrollida ja hallata. Terminalis oleva sidemoodulisüsteemi kaudu saate aru iga sõiduki arvestusandmest ja päevasest sissetulekust. Nende kahe indeksisüsteemi kaudu saab analüüsida iga juhi igakuist põhisissetulekut. Igakuise sissetuleku järgi saab otsustada, milliseid autojuhte tõenäoliselt õhutatakse, ning haldusosakond võib varjatud ohtude ja lootustandvuse kõrvaldamiseks rakendada mitmesuguseid meetmeid. Näiteks saavad ettevõtted küsitleda madala sissetulekuga autojuhte viisil, et nad hooliksid oma töötajatest, saaksid õigeaegselt teada autojuhtide raskustest ja annaksid teatud raskustest toetusi või suurendaksid juhtide tegelikke sissetulekuid, andes head töökogemust. Ettevaatusabinõude idee on olnud selge: juhi tegelike tulude statistilise analüüsi kaudu, et teha kindlaks, kas juhil on võimalus peatuda. Eelnevalt näost näkku suhtlemisel madala sissetulekuga autojuhtidega ja muude meetodite abil proovige lahendada juhtide tegelikud raskused, hoolitseda madala sissetulekuga juhtide eest ja näidata ettevõtte hoolivust autojuhtide ees, et saavutada probleemide ennetamise mõju enne nende tekkida. Selles protsessis on süsteemil roll intervjueeritava täpses hindamises eelnevalt, vältides ettevõtte eesmärki ning muutes ettevõtte töö sihipärasemaks ja tulemuslikumaks. Realiseerimismeetodi peamine andmebaas on taksomeetri tuluandmed taksos ja taksomeetri arvest. Seetõttu peab arvesti pakkuma andmeside liidest GPS-i sõiduki terminalile ja andmeid saab pärast iga hooldust sõiduki terminali "sülitada". Pärast andmete saamist kinnitab sõidukile paigaldatud terminal ja saadab arvestile tagasisideteate. Sõidukile paigaldatud terminal laadib arvesti andmed süsteemi traadita sidemooduli kaudu. Pärast andmete kättesaamist salvestab süsteem need andmebaasi ja saadab sõidukile paigaldatud terminalile tagasisideteate, mis kinnitab kviitungit. Teoreetiliselt on andmete terviklikkuse tagamine kinnitatud tagasiside sõnumi saatmisega tagatud. Teiselt poolt peab süsteem üles seadma erinevad andmekünnised vastavalt tegelikule olukorrale erinevates kohtades, et teha kindlaks üleslaaditud andmete ja tegeliku olukorra vahelise kõrvalekalde määr, et teha kindlaks, kas andmed on "usaldusväärsed". Näiteks päevase keskmise "mõõtmise" arvu, ühe erinevuse maksimaalse toimimissumma määramine jne. Süsteem genereerib võrdlustulemused vastavalt erinevatele määratud andmekünnistele, et juhid saaksid neid hinnata.
Võttes arvesse taksode tuluandmete tohutut hulka, on 800 tuluandmeid sõiduki kohta päevas, et arvutada 10 000 sõiduki igapäevased käitusandmed. Kaaluge jaotustabeli vastuvõtmist disainiprotsessi realiseerimiseks. See tähendab, et üks jaotustabel kuus. Võtke partitsioonitabeli ja partitsioonitabeli võtmeks üleslaaditud operatsiooniandmete tegelik esinemisaeg. Automaatset statistikat tehakse üks kord päevas, et arvutada iga sõiduki päevane kogutulu, samuti mõõteseadmete arv, sõiduki läbisõit ja tühja sõidu läbisõit päevas. Mõõturite arvu abil tehakse kindlaks, kas juhi sissetulek vastab tegelikule olukorrale, ning võrreldakse töö- ja tühisõitu, et teha kindlaks, kas tühja läbisõitu vähendades saab kütusekulu eesmärki kokku hoida.
Eelnevalt
tuletage
Piirkonnas asuvate sõidukite arvu juhusliku jälgimise idee on kindlaks teha, kas sõidukite arv linna ühel kilomeetril ületab teatud künnise. Kuna hinnatav ala on meelevaldne kombinatsioon, peab süsteem tegema statistilisi hinnanguid, ühendades rakendusprotsessis väikesed alad suurteks aladeks. Näiteks jaguneb 1 kilomeetri ala 9 väikeseks 100 meetri suuruseks alaks. Kui 1 kilomeetri pikkusel alal on sõidukite künnis 30, kui sõidukite arv igas 100 meetri piirkonnas ületab 4, võib kogu 100 meetri piirkonnas asuvate sõidukite koguarv küündida 30 sõiduki künniseni. Seetõttu muudetakse süsteemi seireulatus väikeseks, 100 meetri pikkuseks alaks. Juhusliku seire piirkonna kujundus ja teostus on järgmine: süsteem jaotab kogu linna aladeks iga 100 meetri järel vastavalt linna asukohale ning geograafilisele laius- ja pikkuskraadile. Jagatud ala määrab sõidukite arvu künnise. Süsteem hindab sõidukite arvu põhjal väikesel alal ja kui künnis on saavutatud, otsustab ta, kas ümbritsevas piirkonnas asuvate sõidukite koguarv saavutab jälgitavate sõidukite arvu häirekünnise. Taksojuhtide GPS-terminalidest arusaamise paranemisega peab seireplatvorm varakult ette andma ka ebanormaalse GPS-i andmete üleslaadimise. Näiteks on sõidukite kommunikatsioonianomaaliate arv teatud aja jooksul järsult tõusnud ning seirekaardil olevate sõidukite arv on positsioneerimise jms jaoks järsult kasvanud, samuti on need näitajad, mille osas juhtimisosakond peab valvel olema.
Sündmuste seire
Sündmuste peatamise ja kogumise käigus saab süsteemi kaudu kindlaks määrata seireala ning reaalajas loendada piirkonnas asuvate sõidukite arvu ja põhiteavet, näiteks ettevõtte ja sõiduki juhi kohta. . Juhtide tagasikutsumine ettevõtete kaudu.
kokkuvõte
Suspensiooni kogumine kestab tavaliselt paar päeva või isegi rohkem kui nädala. Pärast seda on vaja läbi viia statistiline analüüs kokkutulekul osalenud juhtide ja üksuste kohta. Süsteem saab sõiduki ajaloolise trajektoori teabe põhjal arvutada parkimisalal viibimise kogunenud kestuse kogu parkimise ajal, et määrata kindlaks juhi parkimises osalemise sügavus. Selle abil saab kogupeatuse ajal koguda statistikat sõiduki võrgusageduse kohta, kas sõiduk on häirinud parda terminali sidet. Pakkuge valitsusele ja ettevõtetele toetust peatamisürituse korraldajate leidmiseks ja kogumiseks.
Kuna linna stabiilsuse säilitamise fookuses on taksopeatus ja kogunemine pälvinud paljude linnade tähelepanu. GPS-põhise takso saatmise ja jälgimise platvormi jälgimisfunktsioon pakub peamiselt sõidu lõpetamise kogunemisürituste ettevaatusabinõusid ja eelhoiatusi. Peatunud sõidu kogunemisjuhtumitel põhinev konflikti peamine põhjus võib vähendada ka GPS-i saatmise funktsiooni abil juhi tühja sõidukiirust, vähendada juhi tühja sõidu kütusekulu ja vähendada juhi kulutusi abi osutamiseks.
Vähendage liiklusummikuid ja kütusekulu
Kodumaise majanduse kiire arenguga on liiklusummikud erinevates linnades muutunud üha tõsisemaks. Liiklusummikute põhjustatud vastuolud kodumaistes esimese astme linnades nagu Peking, Shanghai ja Guangzhou on üha enam esile kerkinud. Veelgi tõsisem on see, et linnaliikluse ülekoormatus on levinud esimese ja kolmanda taseme linnadest. Kuigi paljud suured linnad on hakanud uurima mõningaid piiravaid meetmeid sõidukite liikumise vähendamiseks, et saavutada linnateede ülekoormuse leevendamise eesmärk, näiteks Pekingi paaritu ja paarisarv, Shanghai numbrimärgioksjon ja nii edasi. Mõni linn on hakanud isegi linnade ülekoormustasusid kehtestama. Linnaliikluse ülekoormatuse fenomen pole aga veel paranenud. Vastupidi, rahvamajanduse arengu ja inimeste elatustaseme paranemisega on inimeste nõudlus autode ostmise järele tugevnenud ja linna teede ülekoormuse vastuolu on üha enam esile kerkinud. Maanteede ülekoormuse vähendamisel on võimalik kaaluda teeäärse taksoteatamismeetodi järkjärgulist asendamist sõiduplaani abil. Statistika järgi, võttes näiteks Shanghai, moodustab taksode tühi läbisõit üle 40% kogu läbisõidust. See on
Väidetavalt raisatakse päevas peaaegu pool taksodes olevast õlist ja peaaegu pooled autod sõidavad teel. See raiskab mitte ainult gaasiraha, suurendab autojuhtide töömahukust, vaid võtab ka väärtuslikke linnateede ressursse. Kujutage ette, et kui praegune siseriiklik taksoteatamise süsteem muudetakse avalikust kõnest telefoniteatamise saatmismeetodiks, siis takso puhkab, kui reisijaid pole, see tähendab, et see säästab gaasi ja vähendab töömahtu ning vabastab linna teeressursid. Mõiste muutmine on järkjärguline protsess. Takso värbamine tee ääres on mudel, mis on kujunenud taksotööstuse algusest peale ja see on olnud levinud ärimudel kodust välismaale. Järk-järguline üleminek värbamiselt telefonidispetšerile nõuab mitte ainult autojuhtide tööharjumuste, vaid veelgi tähtsamalt ka reisijate mõtlemisharjumuste muutmist. Praegu on kodumaised ja mõned linnad hakanud rajama linnapõhiseid taksode saatmisplatvorme, nagu Wuxi, Nanchang, Wenzhou ja nii edasi. Ja paigaldades taksodele LED-ekraanid, et saavutada maksebilanss ja minimeerida valitsuse rahastamist. Veelgi enam, linnatasandi taksode saatmisplatvormid sellistes linnades nagu Wuxi ja Nanchang suudavad põhimõtteliselt saavutada isemajandamise alates personalist kuni süsteemi hooldamiseni. Sellest vaatenurgast on linna tasemel taksode saatmisplatvorm kapitaliinvesteeringute osas täiesti saavutatav. Võtke näiteks Wuxi. Wuxis on umbes 4000 taksot. Lähetusplatvorm ehitati kaks aastat tagasi. Alates kümnete reisijate päevasest üleskutsest takso kutsumiseks kuni 2010. aasta lõpuni toimus päevas keskmiselt üle 6000 eduka lähetuse. Rohkem kui 8000. See mitte ainult ei hõlbusta oluliselt Wuxi kodanike reisimist, vaid veelgi olulisem - võimaldab telefonikõnesid
. Auto uus autode tervitamise mudel hakkab juurduma. Telefonikõnede arvu ja edukate lähetuste arvu suurenemine on
praegune Autole helistamise režiim on üldsusele vastuvõetav ja autojuhid on valmis koostööd tegema.
See, kuidas taksode mahtu andmete analüüsi kaudu mõistlikult jaotada, on ka ainus viis taksode üleminekuks palkamiselt ESC-le. Kui taksod toetuvad peamiselt ESC-dele, mis tähendab maanteel tühja sõidu vähendamist, toob see kaasa ka vastuolu, see tähendab, et juhi võimalused reisijaid näha vähenevad ja juhi sissetulek väheneb. Kuidas hoida taksot piirkonnas, kus autot kasutatakse, see tähendab, et see võib jõuda võimalikult kiiresti pärast reisija pardaleminekukohta pärast korralduse saamist saatekeskusest tühja läbisõidu vähendamiseks ja arvestada, et juht peaks sõidukit juhtima sinna piirkonda ootama pärast reisijate saatmist Uus äri. Lühidalt, selle ülemineku saavutamiseks juhi üleviimiselt ESC-režiimile tuleb kõigepealt lahendada juhi kaks probleemi: 1) kuidas tagada teatud summa taksoga ESC-äri; 2) Kuidas jagada sõiduki tavapärane parkimisala mõistlikuks. Kui neid kahte probleemi ei lahendata, on ärimudeli ümberkujundamise eesmärgi saavutamine võimatu. Kolme Shanghai, Volkswageni, Jinjiangi ja Bussi taksofirma statistiliste andmete analüüsi põhjal leitakse, et välja arvatud bussid, mis suudavad igapäevaselt saata rohkem kui 2 tehingut sõiduki kohta, on eduka lähetuse keskmine arv Volkswageni ja Jinjiangi operatsioonide jaoks on ainult umbes 1 pliiats. Ühe päeva jooksul on Volkswageni edukate lähetuste arv umbes 12 000, Jinjiang umbes 4000 ja bussid võivad ulatuda 8000-ni. Jagades nende kolmele ettevõttele vastavate sõidukite arvuga, võib järeldada, et praegune ESC-teenuste arv ei suuda juhtide igapäevaseid ärinäitajaid täita. See on algpõhjus, mille valivad autojuhid ikkagi oma peamiseks töörežiimiks. Pealegi on nende kolme taksofirma ESC-äri tegutsenud enam kui viis aastat. Selle majandus- ja sotsiaalnõukogu äritegevuse kiiruse põhjal on põhimõtteliselt ette näha, et kui administratiivset sekkumist ei toimu, ei ole võimalik värbamise tõstmisest ESC-le automaatselt üle minna. Tuli välja ärimudel. Mida saab siis GPS-põhine takso saatmisplatvorm selle ärimudeli muutmise soodustamiseks teha?
Platvormi andmeanalüüsi eeliste kaudu saame juhtidele pakkuda mõistlikke autokasutusalasid ja muid juhte abistavaid viise, et saavutada platvormi eesmärk - süvendada autojuhtide südant. See tähendab, et süsteem ei mängi mitte ainult juhtimise seisukohast lähetamist ja jälgimist, vaid peab mängima ka juhi vaatenurgast analüüsi ja juhendamist, et pakkuda praktilist abi juhi sissetulek ja tagada juhi turvalisus. Andmete analüüsi kaudu reisija pardaleminekupunkti ja pardale mineku aja kohta näitab juht piirkondi, kus sõiduauto maht on neil ajaperioodidel suhteliselt suur, ning igas piirkonnas ja ajaperioodil kasutatud sõidukite ajalooline arv moodustab igapäevase ajaloolise andmete võrdlus. Tegelikus tööprotsessis, kui taksosõidukite arv selles piirkonnas ületab nendel perioodidel teatud protsendi, võib süsteem alarmeerida ja saata kõigile sõidukitele sõnumi, et piirkonnale meelde tuletada, et sõidukid on küllastunud, ja sõidukid võivad kaaluda sõitmist teistele aladele, et vältida tühja sõitu. Ja lähtudes piirkonna ja ajavahemiku ajaloolistest andmetest ning sõidukite arvust päeva piirkonnas, otsustatakse, millistes piirkondades on endiselt sõidukipuudus, ja juhatatakse juhiga, saates läheduses asuvad sõidukid. Juhi vaatenurgast läbi viidud analüüsi ja juhiste abil saab juhtide seas järk-järgult kindlustatud saatmisplatvormi enesekindlus ja prestiiž, nii et juht pöördub kahtlustelt usalduse poole, et loota saatmisplatvormile. Pardaterminal on sõiduki ja süsteemiga tihedalt seotud. Niikaua kui juhtkond suhtleb juhi ideede mõistmiseks rohkem kui juht ning pakub juhtimise seisukohast mõistlikke lahendusi ja juhtimismeetodeid, usun, et juht on platvormil, et saavutada praktilisi eeliseid. Samaaegselt saab käegakatsutavalt hüvitada ka ettevõtete ja valitsuste investeeringuid. Kindlasti peab praegune majandus- ja sotsiaalnõukogu äri, kus päevas on vähem kui 2 tehingut auto kohta, nende ettevõtete jaoks, kes on varajases staadiumis palju ehitussüsteemidesse investeerinud. Linnateede ülekoormuse ja kütusekulu vähendamine taksode saatmise teel on pikk tee. Raskused seisnevad tavapäraste töömeetodite ja uute töömeetodite teisendamises, mida pole veel võimalik juhtida ega praktiliselt rakendada. Tõesta, et see võib asendada vana propageerimisel põhinevat tööviisi. Kuid süsteem võib siiski mängida teatavat rolli juhi tühja sõidu vähendamisel ja kütusekulu vähendamisel. Kuigi Yang Zhao seisukohta ei saa praegu ESC-ga asendada, on kodumaiste linnade nagu Shanghai, Wuxi, Nanchang ja Wenzhou ESC andmete analüüsist lähtudes hakanud ESC meetodit reisijad ja juhid aeglaselt aktsepteerima. Lihtsalt Yang Zhao kui reisijate ligimeelitamise peamise vahendi edasiseks laiendamiseks ja asendamiseks on veel pikk tee.
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.


Postituse aeg: september-04-2020