System and method for accurately pushing dynamic information of electronic bus stop board of smart city

Abstract

The invention discloses a system and a method for accurately pushing dynamic information of electronic bus stop boards of smart cities, relates to the technical field of bus information pushing, and realizes accurate identification and dynamic adaptation of bus scenes by constructing a four-dimensional data acquisition and multi-dimensional cross check mechanism. The system is based on the four-dimensional characteristics of time, space, events and group behaviors, and combines the confidence quantitative evaluation of the scene template library, thereby effectively solving the problems of fuzzy and lagged scene recognition of the traditional electronic bus stop board, ensuring the accuracy and real-time performance of a target scene template, and providing a reliable scene basis for subsequent information push. A lightweight group label is generated by extracting core features such as a group age structure and interaction preference. By means of the design, the risk of personal privacy disclosure is avoided, the common requirements of the waiting groups can be accurately captured, organic balance between privacy protection and personalized services is achieved, and information services meeting the requirements of the different types of groups are provided for the different types of groups.

Description

Technical Field

[0001] This invention relates to the field of public transportation information push technology, and more specifically, to a system and method for accurately pushing dynamic information from electronic bus stop signs in smart cities. Background Technology

[0002] Traditional bus stop electronic sign information push technology often uses a fixed display pattern, lacking the ability to dynamically perceive and adapt to actual scenarios. Existing systems often only push basic arrival information based on single route operation data, failing to combine time periods, surrounding station environment, and sudden public events to identify specific scenarios. This results in a disconnect between the pushed content and actual traffic conditions and user needs, making it difficult to cope with the information service requirements of complex scenarios such as rush hours and the end of large events.

[0003] Traditional public transport information push technologies have limitations in capturing user needs, relying heavily on a standardized information display logic and failing to fully consider the differentiated needs of different waiting groups. Due to a lack of effective perception and analysis of group characteristics, the system cannot distinguish the core demands of different user types such as commuters, the elderly, and tourists, resulting in a one-size-fits-all approach to content. This not only fails to meet the personalized needs of specific groups but may also reduce the efficiency of users in obtaining key information due to information overload, thus impacting the public transport service experience.

[0004] Furthermore, existing technologies fall short in balancing data fusion and privacy protection. Some systems, due to their limited data collection dimensions, cannot support accurate scenario identification and demand matching; while a few solutions attempting multi-source data collection are prone to user privacy leaks due to a lack of effective anonymization mechanisms. Simultaneously, the prioritization of information push lacks scientific basis, with key and non-key information presented interchangeably, further reducing the service efficiency of electronic bus stop signs.

[0005] Based on the above, this invention proposes a system and method for accurately pushing dynamic information from electronic bus stop signs in smart cities. Summary of the Invention

[0006] In view of the shortcomings of existing technologies, the purpose of this invention is to provide a system and method for accurately pushing dynamic information of electronic bus stop signs in smart cities.

[0007] To achieve the above objectives, the present invention provides the following technical solution: The smart city's electronic bus stop sign dynamic information precision push system includes a four-dimensional data acquisition module, a target scene template selection module, a group profile construction module, and a demand sorting and push module; The four-dimensional data acquisition module is used to build a bus stop template library and periodically collect the four-dimensional raw data of electronic bus stop signs. The target scene template selection module standardizes the collected four-dimensional raw data to obtain four-dimensional features. It then performs multi-dimensional cross-validation on the four-dimensional features and calculates the confidence of each scene template in the bus stop scene template library. The scene template with the highest confidence is marked as the target scene template. The group profile building module constructs group profiles for electronic bus stop signs; The demand sorting and push module matches and sorts demands based on target scenario templates and group profiles, and pushes the sorted demands in order on the bus electronic bus stop sign.

[0008] Furthermore, the four-dimensional raw data includes time dimension data, spatial dimension data, event dimension data, and group behavior dimension data.

[0009] Furthermore, the process of multi-dimensional cross-validation of the four-dimensional features is as follows: the four-dimensional features are compared with all scene templates in the bus stop scene template library, and the "four-dimensional feature rules" of each scene template are matched item by item, outputting the number of matching dimensions for each scene template. When feature comparison reveals a "dimensional feature contradiction", it is determined to be a "conflict scenario". For identified conflict scenarios, a "multi-source data cross-validation" mechanism is activated, auxiliary data is called, and relevant data are automatically associated according to the conflict type. If the auxiliary data supports the "reasonableness of conflict features", the "conflict is resolved"; otherwise, the "conflict is valid" is confirmed.

[0010] Furthermore, the confidence score adopts a rule-based scoring system of "base score + extra score - conflict penalty". Base score: A score is awarded for each successfully matched dimension; Bonus points: If the event dimension or group behavior dimension matches, an additional B point will be awarded; Conflict deduction: C points are deducted for each valid conflict; D points are recovered after the conflict is resolved.

[0011] Furthermore, the demands are ranked using a "three-dimensional weighted evaluation method," with the three dimensions including urgency, frequency, and universality.

[0012] Furthermore, the three-dimensional evaluation rules are as follows: Urgency: the degree of impact of delayed demand fulfillment, including high urgency, medium urgency, and low urgency; High frequency includes high-frequency, mid-frequency, and low-frequency. Universality can be categorized into high universality, medium universality, and low universality.

[0013] Furthermore, the method for accurately pushing dynamic information from electronic bus stop signs in smart cities involves the following steps: S1: Four-dimensional data acquisition and template library construction; S2: Four-dimensional feature standardization and target scene template recognition; S3: Group Profile Construction; S4: Demand matching, sorting, and information push.

[0014] Compared with the prior art, the present invention has the following beneficial effects: This system and method achieve accurate identification and dynamic adaptation of public transportation scenarios by constructing a four-dimensional data acquisition and multi-dimensional cross-validation mechanism. Based on four-dimensional features of time, space, events, and group behavior, combined with confidence quantification of the scenario template library, the system effectively solves the problems of fuzzy and lagging scene recognition in traditional electronic bus stop signs, ensuring the accuracy and real-time nature of target scenario templates and providing a reliable scenario basis for subsequent information push. Lightweight group tags are generated by extracting core features such as group age structure and interaction preferences. This design avoids the risk of personal privacy leakage while accurately capturing the common needs of waiting groups, achieving an organic balance between privacy protection and personalized services, providing information services tailored to the needs of different groups. Through a three-dimensional association mechanism of "scenario-group-needs" and a dynamic sorting strategy, the accuracy and efficiency of information push are significantly improved. The system matches core needs based on target scenario templates and group profiles, and prioritizes needs through a three-dimensional weight evaluation of urgency, frequency, and universality. Combined with adaptive information presentation methods, this ensures that the pushed content highly matches the actual needs of waiting groups, effectively improving the convenience and user experience of public transportation. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the principle of the present invention; Figure 2 This is a flowchart of the multi-dimensional cross-validation process for four-dimensional features. Detailed Implementation

[0016] Example 1: Refer to Figures 1-2 The smart city's electronic bus stop sign dynamic information precise push system includes a four-dimensional data acquisition module, a target scene template selection module, a group profile construction module, and a demand sorting and push module.

[0017] The four-dimensional data acquisition module builds a bus stop template library and periodically collects four-dimensional raw data from electronic bus stop signs (the period interval is set and adjusted according to the frequency of dynamic changes in the data; the four-dimensional raw data includes time dimension data, spatial dimension data, event dimension data, and group behavior dimension data).

[0018] The construction process of the bus stop scene template library is as follows: Core Element 1: Four-dimensional feature matching rules: Clearly define the "must-meet conditions" and "prohibited conditions" for the time, space, event, and group behavior dimensions. For example, the rules for the "morning rush hour commuting scenario" are: the time dimension must meet "morning rush hour (7:00-9:00) + weekdays", and "holidays / adjusted days off" are prohibited; the space dimension must meet "business commuting stations / densely populated residential stations", and "scenic area shuttle stations" are prohibited; the event dimension must meet "no high-impact events", and "large-scale events / rainstorm warnings" are prohibited; the group behavior dimension must meet "high crowd density (≥15 people) + stay for 3-5 minutes + transfer query clicks ≥10 times / 30 minutes". Core Element 2: Trigger threshold: Define the quantitative boundary of the features (not formulaic, but described by thresholds). Example: The threshold for "high crowd density" is "number of people waiting ≥ 60% of the station's waiting area capacity"; the threshold for "increased dwell time" is "current average dwell time ≥ 1.5 times the historical average for the same period" (e.g., dwell time increases from 5 minutes to 8 minutes on rainy days compared to sunny days). Core Element 3: Related Push Strategy Tags: Pre-bound to the core push requirements of this scenario (for subsequent push engine calls). Example: The related tags for "large event exit scenario" are "temporary additional bus information + evacuation routes + estimated queuing time". Template Classification and Coverage: Based on the high-frequency characteristics of urban public transport scenarios, 12 core templates are preset (covering 90% of daily scenarios), categorized as follows: Scene categories Specific scenario examples Core feature differences Commuting Morning rush hour commute, evening rush hour commute, post-holiday return-to-work peak Time period (weekdays) + Space attribute (business / residential) Events Large event closing time, school dismissal time, and evening rush hour in shopping districts Event triggered (event / school dismissal time) + sudden increase in crowds Meteorological Related Categories Waiting for a bus in the rain, waiting for a bus in the high temperature, and during typhoon warning periods. Weather event level + changes in stay behavior (avoiding rain / heat) Special period Tourist flow at scenic spots during holidays, peak travel season during the Spring Festival, and exam periods Periodic tags (holidays / special occasions) + POI attributes Offline optimization: Based on historical scenario data (such as the "scenario-feature-user feedback" association records of the past 7 days), new high-frequency scenarios (such as "morning rush hour around schools during the back-to-school season") are identified weekly through cluster analysis and included in the template library after manual verification; Online tuning: When the recognition accuracy of a certain scenario (the percentage of users who reported "accurate matching") is less than 70%, template rule fine-tuning is automatically triggered (such as adjusting the "stay time threshold" or "POI percentage standard"); Version management: The template library supports version rollback. When a new template causes recognition anomalies, it can be quickly rolled back to a historical stable version.

[0019] Time-based data acquisition process: Time reference synchronization: A "dual-source time calibration" mechanism is adopted: The master clock is connected to the National Time Service Center's NTP (Network Time Protocol) server, synchronizing every 30 seconds to ensure a system time error of ≤1 millisecond; the backup clock is based on the terminal's local high-precision crystal oscillator, automatically switching when NTP synchronization is interrupted to ensure time continuity. Output: System real-time time (format: YYYY-MM-DDHH:MM:SS, accurate to the second). Calendar data integration and parsing: Connecting to the city's government service platform's "Public Calendar Database" API, automatically retrieving calendar data for the current day and the next 7 days at 3 AM every day, including: Date type: weekday / weekend (Saturday / Sunday) / statutory holidays (such as Spring Festival, National Day); Adjustment information: such as "Due to holiday adjustments, this Saturday (Month X, Day X) will be treated as a weekday"; Special period markers: such as the start and end dates of school winter and summer vacations, Spring Festival travel season, college entrance examination period, etc. Data storage: Real-time calendar data is cached using Redis, with a 24-hour expiration time set to ensure data freshness. Automatic Time Segmentation: A preset "dynamic time segmentation rule base" is used to configure time segmentation standards based on urban traffic characteristics (supporting city-level differentiated configurations, such as 7:00-9:00 AM in first-tier cities and 7:30-9:30 AM in third- and fourth-tier cities): Peak Hours: Morning peak (7:00-9:00 AM), Evening peak (5:00-7:00 PM); Off-Peak Hours: Weekday daytime (9:00-5:00 PM); Low-Peak Hours: Nighttime (10:00 PM - 6:00 AM the next day); Transition Hours: 30 minutes before peak hours (e.g., 6:30-7:00 AM is the transition period between the morning and evening peak hours), 30 minutes after peak hours (e.g., 9:00-9:30 AM is the transition period after the morning peak hour). Real-time Matching: The system compares the current time (e.g., 7:30 AM) with the rule base and automatically tags the time segment (e.g., "morning peak hour"). Intelligent tagging of special time points: Based on calendar data and preset rules, automatically tag high-frequency special time points: School-related: primary and secondary school arrival and dismissal times (7:00-8:00) and (16:30-17:30); university start season (September) and end-of-term season (January / June); Commuting-related: first day back to work after holidays (e.g., the first working day after the Spring Festival) and peak travel period before holidays (e.g., the first 3 days before the Spring Festival travel rush); Public events: special examination periods such as the college entrance examination (June 7-8) and the middle school entrance examination. Output: Standardized data in the time dimension (format: [real-time time, date type, time period label, special time point tag]).

[0020] Spatial Dimension Data Acquisition Process: GIS Basic Data Integration: Integrating with the city's Natural Resources Bureau's "Basic Geographic Information Database," core spatial data of the site is obtained through the WFS interface: Precise site coordinates: latitude and longitude (e.g., 39.9042°N, 116.4074°E); Road network around the site: distribution of main roads, secondary roads, and sidewalks within a 500-meter radius; Administrative division association: affiliated administrative district and street (for subsequent regional configuration). Data Update: Automatically synchronizes GIS database updates on the 1st of each month (e.g., adding roads, minor adjustments to site locations) to ensure accurate spatial benchmarks. POI Data Collection and Filtering: Multi-source POI data access: Main data source: Integrating with the Gaode / Baidu Maps open platform POIAPI, batch-pulling POI data within a "site coordinates + 500-meter radius" range, including name, type, address, business hours, and real-time status (e.g., open / closed); Supplementary data sources: Integrating with local life service platforms (e.g., Meituan, Dianping) to obtain real-time popularity data of commercial POIs (e.g., shopping mall visitor traffic levels), and integrating with the Culture and Tourism Bureau to obtain the opening status of scenic spots. POI Type Standardization: Original POI types are mapped to a pre-defined classification system (Business, Education, Commerce, Culture & Tourism, Residential), eliminating low-relevance POIs (such as trash cans, public toilets, and other non-core points of interest). Spatial Scope and Weight Calculation: Precise Scope Delineation: Based on station coordinates and GIS data, a circular spatial scope with a 500-meter radius is generated using "buffer analysis" technology (excluding inaccessible areas such as rivers and railways), ensuring that POI statistics only include areas accessible by foot. Dynamic Weight Assignment: Weights are set according to the POI's impact on passenger demand (dynamic adjustment supported): Basic Weight: Business, Education, Commerce, Culture & Tourism weight = 1.2, Residential weight = 1.0; Dynamic Adjustment: For example, the weight of schools is temporarily increased to 1.5 during school hours, and the weight of scenic spots is increased to 1.5 during holidays; Weight Calculation: Final weight of a single POI = Basic weight × Dynamic adjustment coefficient. Automatic Site Attribute Labeling: Percentage Calculation: Calculates the "weighted percentage" of various POIs within a 500-meter radius (total weight of a certain type of POI / total weight of all POIs × 100%). Attribute Labeling Rules: Business POI weighted percentage ≥ 60% → Labeled as "Business Commuter Station"; Education POI weighted percentage ≥ 50% → Labeled as "University / School Surrounding Station"; Commercial POI weighted percentage ≥ 50% → Labeled as "Business District Hub Station"; Cultural Tourism POI weighted percentage ≥ 50% → Labeled as "Scenic Area Shuttle Station"; Residential POI weighted percentage ≥ 60% → Labeled as "Community Convenience Station"; Multiple categories with similar percentages (e.g., Business 35% + Commercial 30%) → Labeled as "Comprehensive Functional Station," and the core POI combination (e.g., "Business + Commercial") is also marked. Output: Standardized spatial data (format: [site coordinates, 500-meter POI list, weighted percentage of various POIs, site attribute labels]).

[0021] Event-level data acquisition process: Multi-source event interface aggregation: A standardized interface gateway is built, supporting protocols such as HTTP / HTTPS / MQTT, and connecting to three core event data sources: Meteorological events: The meteorological bureau's "Meteorological Warning Release System" API, obtaining real-time warning type (heavy rain / high temperature / typhoon), level (blue / yellow / orange / red), affected area (accurate to the street level), and effective time; Large-scale events: The city's "Large-scale Event Management Platform" API, obtaining event name, location (latitude and longitude), start / end time, estimated number of participants, and organizer contact information; Traffic events: The traffic management department's "Real-time Traffic Command Platform," obtaining temporary control road sections, accident locations, estimated recovery time, and detour suggestions. Event filtering and priority ranking: Filtering low-impact events: Events with minimal impact on public transport passenger flow, such as "light rain warnings" and "small meetings with fewer than 50 people," are directly removed; Priority classification: Based on the degree of impact, events are divided into "high priority" (e.g., orange or higher meteorological warnings, events involving tens of thousands of people, main road control), "medium priority" (e.g., yellow warnings, events involving thousands of people), and "low priority" (e.g., localized construction). Event impact range correlation: Impact level is calculated based on the straight-line distance between the event location / warning area and the site coordinates: Distance ≤ 1 km → "High Impact Event" (requires priority response); 1 km < Distance ≤ 3 km → "Medium Impact Event" (requires attention); Distance > 3 km → "Low Impact Event" (only recorded, no proactive response). Output: Standardized event dimension data (format: [Event Type, Priority, Affected Area, Affected Time Period, Site Impact Level]).

[0022] Group behavior dimension data acquisition process: Non-invasive sensor deployment and data collection: Sensor configuration: Four types of sensors are deployed at each bus stop (all comply with privacy protection standards and do not collect personal identification information): Millimeter-wave radar: counts the real-time number of people in the waiting area (accuracy ±1 person) and the direction of people entering and exiting (updated every 30 seconds); Low-power camera (with edge computing function): estimates age distribution (elderly / middle-aged / children) and carrying characteristics (pushing strollers / luggage / no special carrying) through contour analysis, without storing the original images; Touch screen interaction logger: records click behavior (such as the number of clicks on the "Route Inquiry", "Transfer Guide", and "Nearby Services" buttons, and the duration of each interaction); Infrared dwell timer: detects the entry / exit time of passengers through infrared sensing and calculates the dwell time of a single passenger (excluding short-term passes of less than 1 minute). Real-time anonymization processing: Camera data: After real-time analysis of contour features by edge nodes, the original images are immediately deleted, and only statistical data (such as "middle-aged and young people account for 70%)" is output; Device data: Bluetooth / WiFi probes only collect anonymous MAC addresses (after hash processing), without associating with device owner information, and are only used to count the number of devices and dwell time. Behavioral Feature Extraction: Real-time calculation of core features: Crowd density: Current number of waiting passengers / maximum capacity of the station's waiting area × 100% (divided into three levels: "low density / medium density / high density"); Average dwell time: Average dwell time of all valid waiting passengers; Core interaction behavior: The interaction type with the most clicks within 30 minutes (e.g., "transfer query"); Group feature proportion: The proportion of people of each age group / with certain characteristics. Output: Standardized data of group behavior dimensions (format: [crowd density level, average dwell time, core interaction type, group feature proportion]).

[0023] The target scene template selection module standardizes the collected four-dimensional raw data to obtain four-dimensional features. It then performs multi-dimensional cross-validation on the four-dimensional features and calculates the confidence of each scene template in the bus stop scene template library. The scene template with the highest confidence is marked as the target scene template. The following is an example of standardizing the collected raw four-dimensional data: Time feature standardization: Output label format: [time period label, cycle label, special time point label]; Example: "7:30 (Monday)" → label is [morning peak, weekday, no special time point]; "16:45 (Friday, primary and secondary school dismissal day)" → label is [off-peak to evening peak, weekday, school dismissal time].

[0024] Spatial feature standardization: Output label format: [Site attribute label, core POI type, POI density level]; Example: "3 office buildings and 2 shopping malls within 500 meters of the site" → label is [Business district hub station, business + commerce, high density].

[0025] Event feature standardization: Output label format: [Event type, impact level, impact period]; for example: "Gymnasium 20:00-22:00 concert (800 meters from the site)" → label is [Large-scale event, high impact, 20:00-22:30]; "Blue rainstorm warning (lasting until 18:00)" → label is [Meteorological event, moderate impact, 14:00-18:00].

[0026] Standardization of group behavior characteristics: Output label format: [People density level, average dwell time, core interactive behavior, proportion of group characteristics]; Example: "20 people waiting for the train (high density), average dwell time of 6 minutes, 15 clicks on transfer query, 80% of them are young and middle-aged" → Labels are [high density, 6 minutes, transfer-dominated, young and middle-aged as the main group].

[0027] The process for multi-dimensional cross-validation of four-dimensional features is as follows: The four-dimensional features are compared against all scene templates in the bus stop scene template library. For each scene template, the "four-dimensional feature rules" are matched item by item, outputting the "dimensional matching result" (success / failure): Time dimension: Compare whether the "time period label, period label, and special time point" fully comply with the template rules (e.g., for the "morning rush hour commuting scenario," both "morning rush hour + weekday" must be met); Spatial dimension: Compare whether the "station attribute label and core POI type" comply with the template rules (e.g., for the "scenic spot tourist scenario," the "scenic spot shuttle station" attribute must be matched); Event dimension: Compare whether the "event type and impact level" comply with the template rules (e.g., for the "rainy day scenario," "heavy rain / rainstorm warning (medium to high impact)" must be matched); Group behavior dimension: Compare whether the "people density, dwell time, and core interactive behavior" reach the template threshold (e.g., for the "large event ending," both "sudden increase in people density (doubling of people within 10 minutes) + dwell time > 8 minutes" must be met). Output: The "number of matched dimensions" (0-4) for each scene template.

[0028] When feature matching results in "dimensional feature contradictions," it is classified as a "conflict scenario." Specific classifications and identification criteria are as follows: Type 1: Intra-dimensional feature conflict: Features within a single dimension contradict each other. Example: The time dimension is simultaneously labeled "morning rush hour" and "holidays" (morning rush hour usually corresponds to weekdays, contradicting holidays); Type 2: Cross-dimensional feature conflict: Logical contradictions between features from different dimensions. Example: The time dimension is "morning rush hour," while the spatial dimension is "scenic area shuttle station" (the core scenario of morning rush hour should be commuting, contradicting the scenic area attribute); Type 3: Threshold failure conflict: Key features do not meet the template threshold, but the dimension labels match. Example: The time and event dimensions match for the "rainy day commuting scenario," but the group behavior dimension "rain avoidance interaction clicks < 3 times / 30 minutes" (does not meet the threshold).

[0029] For identified conflict scenarios, a "multi-source data cross-validation" mechanism is initiated. The specific process is as follows: Auxiliary data is invoked: Relevant data is automatically associated based on the conflict type, such as: Cross-dimensional conflict (morning peak + scenic area station) → Invoke "recent passenger flow data" (percentage of tourists during this time period in the past 7 days) and "real-time opening status of the scenic area" (whether it is summer / peak season); Conflicts that do not meet the threshold (rainy day but little interaction for rain shelter) → Invoke "station facility data" (whether there is a covered waiting area; if there is no covered area, the demand for rain shelter is low) and "real-time video snapshot" (whether passengers bring their own rain gear); Validation rules: If the auxiliary data supports the "reasonableness of conflict characteristics," then "conflict resolved" is determined; otherwise, "conflict valid" is confirmed. Example: Morning peak scenic area station conflict → Auxiliary data shows "82% of tourists during this time period in the past 7 days (summer peak season)" → "spatial characteristics valid, conflict resolved" is determined; Output: Conflict verification results (conflict resolved / conflict valid) and verification basis.

[0030] The confidence score calculation process for each scene template in the bus stop scene template library is as follows: Rule-based confidence score: A rule-based scoring system of "base score + extra score - conflict deduction" (maximum score 100 points) is adopted. Specific scoring criteria: Base score: 25 points for each successfully matched dimension (maximum score for all four dimensions is 100 points); Extra score for core dimensions: If the event dimension or group behavior dimension matches (most directly impacting the scene), an extra 10 points are added (core dimension definition: dynamically set according to the template type, such as "event dimension" as the core in large-scale event scenarios, and "time dimension" as the core in commuting scenarios); Conflict deduction: 20 points are deducted for each valid conflict (unresolved); additional points are deducted after conflict resolution. Return 15 points (only deduct 5 points, acknowledging the reasonableness of the feature but retaining a slight penalty); Example: Matching results for a large event exit scene: Time (match +25), Space (match +25), Event (match +25 + 10 extra points), Group behavior (match +25) → No conflict → Total score = 25 + 25 + 35 + 25 = 110 → Capped at 100 points (100% confidence); Matching results for a scenic spot station scene during morning rush hour: Time (match +25), Space (match +25), Event (none +0), Group behavior (match +25) → Cross-dimensional conflict (deduct 5 points after resolution) → Total score = 25 + 25 + 25 - 5 = 70 points (70% confidence).

[0031] The group profile building module constructs group profiles for electronic bus stop signs; The process for constructing a user profile for electronic bus stop signs is as follows: Step 1: Extract core features of the group based on the sensors of the bus stop electronic sign. Examples of core features are as follows: age structure features, carrying needs features, device type features, interaction preference features, and dwelling behavior features. The extraction index for age structure features is the percentage of elderly / middle-aged and young / children. Example result: elderly account for 40%, middle-aged and young account for 55%. The extraction index for carrying needs features is the percentage of strollers / luggage / no carrying. Example result: luggage accounts for 20%. The extraction index for device type features is the percentage of feature phones / smartphones / tablets. Example result: smartphones account for 90%. The extraction index for interaction preference features is the interaction type with high frequency of clicks. Example result: transfer query clicks 15 times / 30 minutes. The extraction index for dwelling behavior features is the average dwelling time and the frequency of people entering and leaving. Example result: average dwelling time 6 minutes, inflow > outflow. The sensor deployment and data acquisition logic is as follows: Smart camera: Deployed on the top of the bus stop sign (covering the waiting area), with a built-in edge computing chip, it only analyzes the contour features of the crowd in real time: Age distribution estimation: Divide the population into "elderly group (≥60 years old)", "middle-aged and young group (18-59 years old)" and "children (≤17 years old)" based on contour height and body characteristics (such as the proportion of elderly people bending over and the height of children), and output the percentage data (such as "elderly group accounts for 45%)"; Carrying feature recognition: Recognize three types of features through contour shape: "pushing a stroller", "carrying large luggage" and "no special carrying", and calculate the percentage of each type (such as "stroller carrying accounts for 10%)". Bluetooth / WiFi Anonymous Probes: Deployed at the bottom of the bus stop sign, with passive scanning mode enabled: Device Type Statistics: Captures broadcast signals from anonymous devices (e.g., MAC addresses of mobile phone Bluetooth / WiFi are hashed using SHA-256, making it impossible to reverse-link to individuals), and infers the age group based on device model (e.g., feature phones / smartphones / tablets) (e.g., high proportion of feature phones → concentrated elderly population); Dwell Time Analysis: Records the signal duration of devices in the waiting area, eliminates short-lived devices (<1 minute), and calculates the average dwell time of the group (e.g., "average dwell time 7 minutes"). Touchscreen interaction log collection: Records anonymous interaction behavior (no user account association): Interaction type statistics: Categorized by "Route query", "Transfer guidance", "Nearby services (restaurants / toilets)", "Attraction introduction", etc., recording the number of clicks on each button within 30 minutes (e.g., "Attraction introduction clicked 20 times"); Interaction duration analysis: Statistics on the average duration of a single interaction operation (e.g., "Transfer query average operation 30 seconds"), reflecting the intensity of the group's demand for a certain type of information; Step 2: Combine the target scene template and generate tags through "Group Core Features - Scene Association Rules of Target Scene Template"; the tag generation rules are as follows: Rule 1: Age + Scene Association: Scenic Area Shuttle Station + Middle-aged and young people account for ≥70% → Tag "Tourist-led"; Community Station + Elderly account for ≥50% → Tag "Elderly Group Concentration"; Rule 2: Interaction Preference + Scene Association: Business Commuting Station + Transfer Inquiry Clicks ≥10 times / 30 minutes → Tag "Commuter-led"; Business District Station + Surrounding Services Clicks ≥8 times → Tag "Consumer Demand"; Rule 3: Behavioral Characteristics + Scene Association: Surrounding Large Event Venues + 30-minute Population Growth ≥200% → Tag "Short-term Gathering"; Surrounding Schools + School Dismissal Time + Children and Teenagers account for ≥60% → Tag "Student Group Concentration"; Output format: [Core Group Tag, Key Feature Supplement] (e.g., "[Elderly Group Concentration, Stroller-carrying Percentage 10%]", "[Tourist-led, Smartphone Percentage 95%]").

[0032] The demand sorting and push module matches and sorts demands based on target scenario templates and group profiles, and then pushes the sorted demands in sequence to the bus stop electronic displays, as detailed below: Based on the "target scenario template + group tags" association with the pre-set requirement library, a candidate requirement list is generated; the pre-set requirement library is designed to be categorized into "basic transportation requirements + scenario-derived requirements," covering 8 core requirements: Demand type Specific content Target scene template + group tag example Basic transportation demand Vehicle arrival time and congestion prediction Universal for all scenarios Transfer connection needs Transfer route guidance, walking navigation Commuting-driven, short-term clustering Comfortable travel needs Vehicle parking space prediction, rain / heat shelter guidance elderly people, rainy day scenes Emergency evacuation needs Temporary additional bus information and alternative routes Large event closing time, peak passenger flow surrounding service needs Location of restaurants / toilets / convenience stores Commercial district stations, consumer demand-oriented Cultural and tourism information needs Attraction introductions, multilingual guides Scenic area shuttle stations, tourist-oriented Special care needs Accessibility signage, student discount information Stroller carrying, student groups Efficiency optimization requirements Fastest route recommendations and congestion avoidance tips Morning / evening rush hour commuting scenarios The matching logic for the candidate demand list is as follows: Combining the current scenario tags and group tags, select the 3-5 demands with the highest matching degree from the demand library: For example: "Rainy day + concentrated elderly group" scenario → matching demands: ① vehicle space prediction (comfort demand), ② rain shelter guidance (comfort demand), ③ arrival time (basic demand); For example: "large event dispersal + short-term gathering" scenario → matching demands: ① temporary vehicle information (emergency demand), ② queue time estimation (efficiency demand), ③ alternative evacuation routes (emergency demand); The "three-dimensional weight evaluation method" (urgency + frequency + universality) is used to rank the needs, and the weights are dynamically adjusted according to the scenario.

[0033] Three-dimensional evaluation rules: Urgency (weight 40%): The degree of impact of delayed demand fulfillment: High urgency: Temporary vehicle addition information, congestion avoidance tips (delayed push notifications may cause you to miss your vehicle); Medium urgency: Availability prediction, rain shelter guidance (delay affects the experience but not travel); Low urgency: Nearby services, attraction introductions (delay has no significant impact).

[0034] High frequency (weight 30%): The demand intensity reflected by group interaction data: High frequency: ≥10 clicks within 30 minutes (e.g., 15 clicks for transfer query); Medium frequency: 5-9 clicks; Low frequency: ≤4 clicks.

[0035] Universality (weight 30%): The proportion of the group covered by the demand: High universality: Covering ≥70% of the waiting group (e.g., basic arrival time); Medium universality: Covering 30%-69% of the group (e.g., the demand for empty seats for the elderly); Low universality: Covering ≤29% of the group (e.g., accessibility guidance for strollers).

[0036] Dynamic sorting example: Scenario: "Morning rush hour commuter station + commuter-dominated type" → Demand sorting: ① Target line congestion prediction (high urgency + high frequency + high universality); ② Fastest arrival time (high urgency + high frequency + high universality); ③ Transfer connection prompts (medium urgency + high frequency + medium universality).

[0037] Scenario: "Off-peak tourist season + tourist-driven" → Demand ranking: ① Multilingual transfer guidance (medium urgency + high frequency + high universality); ② Attraction introduction (low urgency + high frequency + high universality); ③ Location of nearby specialty restaurants (low urgency + medium frequency + medium universality).

[0038] Example 2: A method for accurately pushing dynamic information from electronic bus stop signs in smart cities, the steps of which are as follows: S1: Four-dimensional data acquisition and template library construction; S2: Four-dimensional feature standardization and target scene template recognition; S3: Group Profile Construction; S4: Demand matching, sorting, and information push.

[0039] The aforementioned system and method achieve accurate identification and dynamic adaptation of public transportation scenarios by constructing a four-dimensional data acquisition and multi-dimensional cross-validation mechanism. Based on four-dimensional features of time, space, events, and group behavior, combined with confidence quantification of the scenario template library, the system effectively solves the problems of fuzzy and lagging scene recognition in traditional electronic bus stop signs, ensuring the accuracy and real-time nature of target scenario templates and providing a reliable scenario basis for subsequent information push. Lightweight group tags are generated by extracting core features such as group age structure and interaction preferences. This design avoids the risk of personal privacy leakage while accurately capturing the common needs of waiting groups, achieving an organic balance between privacy protection and personalized services, providing information services tailored to the needs of different groups. Through a three-dimensional association mechanism of "scenario-group-needs" and a dynamic sorting strategy, the accuracy and efficiency of information push are significantly improved. The system matches core needs based on target scenario templates and group profiles, and prioritizes needs through a three-dimensional weight evaluation of urgency, frequency, and universality. Combined with adaptive information presentation methods, this ensures that the pushed content highly matches the actual needs of waiting groups, effectively improving the convenience and user experience of public transportation.

[0040] Based on the above technical solutions, the smart city's electronic bus stop sign dynamic information precision push system also includes the following functions: Real-time bus information: The electronic screen displays the real-time location, estimated arrival time, and vehicle congestion level of passing bus routes, making it easier for passengers to plan their waiting time.

[0041] Comprehensive information services: Provides public information such as weather forecasts, news, information on surrounding business districts (such as shopping malls, restaurants, attractions, etc.), and traffic control notices.

[0042] Human-computer interaction: Supports touch screen operation, allowing passengers to check bus route plans, details of facilities around stations, etc., and some also have voice interaction functions.

[0043] Mobile payment integration: It can integrate QR code scanning for public transport guidance, or provide services such as transport card top-up and balance inquiry.

[0044] Basic amenities include USB charging ports, Wi-Fi coverage, and some station halls have heated / cooled seats, emergency call buttons, and facilities for people with disabilities.

[0045] Commercial service extensions: Vending machines, shared power banks, and parcel lockers may be introduced to meet passengers' temporary needs.

[0046] Monitoring and security: Cameras are installed to enable real-time monitoring, ensuring the safety of the station hall and surrounding areas. Some cameras have automatic alarm functions for abnormal situations.

[0047] Environmental monitoring: Monitor temperature, humidity, and air quality in the station hall, and coordinate with ventilation and temperature control equipment to improve the waiting environment.

[0048] These features are designed to improve the convenience, comfort, and efficiency of public transportation, making it more aligned with the needs of citizens.

[0049] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0050] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A smart city bus stop electronic sign dynamic information precise push system, characterized in that, It includes a four-dimensional data acquisition module, a target scene template selection module, a group profile construction module, and a demand sorting and push module; The four-dimensional data acquisition module is used to build a bus stop template library and periodically collect the four-dimensional raw data of electronic bus stop signs. The target scene template selection module standardizes the collected four-dimensional raw data to obtain four-dimensional features. It then performs multi-dimensional cross-validation on the four-dimensional features and calculates the confidence of each scene template in the bus stop scene template library. The scene template with the highest confidence is marked as the target scene template. The group profile building module constructs group profiles for electronic bus stop signs; The demand sorting and push module matches and sorts demands based on target scenario templates and group profiles, and pushes the sorted demands in order on the bus electronic bus stop sign.

2. The smart city bus stop electronic sign dynamic information precise push system according to claim 1, characterized in that, The four-dimensional raw data includes time dimension data, spatial dimension data, event dimension data, and group behavior dimension data.

3. The smart city bus stop electronic sign dynamic information precise push system according to claim 1, characterized in that, The process of performing multi-dimensional cross-validation on four-dimensional features is as follows: compare the four-dimensional features with all scene templates in the bus stop scene template library, match the "four-dimensional feature rules" of each scene template item by item, and output: the number of matching dimensions for each scene template; When feature comparison results in "dimensional feature contradictions", it is determined to be a "conflict scenario". For identified conflict scenarios, a "multi-source data cross-validation" mechanism is activated, auxiliary data is called, and relevant data are automatically associated according to the conflict type. If the auxiliary data supports the "reasonableness of conflict features", the "conflict is resolved"; otherwise, the "conflict is valid" is confirmed.

4. The smart city bus stop electronic sign dynamic information precise push system according to claim 1, characterized in that, Confidence scoring: A rule-based scoring system of "base score + extra score - conflict penalty" is adopted; Base score: A score is awarded for each successfully matched dimension; Bonus points: If the event dimension or group behavior dimension matches, an additional B point will be awarded; Conflict deduction: C points are deducted for each valid conflict; D points are recovered after the conflict is resolved.

5. The smart city bus stop electronic sign dynamic information precise push system according to claim 1, characterized in that, The requirements are ranked using a "three-dimensional weighted evaluation method," with the three dimensions including urgency, frequency, and universality.

6. The smart city bus stop electronic sign dynamic information precise push system according to claim 5, characterized in that, Three-dimensional evaluation rules: Urgency: The degree of impact of delayed demand fulfillment, including high urgency, medium urgency, and low urgency; High frequency includes high-frequency, mid-frequency, and low-frequency. Universality can be categorized into high universality, medium universality, and low universality.

7. A method for accurately pushing dynamic information from electronic bus stop signs in smart cities, applied to the method for accurately pushing dynamic information from electronic bus stop signs in smart cities as described in any one of claims 1-6, characterized in that, The steps are as follows: S1: Four-dimensional data acquisition and template library construction; S2: Four-dimensional feature standardization and target scene template recognition; S3: Group Profile Construction; S4: Demand matching, sorting, and information push.

Images