吕
吕雪松
Unregistered / Unconfirmed
GUEST, unregistred user!
Location-Based Services And Topology
By: Jim McGeough, President &
CEO, Digital Earth Systems, Inc. (Dec. 27, 2001) - Originally published and presented at GITA conference, August 29, 2001 -- Printer Friendly Version
Several GIS companies are promoting hybrid technologies and location engines for locationaware applications. However, the effective deployment of Location Based Services on the Internet will require topology integrated with the data. While numerous ‘topology modules’ have been available from Enterprise GIS vendors for some time, these modules are external to the data and are typically found in separate proprietary applications. Development platforms for LBS have been brought together by various vendors with labels like “Location Engine” and “Data Engine” however, it is apparent to many technology architects that their separate and disconnected origins may present some ‘show-stopping’ integration and scalability hurdles in a web environment. This paper describes the important role played by topology in Location-based Applications and the value of a web enabled database centric solution where all spatial data relationships are maintained and managed directly in the database itself, without the need for any specialized or proprietary GIS application. This solution will provide integrated dynamic topology and spatial analysis from any wireless handheld device. These capabilities are especially significant for those organisations that wish to deploy spatially enabled Location Based Services and Applications on the Internet where the source data is constantly dynamic.
--------------------------------------------------------------------------------
The importance of Location Based Services (LBS) and the commercial promise it presents to both the traditional GIS industry and the emerging wireless devices industry is now well publicised. Examples are being expounded. Competitive architectures are being promoted and, if activity is a guideline, excitement is growing rapidly;
the location bug has taken hold. Both the government and private sectors are recognizing the considerable value of location information as a platform for improved services and business applications.
Figure 1 - Revenue (in millions) projected for Location Based Services by 2004 Source: Wireless Location Services: 1999, The Strategis Group
As the GIS and mapping industry recognize the possibilities, we’re starting to see many increasing examples of LBS such as “Where’s the nearest bank ATM”. Such a service accepts your present address and delivers ATM addresses that are in close proximity to your entered address. Similar examples are available for restaurant, museum and other popular place locations. However, when we consider the degree of intelligence imbedded in these initial applications, it becomes apparent that some important pieces of the technology are still missing from the overall schema of location-based services. The technology that we’re still missing is integrated topology;
real-time, dynamic topology and network tracing.
Development platforms for LBS have been brought together by various vendors with labels like “Location Engine” and “Data Engine” however, it is apparent to many technology architects that their separate and disconnected origins may present some ‘show-stopping’ integration and scalability hurdles in a web environment.
This paper describes the important role played by topology in Location-based Applications and the value of a web enabled database centric solution where all spatial data relationships are maintained and managed directly in the database itself, without the need for any specialized or proprietary GIS application. This solution will provide integrated dynamic topology and spatial analysis from any wireless handheld device.
What is Topology?
While many industry visionaries and technology writers have presented examples of applications and services that can be enabled by location information, these examples have not been brokendo
wn into their constituent technology parts. The Open GIS Consortium (www.opengis.org) however, is unique in its efforts to examine in more detail what exactly will be required to realize the goals presented. Through such analysis, a consistent conclusion emerges: real-time, dynamic topology functionality is necessary to effectively realize the full potential offered by most location aware applications.
What is topology? In its simplest form, topology is the ‘shape’ of data;
the specific physical, i.e., real, or logical, i.e., virtual, arrangement of the elements of a network. Currently, the function of topology management is provided by many software vendors in the form of a specialist proprietary application external to the database. These applications are typically ‘run’ by the user during data entry, data editing and most spatial queries.
If full topology can be integrated into the database, the database can then
control and issue asynchronous events upon the recognition of certain topological (physical relationship) criteria, without the need for an additional specialized application. Examples include notification when certain spatial relationships exist, or when a point passes into or out of a specified region, or when two elements (linear or curved) intersect. Other examples could include database driven events related to dynamic polygons representing business data analysed against dynamic demographic data. This type of application can also serve as a platform for Decision Support Systems (DSS).
While topology is a basic function in many typical GIS applications today, it may not appear immediately relevant to the location based services developer. For example today, several simple LBS applications function without integrated topology. These examples are using the mobile phone relationship to the carrier’s ‘cell’ location to determine a basic level of location awareness. An example of this is the wireless discount coupon application, which recognizes a customer’s phone number as it enters the mobile carrier’s cell;
the application sends a time sensitive electronic coupon to the phone, valid only in a nearby store within the same carrier’s cell. This application is confined to the carrier’s system and the carrier’s customer. Sophisticated applications of the future will draw on dynamic data from wide and varied sources, both government and private data, and will require advanced real time topology. The importance of integrated topology is especially true in commercial enterprise applications where dynamic polygons can represent dynamic business data, which could be analysed in real time against mobile customer data and fixed networks.
An examination of the following examples describes some applications which can benefit from integrated topology management and real-time topology validation. Many Location Based Service applications also require network tracing and similarly, this functionality must be integrated within the database itself if scalability and rapid deployment is to be realised.
Example Applications:
The Open GIS Consortium (OGC) has identified several examples of location-based applications, which will allow us to examine a more detailed breakdo
wn of what is entailed in the successful realization of location-based services. These examples will now be examined to identify the role of topology and dynamic topology.
Traffic Information
“You are about to join a ten kilometre traffic queue, turn right on the A3 ahead for a better alternate route.”
This was reported as one of the most complicated examples so it shall be examined in depth. The OGC’s detailed breakdown goes as follows:
a) Create a planned route
b) Periodically get device location
c) Position device on appropriate transportation network (usually streets)
d) Examine planned route for obstacles
e) Compute work-around if obstacle is discovered
f) Process and present a work-around
i. Obtain background road networks with street and place names with scale and map up date as device moves
ii. Highlight planned route
iii. Highlight work-around route
g) Explain the obstacle
Step a) requires topological services, although not of a dynamic nature. A static topology engine would suffice for the simplest cases. But consider the task of planning a route subject to dynamic constraints represented by other data sources. Typical constraints are traffic and weather. Or, for commercial vehicles, maybe the route should remain a minimum distance from some fixed or mobile features. Commercial vehicles may also need to respond to changing customer activity or remote transactions, such as calls for service. These constraints imply topological capabilities: proximity zones and containment tests. If routes are subject to on-the-fly update then
dynamic topology is required. Either way, topological data models and data structures could assist in representing, storing, and communicating the route. Step b) requires real-time location positioning such as GeoMode (www.geomode.com) for urban wireless devices or Global Positioning Satellite (GPS) based systems for rural areas. Step c) brings us right back to topology in the application. Any location that comes out of the previous step will have some error associated with it. In its simplest form this may be modelled as a point in a circle, or with slightly more complexity, a point in an ellipse. In either case it is highly unlikely that the point itself will lie on a unique street in a street network. Instead the point will more likely lie off the streets but the circular or elliptical error envelope will overlap one or more streets. The location algorithm might proceeds as follows:
a) Locate all the streets that intersect the error envelope
b) Compute a perpendicular minimum distance to that limited set of streets
c) Select the closest and/or similar alignment to device movement as the result
Of course, smarter algorithms could be developed that take prior locations into account. Step d), like step a), could make good use of the data models and algorithms contained in a topological component. The examination of the route for obstacles certainly implies network traversal on a graph that stores the route itself. Definition of obstacle could be a simple topological fact like an open drawbridge. More complete definitions would likely include topological conditions and other attributes as well.
The reasoning implied by computing a work around in step e) again demands a high degree of topological capability. Whatdo
es “around” mean?do
es it mean a route that starts and ends at certain points of an original route, but avoids the region of an “obstacle” in between? Of course direction is critical here as well as a route is assumed to be directed. Care must be taken not to miss any key points on the original route. Missing a delivery because of traffic is not an excuse that people would accept in eitherdo
mestic or industrial settings.
Step f) requires topology similar to step a) and is one that is repeated in many of the further examples to be examined.
Step (g) will not require immediate application of topological functionality In the Traffic Information example, topology and dynamic topology have a role to play in 4 of 7 steps as presented in this breakdown. In one of the other steps there may be topological services needed at a level below that of application. It is clear that topology is critical to any intelligent implementation of the Traffic Information scenario.
Emergency Services
“I’ve had an accident.” This scenario is interesting in that it captures the requirements the United States’ Federal Communication Commission (FCC) has placed on mobile operators in the US. Emergency calls must be locatable to within 100 meters. The OGC’s detailed breakdown is as follows:
a) Get device location (GeoMode or GPS)
b) Position device location to address or other human location
c) Communicate request for assistance to closest Emergency Call Desk
d) Convey response to accident victim (e.g. ETA)
Location positioning for step (a) can be provided by GeoMode for urban areas and areas with adequate wireless coverage or GPS for rural areas. Positioning the device in step (b) will require topology to convert X,Y to a street address. An error envelope a true position has to be determined and topology can refine the X,Y to a street address. Step (c)do
es not require immediate use of topology, as it is a simple communication step. Step (d) is a communication step however topological functionality is required to calculate a drive time along a route to the emergency to estimate the time of arrival (ETA). There are many dynamic conditions, which can impact the ETA, which require topology. Topology also plays a critical role when attempting to coordinate mobile emergency vehicles with the location of the emergency. This coordination requires dynamic topology to manage and select the emergency vehicle that can respond in the shortest time (and not distance) possible.
Roadside Emergency
“Help, my car has brokendo
wn.” This scenario is detailed identically to the last except that the call is routed to a Road Assistance call desk instead of an Emergency desk. It will therefore not be discussed separately.
Law Enforcement
“What is the speed limit on this road where I am?” This scenario requires real time location and positioning on a road network, and topology to relate position with the law enforcement spatial database.
Other applications, such as connecting alarms to police vehicles, without the need for the traditional dispatcher involvement, require topology. Topologically managed events like this can save precious minutes in responding to emergencies.
Fire fighting 1
“Where should I shovel snow to find the hydrant?” This scenario is unique enough to warrant examining the OGC’s detailing:
a) Get fire-fighter’s location (GeoMode or GPS)
b) Form query to request location of nearest hydrants from appropriate database
c) Compare device’s and hydrant’s locations to obtain search vector
d) Obtain and display map backdrop with landmarks (such as poles and curbs) and superimpose or highlight hydrants
e) Repeat if necessary
As before, GPS or GeoMode can provide the fire fighter’s location. The second step asks a question as to which hydrant is closest to the determined location. An accurate and robust way to answer this question is to determine which region of a Voronoi diagram contains the device’s location.
A Voronoi diagram is a mathematical tiling of a region induced by a collection of points, in this case the collection of fire hydrants. Each hydrant defines a region such that it is the nearest hydrant to any point in that region. Identifying which regions contains a test point then
gives the hydrant closest to that point. This approach is unambiguous anddo
es not rely on heuristics concerning what todo
when different hydrants are all nearby. This topological approach simply returns the right answer.
Dynamic topology is further useful in this scenario as the fire-fighter moves. As the location of the person changes, the system continuously knows which hydrant is closest. It furthermore knows just how close and in what direction. This is step (c) of the OGC’s breakdown. The importance of topology to information display (step (d)) has been mentioned already. Here it should simply be stated that with the proper display, step (e) would be unnecessary, as it should be. Time cannot be wasted when fighting fires.
Fire fighting 2
“Are there flammables/explosives nearby?” This second fire-fighting example shares similarities regarding device location and information display with the last scenario. What should be examined, however, is the query for flammables or explosives nearby. This topologically latent word can have many meanings in this example. A flammable barrel of chemicals can be modelled as a point. A pipeline of flammable material must be modelled as a possibly branching linear network. A standing pool of oil must be modelled as a 2-dimensional feature. Whatdo
es it mean to be nearby any of these? One definition might be that a circle of specified radius centered on the device locationdo
es not contain any point objects, or intersect any linear or area features. Clearly these are topological tests. Given a moving fire fighter they suddenly become real-time, dynamic topology. Imaging a fire fighter receiving a warning when moving within 10 meters of any such feature. With dynamic topology such applications are conceivable.
Classified Advertising
“Is there a programmer’s job nearby?” “Where are nearby yard-sales featuring antiques?” or from a profile submitted by a customer, tell me when a certain product is for sale within a specific price range in a specific location / area (i.e. near my home). The OGC gives these identical breakdowns:
a) Get relevant location (might be “home” or another default location)
b) Form and issue query to regional employment / yard-sale service(s)
c) Interpret and portray response in sorted order on a map backdrop In step a), the specific fixed locations, such as home, may be dealt with at an application level. Mobile locations such as a moving vehicle can be handled by first computing the location with GeoMode or GPS technology.
Step (b) hides an awful lot in the simple word “form.” What exactlydo
es a query need to contain? How should it be formed? A lot depends again on the meaning of “nearby.” A lot ties into the ordering mentioned in step (c). One conceivable, topologically based solution positions the base point on a Voronoi diagram generating the closest target. The Voronoi diagram could then
be explored by visiting adjacent cells in order to create an ordering of targets. An alternative approach simply queries for all targets within a search radius and then
sorts the reported targets based on actual distance.
Location Visualization
“Where am I?” The details of this scenario are as follows:
a) Obtain location via input address;
GeoMode or GPS
b) Form and issue query to application database (customer or facility database)
c) Interpret and portray response on map backdrop with appropriate context The first step, naturally enough, is to determine the actual location under consideration. If this is known from other sources then
there is not a need for topology. If, however, the location is to be identified from location positioning technology, then
a topological containment test is required. It is not hard to imagine a dynamic need here if a utility inspector or surveyor is tracing property lines through a housing estate. As each new parcel is entered the display can change appropriately, perhaps also indicating textual information about the owner of that lot. Integrated topology management supports step (b) above, to capture the geometric configuration of the parcel’s boundary returned from the query.
Public Safety Vehicle Management
“Who is closest to that emergency?” This scenario calls for location positioning from GeoMode or GPS for the location of the emergency, and also requires the dynamic topology described in the introduction. It should be pointed out that this example also represents a taxi dispatch problem, although this is somewhat less dramatic setting. The OGC breaks this scenariodo
wn as follows:
a) An emergency is communicated to a call centre
b) Each vehicle in the emergency response fleet receives the location of the emergency
c) Each vehicle periodically (every few seconds) reports its position and status to the call centre
d) The call centre computes the response ‘time’ for vehicles to attend the emergency
e) The call centre assigns the closest vehicle (in the correct status) to the emergency
f) The call centre sends a route to the vehicle;
optionally it sends only the destination, and the vehicle computes the route
In this example, topologically speaking, everything here is dynamic. For this type of ‘real-time’ Location application to be effective, dynamic real-time topology is a requirement. Vehicle location, in the cases above, requires topology to position a device on a road network given the inevitable errors that can creep into the location positioning process. In steps (d) and (e), rather than calculating all the distances between the vehicles, an alternative approach is to create the Voronoi diagram of the vehicle’s locations as discussed above. Selecting the nearest vehicle/s becomes a simple point containment test to determine which vehicle’s cell contains the location of the emergency. Any refinement of the response time for emergency vehicles (should they’re be more than one emergency vehicle available in the same cell) must include driving conditions, which impact time to the emergency location;
this requires dynamic topology. Further functionality can be achieved through the use of dynamic topology in this scenario. Imagine the taxi dispatch variant. A dynamic topology component at the call centre can monitor continuously and report lack of coverage of certain areas in the region. This would be a clue to the human dispatcher to instruct vehicles to move to a new location. Lack of coverage under a specified time would be determined as a region larger than a tolerance size that lies outside the union of specified time drive time areas of each vehicle. With appropriate algorithms and a realtime topological component even further services can be developed.
Location-Based Billing
Free calls on your mobile phone, while you are in a particular location or the called number is within a certain range. The simplicity of this scenario should not detract from the importance it holds to the operators. Anything that strikes at the heart of the billing relationship in this industry is of critical importance to retaining customers. Topologically, this service depends on a point in polygon test where the polygon represents the discounted billing area and the point represents the position of the mobile station. More complex topological relationships are of course possible with a dynamic topology engine. Promotional programs which can offer free or subsidized calls while in this area and within 1000 meters of a specified feature or the number being called.
Leisure Information
“We want to go to Ronnie Scott’s Jazz Club tonight;
howdo
we get there from here?” The detailed breakdo
wn starts with geo-coding Ronnie Scott’s to get a destination address. then
the device’s location is determined (GeoMode or GPS). Here the need for topology arises. The next step consists of determining an optimal path from the device location to the club. This potentially difficult step clearly requires topological data models and data structures for completion. As above, extra constraints on the route, including those that may depend on current traffic or weather conditions, further complicate the task.
Finally, the route needs to be displayed in the proper context, perhaps going so far as to show nearby points of interest if the estimated time of arrival is significantly before the time of the show. Dynamic topology is clearly needed in such contextual display operations. Current online services for directions such as MapQuest or MapBlast, offer simple visual directions on a static map display, void of any dynamic events or obstacles. Dynamic topology would be required for determining “what live jazz club choices are available within 1 mile of my location tonight”. Or, find me a hotel within a specified distance, which also has nearby events for children. Here you are requesting a Boolean operation on separate data types in a spatial context. This requires dynamic topology.
Similar applications apply to finding parking spaces, hotel rooms, events, nearby club members etc.
Mobile Service Information
“I need to upgrade my mobile terminal;
where is the nearest phone shop?” This example shares many similarities with the last one. The difference lies in the existence of multiple possible goals, namely all phone shops. These must be selected based on distance from current location, a task easily accomplished using a Voronoi diagram as above. Displaying the results requires topology as shown previously.
Road Service Information
“Where is the nearest petrol station?.” This scenario is detailed identically to the last except that a different criteria may be use to select the actual destination based on shortest travel time. It will therefore not be discussed separately.
Directions
“I’m lost;
where is the nearest Metro station?” This, too, is identical in principle with prior examples, and so will not be discussed separately.
Fleet Tracking
“Whydo
es it always take twice as long to deliver to that customer?” As detailed by the OGC this scenario makes repeated use of tasks described previously. Routes between a series of randomly chosen points and a target destination are calculated;
travels times are then
calculated. Like the examples above, topology is required here, primarily to support the creation of routes and the calculations of the associated driving times.
Package and Asset Tracking
“Where is the package with those new SIMM cards?” The OGC details for this case consist of getting a path and vehicle ID for the delivery route from the electronic record of the parcel. This path is then
compared with actual X,Y location of the shippers vehicle. Linear positioning is used along this segment to more precisely pinpoint the parcel and delivery estimates can be precisely calculated and the consignee notified by synthetic voice announcement. Dynamic topology is necessary to define the path, navigate it segment by segment and compare the segments to real-time vehicle location.
“I’m sure I left my PDA on the train, but where is it now?” The primary topological requirements of this use case consist in modelling the path of a train and performing a linear positioning process to location the station at which to find the train. This is essentially the same task as described in the last example.
Vehicle Navigation &
In-Vehicle services
Currently, we have several available novel examples of in-car navigation products, however these systems are limited to positioning the car location on a static map display stored within the product. The current systems also require the user to input a destination address manually. Simple questions like howdo
I get from one address to another address are easily supported by current systems, but the question “Howdo
I get back to the Interstate from here” or “what’s the fastest way to…” require topological services. Dynamic data sources such as weather and other traffic cannot be considered by current systems. If any sort of update is required before the destination is actually reached, such as testing if the road has been ploughed during a snow condition, then
dynamic topology is required. Proximity queries such as “find all of the available hotel rooms less than $80 per night for the night of 12/12/02 along my route” can also be performed quickly and easily. More innovative applications, which integrate vehicle navigation systems with automatic parking systems can be developed whereby locating and purchasing a parking space and being directed to the space, are possible with Topology Manager.
Public Transport Schedules and Tracking
Security applications, where the tracking (www.geomode.com) and disabling of public transit vehicles which stray from pre-set routes, are becoming necessary as public safety comes under threat from terrorist and criminal groups. Additionally, the ability to inform the public of the currently best available options for getting from A to B can increase the commercial use of public transport. Topology Manager can support the integration of transport schedules from different transport systems such as Greyhound and Amtrak. Today, with the current website schedules, it is impossible to find a bus / train combination to get from A to B. With Topology Manager, passengers could type their home or starting address and destination address into a search field on the Amtrak website;
their preferred time of departure or arrival and the schedule application would direct the customer to the correct bus and train schedule for the best routing. The need for dynamic topology arises from the need to query separate transport systems and networks related to the customer location and destination.
Vehicle Theft Detection and Recovery
“My car has been stolen;
where is it?” Locating the position of the vehicle requires GPS or GeoModeTM location positioning, but the management of recovery events requires topology. Determining the jurisdiction boundaries and identity of the closest patrol cars clearly demands dynamic topology. Nearby police vehicles could automatically be notified bringing in the prior example about selection of emergency vehicle. In this example, integrated network topology would be required to ensure that the closest police car is defined using a metric related to the directed network of streets. It is no good to be literally on top of the stolen vehicle such as on a highway overpass, and be unable to pursue it.
The most significant aspect of this example is the opportunity for event driven actions / messages to be automatically initiated in the vehicle recovery process. As described in prior examples, topology is used in determining the many vehicle locations needed in this scenario, and also in displaying all the information at a control centre and to the various police vehicles. This example demonstrates the true value of LBS as the ability to use dynamic location information and topology to drive and automate the management of complex events and resources.
People Tracking
GeoModeTM (www.geomode.com) or miniature GPS technology can be imbedded into items of clothing and footwear to support child-tracking services i.e. “Tell me if my child strays beyond the neighbourhood.” The complete implementation of this example requires dynamic topology. The real-time nature of the requirement statement indicates that a child’s position is to be continually tracked. Topologically, the child’s location must remain within an area defining the neighbourhood. This ‘area’ could also be augmented by other separate dynamically assigned “out-of-bounds” areas either within or outside the primary area. The parent could maintain the service parameters online (visually looking at an online map). The dynamically assigned “outof- bounds” areas could be assigned on the basis of criteria selected by the parent such as time windows or social parameters.
Given sufficient accuracy of the location process a further condition could be monitored to ensure that the child remains away from roads. If the location is too close, or if the velocity of the position indicates that the child has entered an unauthorised vehicle, then
the police could be automatically notified and a pursuit begun. These conditions have clear topological components to them. Other similar personal and commercial examples of people tracking, where the person being tracked provides tracking permission, can improve customer service and public safety.
Animal Tracking
Recent outbreaks of animal disease in various parts of the world have highlighted the importance of monitoring animal movements. We are not suggesting that positioning technology be attached to commercial herds however, portable or fixed GeoMode monitoring stations can scan the animal bar coded tags to collect the location / time data. Questions such as “What is the exact movement history for the previous 30 days of these 100 cattle?” can dramatically improve the control of animal health and public safety. In the commercial context, the tracking of valuable herds is as important as the tracking of airline baggage or Federal Express shipments. This example is identical in principle, if not severity of response, to the prior example. Therefore it will not be discussed separately.
An Integrated Solution
Over the years, virtually every industry has evolved sophisticated models to handle complex data objects that make up the heart of their business. By data objects, we mean both the structures that relate different units of information to one another and the operations that are performed on them. As seen above, web-based ‘location aware’ applications include many kinds of complex data objects which, to be effective, will require the topology to be dynamic. A typical topology application from a GIS ‘vendor’ requires the user to ‘run’ the topology application against the data from time to time, especially after data maintenance actions. Our alternative approach is to build the topology logic into the database itself thereby avoiding integration and scalability issues. The ability to extend the database to include complex application-specific data types as well as the business logic associated with these types, offers a more advanced solution for web-based applications. Additionally, the inclusion of topological intelligence within the data structure provides dynamic topology, which is better suited to applications where the data is dynamic such as Location-Based Services.
Database products are also becoming more extensible so that advanced software modules and business logic, such as topology, can be incorporated directly into the database. Oracle Corporation, one of the leading database vendors, has successfully implemented a Spatial Cartridge or extension to the data structure so that spatial data in the Oracle database is available to any application. The data cartridge approach allows the user to leverage the business specific expertise by encapsulating this business logic in software components that integrate with the Oracle server. The notion of adding logic to data in a database has been available for some time by way of stored procedures. With the addition of object-relational extensions, the Oracle9i Application Server can now be enhanced by application programmers and independent software vendors to support a new generation of data types, processes, and logic in order to model business objects.
Our own effort in this area includes the development of a Topology Manager;
a best-of-breed software component that dynamically discovers and persistently tracks topological and spatial relationships within vector geometry models such as those stored in Oracle Spatial, and indeed, any other file format that stores vector geometry with integer, single, ordo
uble precision, such as AutoCAD DWG or DXF files, MicroStation DGN files, ESRI shape files, simple vector format SVF files or stereo lithography STL files. Such relationships include intersection, adjacency, containment, enclosure, and overlap.
The Topology Manager has been implemented across many operating systems including popular Unix flavors and the Microsoft Windows 32-bit platforms. It is accessible as a native language shared library in C and C++ development environments, from within Java-based applications, or from within visual-based development environments.
The Topology Manager provides interactive topology through a rich event-driven paradigm using asynchronous messages and registered listeners. As topologically important events occur-edge intersection or shape creation, for instance-the Topology Manager notifies the application, triggering intelligent behaviors that previously had to be performed by end-users. Associated attribute data is easily maintained this way.
Further development is now underway to implement Topology Manager into Oracle as a complimentary ‘Cartridge’ to Oracle Spatial. Such a Topology Cartridge will dynamically discover and persistently track all topological and spatial relationships within the Oracle Spatial vector geometry model. As topologically important events occur i.e. edge intersection, shape creation, point-in-polygon and other dynamic events-the Topology Manager will notify the application, triggering intelligent behaviours.
By integrating Topology Manager with Oracle9i Application Server Release 2.0, using open APIs, Topology Manager utilizes the wireless functionality of Oracle9i Application Server to deliver high-performance location-based services (LBS) such as emergency response applications, interactive yellow pages, real-time traffic monitoring, point-of-interest selection, optimal routing and driving directions. By embedding Topology Manager within Oracle9i Application Server, the user has the ability to quickly deploy key location-based services as well as develop their own applications to access the Oracle9i Database, The combination of Topology Manager and Oracle9i Application Server allows companies to develop location-based services using spatial datasets from a variety of sources. Proximity queries such as “find all of the available hotel rooms less than $80 per night for the night of 12/12/02 along my route” can also be performed quickly and easily.
Such a database centric approach is necessary if we are to build truly scaleable LBS applications without the complexities, which arise from data integration issues. Topology Manager will allow users to integrate, manage, develop and deploy spatial and transactional applications totally within a single, open, database environment, paving the way forward for location-aware decision support systems including advanced visualization applications. This approach will also solve some of the address matching issues that are emerging in the mobile wireless technology world, where a location-aware device (e.g. a cell phone) will compute an X, Y location, with accuracy anywhere from +/-25 m to 100 m (www.geomode.com). However, it will most likely not coincide with existing road alignment geometry. Any location that is computed by a location aware device will have some error associated with it. In its simplest form this may be modelled as a point in a circle or polygon, or with slightly more complexity, a point in an ellipse. In either case, dynamic topology can provide the analysis required to convert the X, Y location into a street address.
The advanced solutions being described here, will allow organizations to develop and deploy spatially enabled e-business and m-commerce applications such as optimal routing, public transit systems, emergency dispatch, intelligent traffic guidance systems and related ‘Locateme’ applications, within a scalable database centric system, without the need for any proprietary geo-data management application. This approach leads to a more cost effective, open and powerful enterprise wide location aware development platform, suitable for e-business and mcommerce, which can be deployed to provide ubiquitous access to a truly digital earth.
Conclusion
Web visionary Tim Berners-Lee, stated that the next phase of the Internet would see the development of a "semantic Web,"
one in which meaning is embedded within the framework of the Internet. This ‘meaning’ is the sort of intelligence exhibited when humans look at maps and such intelligence is required for most advanced LBS applications.
Such a semantic Web requires unifying principles in order to organize and embed greater intelligence in the Web, and topology is one such principle. And ‘location’ (GPS or GeoMode) combined with integrated topology is the ‘glue’ which adds relevance to disparate sets of data. The implementation of real-time dynamic topology, within a database, is necessary for capturing and managing this intelligence in real-time.
These capabilities are especially significant for the modern enterprise or utility where the enterprise or network is constantly expanding and changing, where the source data is constantly dynamic. This technology provides a solution allowing ubiquitous data collection, posting, analysis and retrieval to be managed in real-time without the need for data translators, application interfaces or data integration concerns. In this solution, all data, both spatial and non-spatial, is managed in a single data model and can be made available, specifically filtered by location, transmitted to mobile workers in the field via any wireless handheld device. Integrated dynamic topology is especially significant for those organizations that wish to deploy spatially enabled Location Based Services and Applications on the Internet where the source data is constantly dynamic.
Bibliographical references:
1. Niedzwiadek H. 2001;
E-Business Embraces Location, Business Geographics
2. Open GIS Consortium 2000, Website Information
3. Lopez X. 2001;
Enhancing Mobile Applications with Location Based Services, Oracle White Paper
4. Lopez X. 2001;
Deploying Location Based Services with Oracle Spatial, Oracle White Paper
5. Edwardes A. 2001;
Interoperability Pieces Together Location-based Services, Business Geographics
6. Apex Data Services 2001;
DataWorks®
Product / Service Specifications
7. GeoMode, a Wireless Location Positioning Solution;
www.geomode.com
About The Author
Jim McGeough is the CEO of Digital Earth Systems, Inc. a software development company and consultancy specializing in location based technologies, which he founded in 2000. Prior to founding Digital Earth Systems, Jim held a number of senior executive positions with geographic information system (GIS) software companies in Australia and the USA including Synercom (now part of Logica). Jim also spent many years in management and consulting with technology firms such as Azimuth Consulting (Silverline Technologies);
Wang New Zealand (now Gen-i);
local government consulting firm PlanGraphics, Inc. in Washington DC and, more recently was responsible for the Worldwide Operations at Analytical Surveys, Inc. After graduating from the West Australian School Of Mines in 1972, and during the personal computer revolution of the early 1970s, Jim joined several early pioneers in the development of automated mapping software in Perth, eventually moving to California where he spent 10 years with Synercom Technologies. He has published and presented papers on the subject of digital mapping, topology and location based services. Jim has been a keynote speaker at professional user groups and a presenter / speaker at industry conferences. A native of Ireland, Jim is currently based in Washington DC where he is an active member of industry groups including the Geospatial Information Technology Association (GITA).
"A Database Platform for Location-Based Service Applications"
©
2001 Copyright Digital earth Systems, Inc. All Rights Reserved.
Are you involved in wireless application development or other wireless business and technologies, or have we missed something that you feel should have been mentioned here? Send your comments to WDN
摘自：http://spatialnews.geocomm.com/features/geomode2/