URL to USL or web enabled GIS
Tier 1 – Clients
These clients can be anything from ultra-thin (Palm OS and Windows CE or Network
Computing Device) running nothing more than a browser; thin clients capable of running the
same browsers but with plugins that add some GIS functionality; and applications running on
workstations that have their own datastores and talk directly to an application server.
Tier 2 – Presentation Servers
These are web servers that serve up HTML or Java Applets to browsers using either a servlet or
JSP (Java Server Page).
Tier 3 – Application Servers
The three-tier computing model evolved to address the problems of the two-tier model. In a
three-tier model, a middle tier exists between clients and the database server. This middle tier
consists of an application server that contains the bulk of the application logic of the three-tier
model. Clients in this model are thin clients. With this architecture, application logic resides in a
single tier and can be maintained easily at one point. The architectural design of the middle tier
can also be optimized for server functions since it does not have to house the database.
Tier 4 – Data Stores
Flat-file, hierarchical, and network database systems were displaced by relational database
management systems because their flexibility and interfaces insulated application code from
physical storage schemes. Object-relational systems are based on a simple idea: the data model
they support is an extension of the SQL92 relational model (SQL3). This extension has been
achieved with user-defined types and functions that model business objects more naturally and
encapsulate business rules with data.
The OpenGIS specifications give a way of defining things in the database that have a location
and/or have geometry. Using this specification and the emerging object-relational or object
databases, it is know possible to define data types (ORDBMS) or objects (ODBMS) that have
agreed to attributes and well known behavior. In addition to this the OpenGIS specifications also
define the data object interfaces for CORBA that can be encapsulated into business objects for
use in a distributed object architecture, such as is required by applications running on the WWW.
Current offerings by the major software vendors do not come close to this kind of functionality,
either architecturally or as define by the OGC.
In the presentation layer these things that now know where they are can be drawn in context
using a mapping component written using the Java JDK 1.2 which has extensive drawing
capabilities in the graphics package. So now, instead of delivering an image with very little user
interaction capabilities, it is possible to stream these objects and the relevant land-base
components to the browser or Java application. Once on the client they have similar or the same
interaction capabilities GIS users have become used to in the current client/server style GIS
engines. It is worth noting that both MapGuide (Autodesk) and GeoMedia Web Map (Intergraph)
use graphic objects.
If an image is delivered to the client, the local software “knows” only the mouse’s window
coordinates, in the object aletrnative, the software knows the point line or polygon that the
mouse position indicates. The former method requires a trip to the server to determine what
thing is being pointed at, whereas in the latter the software can make this determination without
going back to the server. In a distributed architecture, such as the WWW, the fewer round trips
to the server the better, put another way, if the user has to wait too long he/she will go
somewhere else on the Web for this service.
Spatially enabling the enterprise with web based GIS
We have seen that we can define a set of business objects that can encapsulate data objects that
have been designed using the OpenGIS Simple Features specification. These business objects
are able to present an interface using CORBA or EJB technology that is callable from traditional
clients or other business objects. In any typical enterprise there are many systems that have
business objects that have some attributes that describe a location. In a CRM system, the
customer has an address, the store has an address, but neither of them are capable of
understanding their spatial relationship to one another. Simply geo-coding the addresses does
little to give them spatial awareness, all it does is allow them to be placed on a map. For spatial
awareness organizations have had to turn to GIS engines and move their data into a new
repository before they could answer the question “where” relative to anything. This is a costly
exercise for not only does the enterprise have to geo-code their data but they have to establish a
land-base with which they can generate the maps for viewing people, places and things in a
geographic context. This land-base may be easy to find for an experienced GIS person and they
will understand the nuances of geographic data and datums and projections. However, for the
average enterprise this skill-set is not going to be found in their IT departments or business units.
What happens is that for a simple question to be answered: “where is my customer?” or, “where
are they in relation to some thing (store, outside plant)?”, the enterprise has to expend large
quantities of time and effort, as well as the expense of data migration and cleanup and client
software that typically requires a workstation of an order of magnitude greater performance
specifications.
Surely there is an alternative? With the emergence of the WWW and networks of everincreasing
bandwidth, as well as the underlying n-tier architectures and objects being supported
by major database vendors, the answer is a resounding YES.
Software companies have long been striving for the object nirvana of write once and re-use many
times, and with Java and EJB or CORBA this is fast becoming possible. What if we extend this
concept to the land-base and had an on-line 7x24 database that had all the land-base for North
America, and it was accessible using the business object concepts and interfaces we have talked
about. Any application could discover the published interfaces to these objects and use them to
perform on-line GIS without having to understand GIS or expend the time and money required to
build and maintain the land-base for their region. Instead they could use the on-line GIS
capabilities to link their corporate systems in such a way that the business objects that have
location attributes can be given a unique key that says “I am here”! This is the USL concept. If
we are dealing with one version of a land-base then anything can be placed in context with it and
using the spatial operators defined by the on-line GIS associated with such a land-base could
simply ask “Where is my customer?”, “Where are the things I care about”, “Can I give my
customer the service they require?”, “Should I build a new store here?”. In e-commerce location
matters, one-to-one marketing requires an understanding of where your customer is in relation to
the business.
|
