skip to main content

TAMU Webmaster's Blog

Information and insight from the A&M Webmasters

Campus Maps Architecture

October 8th, 2008 by tamuwebmaster

As I stated in the previous post, I have been doing a lot of research into GIS solutions and web mapping technology. The first rewrite version of the campus map was used to replace an old set of images that had become outdated and difficult to maintain.

This version is going to go above and beyond that. This will not be just a single silo application that goes from database to web browser. We are planning on bringing web, mobile, and flash versions online, adding live content, and providing some new features like walking distance/time calculations, and possibly enabling log-ins to view class schedules and creating custom maps.

We are also going to break up the administrative side so that as we bring on collaborative partners, we can hand over administrative functionality to the people who already create and provide the relevant information. Read more for a detailed high level architecture explanation.

Below is an image outlining the high level architecture, and under that is a description of each component and what it brings to the table:


A: Resource Layer – Databases and Web Services

This layer is really just a grouping of resources such as databases (A.1) and third party web services (A.2) from which the mapping system gets raw data. These web services are provided by third parties such as on campus collaborators (providers), Google Maps services, Yahoo Weather Services, and many others.

B: GeoServer WMS/WFS Server

GeoServer is an open source project for serving raw spatial data in a standards compliant formats (WMS/WFS) (B.1) developed by the Open GeoSpatial Consortium (OGC). It can serve up ESRI Shapefiles, Google Maps layers, NASA layers, and database backend layers for points, lines, and polygons. It is a mature server and it will serve as the tile builder for the base layers, as well as some of the overlays that are put on top of the base layer. This really increases of flexibility and allows some of the more complex GIS operations to be handled by a group that developers in that area full time.

GeoServer will be used most for base layers in the ASP.NET OpenLayers web map (F.3), as well as by other sites (F.1) that want more than a basic map. It’s responses will also be cached sometimes by the next layer (C) to alleviate network usage talking to layer (A).

In the diagram, there are two channels of communication. One for simple public base layers that go from layer (B) to layer (F), and one from (B) to (C). The difference here is in the security requirements. Layers that do not contain sensitive information will be made available for reuse by the public, and layers that must be protected with AuthN and AuthZ will sit behind the business logic layers, eventually made public – if appropriate – through Layer (E).

C: Data Caching Layer

The Data Caching Service (C.1) will be a .NET Windows Communication Foundation (WCF) service that will initially probably reside on the same physical server as layers (D), (E), and (F).  However, as raw data feeds and data collected in our databases increases, this layer can be moved to another server to provide cached results, and long running data intensive process results. This service provides two critical functions:

  1. Minimize the stress put on third party web services by repeated calls for popular information. Each third party service provider will negotiate a Service Level Agreement (SLA) that specifies maximum load, cached data timeout values, and other information. This information will be used by the Caching Service (C.1) to meet that agreement.
  2. Provider faster response times for the lower layers (D,E,F) so that the user on layer (G) gets the data as fast as possible with the most accuracy possible. Since certain GIS features can be time sensitive, this layer becomes important by providing updated information without putting undue stress on services in layer (A).

D: Resource Access Service Layer

Because of the wide range of data sources available, an abstraction layer for data access is essential to a solid, flexible application. This allows us to change out database backends (from Postgres to Oracle for example), or web service consumer implementations (from SOAP to JSON) without affecting the rest of the application. These interactions can also be tested in isolation to ensure the system(s) work as intended. The services and databases can also be moved without a great deal of recoding (if any) because those details are stored in metadata.

This layer is also comprised of WCF services (D.1). Initially they will run in binary mode over local pipes for speed. If the data layer ever needs to be given it’s own physical machine, it will change to using HTTPS. The nice thing about WCF is that this change has absolutely no effect on the code, only on the metadata for the service application. Again, solid layers with the flexibility to move around and scale as needed.

E: Business Logic Services (BLS)

The BLS layer is where the actual rules and operations of the application get handled. This is the first publicly accessible service besides the base maps provided by GeoServer. It offers services such as authentication (redirection to CAS) and authorization to certain actions (admin, student roles, etc).

The components in layer (F) will all use standard APIs defined in this layer and make calls to HTTPS SOAP services. Third party applications may also incorporate these services in their applications, in the case where we offer some functionality that is not available through other services (such as Google Maps). Our services will also be specific enough to serve the A&M campus, but should be extensible enough to allow other universities to take this portion of the system and reuse it for their mapping needs as well.

(E.1) represents the admin services. They are separated from the public services (E.2) so that they can be updated independently. For example, if a SLA is negotiated between a department that maintains a data set we originally implemented ourselves, we can give them the admin APIs and authorization to use them. Without affecting the public services,  the administrative features can now be utilized by people closer to the raw data. (E.2) is just the public way this data is made available to the components in layer (F).

F: User Interfaces

In today’s web applications, web browsers on the desktop are no longer the only target for websites and applications. The User Interfaces layer is really a collection of presentation mediums for various Clients (G). Developers have to not only consider browsers (F.3), but mobile phones and PDAs (F.2/F.4), custom feed readers (RSS, Atom), and applications such as Google Earth and GPS devices (F.4).

Consider the potential of providing visitors and students with GPS information (F.4) that can be imported into a GPS device for their visit or class schedule. Game day services such as parking and ticket locations are also possible in this manner. With a variety of presentation formats, this is possible and it is easy to adapt to new technologies and demands.

G: Clients

This is where a user such as a student, faculty member, or staff member actually interacts with the application. They may be using a web browser (G.1) or a PDA with Google Maps (G.2) such as the iPhone. They should get a consistent representation of the data, regardless of the device they are using.

This means that users using Internet Explorer or Firefox on a Windows or Mac desktop will see the same data that a user on an iPhone will see. However, we have now added the ability to take advantage of device specific operations. For example, using the iPhone’s GPS ability to show the user on the map as well. The browser cannot do this, but by seperating presentation of data from the data itself, we can make this possible. So in the browser, users see a larger map with little user location awareness, and users on the go with a mobile phone will see a smaller image (faster loading) and features specific to mobile users (such as “you are here”).

As more and more clients become available to consuming spatial data related to other information, this client layer will allow us to quickly adapt and answer those  new technologies.

Wednesday, October 8th, 2008 Campus Maps
Share this article

No comments yet.

Leave a comment