Published on GEOG 585: Web Mapping (https://www.e-education.psu.

edu/geog585)
Home > Lessons > Lesson 1: FOSS and its use in web mapping

Lesson 1: FOSS and its use in web mapping

The links below provide an outline of the material for this lesson. Be sure to carefully read through the entire lesson before returning to
Canvas to submit your assignments.
Note: You can print the entire lesson by clicking on the "Print" link above.

Overview
In this lesson, you'll learn some of the history of web mapping and why web services are so important. You'll also learn about free and open
source software (FOSS) and the benefits and drawbacks of using it. Finally, you'll get the chance to install and use QGIS, a FOSS solution for
desktop GIS work. QGIS will help you preview and manipulate your data as you prepare to create web maps later in the course.
Objectives

Describe the roles of clients, servers, and requests and how they contribute to web service communication patterns.
Identify benefits and challenges to FOSS and how they should be weighed when choosing a software platform.
List common FOSS solutions for general computing and GIS and discuss how you have seen these used in the “real world.”
Recognize when and how FOSS might be used in a “hybrid” model with elements of proprietary software.
Add and symbolize GIS data in QGIS.
Checklist

Read the Lesson 1 materials on this page.

Complete the walkthrough and post your final screenshot as a post on the "Lesson 1 walkthrough result forum" on Canvas.
Complete the Lesson 1 assignment, which involves readings and a discussion.

The history and importance of web mapping

For decades, most digital geographic information was confined for use on desktop-based personal computers (PCs) or in-house mainframes
and could not be easily shared with other organizations. GIS analysts would access data from their own workplace computers that were often
connected to a central file server somewhere in the office. Specialized software was required to view or manipulate the data, effectively
narrowing the audience that could benefit from the data.
With mass uptake of the Internet in the mid-1990s, people began thinking about how maps and other geographic information could be shared
across computers, both within the organization and with the general public. The first step was to post static images of maps on HTML pages;
however, people soon realized the potential for interactive maps. The first of these, served out by newborn versions of software such as Map
Server and Esri ArcIMS, were horrendously pixelated, slow, and clunky by today's standards. Limited by these tools, cartographers had not yet
arrived en masse on the web mapping scene, and most of the maps looked hideous. However, these early interactive web maps were
revolutionary at the time. The idea that you could use your humble web browser to request a map anywhere you wanted and see the resulting
image was liberating and exciting. See Brandon Plewe's 1997 book GIS Online (findable in many university geography libraries) to get a feel for
the web mapping landscape at this time period.
These early, dynamically drawn web maps ran into challenges with speed and scalability (the ability to handle many simultaneous users). The
server could only accommodate a limited number of map requests at a time before slowing down (at best) and crashing (at worst). Web maps
matured significantly in these two metrics when websites began to serve out tiled map images from pregenerated caches. Why ask the server
to draw every single map dynamically when you could just put forward an initial investment to predraw all possible map extents at a
reasonable set of scales? Once you had the map images drawn and cached, you could serve out the images as a tiled mosaic. Each tiled map
request was satisfied exponentially faster than it would take to serve the map dynamically, allowing for a server to accommodate hundreds of
simultaneous users.
Following the lead of Google Maps, many sites began serving out “pre-cooked” tiled map images using a creative technique known as
Asynchronous JavaScript and XML (AJAX) that eliminated the ubiquitous and annoying blink that occurred after any navigation action in earlier
web maps. Now you could pan the map forever without your server gasping for breath as it tried to catch up.
Cartographers, who had largely been resigned to trading aesthetics for speed in web maps, also realized the potential of the tiling techniques.
No longer would the number of layers in a map slow down the server: once you had pregenerated the tiles, you could serve a beautiful map
just as fast as an ugly one. Web maps became an opportunity to exercise cartographic techniques and make the most attractive map possible.
Thus were born the beautiful, fast, and detailed “web 2.0” basemaps that are common today on Google, Microsoft Bing, OpenStreetMap, and
other popular websites.
As web browsers increased in their ability to draw graphics using technologies such as SVG and later WebGL, the possibilities for interactivity
arose. On-the-fly feature highlighting and HTML-enriched popup windows became common elements. For several years, developers
experimented with plug-ins such as Adobe Flash and Microsoft Silverlight for smooth animation of map navigation and associated widgets.
More recently, developers are abandoning these platforms in favor of new HTML5 standards recognized by the latest web browsers without
the need for plug-ins.
Although maps had arrived on the browser by the mid-2000s, they were still largely accessed through desktop PCs. The widespread adoption
of smartphones and tablets in subsequent years only increased the demand for web maps. Mobile devices could not natively hold large
collections of GIS data, nor could they install advanced GIS software; they relied on web or cellular connections to get maps on demand. These
connections were either initiated by browsers on the device, such as Safari, or native applications installed on the device and built for simple,
focused purposes. In both cases, GIS data and maps needed to be pulled from the organization's traditional data silos and made available on
the web.
The importance of web services

All the above web mapping scenarios are possible because of web services. If you search the Internet, you'll find many definitions of web
services and can easily get yourself confused. For the purposes of this course, just think of a web service as a focused task that a specialized
computer (the server) knows how to do and allows other computers to invoke. You work with the web service like this:
1. You invoke the web service by making a request from an application (the client). To make this request, you usually use HTTP, a standard
protocol that web browsers use for communicating between clients and servers. The request contains structured pieces of information
called parameters. These give specific instructions about how the task should be executed.
2. The server reads the request and runs its web service code, considering all the parameters while doing so. This produces a response,
which is usually a string of information or an image.
3. The server sends you the response, and your application uses it.
Examine how the following simple diagram describes this process, returning a map of current precipitation:

Figure 1.1 Example request and response flow of a web service that draws maps.
Figure 1.1 Text description [1]
Credit: Sterling Quinn
Now, for an example. Let's suppose that you've identified the URL of a web service out there somewhere that draws maps. You make a
request by constructing a URL (http://...) containing the address of the web service and various parameters for the map, such as the format of
the image you want to receive (JPG, PNG, etc.), bounding box (coordinates defining the geographic area you want to see mapped), and map
scale. You paste this into your browser's address bar and the server sends you a response containing the map image you requested.
Here's an example of just such a request, using a radar map of the United States. First, see if you can identify some of the parameters in the
URL. Then take a guess at what the response will look like when you get it back. Then click the link to invoke the web service and get the
response:
http://mesonet.agron.iastate.edu/cgi-bin/wms/nexrad/n0r.cgi?
SERVICE=WMS&REQUEST=GetMap&FORMAT=image/png&TRANSPARENT=TRUE&STYLES=&VERSION=1.3.0&LAYERS=nexrad-
n0r&WIDTH=877&HEIGHT=276&CRS=EPSG:900913&BBOX=-15252263.28954773,2902486.4758432545,-6671748.242369267,5602853.811101243
[2]

As you examined the URL of this request, you might have noticed parameters indicating the width and height of the image, the image format,
the image background transparency, and the bounding coordinates of the map to be drawn. These parameters provide specific details about
how the web service should run its map drawing code. You see these parameters reflected in the response image sent back to your browser
when you clicked the link. In a future lesson, you'll learn about more of the parameters in the request above.
Not all web requests invoke web service code. Some web requests just return you a file. This is how tiled maps work, and this is why they are
so fast. You'll learn more about tiled maps in a later lesson, but examine the following request for a specific zoom level, row, and column of a
tile:
http://a.tile.openstreetmap.org/15/11068/19742.png [3]
The request drills down into the server's folder structure and returns you the requested PNG image as a response. No special code ran on the
server other than the basic file retrieval, therefore you could argue that a web service was not invoked. However, this type of simple web
request is also an important part of many web maps.
At this point, you might be thinking, “I've used web maps for years and I have never had to cobble together long clunky URLs like this. Have I
been using web services and other web requests?” Absolutely, yes. As you navigate Google Maps, your company's online map site, and so on,
your browser is sending hundreds of web requests similar to this one. You've just never needed to know the details until now. When you begin
setting up your own GIS server or designing your own client web application, it becomes important to understand the theory and architecture
behind web traffic.
Not all web services use the same format of URL and parameters. In this course, you'll learn about some of the most common formats for
online web services, especially ones that have been openly developed and documented to work across software packages.
Viewing web service requests in real time

Here's a simple way you can view web requests made “behind the scenes” by your browser as you navigate a website. These instructions are
for the tools provided by Mozilla Firefox. Chrome and other browsers have similar tools that typically go under the name "developer tools" or
"web tools" and should not be difficult to locate. 
1. Open Mozilla Firefox (if it's not already running) and from the main menu choose Web Developer -> Network . This will open the
developer tools window in the bottom part of your browser. At the top of the window, you can see different tabs "Inspector", "Console",
and so on. Right now, the "Network" tab is active, which is for monitoring network traffic. In addition to the "Network", the "Console" tab
will be important for this course because it will show the Javascript and other error messages if something is not right with your
Javascript code.
2. Make sure that All is highlighted in the menu of filters below the tabs (which will contain items such as All, HTML, CSS, JavaScript, etc.).
3. Hit this website for the Portland TriMet interactive system map [4] (note that this site exclusively uses FOSS mapping software).
4. Navigate the map of the Portland transportation system.
5. Notice the web requests as they are sent. You'll see a lot of requests appearing for map tiles.
6. Hover over a request to see its full URL. If the response is an image, hovering over the little thumbnail in front of the URL will show a
larger version of the returned image. 
7. When an entry in the list of requests is selected, the right part of the window will show many additional technical info about the request
and response. 
This kind of developer tool will be valuable to you later in the course as you develop your own web maps, mainly for troubleshooting scenarios
where you expect a map to show up and your browser does not send you the expected response.
References

Plewe, B. (1997). GIS online: Information retrieval, mapping, and the Internet. OnWord Press.

Understanding FOSS and its use in web mapping

The term “free and open source software” (hereafter referred to as FOSS) includes a number of ideas that can invoke complex and even
emotional discussions within the technical community. To begin to describe this term, it's important to understand that software development
is more enigmatic and artistic than other crafts in the tech industry [5], such as computer chip design. Software cannot be seen, touched,
tasted, or described in a physical sense, other than the number of megabytes it occupies on your computer. Software often begins as ideas on
a whiteboard, which are then encapsulated into intangible “classes” and "objects" of code by a programmer. These are then assembled into
invokable sets of concrete tasks and dressed with a user interface of buttons, menus, and icons that require a whole other skillset of aesthetic
design.
As a result of all this work, software is an empowering technology that enables a person to make practical use of computer hardware. In fact,
specialized software can often cost much more than the physical machine that it runs on. Software is your window into printing, painting,
calculating, storing data, and, in our case, making maps.
Given the value of software, it's no surprise that commercial businesses invest millions in researching, developing, and selling proprietary
software. They protect it through patent and copyright laws. They obfuscate (scramble) the code to make it harder to copy or reverse
engineer. Commercial software development has become a successful enterprise whose resulting tools have shaped our work and home
environments.
At the same time, some software users and developers have advocated that there are benefits from making software source code freely
visible and able to be modified or shared without legal or technical restraint. Business benefits, technical benefits, and moral arguments have
been invoked in support of this concept of “free and open source software.”
It's possible to get confused when learning about FOSS, because the word “free” carries several meanings in the English language. A common
analogy describing the F in FOSS is “free as in free speech, not free beer.” In other words, FOSS is “free” in the sense that it is open and
amenable to use and modification. (You may sometimes see the term Free/Libre [6] Open Source Software (FLOSS) used to communicate this
idea.) A whole range of license types [7] are used with FOSS that specify the conditions surrounding the modification and reuse of the software,
along with the attribution required on any derived products.
While the selling of FOSS is not necessarily restricted, FOSS is usually available free of charge. All of the software we'll use in this course can be
downloaded directly from the Internet and requires no fee, although donating a few dollars to your favorite project is a good way to invest in
its continued development.
If FOSS is usually available without cost, why is it such a successful concept? And how do people make a living from coding with it? First, it's
important to mention that many developers contribute to FOSS solely for personal enjoyment and for the desire to donate their skills to a
project offering wide societal benefits. They enjoy working on virtual teams and facing the challenges of rigorous software development that
their ordinary “day jobs” might not offer.
At the same time, though, many individuals make a generous living by selling services and training related to FOSS, and some of these efforts
may increase the quality and number of FOSS features available. For example, suppose your company invests in a FOSS package that does
everything you want at $30,000 cheaper than the proprietary software alternative; however, it's missing “Feature X” that is critical for your
workflows, and you don't have a programmer who can implement Feature X. Because the code for the software is all open to examination,
modification, and extension, you can contract with Rock Star Programmer to implement Feature X for you for $10,000. If Feature X is widely
applicable to the good of the product, and you and the contractor are okay with the idea, Feature X may eventually be rolled into the core
source code so everyone can benefit from it.
Other people may not contribute frequently to FOSS projects, but can still make a profit selling support services for FOSS software. When you
buy proprietary software, you often are given access to a technical support package that allows you to call and talk to an analyst if needed.
Because FOSS does not offer these official support systems, enterprising individuals have stepped in to fill this void. See this article in Linux
Insider [8] for more commentary on FOSS services consulting.
Finally, several new firms are building subscription-based online services that are created using open source building blocks and may even be
released under open source licenses. The services are offered for a subscription cost that is lower than most organizations could achieve if
they attempted to build their own comparable infrastructure or quality control procedures. Through these FOSS-based Software-as-a-Service
(SaaS) offerings, the value of the free software is passed on to many buyers.
Although there are many FOSS purists out there, the decision to use FOSS does not have to result in a full migration away from proprietary
software. Many businesses and governments use what might be termed a "hybrid approach," incorporating a mix of FOSS and proprietary
software depending on their budget, staff skills, and technical needs.
Let's consider some of the benefits, challenges, and other considerations that the adoption of FOSS brings into your workflows.
Benefits of FOSS

As you begin the endeavor of learning to use FOSS, it's helpful to understand some of the benefits that you may see:
Lower cost software – The reason FOSS can be offered free of charge is discussed above. Even if you have to spend a substantial
amount on training, support, and consulting, these expenses may not reach the amount that you would have spent for a proprietary
software package.
More flexibility with the software – If you commit to a proprietary software vendor and you really need Feature X or Bug Fix Y, your
ability to persuade the vendor to add this feature may depend on the size of your contract, how many other people want the feature,
and when the next software release is available (unless you are an important enough customer to warrant a specially-built hotfix or
patch). If you are a small customer and the feature you want is obscure (albeit mission critical to you), then you may wait for years and
never see it added. With FOSS, you can add the feature or fix a bug at any time, and your only limits are the programmer skills you can
find.
Interoperability of the software – Many FOSS offerings attempt to abide by open specifications for data and web services so that they
can interact seamlessly with other products. You will learn about some of these specifications for geospatial data later in this lesson and
course.

Many proprietary software vendors indeed support the reading of open specifications, but often they will write data into proprietary data
formats that can only be processed by the vendor's software. This becomes a problem when open government initiatives come into play,
as demonstrated in March 2013 when the Ohio Supreme Court ruled [9](*) that Scioto County was justified in asking a citizen for a $2000
fee in response to a Public Records Act request for its GIS data. The reason for the fee: the data was inextricably intertwined with
proprietary GIS software and would require extra effort to extract.
* If the link does not work for you, the reason most likely is that you are located outside the US; just search for the event on the web and
you should be able to find some articles about it.
Security – Militaries, banks, and other government agencies have gravitated toward FOSS because they have a full view of its
cybersecurity mechanisms and can patch or modify these according to their own desires. Some agencies will not use a new version of
any software until it has passed a rigorous security certification process. FOSS allows for more agile response to issues that are brought
to light during this testing.
Ethics –  Some people view the use of open source software as an ethical question. Creating and using software that is part of an
intellectual commons is a powerful motivating factor for many open source advocates. The development and use of FOSS contributes to
the expansion of collective human knowledge.
Challenges of FOSS

A danger of evaluating FOSS systems is to allow the potential exciting benefits to obscure the real challenges that can accompany a FOSS
deployment. Some or all of the challenges below can be mitigated, but proprietary software may offer a smoother road in these areas, if you
can bear the cost.
 Usability – Designing a user-friendly software product requires a much different skill set than that required to write back end software
code. When the author of this course worked at a proprietary software vendor, he held the title of “Product Engineer.” These were people
whom the company hired to work with the developers to design, test, and document the product. They did not write source code; they
just concentrated on making a usable product.

Good product engineers are hard to find and hire, even when you are a proprietary software company with attractive salaries to offer.
When the number of coders working on the back end logic of a FOSS project outweighs the effort going into user interface design, then
usability can suffer. Compounding this problem is the need for frequent iteration and clear communication between software designers
and developers. In the halls of a proprietary software company, this may occur more readily than in the online collaborative forums
driving FOSS.

Some people who work on FOSS may vigorously debate this point, so as you work with FOSS in this course, be aware of its level of user-
friendliness compared to proprietary software, and draw your own conclusions.

Documentation availability – Just as proprietary software companies pay designers and test engineers, they also are expected to deliver
a fully documented product. Thus, they hire technical writers who can produce software manuals, online tutorials, and other training.
There is a business incentive for this: if your product isn't well documented, it will get a negative reputation in the community, and
people will stop buying it.

When software is delivered free of charge, you rely on the benevolence of project contributors to provide any sort of documentation,
much of which may be produced in the forms of wikis, tutorials, and forum posts. This can be maddeningly unstructured to someone
accustomed to proprietary software whose documentation is expected to "just be there” in a single unified and searchable help system.

Some FOSS documentation is excellent, and it's important to respect the people who contribute, proofread, and translate it. However,
beware that FOSS is often created by very bright individuals who can Just Figure Things Out using minimalist or fragmented sources of
information, and they may expect that you can play at this same level as you try to use their product. In both proprietary software and
FOSS, documentation quality can sometimes be slighted or given lower priority when the initial coding and testing have been completed
and everyone is itching to get the product out the door.

Just as you did with usability, pay attention to documentation quality, and make your own judgment as you work through the course.
Would you be able to figure things out without the course walkthroughs guiding you? How does it compare to the proprietary software
help that you have used in the past?

Support availability – As mentioned above, many third-party contractors offer technical support and consulting for FOSS products;
however, the advantage of purchasing support from a proprietary software vendor is that the people who developed the software are
often accessible by the support team. Thus, the support team can get a closer understanding of the intent, logic, design, and planned
trajectory of the software. They may also maintain a large database of both internally and externally documented bugs that can help find
you a workaround in a hurry. Although it may be possible for a FOSS support consultant to learn some of these same types of things, the
support experience is not as smoothly integrated.
Contested points

Some aspects of FOSS and proprietary software are not as clear when it comes to deciding which type of software owns the advantage.
Breadth of features – It can be argued (and you will see this in the Ramsey video required later in this lesson) that FOSS offers a more
focused, prioritized list of features and may not be able to compete with proprietary software when it comes to sheer number and depth
of features. At the same time, the flexibility of FOSS allows for infinite features to be added via plug-ins and direct modifications for the
source code, something that cannot always be said for proprietary software where limited lists of new features are released via periodic
updates. It should be noted here that if the proprietary software offers good APIs (in other words, programming frameworks), it, too,
may be extended to a limited degree by third-party developers.
Quality and technical superiority – The “bugginess” of FOSS compared to proprietary software probably depends on the products in
question, how mature they are, and who's developing them. FOSS advocate Eric Raymond argued that “given enough eyeballs, all bugs
are shallow,” contending that it would be difficult for any major issues with FOSS to go unfixed for long among a broad community of
developers. It's less clear who fixes the obscure bugs that you hit and others don't. If you can't convince someone in the FOSS community
to fix it, you could at least attempt it yourself or hire a consultant.

Proprietary software vendors obviously have business incentives to fix bugs; however, they also have business incentives to NOT fix
certain obscure bugs if the time, effort, and risk to do so would not provide a good return on investment. If you're a small-potatoes
customer with an obscure bug holding up your project, you'd better start looking for a workaround.
Innovation – Does innovation occur more readily in a proprietary software company where large amounts of research and development
dollars can be invested in full-time employees who collaborate face-to-face, or does it thrive in an environment where all the code is
available for perusal and experimentation by anybody? Part of the answer may depend on how much the proprietary software company
operates on a “reactive” basis as compared to a forward-looking vision. It also depends on whether the company's goals encourage
certain types of development at the expense of others.
 Innovation rarely occurs in a vacuum. Some would argue that innovation happens more freely when there are more elements in the
intellectual commons that can be drawn upon.
Examples of widely-used FOSS

FOSS has been developed to support all tiers of system architecture. You've probably heard of (or used) some of this software before. For
example, the term “LAMP stack” refers to a system that is running:
Linux operating system
Apache web server
MySQL (or MariaDB) relational database
PHP application scripting language
Other variations of this acronym exist. For example, PostgreSQL is another open source relational database that is commonly used with GIS
because of the popular PostGIS extension. This results in a LAPP stack rather than a LAMP stack.
Other general-use FOSS includes the LibreOffice suite (similar to Microsoft Office), the Mozilla Firefox web browser, the Thunderbird e-mail
client, the Python scripting language, and more.
FOSS use in government

Some governments have begun mandating or encouraging the use of FOSS for government offices and projects. This is especially popular in
Latin America and Europe, with one of the more recent government decrees occurring in the United Kingdom [10]. Often the FOSS is
implemented first on servers and back-end infrastructure, then rolled out to desktop workstations in later phases.
These policies favoring FOSS come about for different reasons. Obviously, the savings in software licenses and the flexible security models
offered by FOSS are desirable, but sometimes there are political motivations to reject proprietary software companies and their countries of
origin (particularly in places where the United States is perceived as imperialist). If you are interested in more reading on this topic, I
recommend Aaron Shaw's study of the FOSS movement in the Brazilian government [11] and its tie to leftist politics [here is an alternative link
[12] to the paper in case the other link isn't working].

FOSS and web mapping

FOSS has a strong and growing presence in the GIS industry. Some tools and utilities for processing geospatial data have been around for
decades. For example, GRASS GIS [13] developed by the US Army Corps of Engineers recently turned 30 years old. To see what it looked like
back then, see this old GRASS promotional video [14] narrated by none other than William Shatner. I still use this video in introductory classes to
teach the benefits of GIS and the main components of a GIS system.
In this course, we'll use some of these desktop workstation GIS tools for previewing and manipulating our datasets before putting them on the
web. For example, later in this lesson, you'll install and explore QGIS [15] (previously known as Quantum GIS), one of the most popular and user-
friendly FOSS GIS programs.
There are also various FOSS options for exposing your GIS data on the web, either within your own office network or on the entire Internet.
These include Map Server [16], QGIS Server [17], and GeoServer [18], the latter of which you will learn in this course. These software offerings take
your GIS datasets and make them available as web services that speak in a variety of formats. They include a web server or are designed to
integrate with an existing web server, so that your web services can reach computers outside your own office or network.
FOSS can also be used to generate sets of tiled images or vector data that you can use as layers in your web maps. In this course, you'll learn
how to do this using a new tool recently integrated into QGIS.
Underlying both desktop and server GIS are the databases containing your GIS data. If you need something a little more complex than a folder
of shapefiles or want to make use of spatial database types, then you can use a FOSS GIS database. These include PostGIS [19] (which is an
extension to the PostgreSQL relational database) and SpatiaLite [20] (which uses the SQLite database). A lighter fare option for smaller datasets
is to use standalone files of GeoJSON, KML, GeoRSS, or other well-documented text-based data formats.
To pull all your map layers together and display them on a web page, you'll use a programming framework, or API. Some of the most mature
web mapping APIs are OpenLayers [21] and Leaflet [22], which you will use later in this course with the JavaScript programming language. Other
popular FOSS web mapping APIs include ModestMaps [23], D3 [24], and Polymaps [25].

The role of open specifications and open data

Not to be confused with open software, open specifications are documented and mutually agreed-upon patterns of how software and digital
data should behave in order to be interoperable between systems. For example, HTTP (hypertext transfer protocol) is based on a specification
defining how web servers and web browsers should communicate in order to exchange information. Without open specifications, you would
not be reading this web page.
How are open specifications used in web mapping?

In this course, we'll learn about two types of open specifications:

 Open data formats – Most GIS data formats are open in the sense that the way they are constructed is fully documented, and various
GIS programs can read and write them. Also, the inventors of these formats have not asserted the right to any royalties when you use
them.

KML and GeoJSON are some examples of GIS data formats that you can create just by writing a text document in a particular way. Most
raster formats such as JPEG or PNG are also open. The shapefile is one of the most common formats for exchanging vector GIS data,
because Esri has openly documented how to create a shapefile and relinquished any legal restrictions on creating shapefiles. In contrast,
an example of a closed data format is the Esri file geodatabase, because Esri has not openly documented how to create a file
geodatabase without using Esri tools.
Open specifications for web map services – There have been several efforts to openly document patterns that GIS web services should
use when communicating with clients. The Open Geospatial Consortium (OGC) has created several of these specifications, the most
popular of which is the Web Map Service (WMS). The USA weather radar service you accessed earlier in this lesson was an example of a
WMS. You will learn more about the various OGC specifications later in this course.

In a document called the GeoServices REST Specification, Esri has also openly documented the form of communication used by
geospatial web services in its products such as ArcGIS Enterprise and ArcGIS Online. This means that non-Esri developers are free to
build applications that read or serve web services according to this pattern. Although the GeoServices REST Specification was not
adopted by the OGC (a long story covered in a later lesson), it is an example of a specification that has been voluntarily made open by a
proprietary software vendor.
The role of open data

In this course, we'll also be using open data, which is data that has been made available to the public free of charge and bereft of most
copyright restrictions. These data may be shared by government entities, researchers, not-for-profit organizations, or ordinary citizens
contributing to online projects. For example, Data.gov [26] is a popular website offering datasets collected by the US government. And, later in
this course, we'll learn about one significant source of open GIS data called OpenStreetMap [27]. This is an online map consisting of voluntary
contributions in the style of Wikipedia.

Figure 1.2 Detailed OpenStreetMap data in Yaounde, Cameroon.

Credit: © OpenStreetMap contributors
Open datasets are often rich and exciting to include in web maps, but there are some precautionary measures you should follow in order to
be successful with using them. First, be aware that even though the data is free, you are often still required to provide attribution describing
where you obtained the data. You may also be restricted from redistributing the data in any way that requires a fee. When you use an open
dataset, you are responsible to carefully research and adhere to any attribution requirements. You should also make an effort to verify the
data quality by examining any accompanying metadata, researching the sources and collection methods of the data, and scrutinizing the data
itself.

The scope of this course

In this course, you will be getting some experience installing and using FOSS and creating web maps with it. While doing this, you will use open
specifications for GIS data and web services. You'll also learn how to use open data and contribute to OpenStreetMap.
Each week, you'll complete a walkthrough explaining some FOSS tool. Following the walkthrough, I will often ask you to apply what you've
learned to some of your own datasets you've found or collected. This will allow you to build up a comprehensive project as the course
progresses. The goal is to produce something you can host on your personal webspace and reference in a professional portfolio.
The functionality of our web maps will be relatively simple, limited to layer display and point-and-click queries. However, the frameworks that
we'll use are broadly extensible depending on how much programming you're willing and able to do.
Along the way, you'll pick up some skills with manipulating data (projecting, clipping, and so forth) with FOSS, which will hopefully prove handy
throughout your GIS career. Many of these tools can be scripted with Python and other languages that you may have learned already in other
GIS coursework.
Walkthrough: Installing and exploring QGIS
The first FOSS product you'll use is a GUI-based program designed for desktop workstations. It's called QGIS (kyoo-jis), although you should
know that sometimes in the past it was referred to as Quantum GIS. QGIS is somewhat similar in appearance and function to Esri's ArcMap,
which you've likely used in previous courses.
In this tutorial, you'll install QGIS and make a basic vector map with it. You'll use some shapefiles of downtown Ottawa, Ontario, Canada that I
originally downloaded from the OpenStreetMap database.
Download the Lesson 1 walkthrough data [28] (It is a folder of shapefiles that you should extract into a folder such as c:\data).
1. Visit the QGIS home page at www.qgis.org [29]. Take a few minutes to explore this introductory page and any links that look interesting.
This tells you a bit about who makes QGIS and what it can do.
2. From the main QGIS page, click the Download Now Button.

The usability of this page has greatly improved in the past few years. Because FOSS can run on a variety of platforms and can be built
directly from source code (as opposed to running an installer program), it's not uncommon with FOSS to see mind-boggling installation
instructions with all manner of parenthetical warnings, stipulations, dependencies, and links to obscure download pages. This was
previously the case with QGIS, but now the experience is much smoother.
3. You can now choose between the latest release of QGIS or the most recent long term release (LTR) version. The advantage of using the
LTR version, (version 3.22 at the point of this writing) is that the examples in this course have been tested with this version and things on
your screen will look very close to what is shown in the images you will see here. If you instead want to see all the features that QGIS has
to offer right now and don't mind that things may look slightly different, feel free to go ahead and install the latest release. You can
also install both version and switch between them.

For the Windows QGIS installers, you will also need to choose between 32 bit and 64 bit. If you don't know which one to select for your
machine, open Windows Explorer (by pressing Windows key + E) and look in your main drive (probably C:). If you have two Program Files
folders, one of the suffixed with "(86)" then you are running 64 bit Windows. If you just have a single Program Files folder, then you are
likely running 32 bit Windows.

To start the download, click on the QGIS Standalone Installer link for the version that you have decided to use under "Standalone
installers (MSI) from OSGeo4W packages (recommended for new users)". Once you've downloaded it, run through the installation
wizard and accept the default options:

QGIS can also run on Mac or Linux. You will see installation instructions for these platforms, and you are welcome to use them; however,
only Windows instructions are given in these lesson materials. (I know this is paradoxical for a FOSS course, but teaching you to use Linux
is outside the scope of these lessons.) If you get hung up, you may be expected to troubleshoot on your own or default to a Windows
machine in order to complete the exercises. If all you know is Windows, I suggest you stick with Windows for this course.

The QGIS installation will place some other shortcuts and programs on your machine, such as GRASS GIS and OSGeo4W. This is fine. In
fact, we will use some of these in later lessons.
4. Start QGIS. You can do this through the Windows Start Menu > All Programs > QGIS (Version name/number) > QGIS Desktop (Version
number).

You will notice many toolbars available. In QGIS, the button you click to add data depends on the type of data source. For example, you
click different buttons to add vector files, raster files, CSV files, web service layers, and layers from databases.
5. Drag the toolbars and windows around and clean up your display so that the layout looks something like the screenshot below (Figure
1.3). Don't worry about the order of the toolbars; just get them off the left-hand side. You may have to explicitly add the "Manage Layers"
toolbar to perfom the next step, as described below. Adding toolbars works the same as it does with ArcMap: just right-click any empty
gray area around the toolbars and select the desired toolbar from the menu that appears. Alternatively, go View -> Toolbars in the main
menu bar to toggle individual toolbars on and off. 

6. Click the button for adding vector data: 

Once you've clicked the button to add vector data, click the ... button and browse to the roads.shp file from the lesson data folder. Even
though a shapefile consists of multiple files, you just need to browse to the .shp when adding a shapefile in QGIS. Now click Add and then
Close to close the window again.
 Figure 1.3

7. In the layer list, double-click the roads layer. You'll see a Symbology menu and a bunch of styling options where you can set the line
color, the line width, a scale range for visibility, and labeling. Set the roads as a thin gray line.

Notice that in QGIS, you typically get a lot more symbol options if you highlight the deepest level of the symbol hierarchy, in this case,

Simple line.

Note: During this walkthrough, I will provide general guidance about which settings to apply, and I will lead you to the correct
neighborhood of dialog boxes to accomplish it; however, I will not provide point-and-click instructions for all actions. Although you may
curse my name for this, I am doing it deliberately so that A) you can think about what you are doing and B) you can develop the habit of
exploring new and unfamiliar software in a fearless manner. This is an essential skill if you are going to use FOSS.

That being said, it is not my intent to leave you frustrated and helpless. If something is not clear, please use the discussion forums to
help each other out. I will regularly monitor the forums to make sure your question doesn't languish unanswered.

Next, we'll put some labels on the roads.

8. In the Layer Properties dialog box, use the Labels tab to label the roads layer with the roads' name attribute using a small gray font (this
in the Text submenu). Set the label distance as 0.5 mm (this is in the Placement submenu of the Labels tab) so that the layer is not too
close or too far away from the line. When working with streets, you might also want to check Merge connected lines to avoid duplicate
labels (this is in the Rendering submenu). Finally, set Scale-based visibility (or Scale dependent visibility) preventing the labels from
displaying when the map is zoomed out beyond 1:10000. When you are finished, you should have something like this.

Figure 1.4

9. Add the dataset natural.shp and symbolize it as a light green fill with no outline. You will need to set the Stroke style to No pen in order
to accomplish this.
 Figure 1.5

10. This is a good time to save your map. Click Project > Save As and save your map as Ottawa.qgz. It will be easiest if you save it in the
same folder where your shapefiles live.
Note: You may be accustomed to using the .mxd format, and now is an opportune time to learn that .mxd is a proprietary format that is
used by Esri software. QGIS uses an easily-readable XML format for storing projects (.qgs file) and the .qgz file is a zipped version of the
.qgs file. You can also choose to store your project as an unzipped .qgs file and then open it in a text editor to inspect the XML code.
However, .qgz is now the default file format for QGIS.
11. Add buildings.shp to the map, and experiment with a multilayer symbol to make the buildings “pop out.” Here's how I set this up:

Figure 1.6

12. Add bus_stops.shp to the map, and symbolize it with an SVG marker that looks like a bus. In the Symbol layer type dropdown, select SVG
marker like in the image below. 
 Figure 1.7

SVG stands for “scalable vector graphics.” It's a way of making marker symbols that don't get more pixelated as you expand their size. If
you want a different color of marker, you can open the SVG in a graphics editing program such as the open source Inkscape, recolor and
save a new version of the graphic, and then browse to it in QGIS.
13. Set a scale range on the bus_stops layer so that it doesn't appear when zoomed out beyond 1:10000. You can do this in the Rendering
tab.

Figure 1.8

This is also a good time to set a user-friendly display name for this and other layers. The display name appears in the layer list. You can
change the display name in the Source tab.
 14. In the layer list, highlight the bus stops layer and click the Show Map Tips button. This button varies in appearance depending on the
version of QGIS you're using, but in all cases it contains a little yellow speech bubble, like this  . Map tips add some interactivity to the
layer, a la Google Maps, so that when you hover over a stop for a short moment, the name of the corresponding bus line will be
displayed. As we work with web maps during this course, we'll work with getting the same kind of interactivity for particular layers of
interest.
In some versions of QGIS, this will show the bus stop ID number by default rather than the name. To remedy this, open the bus stops'
Layer Properties again, go to the Display tab, and select the name field in the Display expression or Display name dropdown list.

Your map should now look something like the following:

Figure 1.9

15. Save your map, then add some more shapefiles and experiment with symbolizing and labeling things in an aesthetically pleasing way.
16. Post a screenshot of your beautiful QGIS map on the "Lesson 1 walkthrough result forum" on Canvas. Include some commentary about
any features you found useful.

Lesson 1 assignment: Responding to FOSS

In this week's assignment, you'll watch and read several opinions on the use of FOSS within the GIS community. I will then ask you to respond
to these in a detailed discussion below.
Readings

Read the online chapter Web GIS [30] from the GIS&T Body of Knowledge, a web-based resource used by educators to outline the essential
information that people should know about geographic information science and technology. This assigned chapter contains an overview
of the most important things to know about Web GIS, and mentions many of the topics that will be covered throughout this course.
Becoming familiar with the terms and acronyms in the glossary at the beginning will help you when you encounter these later on.

Watch the video below: A GIS Manager's Guide to Open Source. This is a talk given by Paul Ramsey, a major contributor to PostGIS. He
submits an argument for the use of FOSS and summarizes some of the FOSS tools available to geospatial professionals. Plan for 45
minutes to watch the entire video.

The Unknowns: A Manage…

Manage…

Click here for transcript of A Managers Guide to Open Source.

Credit: OpenGeoSuite [31]

Read the following items to see how a proprietary software company positions itself in the area of open source and how this changed
over time. Pay attention to which aspects of FOSS and open standards are emphasized, and, just as importantly, make note of which
FOSS projects are deliberately not mentioned:
1) Open Source Technology and Esri [32] - this news item is a historic account stemming from 2011
2) Esri's Open Vision [33] - Esri's current web site dedicated to its "open vision"; check out Jack Dangermond's initial statement linked at the
top and then just browse the content and links from this page a bit
Discussion

Make a post on the "Lesson 1 assignment forum" on Canvas that addresses both of the following questions:
 Which of Ramsey's observations about FOSS and proprietary software have you observed in your own home or workplace (does not have
to be GIS related)? Or, if you don't think Ramsey's observations are legitimate, justify why.
After studying this lesson, would you advocate the use of a pure FOSS approach for your GIS work, or are there certain elements of
proprietary software that you would retain as part of a hybrid approach? If the latter, which software would you want to keep as
proprietary?
You can optionally make two posts addressing the questions separately. You will be graded on the depth of the arguments that you put
forward in your responses and the evidence you produce to support these arguments, not on your opinions toward FOSS.
To receive full credit, please also write at least one response to another student's post building on whatever he or she said.
I encourage you to continue thinking about these questions throughout this course as you get more hands-on experience with FOSS.

Source URL:https://www.e-education.psu.edu/geog585/node/3
Links
[1] https://www.e-education.psu.edu/geog585/sites/www.e-education.psu.edu.geog585/files/lesson1/Figure_1.1_LD.html [2] http://mesonet.agron.iastate.edu/cgi-
bin/wms/nexrad/n0r.cgi?
SERVICE=WMS&REQUEST=GetMap&FORMAT=image/png&TRANSPARENT=TRUE&STYLES=&VERSION=1.3.0&LAYERS=nexrad-
n0r&WIDTH=877&HEIGHT=276&CRS=EPSG:900913&BBOX=-15252263.28954773,2902486.4758432545,-6671748.242369267,5602853.811101243 [3]
http://a.tile.openstreetmap.org/15/11068/19742.png [4] http://ride.trimet.org/?tool=routes [5] http://parrt.cs.usfca.edu/doc/software-not-engineering.html [6]
http://en.wikipedia.org/wiki/Libre [7] http://choosealicense.com [8] http://www.linuxinsider.com/story/67655.html [9]
http://www.courtnewsohio.gov/cases/2013/SCO/0307/121296.asp#.XNmp2ZNKiu7 [10] http://www.computerweekly.com/news/2240179643/Government-mandates-
preference-for-open-source [11] http://aaronshaw.org/papers/Shaw-2011-Insurgent_Expertise-JITP.pdf [12]
http://innovacionucb.pbworks.com/w/file/fetch/77872493/Aaron_2011_Insurgent%20Expertise-
%20The%20Politics%20of%20Free%3ALivre%20and%20Open%20Source%20Software%20in%20Brazil.pdf [13] http://grass.osgeo.org/ [14] https://www.youtube.com/watch?
v=U3Hf0qI4JLc [15] http://www.qgis.org/en/site/ [16] http://mapserver.org/ [17] https://docs.qgis.org/2.14/en/docs/user_manual/working_with_ogc/ogc_server_support.html
[18] http://geoserver.org [19] http://postgis.net/ [20] https://www.gaia-gis.it/fossil/libspatialite/index [21] http://openlayers.org/ [22] http://leafletjs.com/ [23]
http://modestmaps.com/ [24] http://d3js.org/ [25] http://polymaps.org/ [26] http://www.data.gov [27] http://www.openstreetmap.org [28] https://www.e-
education.psu.edu/geog585/sites/www.e-education.psu.edu.geog585/files/lesson1/Ottawa.zip [29] http://www.qgis.org/ [30] https://gistbok.ucgis.org/bok-topics/web-gis [31]
https://www.youtube.com/channel/UCaM-49dLjHOiQ0k0K4w5uhw [32] http://www.esri.com/news/arcnews/spring11articles/open-source-technology-and-esri.html [33]
http://www.esri.com/products/arcgis-capabilities/open-source