CN101916270A - 旅游导航与救援系统服务器端的设计与实现 - Google Patents
旅游导航与救援系统服务器端的设计与实现 Download PDFInfo
- Publication number
- CN101916270A CN101916270A CN2010102484824A CN201010248482A CN101916270A CN 101916270 A CN101916270 A CN 101916270A CN 2010102484824 A CN2010102484824 A CN 2010102484824A CN 201010248482 A CN201010248482 A CN 201010248482A CN 101916270 A CN101916270 A CN 101916270A
- Authority
- CN
- China
- Prior art keywords
- information
- server
- terminal
- scenic spot
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
本发明设计和完成了一个旅游导航与救援系统服务器端的设计与实现。系统由四部分构成,分别是:服务器端与终端通信机制的实现、终端信息的分类存储、查询和管理、位置搜索和路径导航。实现服务器端与终端的相互通信,完成了相关信息的接收与发送;实现了终端信息的分类存储,包括注册信息、登录信息、位置信息、查询信息和求援信息。针对特定信息能够进行回复;实现了景区信息的查询与管理,在电子地图中显示景区游客的位置及运动轨迹;能够直观的观察各个景区的游客分布情况以及景区中求援游客的情况。管理者能够查看特定游客的位置以及在景区中的游览轨迹。利用关键词匹配技术,实现基于网站电子地图的位置搜索功能。基于改进的最短路径算法,实现电子地图路径推荐功能。为普通的浏览器用户提供位置搜索和路径导航功能。该系统实时性强,具有很高的应用价值。
Description
技术领域
本发明属于旅游信息化领域,具体涉及服务器端与终端通信机制的实现、终端信息的分类存储、查询和管理、位置搜索和路径导航等。
背景技术
手机导航技术结合了实际全球卫星定位技术(GPS)和地理信息技术(GIS)技术,GIS作为获取、整理、分析和管理地理空间数据的重要工具,近年来得到了广泛关注和迅猛发展。手机导航的特色是用手机作为导航软件的硬件平台,在手机上运行导航软件。通过外置或者内置的GPS接收器接收卫星信号把位置数据传送给手机导航软件,通过导航软件确定使用者的当前位置和导航功能等。
各大门户搜索网站一般都提供电子地图功能。随着网络、通信和GPS等信息技术的发展,网络地图的应用日益广泛。全球著名的搜索引擎相继在国内强势推出地图搜索服务,如谷歌、雅虎、搜狐等,国内门户网站和搜索引擎也相继跟进,如新浪、百度等,电子地图技术被推向了应用的高峰。
旅游导航与救援系统服务器端充分利用景区现有的软硬件资源,结合GPS、移动通讯技术、GIS、影像监控与模式识别技术、数据加密传输技术和Internet互联网等现代高新技术,使复杂多变的旅游信息能够实时地交互、分析、显示和发布,实现了旅游资源的预警和调度以及对特殊人员的定位监控和突发事件的应急管理。
本发明旨在设计并实现一个能与具有GPS接收和GPRS通信功能的终端进行交互的平台,为景区管理者提供了解景区游客情况的媒介,同时为景区游客提供基于网站电子地图的位置搜索和路径推荐功能。
发明内容
本发明设计并完成了一个旅游导航与救援系统服务器端的设计与实现。系统由四部分构成,分别是:服务器端与终端通信机制的实现、终端信息的分类存储、查询和管理、位置搜索和路径导航。
(1)服务器端与终端通信机制的实现。利用GPRS网络和计算机互联网作为通信链路,实现服务器端与终端的相互通信,在服务器端建立socket服务器,完成连接的建立和相关信息的接收与发送。
(2)终端信息的分类存储。利用关键词匹配技术和.NET数据库技术,实现终端信息的分类存储,包括注册信息、登录信息、位置信息、查询信息和求援信息。针对特定信息,如查询信息和登录信息等,能够进行回复。
(3)查询和管理。结合网站电子地图,实现景区信息的查询与管理,利用MapXtreme控件技术,完成电子地图操作,并在电子地图中显示景区游客的位置及运动轨迹;利用web chart控件,在.NET页面中显示景区游客分布信息。管理者能通过浏览器访问服务器的数据库,通过页面能够直观的观察各个景区的游客分布情况以及景区中求援游客的情况。在载有电子地图的页面中,管理者能够查看特定游客的位置以及在景区中的游览轨迹。管理者能够查看并管理注册用户的信息,添加或删除新的系统用户。
(4)位置搜索和路径导航。利用关键词匹配技术,实现基于网站电子地图的位置搜索功能,基于改进的最短路径算法,实现电子地图路径推荐功能。普通用户通过浏览器访问服务器可以在电子地图页面中搜索特定位置,并且能获得两个地点之间的最短路径。为普通的浏览器用户提供位置搜索和路径导航功能。普通用户通过浏览器访问服务器可以在电子地图页面中搜索特定位置,并且能获得两个地点之间的最短路径。
附图说明
图1为系统整体结构;
图2为服务器端与终端交互模块;
图3为面向连接套接口应用程序时序图;
图4为服务器交互功能流程;
图5为短信功能模块;
图6为读取信息流程;
图7为信息发送流程;
图8为非格式化短信自动回复流程;
图9为查询管理模块;
图10为景区总览工作流程;
图11为景区人数详情工作流程;
图12为位置搜索模块。
具体实施方式
本发明利用GPRS网络和计算机互联网作为通信链路,实现了服务器端与终端的相互通信,在服务器端建立socket服务器,完成连接的建立和相关信息的接收与发送。用户能够通过移动终端完成位置确定与路径导航,并且能够通过终端与系统的服务器进行连接,因此旅游导航与救援服务器端应具有接收终端信息的功能,并且对信息能够进行回复。服务器把接收到的终端信息存储到数据库中,景区管理者能通过浏览器访问服务器,查询数据库中的信息,服务器提供基于WEB的位置搜索和路径推荐功能。系统由四部分构成,分别是服务器端与终端通信机制的实现、终端信息的分类存储、查询和管理、位置搜索和路径导航。系统结构如图1所示。
1.服务器端与终端通信机制的实现
旅游导航与救援系统服务器端具有的功能如下:
●与移动终端通信功能,接收终端发送的信息,如位置信息、求援信息等,并在数据库的相应表中进行存储;
●为景区管理者提供景区信息查询功能,主要是景区中持有移动终端的游客的信息,包括景区游客分布情况、相应游客位置信息、游客求援信息等;
●基于WEB的电子地图功能,能够完成特定位置的搜索和两点间路径的推荐。
1.1系统总体设计
服务器端提供与终端的功能、通过WEB对数据库中信息的查询管理功能以及WEB端的搜索导航功能。通过建立Socket服务器来完成信息的接收、处理和存储以及对终端信息的回复,这个过程需要数据库系统的支持。系统还包括一个短信收发模块,该模块主要针对系统的求救和救援功能,它依托终端(手机或PDA)的短信功能,通过短信的形式与带有应用程序的终端用户交互,接收和回复用户发送的求援信息,这部分也需要数据库系统的支持。基于WEB的数据库信息查询管理使管理者可以通过浏览器查询管理数据库中的信息。数据库的信息分为景区和游客信息两部分,这功能只对服务器的管理人员开放。WEB端的搜索导航功能是对普通用户开放的,提供位置搜索和路径推荐功能。
系统是一个与终端交互的平台,提供基于web的查询管理功能,服务器数据库系统是实现各种功能的基础,其它模块在工作过程中都必须和数据库进行交互。其它模块包括:
●服务器与终端进行交互的模块,该模块不仅要完成通信连接的建立,在此之后,按照接收到的信息的格式完成对信息的存储,这些信息包括终端的注册信息、登录信息、位置信息、求援信息等,另外服务器与终端通过短信的方式进行通信的功能也在该模块中完成;
●查询管理功能模块,该模块主要向景区管理者开放功能,分为景区总览、景区游客信息、景区人数详情、景区评分详情和景区求援信息详情模块;
●电子地图模块,该模块向普通浏览器用户开放,提供位置检索和路径推荐功能。
1.2服务器端数据库设计
数据库中存储的信息可以分为两类:关于景区的静态信息和关于游客的动态信息。静态信息中包括景区相关的信息和一个用于匹配终端查询信息的关键词词库,以便能准确的回复终端发送来的问题。静态信息主要存储终端用户的信息,首先是用户注册信息,当终端选择使用应用程序进行连接时,在建立连接后必须先进行注册,才能继续使用以下的功能,用户注册信息库用于存储用户注册时向服务器发送的信息;用户位置信息用来存储终端发送来的位置信息,以便完成对终端的定位;用户求援信息用于存储终端发送来的求援信息。动态信息库中会涉及到信息的插入、更新和删除,由访问数据库的其他模块来完成。
2.终端信息的分类存储
利用关键词匹配实现终端信息的分类存储,包括注册信息、登录信息、位置信息、查询信息和求援信息。针对特定信息,如查询信息和登录信息等,能够进行回复。该模块主要完成服务器端与终端连接的建立和终端信息的处理,由于终端向服务器发送的信息中包括:注册登录信息、终端位置信息、终端查询信息和终端求援信息,总体结构如图2。
图2中服务器端与终端交互模块可以细分为:通信链路建立、终端注册登录、信息分类、位置信息处理、查询信息处理和求援信息处理六个子模块。通信链路建立模块用于建立终端与服务器之间的初始链路;终端注册、登录模块用来确认用户的合法性,若终端用户以前已经注册过,在经过登录验证后,可以继续使用系统其他的功能,若终端用户是第一次注册,则终端注册、登录模块负责向数据库中存储注册信息;针对已经成功登陆的用户,它们发送的信息会被信息分类模块处理,该模块根据规定的信息格式,判断用户发送的是位置信息、查询信息还是求援信息,并根据结果将它们传递到不同的模块进行处理;位置信息处理模块对终端用户发送的位置信息进行处理,将它们存储的相应的数据库中,并对数据库信息进行更新;查询信息处理模块将终端用户发送的查询信息与关键词词库进行比较,匹配后将答案再回复给终端用户,同时将终端发送的查询信息存储到数据库中;求援信息处理模块主要处理用户发送的求援信息,完成信息的存储和回复。
2.1通信链路的建立
在服务器端建立Socket服务器接收终端通过GPRS网络、互联网络传送来的信息,它依据TCP协议,能够提供双向的、有序的、无重复并且无记录边界的数据流服务。面向连接的SOCKET的工作时序图3。
用户通过浏览器确定自己的位置或通过智能终端查询景区相关信息、与服务器交互获得救援信息等,首先要完成服务器与终端的通信功能。终端首先通过GPRS网络接入互联网,然后连接作为服务器的特定主机,为了与终端建立连接,选定的主机要建立SOCKET服务器。为了适应多用户的需求,可以为每个用户分别建立一个线程,从而使每个用户在互相不干扰的情况下完成与服务器的交互。按照Socket的工作时序建立socket侦听,并创建相应的监听线程,当有用户连接时,为每个用户建立一个用户建立一个线程,并用参数来区分它们。
2.2与应用程序通信
服务器只与在服务器上注册过的终端用户进行信息交互,拥有用户名和密码的用户在进行用户合法性验证后,与服务器建立连接,若终端用户选择向服务器发送的数据中包含GPS信息(即终端用户的经度、纬度),表示终端用户要求服务器对自身的位置进行记录,则服务器应该把接收到的位置信息存储到数据库中。同时服务器也能接收终端发送的查询请求并对其进行处理然后回复,如终端用户查询所在地周围的景点信息,则服务器根据用户的当前位置以及所要搜索的关键字在数据库中进行查找,得到符合要求的结果后再将信息回复给终端。交互功能的工作流程如图4。
应用程序在启动时,要初始化与数据库的连接,以便应用程序在后面的步骤中与数据库进行交互。在终端成功连接服务器后,终端应用程序首先呈现给用户的是注册、登陆界面,用户填写登陆信息并向服务器发送,用户验证模块会对登录信息进行验证,与数据库中存储的信息进行比较,若信息错误便会提醒用户进行注册,如果用户选择进行注册则程序继续向下进行,如果用户选择退出,则程序终止。登录成功后,终端信息要经过信息分类模块,区分终端发送的信息是位置信息、查询信息还是救援信息,这根据信息的标识位来完成。
(1)位置信息的处理。位置信息处理时要注意数据库中是否已经存在终端用户的信息,即表中是否有终端的信息,是否有存储终端历史位置的表。信息已存在时,调用数据库操作语言对已存在的表和表中的信息进行更新;若信息不存在,特别是用户第一次注册然后登陆时,数据库中不存在存储终端历史位置的表,这时要调用数据库定义语言,来创建用户历史位置信息表。
(2)终端查询信息处理。该模块首先按照信息格式对关键词进行提取,然后与数据库存储回复信息的表的关键词字段进行匹配,然后将向终端返回信息的字符串的内容设置为查询到的内容,然后调用相关函数完成向终端信息的回复。
(3)求援信息处理。该模块完成求援信息的处理,求援信息中包括用户ID、求援级别、所处位置经纬度以及求援时间,将这些信息存储到数据库表的相应字段。
2.3短息通信模块
服务器端的短信功能模块完成终端用户求援信息接收与回复,终端的应用程序能够将求援信息拼接成固定格式的字符串,然后调用终端的短信功能,将信息发送到服务器指定的号码,终端发送的信息中应该包括用户的用户名、当前所在位置以及对当前处境的描述。服务器端的短信功能模块接收到信息后按照约定好的字符串格式对信息进行解析,得到用户的手机号码、用户名、所处位置、处境描述等信息,并将信息存入数据库中,同时按照解析后的信息在数据库中查询与之匹配的救援方案,然后参照救援方案的内容采取相应措施,如向最近的120、110平台发出求援信息,同时向终端发送应急方案。
对于没有安装应用程序的用户即普通的短信功能用户,服务器端的短信功能模块也提供了求援与救助功能,只要服务器端接收到的短信内容以Help开头,服务器便认为该短信为救助类型的短信,在接收到该类型的短信后,服务器先将短信号码提取出存入数据库,然后调用文本处理功能对短信内容进行关键字提取,在存入数据库的同时查询与关键字匹配的救援方案,然后进行与终端用户相同的操作,选择是否继续向有关救援平台发送求援信息,同时向对方短信号码发送应急方案。服务器端短信功能模块的工作流程如图5。
为了使求援短信得到及时的回复,设计了自动回复求援短信的功能。每隔15秒钟(可设置),系统检测是否有未处理的短信,若检测到未处理的短信,则取出短信内容,通过对短信内容的分析来确定应当如何回复短信。自动回复的短信内容是事先存储在数据库中的,依据收到的求援短信中危机程度、危机种类的不同来判断应该给出什么样的回复,从数据库中读出相应的短信内容,进行回复。
系统接收的求援短信可以分为两类,一类是由本系统的用户终端,按照系统规定的格式发来的;另一类则是没有使用系统的用户终端,即没有严格按照系统规定的格式生成的短信。对于这两类不同的短信,系统需要进行不同的处理。对于前者处理过程相对简单,发来的短信中,有系统规定的间隔符,依据这些间隔符,系统将短信内容分为不同的字段(危机种类、级别等),然后对每个字段进行判断,由判断结果确定要回复的内容;对于后者,由于无法按照格式进行字段的划分,就需要在整条短信内容中进行分词,以便找到可以对危机种类、危机程度进行判断的字词,从而决定回复的内容。
当启动定时器后,首先由暂存短信的域是否为空来判断是否有未读短信,当有短信未处理时,开始读取未读信息,其流程如图6所示。
获得未读信息后,首先通过函数使用split函数,以$为分隔符将字符串分割为4个字段,字段1标识了信息的危机等级;字段2标识了信息的危机种类;字段3是危机的具体描述;字段4则包含了信息发送的坐标、手机号码等。由上一流程所得危机种类和危机等级,可以写出SQL语句,在数据库中找到对应的处理方案,然后将处理方案写入回复信息中,最后将回复信息以pdu方式发送。发送流程如图7所示。
非格式化短信的自动回复流程如图8所示。
当接收到非格式化的短信时,先由短信是否由“H”字母开头来判断该短信是否是向系统发送的求助短信。确认之后,由于这种短信没有固定的格式,无法确认其携带的信息,因此需要对短信的内容进行中文分词,这是处理非格式化的短信的关键步骤。完成分词之后,即可在分出的词组中查找与危机种类、级别相关的描述。
3.查询和管理
结合网站电子地图实现景区信息的查询与管理,采用MapXtreme控件技术,完成电子地图操作,并在电子地图中显示景区游客的位置及运动轨迹;利用web chart控件,在.NET页面中显示景区游客分布信息。管理者能通过浏览器访问服务器的数据库,通过页面能够直观的观察各个景区的游客分布情况,以及景区中求援游客的情况。
该模块为景区管理者了解各景区内的游客情况提供一个平台,服务器管理员在以管理员的身份登录后,能够查询相关景区的信息,包括景区游客信息、游客分布信息以及求援游客信息等。该模块基于B/S结构来实现,分为三个层次,模块结构如图9。
该模块分为以下子功能模块:数据管理、景区总览、游客位置、景区人数、景区评分和求援信息。数据管理要承担管理员对数据库的管理功能,对数据库中动态信息的更新,由于游客位置信息、求援信息等会由服务器端与终端交互模块自动更新,因此管理员能够直接更新的信息大部分是注册用户的基本信息;景区总览模块向管理员提供景区信息,如景区介绍、景区天气等;游客位置模块能够提取数据库中存储的终端用户的位置信息,可以提供时限选择,显示在某一时刻的位置,或者在某一时间段内的行动轨迹;景区人数可以直观的向管理员展示各景区的人数分布情况,它的表现形式应该是一个能够表示分布情况的页面;景区评分模块反映游客对景区的反馈意见,它能够反映不同标准的得分情况,为管理者改善景区服务提供了有力的参考信息;求援信息模块能够从数据库中提取出终端发送的求援信息,求援信息将会以列表的形式显示出来,在选中某一条信息后,能够显示具体内容。、
3.1景区总览
景区总览功能能够使管理者查看所选择景区的概要信息,如当前景区的天气情况、景区简介,并从数据库中提取出当前景区注册终端用户的人数,该模块工作流程如图10。
3.2景区游客信息
该模块包括四个功能,首先进行景区选择,在选定景区后,能够统计该景区内注册终端用户的总数,查看指定用户的当前位置,查看指定用户在某个时间范围内的行踪。
3.3景区人数详情
根据服务器数据库中存储的信息,可以通过浏览器显示景区中持有具有与服务器通信功能的终端的用户在景区之间的分布情况以及单个景区中求援游客不同求援情况所占的比例。该模块工作流程如图11。
3.4景区评分详情
持有与服务器交互能力的终端的用户,可以把对景区的评价发送到服务器,评价标准可以根据当前旅游业的标准来制定,如市场信誉、环境保护、旅游交通等,服务器可以通过浏览器向管理者呈现游客反馈的信息,与景区人数详情功能类似,在显示景区评分详情的页面中也带有时间限制和区域限制的功能,在选择时间段和相应的景区后,页面中会显示特定时间段内某一区域的各景区评分情况,以及某一特定景区各个评分标准的得分情况。
3.5求援信息详情
该模块显示服务器数据库中的求援信息,即各个景区中求援游客的情况。该功能页面中提供了时间限制和区域、景区选择功能。在进入页面没有选择时间限制和特定景区的情况下,页面中将会显示数据库中存储的所有救援信息,包括求援用户ID、求援类型、求援等级和求援时间,若选择时间限制和特定景区,将会显示特定时间段内,某一特定景区的求援情况。
4.位置搜索和路径导航
利用关键词匹配技术,实现了基于网站电子地图的位置搜索功能,基于最短路径算法,实现了电子地图路径推荐功能。普通用户通过浏览器访问服务器可以在电子地图页面中搜索特定位置,并且能获得两个地点之间的最短路径。为普通的浏览器用户提供位置搜索和路径导航功能。普通用户通过浏览器访问服务器可以在电子地图页面中搜索特定位置,并且能获得两个地点之间的最短路径。
4.1位置搜索
该模块完成基于MapXtreme的位置搜索功能,即在基于浏览器的电子地图中为用户提供位置搜索功能,采用基于WEB的GIS技术和电子地图中的位置搜索技术,模块的构成如图12。
用户在浏览器中输入想要搜索的关键词,点击搜索按钮提交要求,服务器端关键词获取模块获取浏览器提交的关键词后,传递给数据处理模块,数据处理模块根据从地图数据服务器和SQLServer数据库中提取数据,对关键词进行整合,得到用户搜索的点在电子地图中的位置,然后将结果传递给结果显示模块,结果显示模块更新地图信息,对结果位置进行特殊处理,然后在浏览器窗口中向用户展示。
4.2路径推荐
若用户通过浏览器访问服务器,服务器可提供景区电子地图导航功能,即按照用户提供的起点和终点,利用最短路径算法对地图数据进行查找,得到最优路径推荐给用户,并且能够在电子地图中显示出推荐的路线。采用最短路径算法在电子地图导航中进行直接应用,或采用改进后的算法,在后台完成路径的搜索后,再显示在电子地图中。
4.3位置数据组织方式
路径导航根据点和边之间的关系来完成,点和点之间的关系表现为连接两点之间的边的权值。将点边的数据存储到数据库中以提高算法的工作效率。在的到点的位置信息后,必须知道点之间的关系,用表edges来存储它们之间的关系,即边的信息。
4.4数据提取方式
从数据库中提取出存储的点和边的信息,使其能被算法使用,分别定义了两个类EDGE、NODE分别表示边和点,将“有向边”抽象为EDGE类。
4.5算法实现过程
求出从始点到终点的最短路径,即始点到各顶点的最短路径。改进的最短路径算法的实现步骤如下:
第一步:初始化。V={1,2,…,N},S={F},D[I]=L[F,I],Y[I]=F,其中I=1,2,…,N。
F表示路径的始点,I表示某一顶点,N表示网络中所有顶点的数目,V是所有顶点的集合,L[F,I]表示从F点到I点的距离,S是顶点的集合,D为N个元素的数组用来存储顶点F到其它顶点的最短距离,Y为N个元素的数组用来存储最短路径中在顶点I之前经过的最近顶点。
第二步:从V-S集合中找一个顶点T使得D[T]是最小值,并将T加入到S集合中。如果V-S是空集合,则结束运算。
第三步:调整Y、D数组中的值:在V-S集合中对于顶点T的邻接各项点I,如果D[I]>D[T]+L[I,T],那么令Y[I]=T、D[I]=D[T]+L[I,T]。
继续执行第二步。
在应用最短路径算法时,在将图中的有向边赋予权值的同时,如果该边事双向的,则用两条方向相反的边来表示。
在计算的过程中,需要记录起始点到达每一个节点的最短路径,这里使用抽象类PathforNode来完成该功能,为了方便记录每个节点的PathforNode,建立抽象类Paths,它能够管理每一个节点的PathforNode。
该算法主要步骤如下:
(1)构建类Paths,其内部包括一个哈希表成员变量,用于记录所有节点的PathforNode,初始化该类时,如果源点能够直接连接到某节点,则该点的PathforNode的权值设为对应的边的权,否则设为double.MaxValue。
(2)选取没有被处理并且当前PathforNode中权值最小的节点N,根据其边的可达性,来更新与它相连的节点的路径和权值,即这些节点的PathforNode的Weight和ListofnodeID,注意只有当其他节点经此节点后PathforNode的权值变小才更新,否则不更新。然后标记几点N为已处理。
(3)重复(2),直至路网中所有能够可达的节点都被处理一遍。
(4)从Paths中获取目的点的PathforNode,即为源点和目标节点之间的最短路径上的点的集合。
4.6与电子地图的结合
通过浏览器在电子地图上显示出推荐的路径,先添加一个临时图层,然后在图层上进行点和边的操作,利用MapXtreme控件API添加临时图层。创建完临时图层后,利用循环在图层上添加轨迹,每次添加两点之间的一条边,因此循环的次数由历史点的个数来决定。在每次循环的结束需要把新创建的线图元插入临时图层。
Claims (5)
1.旅游导航与救援系统服务器端的设计与实现,其特征在于,该方法包括:
服务器端与终端通信机制的实现;
终端信息的分类存储;
查询和管理;
位置搜索和路径导航。
2.根据权利要求1所述的方法,其特征在于,利用GPRS网络和计算机互联网作为通信链路,实现了服务器端与终端的相互通信,在服务器端建立socket服务器,完成连接的建立和相关信息的接收与发送。
3.根据权利要求1所述的方法,其特征在于,利用关键词匹配技术和.NET数据库技术,实现了终端信息的分类存储,包括注册信息、登录信息、位置信息、查询信息和求援信息。针对特定信息,如查询信息和登录信息等,能够进行回复。
4.根据权利要求1所述的方法,其特征在于,结合网站电子地图,实现了景区信息的查询与管理,利用MapXtreme控件技术,完成电子地图操作,并在电子地图中显示景区游客的位置及运动轨迹;利用web chart控件,在.NET页面中显示景区游客分布信息。管理者能通过浏览器访问服务器的数据库,通过页面能够直观的观察各个景区的游客分布情况以及景区中求援游客的情况。在载有电子地图的页面中,管理者能够查看特定游客的位置以及在景区中的游览轨迹。管理者能够查看并管理注册用户的信息,添加或删除新的系统用户。
5.根据权利要求1所述的方法,其特征在于,利用关键词匹配技术,实现了基于网站电子地图的位置搜索功能,基于改进的最短路径算法,实现了电子地图路径推荐功能。普通用户通过浏览器访问服务器可以在电子地图页面中搜索特定位置,并且能获得两个地点之间的最短路径。为普通的浏览器用户提供位置搜索和路径导航功能。普通用户通过浏览器访问服务器可以在电子地图页面中搜索特定位置,并且能获得两个地点之间的最短路径。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2010102484824A CN101916270A (zh) | 2010-08-09 | 2010-08-09 | 旅游导航与救援系统服务器端的设计与实现 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2010102484824A CN101916270A (zh) | 2010-08-09 | 2010-08-09 | 旅游导航与救援系统服务器端的设计与实现 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101916270A true CN101916270A (zh) | 2010-12-15 |
Family
ID=43323782
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2010102484824A Pending CN101916270A (zh) | 2010-08-09 | 2010-08-09 | 旅游导航与救援系统服务器端的设计与实现 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101916270A (zh) |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102123346A (zh) * | 2011-03-09 | 2011-07-13 | 东莞市车友互联信息科技有限公司 | Gps终端即时通信方法及其实现系统和gps终端 |
CN102685660A (zh) * | 2011-03-14 | 2012-09-19 | 中国电信股份有限公司 | 实现路径查询的方法及手机浏览器 |
CN103716382A (zh) * | 2013-12-12 | 2014-04-09 | 北京理工大学 | 用于北斗导航搜救系统的基于xml的数据通信方法 |
CN106446242A (zh) * | 2016-10-12 | 2017-02-22 | 太原理工大学 | 一种高效的多关键词匹配最优路径查询方法 |
CN107122882A (zh) * | 2011-12-22 | 2017-09-01 | 英特尔公司 | 用于为大人群提供援助服务的方法和装置 |
CN109165310A (zh) * | 2018-06-29 | 2019-01-08 | 江苏恒宝智能系统技术有限公司 | 一种游客圈定方法 |
CN109428894A (zh) * | 2017-06-20 | 2019-03-05 | 深圳市小氪科技有限公司 | 一种云救援系统 |
CN111147457A (zh) * | 2019-12-12 | 2020-05-12 | 泰斗微电子科技有限公司 | 数据处理方法、装置、终端设备和服务器 |
CN111915040A (zh) * | 2020-08-05 | 2020-11-10 | 江苏经贸职业技术学院 | 一种旅游管理系统和模式 |
CN114840677A (zh) * | 2022-07-04 | 2022-08-02 | 南京华飞数据技术有限公司 | 面向多粒度需求的短文本分类与智能分析系统 |
-
2010
- 2010-08-09 CN CN2010102484824A patent/CN101916270A/zh active Pending
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102123346A (zh) * | 2011-03-09 | 2011-07-13 | 东莞市车友互联信息科技有限公司 | Gps终端即时通信方法及其实现系统和gps终端 |
CN102685660A (zh) * | 2011-03-14 | 2012-09-19 | 中国电信股份有限公司 | 实现路径查询的方法及手机浏览器 |
CN107122882A (zh) * | 2011-12-22 | 2017-09-01 | 英特尔公司 | 用于为大人群提供援助服务的方法和装置 |
CN103716382A (zh) * | 2013-12-12 | 2014-04-09 | 北京理工大学 | 用于北斗导航搜救系统的基于xml的数据通信方法 |
CN103716382B (zh) * | 2013-12-12 | 2017-02-22 | 北京理工大学 | 用于北斗导航搜救系统的基于xml的数据通信方法 |
CN106446242A (zh) * | 2016-10-12 | 2017-02-22 | 太原理工大学 | 一种高效的多关键词匹配最优路径查询方法 |
CN106446242B (zh) * | 2016-10-12 | 2019-10-25 | 太原理工大学 | 一种高效的多关键词匹配最优路径查询方法 |
CN109428894A (zh) * | 2017-06-20 | 2019-03-05 | 深圳市小氪科技有限公司 | 一种云救援系统 |
CN109165310A (zh) * | 2018-06-29 | 2019-01-08 | 江苏恒宝智能系统技术有限公司 | 一种游客圈定方法 |
CN111147457A (zh) * | 2019-12-12 | 2020-05-12 | 泰斗微电子科技有限公司 | 数据处理方法、装置、终端设备和服务器 |
CN111915040A (zh) * | 2020-08-05 | 2020-11-10 | 江苏经贸职业技术学院 | 一种旅游管理系统和模式 |
CN114840677A (zh) * | 2022-07-04 | 2022-08-02 | 南京华飞数据技术有限公司 | 面向多粒度需求的短文本分类与智能分析系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101916270A (zh) | 旅游导航与救援系统服务器端的设计与实现 | |
EP2428027B1 (en) | Refining location estimates and reverse geocoding based on a user profile | |
Calderoni et al. | Location-aware mobile services for a smart city: Design, implementation and deployment | |
US8265871B1 (en) | Mobile record information entry and geotagging | |
US8566325B1 (en) | Building search by contents | |
CN104115147B (zh) | 位置感知应用搜索 | |
CN104965847A (zh) | 信息展示方法及装置 | |
CN103443788A (zh) | 用于步行浏览的方法和装置 | |
WO2005052737A2 (en) | System and method of virtualizing physical locations | |
CN102016502A (zh) | 基于场境的语音识别语法选择 | |
CN106470216A (zh) | 一种基于信息共享、交互的内容管理系统 | |
JP4950508B2 (ja) | 施設情報管理システム、施設情報管理装置、施設情報管理方法および施設情報管理プログラム | |
CN104484462A (zh) | 一种企业信息获取方法及系统 | |
US20120011463A1 (en) | Method and System for Enabling Location Entry | |
CN102789508A (zh) | 基于地理位置的分布式实况搜索引擎及聊天系统 | |
US20090276398A1 (en) | Search server | |
CN104657448A (zh) | 一种基于移动gis的特种设备监管系统 | |
CN102721421A (zh) | 基于门户网站向车载导航终端推送信息的自动导航系统及方法 | |
CA2760624A1 (en) | Server, dictionary creation method, dictionary creation program, and computer-readable recording medium recording the program | |
CN103226567A (zh) | 旅行管理 | |
Shekhar et al. | From GPS and virtual globes to spatial computing-2020 | |
Korkmaz et al. | A smart school bus tracking system | |
CN105893396A (zh) | 基于附近位置来解释用户查询 | |
WO2014195922A1 (en) | Method and system for decision support in relation to geolocalization of a candidate's residence and workplace | |
CN101311678B (zh) | 手持式电子装置及其地图数据分享方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20101215 |