Metaphor for Introducing & Teaching Map Projections: The world as a Piece of (Digital) Graph Paper

The ins and outs of projection systems can be complicated to introduce to new learners of GIS – and how much do you really need to know to create your first map? Over a coffee in the sunshine (it was hard work teaching summer school in Malta) Claire and I were discussing the question: How do we introduce map projections to new learners?

It turns out we both start with a demonstration. Claire uses her fist to represent the globe and her other hand to represent the piece of paper that is then wrapped around the globe (somewhat like the rock, paper scissors game). I on the other hand use a Clementine and a piece of paper – the paper crumples resulting from wrapping the paper around the Clementine represent the distortions that occur during the projection process. We both then go on to talk about grids etc...

Both of these illustrate the problem of modelling a complex reality in 2D. So if new learners imagined that a giant piece of graph paper is wrapped around the globe and that each place on earth is then marked on the graph paper it is possible to visualise the fundamentals of digital mapping.

The map window in a GIS is in essence a sheet of digital graph paper. One possibility is to harness this metaphor in our tutorials. Projection systems can be introduced simply within our scenarios, perhaps by activating and showing the grid (ie the sheet of graph paper) and asking the user to observe the coordinates changing as the mouse is moved horizontally and vertically.

It is important to understand the basics if you are using data that is not GIS ready. For example, one of the practical’s I have designed for the International GIS summer school at the University of Malta that I teach on uses a data set of road traffic accidents in England (from the UK open data initiative). The text file contains the X,Y location of each accident as an attribute field. In order to create point data of each accident the students need to know:

• 1) Why there is such a thing as a coordinate system?
• 2) How to identify fields containing coordinate data in the data set?
• 3) What coordinate system the fields represent?
• 4) How you can view the coordinates change as you move the mouse over your map

Reflective Teaching Practice: Do I need to know there is such a thing as a map projection?

Myself and Claire have just arrived back from the Island of Malta, where we both participate in the International Summer School in GIS held at the University of Malta. We both design and deliver lecture material targeted at professionals who are discovering how GIS maybe useful.

We were discussing our observations of the students and how they learn and interact with the GIS software and its theoretical principles.

One subject up for debate was, "do new learners of GIS and its concepts need to know immediately about projections?" There is a tendency to be puritanical about what concepts new learners of GIS need to understand putting aside this tendency, our conclusion was: “Not necessarily”.

Let me explain. Most everyday users of Bing Maps, Google Maps etc interact with the map quite happily without needing to know that a projection system makes it possible to create the digital representations of the world. The same can be said for users of navigation systems in cars or on phones.

Therefore, it is only natural that a new user of GIS, creating their first map using off the shelf Shape files or MapInfo Tabs (for example taken from Edina’s Digimap service), does not need their first interaction to introduce the complexities of coordinate systems that enable real world to be projected in 2 dimensions. It is only when their data they want to map is not GIS ready that they need to be introduced to a projection system.

Decision Time: Google Maps vs OpenLayers

Last weekend I attended the 2011 edition of WhereCampEU, held this time in sunny Berlin. It was a great conference, and Kate and myself presented our recent work on geoweb usability at the conference, even though we haven't had a chance yet to do a comprehensive analysis of the user experiments data we collected. I will put online the presentation in due time. Some lively discussions ensued about the nature of OSM, differences between traditional GIS interfaces and neogeography applications, and to what extent it should conform to establish practice in terms of UI (established by Google with for example the Search Bar).

The second day came with a set of more advanced technical discussions, most notably a discussion session on differences between webmapping frameworks (nicely captured in this whiteboard). This discussion was of particular interest to the JiscG3 project, as we need to decide which webmapping framework to implement.

One of the first conclusions from the discussion was that altough there are other libraries, for most geoweb developers, the choice really comes down to Google Maps API vs Openlayers (on its own or inside a UI framework such as GeoExt or MapQuery). The conclusions from the discussion can be summarised under the following headings:

1. The documentation and code examples for OpenLayers, when compared to the Google Maps API documentation still leaves a lot to be desired. For example, the OpenLayers code documentation often leaves out important details regarding necessary options, which are hidden in an options object. And while the provided code examples are good at showing what can be achieved, they fail to guide the user through the architecture and development process necessary for the development of OpenLayers applications.
2. Some users felt that OpenLayers necessitates a much deeper understanding of GIS to be able to develop functionality than Google Maps API. I guess this goes hand in hand with the more advanced functionalities of OpenLayers, for example by supporting OGC services such as WFS and WMS.
3. OpenLayers was also criticised for its default UI elements, which are relatively primitive and unpolished in today's Web2.0 world.

I won't go into much detail here, as the discussion and its outcomes have been discussed by both people in the session, as well as members of the OpenLayers team.

For our project, the decision between OpenLayers or Google Maps API clearly presents a trade-off between the characteristics and benefits of both libraries, as well as practical resource considerations.

For OpenLayers speaks the ability to include different base maps, and the inclusion of a wide set of layers from different data sources. This openess comes with the price of increased complexity and development resources needed, and the issue of integrating and developing an coherent set of UI elements for our site.

The Google Maps API on the other hand presents perhaps a more restricted set of functionalities, precluding the easy integration of different basemaps at this stage. But the Google Maps API is easier to develop for, with an excellent documentation and help functions guiding developers through the architecture, examples and options for developing a web mapping application.

In the end, and through discussion in the team, the winning argument was the fact that we are making use of an existing code-base from a previous project, which was built on top of the Google Maps API. In practice for the JiscG3 project, both libraries would be suitable, and so the decision for the Google Maps API allows us to reuse the existing codebase as a solid and proven basis on which to minimise new development time, and focus on the new functionality needed for this project.

OpenLayers isn't completely out of the picture though, and provisions are being taken in the codebase to facilitate at a later stage the replacement of the web mapping libary, when more flexibility for example in terms of basemaps is needed.