KR20180138114A - Method and Server Apparatus for Navigation Service Providing Unusable Route Information Related to Emergency Area - Google Patents

Abstract

Disclosed are a method and a server device for navigation service providing unusable route information of a disaster area. According to an aspect of the present embodiment, the method comprises the processes of: configuring a disaster area resource including unavailable path information to the disaster area; and receiving a travel parameter from a plurality of applications and transmitting a link to the disaster area volunteer so as to access an application having a request for providing unavailable path information to the disaster occurring area in the travel parameter, and the process of transmitting the link including transmitting the link to the disaster area volunteer so as to access the application having a request for providing unavailable path information for the same disaster occurring area.

Description

TECHNICAL FIELD [0001] The present invention relates to a navigation service method and a server apparatus for providing unusable route information of a disaster area,

The present embodiment relates to a navigation service method capable of providing unavailable route information of a disaster area and a server apparatus using the same.

The contents described in this section merely provide background information on the present embodiment and do not constitute the prior art.

Conventionally, a navigation terminal detects a current location, that is, a departure location through connection with a GPS (Global Positioning System), receives a travel destination from a user, and calculates a route on the terminal itself. However, due to the recent spread of smartphones and performance enhancement, a service method that provides route information, route-related real-time traffic information, and various information is provided from a server that provides traffic information and route information using PNDs (Personal Navigation Devices) .

In particular, while various types of navigation services are provided, the Open Mobile Alliance (OMA) standardization organization provides a method of transmitting TPEG (Traffic Protocol Expert Group) information in a DMB (Digital Multimedia Broadcasting) network, Navigation service for delivering real-time traffic information to P2P (peer-to-peer) through IP (Internet Protocol) based network of mobile communication network or wireless network is becoming popular. In OMA LOC WG, The service framework (NavSe) has been standardized.

The NavSe standard defines a framework to provide users with navigation and path information for vehicle navigation, route information for indoor navigation, and functions for emergency navigation services for mobile communication-based navigation services. In the NavSe standard, the route and traffic information for vehicle navigation uses the ISO-defined TPEG standard already used in the market, and the route information for indoor navigation uses the IndoorGML standard defined by OGC. IndoorGML is a standard for modeling indoor space for navigation purposes. NavSe standard provides standardized path and traffic information for users to receive indoor and outdoor navigation service through ISO TPEG and OGC IndoorGML standard technology.

In embodiments of the present invention, when a server provides information on unavailable roads in a disaster-hit area in a mobile communication-based navigation service, a navigation device that calculates a route itself can calculate routes efficiently And to provide a navigation service method and a server device for facilitating provision of update information when information on additional unusable roads is collected.

According to an aspect of the present invention, there is provided a method of providing path information on a disaster-causing area to a terminal capable of path calculation, the method comprising the steps of: configuring a disaster area resource including unusable path information on the disaster- And transmitting a link capable of accessing the disaster area resource to an application that receives the travel parameter from the plurality of applications and requests the unavailable path information to the disaster area in the travel parameter, Transmits a link capable of connecting to the same disaster area resource to applications having a request for providing unusable path information for the same disaster occurrence area.

Embodiments of the method may further include one or more of the following features.

In the process of constructing the disaster area resource, the unusable path information that is not currently available for the disaster occurrence area and the unusable path information that is expected to be unavailable in the future can be configured.

The method includes receiving a subscription request from an application for a notification service associated with the disaster area; And notifying updated application unavailable path information to the application that received the subscription request for the notification service when the unavailable path information is updated.

Wherein the unusable path information includes at least one unusable path information that is not currently available for the disaster area and unusable path information that is expected to be unusable in the process of configuring the disaster area resource, The process of notifying the information may transmit a notification message including the id of the anticipated unavailable route information when the anticipated unavailable route becomes a route that is not actually available.

In the process of notifying the application of the updated unusable route information, when receiving the current location from the application approaching the disaster occurrence area, the updated route information can be notified to the application.

The method may further include transmitting a location of the disaster area related to the travel parameter to the application when the travel parameter does not include the route information providing request for the disaster occurrence area.

According to an aspect of the present invention, there is provided a server apparatus for providing path information on a disaster-hit area to a terminal capable of path calculation, the server apparatus for providing path information on a disaster- A communication unit configured to communicate; And a controller configured to provide traffic information on a route received from the terminal, wherein the controller configures a disaster area resource including unavailable route information for a disaster occurrence area, And transmits a link to access the disaster area resource to the application having the unusable path information providing request for the disaster occurrence area in the travel parameter, And transmits a link to access applications to the same disaster area resource.

As described above, according to the embodiments of the present invention, it is possible to provide a navigation device capable of calculating a path itself in a mobile communication-based navigation service, providing road state information of a disaster-affected area in a situation of an emergency such as a disaster, So that it is possible to calculate the route by using it.

In addition, according to embodiments of the present invention, resource usage of a service server can be reduced through common resource creation and utilization. It is possible to quickly acquire the unusable route information from the user and to provide the unusable route information to other users.

In addition, when new unavailable route information is generated to a user subscribed to the notification service, the server can be notified immediately and the number of server connection can be reduced, thereby preventing server congestion and stably operating the server.

1 is a network configuration diagram for explaining a NavSe system as a navigation system of the present invention.
2 is a diagram showing a resource structure defined in the NavSe standard.
3 is a diagram illustrating a structure of resources for providing unavailable path information for a disaster area according to an embodiment of the present invention.
4 is a flowchart illustrating a process in which an application requests and receives unavailable path information from a server according to an exemplary embodiment of the present invention.
5 is a flowchart illustrating operations of an application and a server according to an exemplary embodiment of the present invention.
6 is a flowchart illustrating an operation of an application and a server according to another embodiment of the present invention.
7 is a block diagram of a terminal and a server configured to implement embodiments of the present invention.

Hereinafter, some embodiments of the present invention will be described in detail with reference to exemplary drawings. It should be noted that, in adding reference numerals to the constituent elements of the drawings, the same constituent elements are denoted by the same reference symbols as possible even if they are shown in different drawings. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear.

In describing the components of the present invention, terms such as first, second, A, B, (a), and (b) may be used. These terms are intended to distinguish the constituent elements from other constituent elements, and the terms do not limit the nature, order or order of the constituent elements. Throughout the specification, when an element is referred to as being "comprising" or "comprising", it means that it can include other elements as well, without excluding other elements unless specifically stated otherwise . In addition, '... Quot ;, " module ", and " module " refer to a unit that processes at least one function or operation, and may be implemented by hardware or software or a combination of hardware and software.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The following detailed description, together with the accompanying drawings, is intended to illustrate exemplary embodiments of the invention and is not intended to represent the only embodiments in which the invention may be practiced.

Refer to the OMA-TS-REST_NetAPI_NavSe-V1.0, and OMA-ER-NavSe-V1.0 standard documents accessible at http://member.openmobilealliance.org/ftp/Public_documents/LOC/Permanent_documents/ at the time of filing. Quot ;, which is hereby incorporated by reference in its entirety as if fully set forth herein.

Hereinafter, terms used in this specification will be defined.

In this specification, an application refers to an implementation of a well-defined but non-standardized set of functions that perform tasks on behalf of a user. The application may comprise software and / or hardware components and associated user interfaces.

Generally, in the art to which the present invention pertains, a server corresponds to an entity that provides resources to clients in response to requests.

In general, in the art to which the present invention pertains, a client corresponds to a device, user agent or other entity that acts as a receiver of the service.

In this specification, a NavSe application (NavSe Application) corresponds to an entity responsible for interacting with the server to obtain route information, real-time and anticipated traffic information in the future. Accordingly, the NavSe application is installed in a terminal including a smart phone, a mobile phone, a navigation device, and the like, and thus, in this specification, a NavSe application can be referred to as a terminal, a NavSe client (NavSe Client) interchangeably. In this regard, the NavSe application is a kind of client.

In this specification, a NavSe server corresponds to an entity responsible for providing path information, real time, and future expected traffic information to a NavSe application. In this regard, the NavSe server is a kind of server.

In this specification, a location URI corresponds to a URI such that the current location of the device is obtained from the specific location server using a protocol for obtaining the location.

In this specification, a navigation device (ND) corresponds to an entity that assists the driver in using the Global Navigation Satellite System (GNSS) service to show the correct route to reach the final destination. This entity can process real-time and predicted traffic information according to user preferences and dynamically estimate the optimal path.

In this specification, a lightweight ND (ND) is a navigation device that does not have a function for route calculation and requests and receives a route calculated from a server. If a local map database is not available, It corresponds to a navigation device that accesses the server to retrieve the road shape representation.

In this specification, a Smart ND corresponds to a navigation device that can calculate the route (s) using a road network database available in the device itself.

In this specification, a point of interest (POI) describes information about locations such as a name, a category, a unique identifier, or a city address.

In this specification, a continuous road between an intersection and an intersection is referred to as a segment on an ordinary road, and a road is defined as a segment on a highway according to the policy of each highway. Traffic congestion and transit time can be determined on a segment basis. In this specification, segments are used interchangeably with road segments.

In this specification, a Segment Sequence refers to a set of one or more contiguous segments. If necessary, a segment sequence composed of one segment is also possible. Also, for example, in a segment sequence composed of two or more segments, the end point of the first segment is the same as the start point of the second segment.

In the present specification, a polyline corresponds to a continuous line used in graphic computing consisting of one or more line segments defined by specifying the end points of each segment.

In this specification, the Route Information corresponds to the set of segments from the defined origin to the destination and the coordinates information of the auxiliary data.

In this specification, traffic information corresponds to information composed of traffic events and network performance parameters related to an area or a route. In addition, the traffic information may include current or future traffic information, that is, future traffic information.

In this specification, a traffic event is a traffic event that is generated by events (e.g., roadworks that cause road closure) or events that occur outside the control of the network operator (Ie, accidents).

In the present specification, a network performance parameter corresponds to information on the performance or traffic flow (i.e., speed, delay, and time required) of each segment existing in an area or a path.

In this specification, the term "Route Information in Full Format" means a form of route information including all segments from a source to a destination. Unless otherwise noted, path information refers to the entire path.

In this specification, Route Information in Summarized Format is a form of route information including only segments selected for summarizing information among all segments from a source to a destination.

In this specification, Unusable Route Information corresponds to information about a blocked or destroyed route in a disaster area such as a fire, an earthquake, a flood, or the like.

In the present embodiment, a navigation device refers to a device capable of performing a route guidance function. The navigation device can be a portable device such as a smart phone, a mobile phone, a mobile device, a laptop, a tablet PC, Includes all attachable electronic devices. Hereinafter, the navigation device may be referred to as a navigation device, Navigation Device, ND.

NavSe, currently being standardized in the OMA LOC WG, belongs to a type of delivering IP-based traffic information to a navigation device. More specifically, it belongs to a P2P type. NavSe classifies navigation devices into two types as follows .

1. Smart ND (Smart ND, 122): It is a device that solely calculates the route and requests only real-time traffic information without receiving route information through the server

2. Lightweight ND (Lightweight ND, 121): A device that requests all real-time traffic information including route information through a server,

In the NavSe standard, a smart navigation device (ND) computes the path to travel on its own based on the traffic information provided by the NavSe server and provides it to the user. In some situations, disaster (fire, flood, earthquake, quarantine, etc.) may occur in certain areas, which limits the passage of certain roads and may lead to roads where traffic is proposed due to disaster. It is impossible to provide a normal path to the user. If a NavSe server provides Unusable Route Information in a specific area where a disaster (such as fire, flood, earthquake, or epidemic) occurs to a Smart ND in the event of a disaster, It is possible to provide an appropriate path except the path which is not available to the user through the path information.

Hereinafter, in order for the Smart ND to provide the user with a route considering the unavailable route information of the disaster area, the Smart ND's NavSe application transmits the unavailable route information related to the disaster area or the traffic related to the route estimated by the NavSe application Describe the process of requesting and receiving information. For purposes of discussion, the NavSe application and the NavSe server may be referred to simply as an application and a server.

1 is a network configuration diagram for explaining a NavSe system as a navigation system of the present invention.

1, the navigation system of the present invention includes a navigation device capable of accessing a mobile communication network, a mobile communication network for wireless transmission and reception, a traffic information collecting device and a traffic information and path providing server (NavSe Server) . ≪ / RTI >

In the present embodiment, the terminal can be connected to an IP network such as a mobile communication network or Wi-Fi as shown in the figure, and has a navigation application for route guidance. The application connects to a server, And can guide the route. Here, the real-time traffic information refers to optimal path information, real-time and predicted traffic information calculated by the NavSe server and transmitted to the terminal, and additional information related to traffic such as POI and weather.

2 is a diagram showing a resource structure defined in the NavSe standard.

3 is a diagram illustrating a structure of resources for providing unavailable path information for a disaster area according to an embodiment of the present invention.

In the NavSe standard, when an application requests a route or generates traffic information for a route, as shown in FIG. 2, the NavSe server newly creates a resource and provides a service according to each request of the NavSe application. That is, the NavSe resource structure of FIG. 2 is newly generated according to each request and provides a service. On the other hand, the unavailable route information for the disaster area corresponds to information provided to a plurality of users equally. Accordingly, in the present embodiment, as shown in FIG. 3, only a single resource can be generated and provided to a plurality of users located in the disaster area or passing through the disaster area, as shown in FIG.

Specifically, in NavSe, when a user creates a Trip resource, a resource is configured in a lower part to provide different services for each request. The Emergency Area resource is created by the server independently of the Trip resource, Provide a link to the same Emergency Area resource for users who need information. By providing information to multiple users with a single resource, it is possible to reduce the resources that are wasted while generating the same information for each user on the server. The user who receives the link can access the emergency area resource and receive the unavailable route information of the disaster area.

In addition, if necessary, the user may subscribe to the emergency area resource for receiving the updated unusable route information, or if the new unusable route occurs in addition to the unusable route information of the provided emergency area, the user may upload the corresponding road information to the new unusable route resource can do. New Unusable Route When new unusable path information occurs in the resource, the server updates the unavailable path information of the Emergency Area resource. In addition, the server may send notifications for providing new unavailable route information to notify other subscribed users of receiving the updated unavailable route information. By allowing the user to update the unavailable route information, the server can quickly obtain additional unavailable route information.

That is, according to the present embodiment, the server can quickly acquire new unusable road information, thereby rapidly updating the unavailable route information, and quickly updating the unavailable route to other users subscribed to the notification service Information can be provided.

Hereinafter, the resources proposed for the practice of the present invention will be briefly described. Other resources for carrying out the present invention are defined in the NavSe standard and are therefore omitted from the specification.

1) Trip Structure: This is the information that the terminal initially sends to set up the route from the user. It basically acquires information such as the source and destination, and then transmits the information to the server. It may include information on whether or not a request for unavailable route information is made or information about the disaster area.

Element Type Optional Description originWGS84 Location_Point Choice The location information of the originating location of the requested route information and related traffic information from the server (Location_Point structure is defined in tpeg-locML [TTI LOG].) One element among origin WGS84 or originAddress MUST be specified when Trip resource is created. This field can be used to indicate the current location of the client, enabling route information updating procedure on the server.
If the value of the unusableRoute parameter is True and the value of orginWGS84 is equal to the value of destinationWGS84, it indicates that the application has requested unavailable path information for the region containing the point specified by originWGS84. If the value of the unusableRoute parameter is True, or if the value of originWGS84 is different from the value of destinationWGS84, it indicates that the application has requested unavailable route information for the specific area on the path it is going to proceed. originAddress Civic_Address Choice IETF Civic Address [RFC5139] The location information of the origin (one element among origin WGS84 or originAddress MUST be specified when Trip resource is created.)
If the value of the unusableRoute parameter is True and the value of orginAddress is equal to the value of destinationAddress, this indicates that the application has requested unavailable route information for the region containing the point specified by originAddress. If the value of the unusableRoute parameter is True, or if the value of originAddress is different from the value of destinationAddress, it indicates that the application has requested unavailable path information for a particular region on the path it is on. destinationWGS84 Location_Point Choice The location information of the destination for the route information requested from the server and the related traffic information (location point structure is defined in tpeg-locML [TTI LOC]. In case that Trip resource is created for an emergency, this field may not be specified otherwise One element among destinationWGS84 or destinationAddress MUST be specified when the Trip resource is created.This structure is mandatory when the Trip resource is read by the client.
If the value of the unusableRoute parameter is True and the value of destinationWGS84 is the same as the value of originWGS84, it indicates that the application has requested unused route information for the area containing the point specified by originWGS84. If the value of the unusableRoute parameter is True, and the value of destinationWGS84 is different from the value of originWGS84, this indicates that the application has requested unusable path information for the specific area on the path it is on. destinationAddress Civic_Address Choice The location information of the destination expressed in IETF Civic Address [RFC5139] format (In case that Trip resource is created for an emergency, this field may not be specified, otherwise one element among destinationWGS84 or destinationAddress MUST be specified when Trip resource is created. The structure may be provided by the server in case the destination uses WGS84 structures.
If the value of the unusableRoute parameter is True and the value of destinationAddress is the same as the value of originAddress, it indicates that the application has requested unavailable route information for the region containing the point specified by originAddress. If the value of the unusableRoute parameter is True, or if the value of destinationAddress is different from the value of originAddress, it indicates that the application has requested unavailable path information for a particular region on the path it is on. waypoints Location_Point [0 ... unbounded] Yes Location information of the waypoint (Location_Point structure is defined in tpeg-locML [TTI LOC].) startingTime xsd: dateTime Yes The start time of the planned trip. If it does not exist, the current time is used. endingTime xsd: dateTime Yes The time at which the planned trip ends is provided by the server based on the path estimate tollRoad xsd: boolean Yes Check whether the route estimate includes the toll road. If the value is true or does not exist, the toll road is allowed. vehicleType xsd: string Yes Type of vehicle requesting route information (This field SHOULD be encoded according to the table of values defined in table RTM01 provided in [TTI RTM]) calculateRoute TripQueryType
[1..2] Yes For a defined trip, whether the server should propose a set of routes with associated traffic events and performance parameters, or whether an alternate route should be proposed if congestion occurs (if this parameter is set to NoAction or absent, the route will be estimated by the ND. requestedEventsCategories xsd: string [0..unbounded] Yes The category of traffic information associated with the defined trip (this field shall be encoded according to the list of values available in the RTM00 table available in [TTI RTM]. If the field is not present, the server MUST provide traffic information for all defined categories (including network performance parameters). unusableRoute xsd: boolean Yes Indicates whether the application requested unusable path information for a particular region. If the value of this parameter is True, this indicates that the application has requested unusable path information for a specific area.
If the server provides this parameter, it indicates that there may be a disaster area on the path the application will travel. The location information of the disaster area is provided through the disasterArea. disasterArea Location Container
[0..unbounded] Yes Provides location information of the disaster area when the server includes unusableRoute. link common: Link [0..unbounded] Yes A link to the reference path resource (Attribute "rel" must be set to "Route" or "unusableRoute".) resourceURL xsd: anyURI Yes Self-referring URL. (The resourceURL SHALL NOT be included in the POST requests by the client, but MUST be included in the POST requests representing the server to the client. responses to any HTTP method that returns an entity body, and PUT requests.

2) Emergency Area Structure: It is defined to provide the unavailable route that the server provides to the terminal. Unlike existing resource structures, this resource is composed and exists on the server alone.

Element Type Optional Description areaDesc Location Container No Unavailable Indicates the area where road information is provided.
It is encoded according to Location Container structure as defined in tpeg-locML. unusableRoute unusableSegment
[0..unbounded] Yes Indicates the unavailable road within the area specified by areaDesc. If all roads in a particular area within the area specified by areaDesc are unavailable, they can be expressed as unusableArea instead of unusableRoute. expectedUnusableRoute expectedRoute
[0..unbounded] Yes indicates a road that is currently accessible within the area specified by areaDesc but is expected to become unusable in the future due to a disaster. unusableArea Location Container
[0..unbounded] Yes Indicates areas where roads can not be used. If all the roads in a particular area within the area specified by areaDesc are unavailable, unusableArea should be used instead of unusableRoute. The maximum size of an area represented by unusableArea is equal to areaDesc (if unusableArea and areaDesc are the same, all roads in the disaster area are disabled). expectedUnusableArea expectedArea
[0..unbounded] Yes indicates an area that is currently accessible within the area specified by areaDesc but is expected to become unavailable in the future due to a disaster. resourceURL xsd: anyURI Yes Self-referring URL. The resourceURL SHALL NOT be included in the POST requests by the client, but MUST be included in the POST requests. The resourceURL MUST also be included in responses to any HTTP method that returns an entity body, and PUT requests.

The server uses the areaDesc parameter to represent the entire disaster area, and provides unusable route information to the application via unusableRoute or unusableArea. UnusableArea reduces the amount of data to be provided to the application by expressing each path as an area containing each path instead of providing each path individually, when all paths in a specific area are unusable paths, It is easy to express the case of unavailable path (this is the case when the value of areaDesc is equal to the value of unusableArea).

In this embodiment, the unusable Segment indicating the unusable road in the emergencyArea resource is as shown in Table 3 below. The emegencyArea may contain zero or more unusableSegments below to represent the unavailable roads in a particular area (disaster area).

Element Type Optional Description originPoint Location_Point No This field represents the origin of the unusable segment in accordance with the Location_Point structure as defined in tpeg-locML [TTI LOG]. endpoint Location_Point No This field represents the end of the unusable segment according to the Location_Point structure as defined in tpeg-locML [TTI LOG]. midwayPoint Location_Point [0 ... unbounded] Yes This field is used to identify the target road segment unambiguously.
It is encoded according to Location_Point structure as defined in tpeg-locML [TTI LOG]. linkName xsd: string Yes Name of the road or street, which belongs to the segment.

The expectedUnusableRoute and the expectedUnusableArea are paths that are currently available but are expected to be unavailable for future use due to a disaster. The application considers the expectedUnusableRoute and the expectedUnusableArea when calculating the path (for example, if the path specified by expectedUnusableRoute and expectedUnusableArea goes directly to the path specified, the application will not use it if it passes the specified path later) .

In the present embodiment, the expectedRoute indicating the unusable road in the emergencyArea resource is shown in Table 4 below. In emegencyArea, zero or more expectedRoute may be included to represent future unavailable roads.

Element Type Optional Description id xsd: string No Id of expected unavailable road information provided  expectedRoute unusableSegment
[1..unbounded] No Indicates expected unusable road information.

In the present embodiment, the expectedArea indicating the unusable area in the emergencyArea resource is shown in Table 5 below. The emegencyArea may contain zero or more of the expectedArea values below to represent future unavailable areas.

Element Type Optional Description id xsd: string No Expected unusable road information provided ID of the region  expectedArea Location Container No It indicates local information including expected unavailable roads.

In addition, the application generates a newUnusableRoute resource in the server in case the new unavailable path information is present in addition to the existing unavailable path information, and provides the server with the newly generated unavailable path information. The newUnusableRoute resource is shown in [Table 6] below.

Element Type Optional Description newUnusableRoute unusableSegment
[0..unbounded] Yes Indicates newly updated unusable road information. This parameter is used by applications to provide new unusable road information to the server.

3) Subscription Structure: An application can be configured to automatically notify the server of new unavailable route information in a disaster area through subscription.

Element Type Optional Description callbackReference common: CallbackReference No Client's Notification endpoint and parameters. link common: Link [1 ... unbounded] No References to resources are subscribed by the application. Attribute "rel" indicates the type of resource subscribed. It may assume the following values:
* "Trip": in order to get notified about:
o new traffic events and performance parameters related to the set of routes defined for the trip
o new alternative route proposals
* "Area": in order to be notified of new traffic events and performance parameters updates
* "UnusableRoute": To receive updated unusable road information for a specific area
Attribute "href" specifies the URL of the subscribed resource. Subscribed resource's type must be the same as specified in the "rel" attribute.
Note: notified information for an existing route are:
a) new traffic events provided with links in the route resource itself;
b) performance parameters available in updated performance parameters filed of segment structures. trackingProc xsd: boolean Yes If you want to be able to connect to the server, deviceLocationURI xsd: anyURI Yes This parameter is used by the server for accessing Navigation Device position information. resourceURL xsd: anyURI Yes Self-referring URL. The resourceURL SHALL NOT be included in the POST requests by the client, but MUST be included in the POST requests. The resourceURL MUST also be included in responses to any HTTP method that returns an entity body, and PUT requests.

4) Notification Structure: The server informs that there is newly updated unavailable route information through Notification and provides a link to receive the updated unavailable route information.

Element Type Optional Description link common: Link
[1 ... unbounded] No Link to updated resources. Attribute "rel" attribute indicates the type of resource updated and may assume "Trip", "Route", "Event", "Area" and "UnusableRoute" values. expectedInfoUpdate xsd: string Yes Contains the ID of the expectedUnusableRoute or expectedUnusableArea provided. Notification that the Route or Area of the expectedUnusableRoute or expectedUnusableArea pointed to by this parameter is currently unavailable

The server provides the application with information (expectedUnusableRoute, expectedUnusableArea) that is currently available to the application via EmergencyArea but is expected to become unavailable in the future. If a road that is expected to be unavailable at a later date becomes unavailable, the server must forward the notification including the link to the application so that the application receives the updated unavailable path information. In this case, it is possible to inform that the expected unusable path information previously provided in the notification transmitted to the application including the expectedUnusableRoute or the ID of the expectedUnusableArea is actually unavailable. When the unavailable route information is updated, the number of times the user accesses the server to receive the updated unavailable route information can be reduced. As a result, in the event of an emergency, the server can be prevented from being congested, Calculate and provide it to the user.

4 is a flowchart illustrating a process in which an application requests and receives unavailable path information to a server according to an embodiment of the present invention. Hereinafter, with reference to FIG. 4, a description will be given of a process in which a server provides unavailable route information to a disaster area to an application.

One. The user sets the Journey parameter to request unavailable route information for a specific area (disaster area).

2. The application sends a request to the server to receive link information that can connect to the unavailable path information.

3. The server responds to the application with link information that can connect to the unavailable path information.

4. The application uses the provided link to request unavailable path information to the server.

5. The server provides unusable path information for the specific area (disaster area) requested by the application.

6. The application subscribes to a notification service to receive updated unusable path information.

7. If the unavailable route information is updated, the server sends a notification message to the application subscribing to the notification service to inform that the update has been made.

8. The application requests the updated unavailable path information. If the id of the unavailable path information predicted in step 7 is notified, steps 8 and 9 may be omitted.

9. The server provides updated unavailable route information.

10. The user senses that there is a new unusable road that is not existing while using the navigation service.

11. The application passes the new unavailable path information to the server.

12. The server updates the unavailable route information of the specific area using the received unavailable route information and delivers the update notification message to another application subscribed to the notification service of the unavailable route information.

Unavailable path information can be continuously changed due to real-time road changes due to disasters. Therefore, there is a need for a scheme that can efficiently provide unusable path information that is continuously updated to an application. In this embodiment, there are three cases in which a user requests information through the NavSe application in connection with the unusable path information.

(a) If a disaster (fire, collapse) occurs in an indoor area such as a building, a basement, or a small outdoor area, and the unavailable route information is requested to calculate a route for escape, the ND provides the user with an indoor navigation service or a disaster area It provides outdoor navigation service and provides unusable route information for a specific area.

(b) When a user using a general navigation service recognizes that there is a disaster area on the route to his / her destination and requests unusable route information of the disaster area, ND provides the user with an outdoor navigation service, Together with unusable route information in the disaster-hit area.

(c) If a user who uses a general navigation service does not recognize that there is a disaster area on the route to his / her destination and requests only general information, the ND provides the user with an outdoor navigation service, In this case, the process of notifying the user that there is a disaster area on the route is preceded.

Hereinafter, a process of requesting and providing unavailable route information to a disaster area by an application in each case will be described, and a process of configuring a resource by an application and a server will be described with reference to the drawings.

 In case (a), a disaster occurs in a limited space such as a building, an underground space, or a limited outdoor space, and a method used when a user requests unavailable path information to calculate a path for movement such as an escape to be.

The NavSe application can provide a service for a navigation terminal. Since the service can be provided through the web even when the navigation terminal is not a web terminal through a web connection, the NavSe application can be used for a service for checking the unavailable route information of the present disaster area have. For example, in order to efficiently perform rescue operations in the fire department, it is possible to use the Web to identify unusable route information of a fire or building, and to instruct movement and placement of rescue personnel. Also, in the event of a disaster such as a fire in a building or the like, the service provider may find it difficult to confirm the unusable route information. In this case, the rescue personnel enter the room and use the NavSe application to provide the unavailable path information to the NavSe server, or the unavailable path information to the NavSe server To provide unusable route information to users or to check the unavailable route information through the CCTV in the building situation room / management room, and to provide it to the NavSe server through the web or the like.

The user of the application defines travel parameters for indicators and other preferences that request unavailable route information related to the origin, destination, and disaster area. At this time, the indicator of the travel parameter indicates that the application is requesting the unavailable route information, and if the source and destination are the same, the application requests unavailable route information related to the disaster area including the location of the source and destination (a)). If the source and destination of the travel parameters are different, it indicates that the unavailable route information of the specific area existing in the route from the source to the destination is requested (in case of (b)).

When the application uploads the travel parameters to the server, the application accesses the unavailable path information via the link provided by the server. Since unavailable path information is common information for users who want to obtain unavailable path information in a disaster area, the server creates a disaster area resource for providing path information, and in order to reduce the number of resources of the server, A link to unusable route information is provided to the user. At this time, the server can provide unexpected route information that is expected to be usable at present but is not expected to be available in the future.

After accessing the unavailable route information, the application automatically subscribes to the notification service without interaction with the user. When a new unusable path occurs in the disaster area, a notification message is triggered from the server to the application. The application can access updated traffic information.

If the predicted unavailable path already provided by the server becomes an actual unavailable path, the server triggers the application with a notification message containing the id of the predicted unavailable path information. After the application receives the notification message, the application internally updates the unavailable route information using the provided unavailable route information. A notification message containing the predicted unavailable route information and the id of the unavailable route information is used to reduce the number of applications accessing the server.

The application receives information about the new unavailable path information from the ND user. The server updates the unavailable path information using the unavailable path information uploaded from the application.

5 is a flowchart illustrating an operation of an application and a server according to an embodiment of the present invention. Through the same process as the flowchart shown in FIG. 5, the server can provide the application with the unavailable route information for a specific disaster area.

1. The user of the application defines the journey parameters and the application posts the travel description to request unusable path information related to the disaster area designated by the user using the travel parameters. The server responds with a generated "trip" resource including a link to access unavailable path information associated with the disaster area.

2. The application accesses the unavailable path information.

3. The application subscribes to the notification service for updated unavailable route information.

4. If the unavailable path information is updated or the unusable path predicted becomes an unusable path, the server notifies the application.

5. The application accesses the updated path information.

6. When the ND user detects a new unavailable path, the user uploads the new unavailable path information to the server through the application. The server updates the unavailable route information.

 (b), when the user tries to travel through a general navigation service, recognizes that there is a disaster area on the route, and when the NavSe application requests traffic information to the NavSe server, It is a way to request information together.

The user of the application defines the travel parameters (origin, destination and road characteristics, etc.) and these parameters are uploaded to the server via the application. Smart ND estimates one or more geographic areas related to the defined trip and accesses the traffic information (event and performance parameters) reported from the server for the selected area. The application proposes to the user a set of routes for defined travel to avoid static road sections using traffic information, and the user selects a reference route from among the suggested routes.

The application uploads the selected path to a server accessing traffic information (real-time and predictive performance parameters). In addition, for real-time optimal path estimation, the application subscribes to a travel-related notification service for receiving updated route-related updated traffic information (performance parameters and traffic events for a selected category).

When an application requests unavailable path information in a disaster area when defining and uploading travel parameters, the server responds with an additional link to access unavailable path information. Since unavailable path information is common to users who want to obtain unavailable path information of a disaster area, the server creates a disaster area resource for providing unavailable path information and uses it to reduce the number of resources on the server Provides a link to users who want to access impossible path information in common. The application accesses the unavailable route information, and ND can calculate the set of routes based on the unavailable route information for the defined trip.

If the application does not request unavailable route information for the disaster area when defining and uploading the travel parameters and the unavailable route information is present in the disaster area associated with the travel parameters, the server may provide additional links to access unavailable route information and / Respond with disaster area information. The application can access the unavailable path information for path computation. In addition, for real-time optimal path estimation, notification service subscription for updated unavailable route information is required.

Since the unavailable path information to the disaster area can be updated frequently, the application subscribes to the notification service when ND arrives near the disaster area to reduce the number of notifications from the server. When the ND arrives near the disaster area, the application uploads the current location of the ND to the server. The server responds to the application with a link to access the latest unavailable path information. The application accesses the unavailable route information and subscribes to the notification service for updated unavailable route information.

When an accident and / or a severe congestion and / or a new unusable path occurs around the current path, a notification message is triggered from the server to the application. The application accesses the updated unavailable route information for the updated traffic information and / or route using the notification message, ND estimates the alternate route and requests the associated traffic information to the server.

If the new path is less congested than the previous path, the previous path is deleted by the ND because ND is no longer interested in the notification service for that resource. If the performance of the proposed alternate path is not good, ND can search for a less congested path before deleting the previous path. ND repeatedly estimates the alternate path set and uploads it to the server. The application can choose to upload the partial path for bandwidth optimization.

The application periodically reports its current location to the server based on the travel distance. Using the updated location information, the server can delete the segment already passed by the vehicle in the route representation. In the next step, when the vehicle leaves the planned path, ND estimates a new path to be uploaded to the server to access new traffic information. The new path replaces the previous path, and the notification service includes the new resource.

6 is a flowchart illustrating an operation of an application and a server according to another embodiment of the present invention. 6, the server can provide the application with the unavailable path information for the disaster area in the path in relation to the travel.

1. The user of the application defines the journey parameters and the application posts the travel description using the travel parameters. The server responds with a "trip" resource generated by including the trip identifier and defined parameters in the application. The application specifies that the path estimation function is not requested. When an application requests an unavailable path, the application specifies that unavailable path information is requested. If there is unavailable route information in the disaster area associated with the travel parameters and the application does not specify that the unavailable route information is requested, the server responds with the disaster area by specifying that there is unavailable route information associated with the travel parameters . In this procedure, the application shows that when generating trip information in step 1, the disaster area is included in the path including the unusableRoute parameter, and it is desired to receive the unusable path information in the disaster area. The server provides the application with a link to receive unusable path information in the disaster area.

2. The application posts a regional description requesting traffic information related to the trip (in this case, the area structure is identified by the coordinates of the origin and destination). The server may select a category for traffic events for the area associated with the de-scripted trip and respond with traffic information including the selected category. If there is severe congestion, it can be answered with performance parameters for the area around the source.

3. The application requests traffic events from the server and reads the traffic information reported from the server. This information is used to estimate the set of paths that ND avoids, along with the performance parameters obtained in Step 2, the critical path segments (affected by accidents, construction or congestion). If the application or server specifies a parameter for unavailable path information in step 1, then the application reads the unavailable path information using the reported link. In Step 3, the road information of the route to be processed is collected from the NavSe server. At this time, the NavSe application also receives the unavailable path information of the disaster area using the link received in step 1.

4. The application uploads to the server the expected path (user-selected from the set proposed by ND). The server responds with a 'route' resource that contains performance parameters and links to traffic events.

5. The application subscribes to the notification service for the selected domain (step 2) and the uploaded path (step 4). If ND arrives near the disaster area while ND is using unavailable path information, the application modifies the source parameter of the trip resource and reads the latest unavailable path information using the reported link. And the application subscribes to the notification service for the unavailable route information. The application is notified of performance parameters and traffic events related to the route uploaded for the selected region and travel trip. The application subscribes to the notification service for the unavailable route information when ND arrives near the disaster area. The application is informed of the updated unavailable path information.

6. The application periodically updates the current location and sends it to the server to modify the existing parameters of the trip resource. This operation is triggered whenever the vehicle travels a certain distance from the previous reporting position. The server uses this information to delete the segment that has already traveled from the route information. If the application acquires the location information of the disaster area through the link of the emergency area resource in step 1, the location information of the current application is transmitted to the server when the user's current location approaches the disaster area. The server receiving the location information of the application provides a link capable of receiving the current emergency area resource. The application receives the new unavailable route information through the link, and receives notification service .

That is, in step 5, the application subscribes only to the general notification service, and subscribes to the notification service to the service for receiving the unavailable route information that is updated only when it reaches the vicinity of the disaster area or only in the disaster area.

In this way, the server and the application do not provide update information every time unusable route information occurs in a disaster area, but provide updated or updated unusable route information only when reaching a disaster area, The operation between applications can be reduced.

7. When the server detects traffic events and / or severe congestion and / or new unusable path information around the proposed route, the server notifies the application.

8. The application accesses the updated traffic information (selected traffic events and performance parameters) associated with the route or updated unavailable route information.

The server provides updated traffic information for the current route and / or the updated unavailable route information through the link specified to the application. When the corresponding road information is updated, the server notifies the application of the updated information as shown in step 7, and the application receives the updated information from the server as shown in step 8.

9. ND decides to recalculate the new path under the following conditions:

a) If the application collects updated traffic information in step 8

b) ND detects that the vehicle has changed its direction away from the defined path

c) If the application receives the updated unusable path information and receives the effect of the current path being affected by the updated unusable path information

The application uploads the newly calculated path to the server by posting (POST) to the existing path or POST to the path factory resource, depending on whether or not the previous information determined by the application remains valid. The server responds with a "root" resource containing performance parameters. This step can be performed iteratively until the recalculated path is better than the previous path. However, to avoid loops, the application may define a new local description to obtain traffic information for the area where the repeated query occurs, similar to that described in steps 2 and 3.

10. The application deletes the old path from the suggested path set if it is no longer used. If the performance of the newly computed path is worse than the path in use, the application deletes the newly computed path from the proposed path set. The application deletes the subscription of the notification service in the previous path (DELETE) (if the new path replaces the old one, via the modify operation, the DELETE operation is not required in step 9).

In case (c), the user does not recognize that there is a disaster area on the route, and uses a general navigation service.

In step 1 of the basic procedure of Smart ND, the NavSe application creates a Trip resource on the NavSe server. If the application does not request unavailable route information for the disaster area when defining and uploading the travel parameters and the unavailable route information is present in the disaster area associated with the travel parameters, the server may provide additional links to access unavailable route information and / Respond with disaster area information. The application can access the unavailable path information for path computation. The NavSe server informs the NavSe application that there may be a disaster area in the path that you want to include by including the unusableRoute parameter, and provides the location information of the disaster area through the disasterArea parameter. It also provides a link to receive unavailable path information via the link parameter.

The NavSe application calculates the path by avoiding the disaster area or receives the unusable path information through the link, and calculates and provides the route by using the disasterArea. The case of receiving the unavailable route information through the following link and calculating the route using the same is the same as the case of (b).

7 is a block diagram of a terminal and a server configured to implement embodiments of the present invention. Each component shown in Fig. 7 may be implemented as a hardware chip, or may be implemented as software and a microprocessor may be implemented to execute the functions of software corresponding to each component.

The terminal 710 may include a communication unit 711 configured to communicate with the server 720 and a control unit 712 configured to calculate the path through the traffic information received from the server 720. [ The server 720 includes a communication unit 721 configured to communicate with the terminal 710 and a control unit 722 configured to collect and process traffic information based on travel related parameters such as the origin and destination information received from the terminal .

One embodiment of the present invention to be described with reference to FIG. 7 is an embodiment in which the terminal 710 is a smart ND. In this embodiment, the control unit 722 configures a resource including path information for a disaster occurrence area, receives travel parameters from a plurality of applications, and provides path information on a disaster occurrence area based on the travel parameters The terminal 710 may be determined to transmit a link capable of connecting to the resource and a link capable of accessing the same resource may be transmitted to the terminal 710 that is provided with the path information for the same disaster occurrence area. At this time, the resource may include unavailable route information that is not currently available for the disaster area and unusable route information that is expected to be unavailable in the future.

The control unit 722 receives the subscription for the notification service related to the disaster area from the terminal 710 and updates the updated path information to the subscriber terminal 710 for the notification service when the path information is updated Can be notified.

In addition, when the expected unavailable route information becomes a route that can not be used, the control unit 722 transmits the updated information to the terminal 710 efficiently by transmitting a notification message including the id of the unavailable route information that is expected And can prevent the connection to the server 720 from being overloaded.

In addition, the control unit 722 can notify the terminal 710 of the updated route information when the terminal 710 receives the current location and accesses the disaster area.

In addition, the control unit 722 may transmit the location of the disaster area related to the travel parameter to the terminal 710 when the travel parameter does not include the request for the route information for the disaster occurrence area.

4 to 6 illustrate that the processes are sequentially executed, but this is merely illustrative of the technical idea of an embodiment of the present invention. In other words, those skilled in the art will recognize that the present invention can be implemented by changing the order described in FIGS. 4 to 6 without departing from the essential characteristics of an embodiment of the present invention, It should be understood that the present invention is not limited to the above-described embodiments.

Meanwhile, each step of the flowcharts shown in FIGS. 4 to 6 can be implemented as a computer-readable code on a computer-readable recording medium. A computer-readable recording medium includes all kinds of recording apparatuses in which data that can be read by a computer system is stored. That is, the computer-readable recording medium includes a storage medium such as a magnetic storage medium (e.g., ROM, floppy disk, hard disk, etc.) and an optical reading medium (e.g., CD ROM, DVD, etc.). The computer-readable recording medium may also be distributed over a networked computer system so that computer readable code can be stored and executed in a distributed manner.

The foregoing description is merely illustrative of the technical idea of the present embodiment, and various modifications and changes may be made to those skilled in the art without departing from the essential characteristics of the embodiments. Therefore, the present embodiments are to be construed as illustrative rather than restrictive, and the scope of the technical idea of the present embodiment is not limited by these embodiments. The scope of protection of the present embodiment should be construed according to the following claims, and all technical ideas within the scope of equivalents thereof should be construed as being included in the scope of the present invention.

Claims (12)

A method for providing path information on a disaster area to a terminal capable of path calculation by a server,
A process of configuring a disaster area resource that includes unusable path information to the disaster area; And
A step of receiving a travel parameter from a plurality of applications and transmitting a link capable of accessing the disaster area resource to an application having a request for providing unavailable route information to the disaster occurrence area in the travel parameter;
/ RTI >
Wherein the step of transmitting the link comprises:
And sending a link to connect to the same disaster area resource to applications having a request to provide unavailable path information for the same disaster area. The method according to claim 1,
The process of configuring the disaster area resource comprises:
Unavailable route information that is not currently available for the disaster area and unavailable route information that is expected to be unavailable in the future. The method according to claim 1,
Receiving a subscription request for a notification service related to the disaster area from an application; And
When the unusable path information is updated, notifying the updated application unavailable path information to the application that received the subscription request for the notification service
≪ / RTI > The method of claim 3,
The process of configuring the disaster area resource comprises:
Unavailable route information that is not currently available for the disaster occurrence area, and unusable route information that is expected to be unavailable in the future,
The step of notifying the application of the updated unusable path information comprises:
If the expected unavailable path is a path that is not actually available, sending a notification message containing the id of the expected unavailable path information. The method of claim 3,
The step of notifying the application of the updated unusable path information comprises:
And notifies the application of the updated route information when receiving a current location from an application approaching the disaster area. The method according to claim 1,
Transmitting a location of a disaster area related to the travel parameter to the application when the travel parameter does not include a route information providing request for the disaster occurrence area
≪ / RTI > A server apparatus for providing path information on a disaster-causing area to a terminal capable of path calculation,
A communication unit configured to communicate with a terminal; And
And a controller configured to provide traffic information on a route received from the terminal,
Wherein,
Construct disaster area resources that contain unusable path information for the disaster area,
Receiving a travel parameter from a plurality of applications and transmitting a link capable of connecting to the disaster area resource to an application having a request for providing unavailable route information to the disaster occurrence area in the travel parameter,
And transmits a link to access the same disaster area resource to applications having a request for providing unavailable path information for the same disaster occurrence area. 8. The method of claim 7,
Wherein the disaster area resource includes unavailable path information that is currently unavailable for the disaster area and unavailable path information that is expected to be unavailable in the future. 8. The method of claim 7,
Wherein the control unit receives a subscription request for a notification service related to the disaster area from the application and updates the unusable route information to the application that received the subscription request for the notification service, To the server device. 10. The method of claim 9,
Wherein the disaster area resource includes unusable path information that is not currently available for the disaster area and unusable path information that is expected to be unavailable in the future,
Wherein the control unit transmits a notification message including an id of the anticipated unavailable route information when the expected unavailable route becomes a route that can not be actually used. 10. The method of claim 9,
Wherein the control unit notifies the updated route information to the application when receiving a current location from an application that has approached the disaster area. 8. The method of claim 7,
Wherein the control unit transmits a location of a disaster area related to the travel parameter to the application when the travel parameter does not include a route information providing request for the disaster occurrence area.

Images