GEOG 585
Open Web Mapping

System architecture for web mapping

Print

It can take several different physical machines to create, serve, and use a web map. These are often depicted in diagrams as separate levels, or tiers of architecture. In this course, you'll likely use just one machine to play all these roles; however, it's important to understand how the tiers fit together.

 System architecture for GIS web services
Figure 2.1 System architecture for web mapping.
Credit: Icons by RRZEicons (Own work) [CC-BY-SA-3.0], via Wikimedia Commons

For example, you might have:

  • desktop workstations that are used by administrators and internal client applications. These machines will also be used to prepare data, author maps, and sometimes administer the other machines.

    In this course, you will be using QGIS and some command line libraries such as GDAL to accomplish these tasks. GeoServer also has a web-browser-based administrator dashboard that you would use from this machine.

    In some cases, your web map may be designed solely for the use of people within your organization and may never see the open web. In this scenario, client applications may also reside on these desktop workstation machines.
  • a database and/or file server holding all of your GIS data. This machine might be equipped with redundant storage mechanisms and regular backup scripts that prevent the loss of data.

    In this course, you'll be using folders of shapefiles for some of the exercises. If you had decided to use a database like PostgreSQL or MariaDB, it would also go on this tier.
  • a geospatial web services server that has specialized software and processing power for drawing maps, responding to feature queries, and performing GIS analysis operations.

    In this course, you will use GeoServer to host your web services.
  • a web server that acts as a web entry point into your organization's network. This is also called a proxy server. It is protected by firewalls that shield malicious traffic into your internal network. It's also a place where you can put web application code (such as HTML and JavaScript files) for your web maps.

    In this course, you will just be using GeoServer on your local machine; therefore, you will not install separate web server software. GeoServer comes with an embedded “servlet” called Jetty that gives you a simple endpoint to your web services that you can locally access for testing. In a more formal setup where you wanted to reveal your GeoServer web services to the world, you would have a web server such as Apache that would forward requests to GeoServer.

    In this course, you will put your web applications in your Jetty home folder (if the application uses GeoServer) or your Penn State personal web space using the PASS Explorer application (if your application does not use GeoServer). The Penn State IT staff has configured your PASS space to be a safe web entry point for your files.
  • many client applications that use the web map. These can be apps that run on your desktop workstation or they could be mobile apps. The clients may be based within your network, or you may allow them to come from outside your network. All clients must be able to make web requests through HTTP, and any client coming from outside your network must have an Internet connection.

    This is the tier you usually have no control over; therefore, it's important to design for different browser versions, screen sizes, ambient lighting, and so forth.

    In this course, you can use any modern web browser to test your apps and services. You can also use a mobile browser, such as Safari on the iPhone, to test the apps that you place on your personal web space.

Again, when developing and testing a web map, you can certainly use a single physical machine to play all these roles. This is a common practice that keeps things simple and more economic. When you work for a “real world” company with its own network and you are ready to deploy your web map, you will move your tested services and applications into a formal “production” environment where you have individual enterprise-grade machines for each role, as described above.