Recommendation method based on urban tourism data

Abstract

The invention discloses a recommendation method based on urban tourism data. The recommendation method comprises the following steps: S1, configuring an urban label library; s2, establishing an association table of cities and labels, and realizing many-to-many relation mapping; s3, the user screens urban tags from the tag library, and the front end sends tag information selected by the user to a back-end server; and S4, after the back-end server receives the labels screened by the user, querying all cities bound with the labels according to the association table of the cities and the labels, and the like. According to the method, the problem that an existing platform lacks urban tourism resource feature abstraction ability is solved by configuring a multi-dimensional urban label library covering seasons, natural scenes, cognition and the like and storing the urban label library through structured fields such as label IDs, names, classifications and the like. The standardized label system enables tourism attributes of cities to be clearly defined and retrieved, and lays a foundation for accurate recommendation.

Description

Technical Field

[0001] This invention relates to the field of urban tourism data technology, specifically to a recommendation method based on urban tourism data. Background Technology

[0002] In tourism service scenarios, users often need to filter target tourist cities based on specific interest dimensions (such as summer retreats, study tours, and cultural experiences). However, current mainstream tourism platforms (such as Ctrip, Dianping, and Meituan) have the following shortcomings: On the one hand, they lack the ability to abstract the characteristics of urban tourism resources and construct a city tagging system, failing to abstract urban tourism attributes into tags according to major categories such as season, natural scenery, and perception; on the other hand, they also lack the function of accurately filtering cities based on users' selected interest tags. For example, in summer, when users have a need to escape the heat, although there are many cities in Guizhou and Yunnan that combine summer retreat advantages with abundant attractions, users cannot efficiently filter these cities through existing platforms. They can only focus on popular areas such as western Sichuan, which may face traffic congestion and other problems, severely restricting the efficiency and experience of users in selecting tourist cities. Summary of the Invention

[0003] The purpose of this invention is to overcome the shortcomings of current tourism platforms, which not only lack the ability to abstract the characteristics of urban tourism resources and construct an urban tag system, but also lack the function of accurately filtering cities based on user-selected interest tags, and to provide a recommendation method based on urban tourism data.

[0004] The objective of this invention is achieved through the following technical solution: a recommendation method based on urban tourism data, comprising the following steps: S1. Configure the city tag library; S2. Establish a table linking cities and tags to achieve a many-to-many relationship mapping; S3. Users select city tags from the tag library, and the front end sends the user's selected tag information to the back end server. S4. After receiving the user's selected tags, the backend server queries all cities that are bound to these tags based on the city-tag association table. S5. The backend returns the retrieved city tourism data to the frontend. The frontend renders a list of cities based on this data and displays the binding reason for the user's selected filter tag under each city entry. S6. After the user clicks on the corresponding city in the city list, the front end sends the city ID and requested detailed information about the city to the back end. The back end retrieves the corresponding detailed data from the city information table based on the city ID and returns it to the front end, which then renders the city page.

[0005] As a preferred embodiment, the city tag library is a relational database, which consists of tag tables, each of which contains at least a tag ID, a tag name, and a tag category.

[0006] Furthermore, the association table mentioned in step S2 includes at least: City ID, which is a unique identifier for the associated city information table; Tag ID, which is a unique identifier for the associated tag library; Association Weight, which is used to quantify the degree of matching between the city and the tag; and Binding Reason, which describes the association logic between the city and the tag in text.

[0007] The "user filters city tags from the tag library" mentioned in step S3 includes at least four components: tag display, function filtering, interactive feedback, and data transmission. The tag display is presented in the form of tag groups, which supports collapsing and expanding. The function filtering includes tag search and visualization of selected tags. The interactive feedback is used to provide real-time prompts when selecting tags. The data transmission is used so that after the user confirms the filtering, the front end sends the list of selected tags to the back end via HTTP / HTTPS requests.

[0008] When "querying out all cities that are bound to these tags" in step S4, a joint index is created in the tag ID and city ID fields of the associated table, and the query results of high-frequency tag combinations are cached in the storage database.

[0009] Compared with the prior art, the present invention has the following advantages and beneficial effects: (1) This invention solves the problem of existing platforms lacking the ability to abstract the characteristics of urban tourism resources by configuring a city tag library covering multiple dimensions such as seasons, natural scenes, and cognition, and storing it with structured fields such as tag ID, name, and category. This standardized tag system allows the tourism attributes of a city to be clearly defined and retrieved, laying the foundation for accurate recommendations.

[0010] (2) This invention utilizes an association table containing city ID, tag ID, association weight, and binding reason to achieve deep many-to-many binding between cities and tags. The association weight can quantify the degree of matching, avoiding fuzzy recommendations; while the binding reason strengthens the association between cities and tags from a logical perspective. Compared with the generalized recommendations of existing platforms, it can more accurately filter out cities that simultaneously meet multiple user interest dimensions.

[0011] (3) The front end of the present invention displays tags in a collapsible tag group, and with the help of search, selected tag visualization and real-time interactive feedback, it lowers the threshold for users to filter; the back end accelerates the query through the joint index and caches the results of high-frequency tag combination, which greatly shortens the response time.

[0012] (4) The front end of this invention displays the binding reasons for the user's selected tags in the city list, allowing the user to intuitively understand "why the city meets the requirements". This transparent display solves the problem of existing platform recommendations "only giving results without giving reasons", helping users to make reasonable choices quickly and reducing decision-making hesitation.

[0013] (5) This invention constructs a complete recommendation process, from users filtering tags and obtaining a list of matching cities, to viewing the reasons for binding to assist in decision-making, and then clicking to enter the city details page to obtain in-depth information. Compared with the existing platform mode that requires users to switch between different pages to find information, this invention achieves efficient connection between needs and information, and significantly improves the overall experience of users choosing tourist cities. Attached Figure Description

[0014] Figure 1 This is a schematic diagram of the overall process of the present invention. Detailed Implementation

[0015] The present invention will be further described in detail below with reference to embodiments, but the implementation of the present invention is not limited thereto.

[0016] Example

[0017] like Figure 1 As shown in the figure, the recommendation method based on urban tourism data described in this embodiment includes six steps, S1 to S6. S1 involves configuring the urban tag library. This urban tag library is preferably implemented using a relational database, and it consists of several tag tables, each containing at least a tag ID, a tag name, and a tag category.

[0018] The aforementioned tag ID is a unique identifier for the tag throughout the entire system. It is the "low-level language" for the computer system to identify and process tags. It does not depend on the tag name, ensuring that each tag can be accurately located in the database, related tables, interface transmission, and other links without confusion.

[0019] The tag name, or "display name," directly conveys the core meaning of the tag to users and operators, allowing them to immediately understand the city characteristics it represents, such as "summer resort," "historical capital," or "family-friendly park." This embodiment prioritizes using short Chinese phrases for naming.

[0020] Tag category refers to the "group" to which a tag belongs. It is used to classify and group scattered tags to establish a hierarchical or dimensional system of tags, making the tag library a structured system. For example, tags can be grouped according to dimensions such as "seasonal demand," "natural landscape," and "cultural attributes." This makes it convenient for operators to manage tags and for users to find target tags by category. In this embodiment, the "category ID + category name" method is preferred for management. The "tag category" field in the tag table is associated with the category ID or directly stores the category name.

[0021] For example, when a user opens the filtering interface, the front end first queries the "tag categories" and displays several major tag groups such as "seasonal needs", "cultural attributes", and "natural landscapes". After the user clicks on the "seasonal needs" group, specific tags such as "summer retreat" and "winter retreat" under this category are loaded (the names are associated with the tag IDs). The entire filtering process is clear and efficient.

[0022] S2. Establish a relationship table between cities and tags to achieve a many-to-many relationship mapping. The relationship table should include at least: City ID, a unique identifier for the associated city information table; Tag ID, a unique identifier for the associated tag library; Relationship weight, used to quantify the matching degree between the city and the tag; and Binding Reason, which describes the relationship logic between the city and the tag in text.

[0023] The city ID and tag ID are the core of the association. The city ID directly links to the city information table, storing information such as city name, geographical location, and basic descriptions, while the tag ID directly links to the tag library in step S1. These two fields combine to form a "composite identifier" for the association table, ensuring that each association is unique. Through this design, a city can be associated with multiple tags through multiple records; for example, Qingdao can be associated with "seaside," "beer culture," and "summer resort." Conversely, a tag can also be associated with multiple cities; for example, "seaside" can be associated with Qingdao, Dalian, and Xiamen, thus achieving a flexible "many-to-many" mapping.

[0024] The aforementioned association weight is a "precision scale" for quantifying the degree of matching. This association weight is a numerical value ranging from 1 to 10, used to represent the matching strength between a city and a label. For example, Sanya's weight for the "seaside" label might be 10 points; Hangzhou's weight for the "West Lake" label might be 9 points; Beijing's weight for the "historical capital" label might be 10 points, while its weight for the "summer resort" label might only be 3 points (due to the hot summer and low matching degree).

[0025] The stated reasons for the association serve as a "transparent basis" for explaining the association logic. These reasons, described in natural language, explain the specific reasons for the association between a city and a tag, and are key to enhancing user trust. For example, the reason for Qingdao's association with the "seaside" tag is: "It boasts more than 10 seaside scenic spots, including Golden Beach and Shilaoren Beach." Similarly, the reason for Xi'an's association with the "historical capital" tag is: "As the capital of thirteen dynasties, it possesses world-class historical sites such as the Terracotta Army and the Big Wild Goose Pagoda."

[0026] This content directly supports the front-end display of step S5, allowing users to intuitively see "why this city meets my filtering criteria" in the city list. This solves the pain point of traditional recommendations that "only give results without reasons" and helps users make quick decisions.

[0027] S3. Users select city tags from the tag library, and the front end sends the user's selected tag information to the back end server.

[0028] In this step, users can access the tag library through the front-end interface (such as an app or webpage) and select tags of interest using filtering controls provided on the interface, including but not limited to drop-down menus and checkboxes. The front-end then sends the user-selected tag information to the back-end server via a wireless network.

[0029] The process of users selecting city tags from a tag library includes at least four parts: tag display, function filtering, interactive feedback, and data transmission. The tag display is in the form of tag groups, which can be collapsed and expanded; the function filtering includes tag search and visualization of selected tags; the interactive feedback provides real-time prompts when tags are selected; and the data transmission is used when the front-end sends the list of selected tags to the back-end via HTTP / HTTPS requests after the user confirms the selection.

[0030] S4. After receiving the user's selected tags, the backend server queries all cities that are bound to these tags based on the city-tag association table. In this embodiment, when querying all cities bound to these tags, a composite index is first created in the tag ID and city ID fields of the association table, and the query results of high-frequency tag combinations are cached in the storage database.

[0031] S5. The backend returns the retrieved city tourism data to the frontend. The frontend then renders a list of cities based on this data and displays the binding reason for the user's selected filter tag under each city entry.

[0032] The city data retrieved by the backend includes basic city information, associated tags, and corresponding reasons. After the backend returns this information to the frontend, the frontend renders a list of cities based on this data, displaying the reasons associated with the user's selected filter tags under each city entry. The frontend can use frameworks such as React or Vue to implement dynamic data rendering, improving page responsiveness and interactivity. Alternatively, a card-style layout can be used for display, with each card showing the city name, main tags, and a summary of the corresponding reasons for quick browsing.

[0033] S6. After the user clicks on the corresponding city in the city list, the front end sends the city ID and requested detailed information about the city to the back end. The back end retrieves the corresponding detailed data from the city information table based on the city ID and returns it to the front end, which then renders the city page.

[0034] The city page display needs to integrate various data, including basic city information and attraction details. The front-end page should comprehensively showcase the city's tourism resources, enhancing the user's browsing experience. Depending on the needs, features such as image carousels and categorized attraction displays can also be added to the front-end page.

[0035] As described above, the present invention can be well implemented.

Claims

1. A recommendation method based on urban tourism data, characterized in that, Includes the following steps: S1. Configure the city tag library; S2. Establish a table linking cities and tags to achieve a many-to-many relationship mapping; S3. Users select city tags from the tag library, and the front end sends the user's selected tag information to the back end server. S4. After receiving the user's selected tags, the backend server queries all cities that are bound to these tags based on the city-tag association table. S5. The backend returns the retrieved city tourism data to the frontend. The frontend renders a list of cities based on this data and displays the binding reason for the user's selected filter tag under each city entry. S6. After the user clicks on the corresponding city in the city list, the front end sends the city ID and requested detailed information about the city to the back end. The back end retrieves the corresponding detailed data from the city information table based on the city ID and returns it to the front end, which then renders the city page.

2. The recommendation method based on urban tourism data according to claim 1, characterized in that, The city tag database is a relational database, which consists of tag tables. Each tag table contains at least a tag ID, a tag name, and a tag category.

3. The recommendation method based on urban tourism data according to claim 1, characterized in that, The association table mentioned in step S2 includes at least the following: City ID is a unique identifier for the associated city information table; Tag ID is a unique identifier for the associated tag library; Association weights are used to quantify the degree of matching between cities and tags; The reason for binding is to describe the logic of the association between the city and the tag through text.

4. The recommendation method based on urban tourism data according to claim 1, characterized in that, The "user filters city tags from the tag library" mentioned in step S3 includes at least four components: tag display, function filtering, interactive feedback, and data transmission. The tag display is in the form of tag groups, which supports collapsing and expanding. The function filtering includes tag search and visualization of selected tags. The interactive feedback is used to provide real-time prompts when selecting tags. After the user confirms the selection, the front end sends the list of selected tags to the back end via an HTTP / HTTPS request.

5. The recommendation method based on urban tourism data according to claim 4, characterized in that, When "querying out all cities that are bound to these tags" in step S4, a joint index is created in the tag ID and city ID fields of the associated table, and the query results of high-frequency tag combinations are cached in the storage database.

Images