|
Newsletters
|
|
|
|
|
Location-Based Services And Topology
By: Jim McGeough, President & CEO, Digital Earth Systems, Inc. (Dec. 27, 2001) -
Originally published and presented at GITA conference, July 26, 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 broken down 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 break down 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. What does “around” mean? Does 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 either domestic 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) does 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 broken down.” 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 and does not rely on heuristics
concerning what to do 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.
What does it mean to be nearby any of these? One definition might be that a circle of specified
radius centered on the device location does 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 exactly does 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 scenario down 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; how do we get there from here?” The
detailed break down 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
“Why does 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 how do I get from one address to another address are easily supported by
current systems, but the question “How do 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, or double 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
|
|
|
