Cloud GIS: Indiemapper review

Update 12/6: I spelt Indiemapper wrongly as Indemapper which I've now corrected. Thanks for the heads up Maarten.

Introduction: Indiemapper is an online GIS from Axis maps, it compares with services like GeoCommons (my GeoCommons review) and the newly released ArcGIS Explorer online (James Fee's review).

I was really excited to dive in and experiment with it as it promised to enable good map design practices. Sure, you can still make ugly maps with it if you try hard but the defaults will nudge (in the sense of this nudge book) you to make good design decisions and contextual help is there to inform you of good design practice. No one will be surprised to hear I think this idea is a Very. Good. Thing.

I discussed Indemapper with Mark Harrower on a conference call before writing this review.

Pros:

• Good Map Design as Default: By integrating colorbrewer and typebrewer into the package and providing design advice in contextual help they've produced an app that promotes good design. Yay!
• Cloud Based: This is aimed at people who don't need the full power of desktop GIS and its a cloud based service so you can access you work from any computer.
• Group Working: Is also possible and I can see lots of potential for this.
• Contextual help: As well as supporting good design, contextual help is a real usability plus - instead of having to waste time finding the help section that deals with your particular problem, a contextual help button takes you straight to what you need.
• Integration with PhotoShop: Axis maps have made a point of making it easy to export from Indemapper into other software such as photoshop.

Sort of Neutral:

• Projections: Indemapper is promoted as being good at handling projections. I can see where Axis is coming from about this but I don't think projections are as important as they make out.

Cons:

• No User Manual (yet): Mark explained to me that one of the audiences they had in mind for Indiemapper was for people not expert in GIS who don't need full GIS functionality. For those people the GIS like interface is intimidating, they really need a set of step by step tutorials on howto make a map with Indiemapper. Contextual help just doesn't fill the need properly. Mark said they had a series of video tutorials planned covering this.
• Free for Educational Users: All Unis I know will have GIS teaching materials authored for Arc. IMHO to persuade a tutor to switch to Indiemapper for teaching the educational licence cost has to be zero and at the moment, its just a reduction. Both ArcGIS Explorer online and GeoCommons are both free.
• Desert Fog on Startup: When first opened Indiemapper has a blank screen. For users who have been making maps in NeoGeo tools like Google Earth or Google Maps, they will be confused and a little intimidated that there isn't a base layer visible. Better to have a default layer visible that users can change than a blank, desert fog screen.
• Static Maps only: Indiemapper isn't designed to produce interactive maps. Mark said this was something they would consider in the future. I agree with him that there's a ton of applications for static maps but I'd like to see some simple interactions possible - clickable pop up balloons with simple html would do.
• GIS Metaphor: Indiemapper works on a GIS metaphor in that a database is linked to a map. If you open a few layers and click on a point you will pull up the normal GIS attribute table. This is second nature to anyone who's worked GIS but newbie map makers will be confused, attribute tables and how it links to a map are quite a complex concept to understand and manipulate. Mark explained to me that the design team spent time discussing if there was a better way to organise a map than layers. I agree with their decision to use layers as the way to organise the map, I can't see a way around that, but I think they could have adopted an interface where data is still arranged in layers but the underlying data structure (XML as it happens) is hidden from the users view by simple screen interactions. Google Earth operates in this way, you don't get to see the KML with simple main screen operations.

Unlike my other criticisms, altering the GIS metaphor is probably a big structural change, so I doubt its worth implementing. That's OK so long as they make sure the issue is well covered in the video tutorials.

When Indiemapper is supported by video tutorials and able to produce simple interactions it's a tool I'd definitely consider for my teaching and for producing my own maps.

Google Earth Tours in Geog. Teaching III

This is a 3rd of a 3 part series. Part 1 was introduction and started the 'rules of flight'. Part 2 finished off the rules of flight. This post covers audio, annotations, testing, use of layers and a literature review that covers all three posts.

3. Audio:
Research shows that an audio commentary is much easier to understand than a narrative delivered via on screen text. Labels identifying major sections of the animation also add value. However, adding background music has been shown to be valueless - it's just a distraction in an educational situation.

Audio and visual elements should match in a GET because you shouldn't make users interpret two different presentations at the same time. A critique of a GET which did not follow this advice can be found in an earlier blog post of mine under the heading; "Talk about what's on Screen"

Audio Practicalities: I describe how to produce an audio GET in this tutorial

4. Annotations:
If the GET audio track has a descriptive line like 'and here you can see the extent of the Scottish Highlands' use an on screen marker such as a polygon to draw the viewers eye to the location concerned. Annotations like this should be used throughout tours, its easy to learn about a study area by doing a tour and forget that your users haven't formed a cognitive map. Annotating what you're discussing is a solution to this.

5. Testing:
Despite the best intentions, and having created a GET that you think looks and sounds excellent, often users miss elements that you thought you had made obvious or they misinterpret the message of the tour in ways that the author had not considered. The only solution is to test 2 or 3 typical users before releasing your GET, fortunately, this is much quicker, simpler and cheaper than you would imagine following Hallway testing guidelines.

6. Use of Layers:
A layer refers to a set of data, examples include: a thematic map showing voting by region in an election or a set of placemarks showing locations of pizza restaurants. If you wish to explain a complex map which is made up of a combination of layers e.g. showing that right wing voter States in the USA have more pizza restaurants in them, you will need to use multiple layers. It helps your users if you turn the layers on one by one in your tour explaining what the screen is showing as you go. Showing them all the layers at once and trying to explain what they are seeing is less clear.

Sometimes layers are complex enough to require annotations themselves (e.g. circling an area of particularly dense concentration of pizza restaurants)

Layers Practicalities: In running through a tour to record an audio it can often help to collect separate layers into a folder. When running through the tour you can then select a camera view for the folder and turn all the elements in it on and off at the same time. For example, you could put the pizza restaurants layer and a polygon annotation mentioned above in one folder.

Literature Review: In writing this series I did a literature review which the academics amongst you may find useful. I've expanded it since writing this.

AGI report: State of GI in 5 years time.

This was a report predicting the future of GI in 2015. It's a good summary made up of opinion from a broad spectrum of GI experts. Of particular interest to me was the section on cartography and visualisation (p 18 main report):

"However, it is not clear if cartographers or visual designers will have more influence in these [challenges of 3D visualisation] developments."

is an intelligent point to make, I see far more visual designers playing with maps on the web than I do cartographers embracing the new GeoWeb tools so it will be interesting to see who influences the development of augmented reality applications the most. However the quote,

"The contrary view is that we may see the death of the conventional 2D map by 2015"

is just plain silly. History is littered with examples of new technologies that were predicted to kill older technologies and didn't. Fax machines were killed by email but theatre, radio and ovens were not killed by cinema, TV and microwaves respectively. There is lots to be said for a 2D generalised map, augmented reality on phones may be dominant by 2015 but don't expect the 2D map to become extinct.

Cartography and Visualization by Mackness is a separate report which the main report summarised. He brings up a good point about the importance of zoom:

"improved capacity to model geographic spaces at multiple levels of detail. Data modelling at multiple scales to support ‘intelligent zoom’ – hugely facilitate map based tasks associated with small devices (with small screen real estate) "

zoom is important and I think it even goes beyond his mobile devices - its very useful on PCs too.

But I was disappointed that whilst he thinks "maps as interface", will be more important to the public in the future he doesn't identify usability of maps as a possible impediment to the development of GI. With each new function developers get to wield in map making there is a slew of bad implementations that are a result of ignoring usability issues, IMHO this is definitely an impediment to effective use of GI tools.

GI and Climate Change: Moving onto the section in the main report I was pleased to see some understanding of the importance of usability being talked about:

"Increasing sophistication in the analysis, presentation and understanding of uncertainty issues, for example how to communicate probabilistic [sic] based information sets. This issue is particularly relevant for scenario forecasting such as climate change or flood risk analysis, where there are increasingly sophisticated datasets availability [sic]"

I agree communication of difficult to understand spatial data to the public will grow in importance. Much the same point is made in the section on renewable energy.

The Data Deluge: Finally, in this section the report talks about the cost of data going down which produces the problem of a data deluge for the public:

"This means that rather than being able to let “the figures talk for themselves” it becomes increasingly important how the information is presented and telling the story associated with the information in a compelling way. This does not mean however to filter the information, to protect it, or to otherwise impede its release – that would be counter productive. Rather the increasing availability of GIS tools and “geoweb” enthusiasts mean that there is a wider pool of people who can be partners in understanding and communicating the issues."

Google Earth Tours are already an answer to 'telling the story' for the amateur enthusiast and I look forward to seeing them and other similar technologies become more popular as ways to dissect public data.

Google Map Styles

I've been keeping tabs on the Google I/O conference via twitter and the blogosphere. I'm very pleased to see that they've announced that in the latest Google Maps API v3 you can apply styles to Google Maps. Here's an example produced by Programmable Web a developer outside of Google:

This is a move I suspect is driven by Cloudmade, a competitor using OSM (Open Street Map) data. They've introduced the ability to style maps already, here's a nice muted example (Pale Dawn) that would work well if your background map was adding too much visual clutter:

So competition from Cloudmade has driven the development of features that help in the design of maps. Good. But I have a grumble:

No Usability Advice: The post discusses how you can now match the map color scheme with the surrounding web page and make your map 'stand out from the crowd'. Whilst web page styling is important the post doesn't discuss anything about how use color to improve map usability: having a common theme between web page and map isn't much use if it makes your map impossible to use.

Red Fail: The post illustrates the new functionality with an example which misuses color:

amongst several criticisms I could level at it the clear fail is that the sea is the same color as Yosemite National park making it look like California is a peninsular.

To Be Fair: A 'hello world' example illustrating new functionality isn't meant to be polished but the implication I read into the post is that map usability doesn't matter whilst standing out from the crowd does.

Google Earth Tours in Geog. Teaching II

part I here. This is the second of three posts, this week I finish off the 'rules of virtual flight' section. Next post will cover audio, annotations, testing and use of layers.

c] Avoid complex camera movement: It is possible to fly out from a location while changing camera tilt, bearing and camera lattitude and longitude all at the same time. This can overload the viewers ability to follow where they are and which direction they are looking, the video above illustrates this: the first section shows a complex flight broken down into 3 separate sections where the camera first moves to point vertically downwards, then gains altitude, then changes position. The return flight changes view angle, position and altitude at the same time and confuses the user as to where they have been taken.

Some views are better with a tilted camera angle such as the one of mountain in the clip. If you haven't got a good reason to tilt the camera, a vertically down view is best.

d] North is Top: Country shapes are most recognizable to users with a 'North at top' orientation. If possible your camera angle should keep this bearing in flights.

e] Keep visual cues in view: It is easier for your users to follow where they are in a GET if you keep visual cues in view (e.g. coastlines, mountain ranges etc). If there are not useful visual cues in view, you can create some placemarks that will serve the same purpose, e.g. marking major cities on the tour route.

f] Smoothness: Flights should be smooth and jerkiness is to be avoided, commonly jerkiness is related to the power of the computer (principally the graphics card) and the Fly-to speed selected.

Practicalities: The considerations here concern setting the speed of flight and smoothness of flight. If you are creating placemarks to produce your tour (see tutorial 1 ) you can adjust the speed of virtual flight by Tools > Options > Navigation > Fly-to speed.

If you access Tools > Options > Touring > When recording a tour, you get a slider. Moving this slider to the right increases the smoothness of flight (by increasing the number of 'points' in space GEarth records) but will increase the size of file users will need to open to see your tour. For small tours, the size issue isn't usually an issue. Experiment with different settings to see the effect.

Google Earth Tours in Geog. Teaching I

This post is the first of three posts on the topic, I offer practical advice on how to use tours in geography teaching with links to specific tutorials where necessary. In today's post I will cover some best practices achievable with with simple tours.

Tours in Education: A tour is a pre-recorded virtual flight around a virtual globe (see example above) and has two strong applications in geography education: A teacher can use them in place of a PowerPoint presentation for part or all of a lesson and students can be set assignments or tasks that involve them producing their own tours.

Why Google Earth Tours? At the time of writing 'tours' are available in two virtual globes, Arc GIS Explorer (AGX) and Google Earth. In some ways AGX offers a richer way to create tours, for example slides from a PowerPoint presentation can be easily incorporated into the tour. However, Google Earth is arguably the better virtual globe and also has a tour audio feature which AGX lacks.

Best Practices: Many best practices in using GETs are the same as best practices for producing maps in Google Earth, for example, good icon design. In the following discussion we refer to best practices that apply mainly to producing GETs. They are arranged in rough order of complexity with the easiest to implement listed first.

1. Scale, Location and GETs A GET is best applied when displaying changes of scale and location. The above example shows an overview of the ships route before zooming in on the ship itself to add detail. If changes of scale and location are not important your narrative it is quicker and just as effective to use presentation software such as PowerPoint.

2. Rules of Thumb for GET Flights These section 2 best practices are part of a group about how to best move the camera viewpoint within a GET.

a] Looped Flight: It is possible to fly from location to location in a way that confuses the user. For example, if we were to position the user over a house in the UK and then fly them rapidly to a house in South Africa at a low altitude the user may fail to realise which country they have ended up in. If the flight path follows a looped path pausing at high altitude with both houses in view, the user has the opportunity to see that they have flown South over the Mediterranean before descending to South Africa.

To force the GET to fly high between two low points of interest simply fly to an appropriate high altitude camera position and insert an intermediate placemark, use of placemarks to control camera locations is explained here.

b] Think about speed: If a flight is too rapid the user might fail to realise where they have travelled to but if it's too slow you may lose their attention. This point is related to point [a] because if you keep visual cues in view the user can follow a quicker flight. This topic needs further research but for now, testing a tour out on a likely user is an effective way of assessing if you have the speed correct.

To be continued.

BBC Election Web Map and Gadget

UK Votes, Seats through time: I like this web gadget from the BBC, it combines a timeline, a pie chart (votes), a graph (seats in parliament) and video clips in a clever way so you can see how voting in UK elections has gone in the past. No map but I think they were right to leave it off in this case as it would have made the whole thing too complex. It shows nicely how our first past the post system has warped a minority vote into majority governments over the years. If you click the timeline from the left to the present day you can see how the liberal vote (including SDP/liberal alliance which then became liberal democrats) has grown over the years to today.

Change Blindness in Maps: I'm less impressed by BBC this map, its major problem is a lack of understanding about change blindness. Try and spot the changes in the images in this video

Change blindness demo from Breakfast Seminar Series on Vimeo.

you can see that our visual system is incredibly good at spotting small changes* in an image but that it doesn't work if a blank 'flicker' screen is inserted between changes. If you go to the BBC map and select different constituencies the map blanks the screen and flies you out and back in again. Not only is the flight back in unnecessary, the introduction of a blank screen hampers our visual memory to track changes.

*Interestingly, its an evolutionary adaption, spotting a small leaf twitching was the difference between being eaten by a lion trying to ambush you or getting away alive to our ancestors in Africa. Its also the reason you can find a flashing cursor on screen.