Today, Groundspeak rolled out another regular update of geocaching.com, and amongst many other changes (including bug fixes and new features) changed the default maps from Google Maps to MapQuest (which uses OpenStreetMap).

This is as much a tale of Google Maps, probably moreso, than it is of Groundspeak and Geocaching.com. To fully understand what is happening, we need to go right back to the start.

First, a brief introduction to some geekery. An Application Programming Interface (API) is a means whereby different pieces of software can be connected and communicate – be it websites or applications. For geocachers, Geocaching.com used the Google Maps API to embed Google Maps onto cache pages, and this is what this issue is all about.

On the 8th of April, 2011, it was announced on the Google Geo Developers Blog that the Google Maps/Google Earth API Terms of Service were being changed. One of the key points of this announcement was that sites were eventually going to have either reduce their map usage to new limits placed on free use of the Google Maps API, or pay to obtain commercial usage of the Google Maps API – either on a per 1000 view model, or what is assumedly a very expensive Google Maps API Premier license.

This was followed up by a further announcement by Google on the 26th of October 2011, that further reinforced these changes, and outlined that the usage limits would begin to be clearly enforced by Google early in 2012.

So, the situation we had late last year was this:

• Google Maps was free
• Google Maps was going to become more expensive in early 2012 for large websites
• Geocaching.com was using Google Maps, and serving up a lot of pages with Google Maps

This meant that Groundspeak would have had three options when the Google Maps API usage limits are enforced early this year.

1. Pay Google’s per 1000 map view charges
2. Purchase a Google Maps API Premier license
3. Change web mapping service

So, that brings us to today – Valentine’s Day 2012 in the US – a day that has seen some love lost for Groundspeak as it moved away from Google Maps with a site update. However, let’s be clear about this up front – the problem is not Groundspeak, but rather the pricing that Groundspeak would have to pay to license the Google Maps API. This is nothing more than business decisons being made by both Google and Groundspeak.

Google for a long time made the Maps API free to lure developers in. Over the last year it has attempted to monetise the free service they are providing. This is course within their rights, although as is always the case when you try to change a free to a paid service, you run the risk of of being called out on the bait-and-switch.

As the Latitude 47 blogs points out, the Geocaching.com website firmly sits in the high-user category – the 0.35% that Google said would be the sites impacted by this license change. Groundspeak states that they are serving around 2 million map loads each and every day. When you work through the numbers, Google’s new charges actually amount to significant amounts of money. Two million map loads a day translate to USD7900 for one day of embedding Google Maps into geocaching.com. Multiply this across a standard 365 day year and you’re talking USD2.88 million – just for serving embedded Google Maps. This figure of course does not even account for continued growth in geocaching worldwide, in terms of more caches and more cachers, both of which will increase the costs because of increased map loads. Google Maps Premier License is possibly an option at this point, but the pricing is not publicly available for comparison, but I understand it starts from USD10,000 per year. I expect for the number of map loads that Geocaching.com is providing that a Premier License will be far more expensive than USD10k.

All we are seeing here is that Groundspeak is not willing to pay for what was previously a free service. Groundspeak has the right to say no to these new terms, and they have said no. Heck, if I was going to see an increase in operating costs for a business of USD2.9million a year, with no increase in revenue to make up for it, I’d say no too.

It should be noted that OpenStreetMap, as a volunteer-driven, open source project, also places server limits on websites using their maps. However, MapQuest provides a means of delivering large volumes of OpenStreetMaps from MapQuest’s own servers, utilising OpenStreetMap data. Groundspeak are using MapQuest, so there are no issues with Geocaching.com overloading OpenStreetMap’s servers – they are not using OSM directly.

However, the map change has certainly become a polarising issue for many. There are now hundreds of posts spread across multiple forum posts regarding these changes.

There are many different points and issues being raised:

• The change between Google Maps and MapQuest/OpenStreetMap is significant for some, and they are not comfortable with the new presentation
• There appears to be some map rendering bugs; some resulting in blank maps, others with not all map tiles loading, another is that the new map doesn’t display a distance scale
• MapQuest does not appear to have good satellite/aerial imagery. However Google Earth is still an excellent means to access caches on the satellite/aerial imagery that Google has licensed.
• There are actually more maps available, as you can view not only MapQuest’s tileset, but different map renderings including CloudeMade’s, OpenStreetMap and OpenCycleMap.

One of the big stand-out improvements that will be obtained by switching to OpenStreetMap – is the ability for the geocaching community to make corrections and improve OpenStreetMap the world over. You see, it is truly open. With an account you can directly edit the maps. So if you find a new walkway, you can add it, and usually within hours see can see your contribution appear directly on the map! Google Maps on the other hand does not even support its community mapping tool, Google Map Maker, in many countries yet. And unlike OpenStreetMap, any community edits to Google Map Maker, stay with Google – you’re just helping one business improve their database for free. OpenStreetMap edits however are shared and available far and wide across many different web services. So if you add or fix something in OSM, your contribution will be shared across many web services. OpenStreetMap is indeed a community service, and your contributions will benefit the increasing number of organisations that use OSM.

The move to OpenStreetMap will also create interesting options already being talked about. It is relatively easy to build your own mapserver that generates and serves your own map tiles. This means that eventually Groundspeak will be completely independent when it comes to map data. Not only that, but they will be able to customise it so that greater emphasis is given to features important to geocachers, such as park polygons, and walkways – the map can be customised explicitly to suit geocachers needs. You couldn’t do that with Google Maps or most other services.

It is going to be a painful transition for many, and when change is forced on you with little notice, it can be uncomfortable to bear. However, I’m firmly convinced that over the long term, most of the Geocaching.com mapping will benefit from this change. For everything else, there is still the free option of Google Earth.

The recent announcement by Groundspeak of the removal of Google Maps from geocaching.com has kicked off a lot of related discussion about the cost of Premium Membership. In short, Google Maps have started charging heavy users of embedded Google Maps (which were used on geocaching.com) and this was going to make the continued use of Google Maps somewhat challenging. It has also resulted in an outpouring of Geocaching.com members that would be keen to see an increase in Premium Membership to ensure continued access to Google Maps.

Currently, Premium Membership is a simplistic all-or-nothing offer. The discussions over the Google Maps indicate that this is quite a polarising issue. For some, it is make-or-break, and the removal of Google Maps functionality has already caused a number of cachers to indicate that they are not going to renew their membership. Others seem unconcerned and are in fact happy with the move to OpenStreetMap – I certainly fall in this camp.

However this got me thinking. Is it time for Groundspeak to look at providing some add-on membership packs? Consider the current Premium Membership a base subscription. When purchasing a membership, it would be good to be able to purchase certain add-on packs that provide additional functionality, or increased capacity on services already provided as part of Premium Membership.

For example, this Google Maps issue clearly indicates that there is a market for members that are prepared to pay to cover the Google Maps API charges that Groundspeak will incur. It is quite unreasonable to expect all Premium Members to cover the costs of those that want to use Google Maps. I certainly don’t want my Premium Membership to go up, possibly a significant amount, just to keep Google Maps functionality on Geocaching.com.

Therefore, it should be possible for members to purchase an add-on pack, that provides Google Maps API functionality for their account.

There are a couple of other add-ons that I would be very interested in seeing Groundspeak offer:

1. Increase Pocket Query limits – the current limit per Pocket Query is 500 caches by email. This was great a few years back, but the explosion in cache placements in the last 3-4 years has seen the email PQ limit become woefully inadequate. I would love to see add-on packs that enable you to upgrade your account to higher email PQ limits, such as 1000 or 2000 caches. I’d have absolutely no problem paying for this as longer as it was cheaper than the current option of purchasing a second Premium account to accomplish this.
2. Increase API daily limit – the current API daily limit is around 6000 caches. For whatever reason, some cachers may want to upgrade their limit to something higher. An added benefit of a Groundspeak API add-on pack could be a faster server so that the caches download faster than the current existing API allows.

I believe that the growth of the different ways that we cache, and use Geocaching.com mean that the current Premium Membership is no longer able to satisfy all users. The time has come for Groundspeak to separate out the base Premium Membership, and provide add-on packs for expanding specific capabilities, or to cover third-party charges such as the Google Maps API.

Currently I make use of four different websites:

• Flickr
• iStockphoto
• Facebook
• Google+

iStockphoto

Let start with the easy and obvious one. iStockphoto is the odd one out, as it is a purely commercial service. I use it not for sharing, but for selling my photos. Over time, there may well be multiple site that fill this commercial niche, but for the time being it is just iStock.

• (+) Easy service for selling/licensing photos online
• (-) Not designed for sharing photos

Flickr

This was my first photosharing website, and until I started using Facebook and Google+ more recently, Flickr was my go-to host for sharing photos online. It definitely provides the richest toolset for photographers, but it isn’t integrated and directly connected to our largest social networks (Facebook for a lot of us).

• (+) Designed for photographers
• (+) Better quality than Facebook or Google+
• (+) Good range of metadata tools
• (+) Does a better job of displaying panoramas
• (-) Sometimes limited to photographic special interest

Facebook

Yes, the behometh when it comes to sharing photos with friends and family. I certainly get the best feedback (likes and comments) on my photos on Facebook. But Facebook honestly does a piss poor job of shaowing off photos in even ‘reasonable’ quality, and it has absolutely no image metadata for those that are interested.

• (+) Definitely has the best direct social network reach for me currently
• (+) Best for friends and family
• (-) No metadata displayed
• (-) Display limited to 960px wide
• (-) The album layout sucks

Google+

The new kid on the block, and definitely evolving quickly. Already it has arguably better photo support than Facebook, and Facebook seems to be copying some Google+ styling – most recently the single photo view with comments down the right hand side. The thing that is really exciting about Google+ is that photography has always been reasonably well considered form the start, including good distraction-free backgrounds. Unlike Facebook, Google+ is also accepting of feedback and actively participate on Google+. I expect we’re going to see Google+ become an ever improving service for sharing photos – given they’ve done so much in a short time.

• (+) Good for photography/tech/special interest circles
• (+) Good metadata (more than Facebook)
• (+) Has a different social network and reach to Facebook
• (-) Like Facebook, the display of photos is limited to 960px wide
• (-) Currently a poor social network (relative to Facebook)

As a result of this, I’ve think I’ve come to a decision as to how I’m going to use these various services.

• iStockphoto – commercial microstock licensing.
• Facebook – mainly people photos.
• Google+ – despite it being better than Facebook, I think I’m not going to use it much for hosting photos directly.
• Flickr – having played with Facebook and Google+ photo hosting, I think for everything other than photos of family and friends, I’ll be coming back to Flickr.

Why do I like higher resolution?

I’m a keen landscape photographer, and some of my panorama images are quite wide. Showing them in 960px wide on Facebook or Google+ doesn’t really do them justice – both of these services are much better designed for more traditional aspect ratios such as 3:2, 5:4 or even 1:1.

Promotion

I learnt a trick recently that helps you promote photos from other sites on Facebook or Google+. Rather than directly linking through to an image, on say Flickr, via an URL, that you get a better effect by uploading a copy to Facebook (or Google+) and adding an URL to the photo or album on Flickr. This results in a much larger photo being displayed on the timeline and not just a little thumbnail image.

Pinterest

And just today, I’ve signed up with Pinterest that looks like a fascinating tool for curating and promoting not only your images, but also images that you appreciate and want to share with others.

Conclusion

There are many photosharing websites and opportunities available, yet there is not a single website that accomplishes everything. This means we have to pick and choose combinations that best meet all our needs. I can’t tell you what combination suits you, that’s something you have to work out for yourself.

Whilst a lot of us like to take photos while caching, with Garmin’s latest update to a number of their recent units, they have now opened new possibilities of taking photos with you where you go caching.

Why is this useful? Well, we’ve all come across caches that have a hint such as ‘see photo’ or ‘see spoiler photo’ but of course the photo doesn’t get downloaded with the GPX we get from websites. So we’re stuck out in the field, without a hint. And if we’re out of cell coverage, then we’re not going to be able to download the spoiler photo on our phones at GZ.

Naturally, Garmin have fully integrated the photo experience with their OpenCaching.com website, and you can now download photos with the GPX and they will be seemlessing installed onto your GPS (the models supported, via the latest software updates, are the Montana, Oregon x50, Dakota, GPSMAP 62/78, and eTrex 20/30). Those of us that use other, somewhat larger, geocaching sites aren’t left entirely in the cold however – Garmin does tell us how to load photos manually, and there is already a couple of GSAK macros that can be used to select, and upload to the GPS, ‘grabbed images’. Note that these macros (one to aid selection of grabbed images, and the other to do the preparation and uploading to the GPS) is very much in the experimental state, and still has a fair amount of refinement to go. It is also coming along in leaps and bounds and improving rather quickly!

I tried the GSAK approach this afternoon, and selected a few photos from unfound caches near my hometown of Christchurch. Worked no problems, and I now have direct access to photos on the GPS, just like the description, logs and hints. The only real catch at this stage, is that the photos must be installed on the internal storage of the GPS, and they cannot be stored on the microSD card.

I’ve included some screenshots to give you some idea what it looks like. First up, top right, looking at the description of a cache shows a photo icon down the bottom left to indicate that this cache has photos attached.

Next up, below left, the paperless cache page has added Show Photos between Description and Logs, and on the right, a thumbnail view of the photos associated with the cache.

And finally, the photo itself. In this case, on the Montana, I rotated the GPS to landscape to get more viewable area. For those that recall the Christchurch earthquake on 22 February 2011 that killed 181 people – its epicentre was just out of the left edge of this photo.

Personally this is a welcome addition to the caching arsenal, and I’ll be very interested to see the development of the GSAK macros over the next couple of weeks!

MEET OUR NEW BLOGGER

Rediguana hails from the shaky city of Christchurch, New Zealand. He is an emergency manager by trade, and some of his interests outside of geocaching include travel, photography, mapping, and open source software and data. An ‘old-skool’ cacher, Rediguana (real name Gavin Treadgold) started geocaching in May 2001.

It’s been a little while since I’ve written on a blog, so I figure I’ll start slowly and introduce myself. Never fear, this isn’t my first time blogging – I have done plenty, including under a pseudonym in the rather vitriolic atmosphere of the New Zealand political blogging scene quite a few years back.

I don’t think I can deny that I am what you’d call an ‘old-skool’ cacher. I purchased my first GPS – a Garmin 12 XL – in Sydney, Australia in April 2001, and then went on to find my first cache in Christchurch early that May. From then, I was hooked, and have remained so.

I have a rather inglorious record of placing the first micro cache in New Zealand (a 35mm cannister thrown in a bush), which was also our first true puzzle and crypto cache. I think I can also be blamed for the green spray-painted containers with yellow, stenciled ‘geocaching’ lettering that you often see around the South Island.

Since those early days, I’ve cached in 10 countries worldwide, including Iceland and Sri Lanka. I found my 10,000th cache earlier this year. I’m also lucky enough to have found a Project Ape cache, and completed the caching quinella of the Original Stash memorial and Groundspeak HQ.

I have a simple caching philosophy: Gotta find them all. Given the last 2-3 years of placement rates, however, I’m increasingly having to find contentment with clearing out areas instead. I’ll do pretty much anything for a cache, and I’m happy doing puzzles, or long physical days for just a find or two. I also love well-designed challenge caches (not Geocaching.com challenges) and my current focus is on completing the Doctor of Geocaching Science – of which I am one of the ‘professors’ responsible for its placement.

In late 2002, the New Zealand Department of Conservation (DOC) discovered geocaching, and became interested in collecting a concession – a charge for commercial operators on DOC land. At this point, the geocaching community jumped into action and formed the New Zealand Recreational GPS Society Inc, so that we had a legal entity to operate with, and form agreements if need be.

I was one of the society’s 15 founders, and remain on its management committee to this day – I’m currently Secretary/Treasurer. Once we had communicated to DOC that geocaching is, at its heart, a non-commercial activity, they left us be. These days, the society is more interested in the promotion of GPS and geocaching for active outdoor lifestyles, and we’re in the process of organising New Zealand’s inaugural MEGA event in Dunedin this coming October.

I will admit now that I am a Garmin addict, and I much prefer the traditional ruggedised handheld GPS receivers – my current tool is the Garmin Montana 650. I carry an iPhone 4 as well but it’s for backup, notes, photos and Wherigo. So you’ll definitely find me a contrarian to the smartphone-loving crowd, but the smartphone definitely has its place in my pockets!

I also enjoying tinkering in GSAK, and have been known to write a macro or two, mostly to help track completion of some New Zealand challenge caches, but have also developed the county boundaries for New Zealand as well as the New Zealand region and state maps that you see in FindStatGen.

Slightly further out on the periphery, I am a keen mapper and strong proponent of open mapping data. I have been involved with the New Zealand Open GPS Maps project since its inception, and I am finding myself increasingly contributing tracks and roads visited whilst out caching to OpenStreetMap.

All this geocaching results in travel, and I’ve been to some pretty amazing places over the years as a result of both. This has also cultivated a very keen interest in photography, and I love nature, landscape and wildlife photography.

Anyway, enough from me. Why aren’t you caching?

It has been some time since I have been in touch, and I apologise for that. I’ll keep this email relatively brief, and had I made the time sooner, I should have sent it a couple of months back.

In short, I am struggling to keep up with my ‘official’ Sahana commitments – although most of you have picked this up already. The main purpose of this email is to just make it official – I need to stand down from all my official Sahana roles – Board, PMCs, GSOC, admin and other relevant committees I am on. This absolutely doesn’t preclude me returning to some roles later, but I do need to make a clean break for the time being.

You shouldn’t read anything more into this other than I’m struggling to put time into SSF activities currently, and I shouldn’t be occupying slots that may be able to be filled by more active people. I quite simply am not in a position to meet any required expectations placed upon me for the foreseeable future.

I’m still absolutely behind Sahana, and as time permits, I’ll be starting on small hands-on projects from the ground up based on observations, experiences and discussions I’ve had as a result of the ongoing run of Christchurch earthquakes. Most of these will be with Sahana Eden, and working on detailed applications such as building information management, managing map production requests within GIS departments, rostering of volunteers, managing radio assets, and managing vehicle logistics.

A related aside – I’ve been interviewed and invited to be ‘under training’ to be a member of the New Zealand Red Cross Information Technology and Telecommunications (IT&T) Emergency Response Unit (ERU). This is one of five worldwide Red Cross IT&T ERU’s than can be deployed to support Red Cross operations to disasters and complex emergencies, and deployments can be up to five weeks in length.

Cheers Gav

New Chch: Oh, and of course a world leading research centre for natural hazards, earthquake engineering and construction, resilient organisations and communities, risk management, business continuity, crisis management, emergency management and all forms of technology to support this. We have a fair amount of this here already, but let’s tightly integrate it into a more integrated cross-platform centre.

Justin Lewis then went on to suggest in my comments that we have a purpose built Emergency Operations Centre (EOC) and Rescue Operations Centre, as well as an Urban Search and Rescue training ground (I’ve been to VA-TF1′s training centre and equipment store in Virginia, US, back in 2002 and it was fantastic). I also added in the comments that the EOC should also be able to operate as an alternative or supporting National Crisis Management Centre – in particularly for when Wellington has their large earthquake. Jon Mitchell, the Regional CDEM Manager has also been promoting similar views.

Of course, the artificial limit of 420 charaters on Facebook points some real constraints on what you can say, so my plan was always to take the time to flesh it out in more detail when time allowed. Well, I’m now taking the time to do so.

Before the earthquakes of September 4, 2010, and February 22, 2011 – Christchurch was already well advanced when it comes to research into natural hazards, engineering, social science and emergency management – and this is one of the reasons why our response to February 22 has been generally highly regarded internationally. We also had a lot of capacity and capability in operational response – for a while we held the lion’s share of NZ Response Teams, as well as being hosts to one of the three Urban Search and Rescue Task Forces (NZ USAR TF2).

To give you a little background, here are some of the ‘centres’ and organisations that have been in place in Christchurch over the years.

• The Emergency Management Training Centre – this was originally the training arm of the Canterbury Regional Council, but has progressed into its own NZQA Private Training Establishment.
• The New Zealand Centre for Advanced Engineering – an engineering and technology think-tank that has done a lot of work around natural hazards, including Engineering Lifelines, Reviews, Natural Hazard Risk Management and Communication, and Public Alerting.
• The Natural Hazards Research Centre based at the University of Canterbury – research programmes related to studies of active tectonics and earthquakes, landscape evolution modelling, land-use planning, urban vulnerability to volcanic eruptions and health risks from eruptions.
• Earthquake Engineering at the University of Canterbury College of Engineering
• Resilient Organisations – represents a synthesis of engineering disciplines and business leadership aimed at transforming NZ organisations into those that both survive major events and thrive in the aftermath.
• NZ Registered USAR Response Teams – we also have 5 of New Zealand’s 18 Registered Response Teams.
• NZ USAR Search Dog Association – of which 9 of the 11 dogs and handlers are located in Christchurch and associated with USAR TF2 (the other two are based in Auckland).

So, Christchurch and Canterbury already have a significant in-region capability across many disciplines – including operational, strategic, policy and research.

We now have the potential to build a world class centre for emergency management and related disciplines that could bring many of these disparate activities together onto a single campus. What a shining light this could be as part of long term recovery from the earthquakes, than to build a nationally and internationally recognised centre.

What would be some of the key capabilities it should have:

• Concentrated – all the facilities should be on a single physical campus to ensure close proximity and collaboration, and integrated under a single administrative structure (if possible).
• EOC – a world class Emergency Operations Centre that supports not only local and regional response, but also can act as an alternate National EOC. This facility would also be a dedicated routine facility for emergency management for Christchurch and Canterbury.
• Internationally-recognised Training Centre – there should be an operationally-focused training centre as part of the facility, that integrates not only the EMTC, but also includes full facilities to undertake not only Urban Search and Rescue, but other specialist search disciplines such as Heights/Ropes and Search Dogs. Again, there are elements of this dotted around Christchurch, such as at the Woolston Fire Station where USAR TF2 is based, but again, this should be completely integrated into this campus, and the training facilities again need to be world class. The facility needs to be capable of supporting training and exercises up to, and including, the extremely challenging 72 hour USAR exercises for Category 2 USAR technicians and engineers.
• Strategy and Policy – thinking about the big pictures issues such as humanities increasing vulnerability to risk, and the strategic and policy decisions required, that have to be managed in terms far longer that three-year political spells.
• Integrated research – currently a lot of the research programmes are not fully integrated and the researchers work out of many different departments. This could be turned on its head and the new programme could ensure that all related disciplines are working in close proximity to not only each other, but also the practitioners.
• New disciplines – such a centre should also look at expanding research and operations into new areas that have not yet been included, and leveraging on Kiwi inginuity and design excellence. Kiwi’s could being a lot to the table in terms of development of technology and IT for risk and emergency management, an area I feel that Kiwi’s are not yet pulling their weight.
• International links – any such centre must not operate in isolation, and there are many relevant forms of partnerships that could be made, including the likes of the Emergency Management Division of the Justice Institute of British Colombia, FEMA’s Emergency Management Institute, and platforms such as the United Nations Global Platform on Disaster Risk Reduction and Integrated Research on Disaster Risk.

We’ve been handed some lemons – let’s make some lemonade and turn Christchurch into a world class centre for emergency management and related disciplines!

Routines – ‘Familiarity is comforting’
Keep up normal activities
Treasure familiar things

Stay connected – ‘We need each other’
Stay in touch with family and friends
Take moments to give others your full attention
Listen and answer children’s questions simply
Be brave for each other
Ask for and accept help

Save your energy – ’Keep it for important things’
Lower expectations of yourself and others
Take breaks and lighten your workloads
Be tolerant of yourself and others
Lots of things can wait
Children may act younger – that’s ok for a while

Lifestyle – ‘Balance is healthy’
Stay active e.g. go for a walk
Relax – take a break
Limit alcohol
Try to get enough sleep
Try to eat well
Do something nice for yourself

Safety – ‘Protect yourself in every way’
Limit exposure to earthquake news e.g. TV
You are not helpless – remember the things you do well
Take care of your spiritual and emotional health
It is ok to be emotional

For extra support contact your GP, or phone 0800 777 846, or go to http://www.canterburyearthquake.org.nz/.

New Zealand College of Clinical Psychologists

Most of this thought has been directed at how to implement it in a Sahana product, but it could conceivably be applied to any product for emergency management, or even broader business/organisation management. Aspects of this solution already exist across both Ushahidi and Sahana – but neither provide the comprehensive solution yet.

This need was also something that I saw during my involvement in Building Safety Evaluation during the Canterbury Earthquake in 2010. It is also potentially a far more robust means of managing the collection of intelligence associated with an emergency.

I’ll talk about this using a modular approach – making the assumption that different groups of users will have different types of access, to ensure the protection of submitted information (see here for a reason why).

Capturing the Information
The first module would be the Intelligence Gathering module. It is where information from other sources is collected from other sources.

In the CrisisCommons context, this might allow an anonymous volunteer to submit cut-and-paste text from a news article on a website or from a situation report. For the purpose of this concept, I’m going to ignore the copyright issue – but do want to flag that this may be an issue with the collection of information from the media where a lot of information is copyright.

For Building Safety Evaluation, this may be the unstructured reports that we received that ‘the wall on this building looks like it is about to fall on a neighbouring building’.

So this module basically allows for the entry and recording of what is mostly unstructured information – it may be from a website, a phone call, SMS, even a scribbled piece of paper that someone passes you in the EOC.

Such a system could be easily configured to allow members of the public, or crowdsourcing volunteers to enter such information without having to register or have an account – thereby keeping the barrier to collecting raw information low.

Adding Structure and Metadata
Having this information in digital form is just the start however, the next step is to get a team of trusted individuals to then review the submitted information and critique it for quality, actionability, and credibility. At they same time they would ideally try and add other metadata to the record.

Does it currently contain a freeform address? Then the reviewer would then associate an address with the record, and this would properly structure the address information. If a geocoder is available then latitude and longitude records would also be entered.

We had some issues in Christchurch whereby some addresses that were reported are not official addresses recognised by the council property system – this usually happens with ‘vanity’ address. Our Kestrel office in Kestrel has a common/vanity address of 35 Riccarton Road, but for council and utility purposes, our building is actually 39 Riccarton Road. I spent a bit of time in September, and again following the Boxing Day aftershock checking some of the incoming addresses that were provided, and then record a Council GIS identifier once we had correctly identified the address. Again, this would be another means of tagging the raw data with something that adds valuable metadata to incoming information.

Does it have a phone number? Associate a structured phone number.

What does the record refer to? Add tags from a controlled taxonomy so that the record can be filtered – e.g. if the record refers to building damage, it may be tagged with ‘building evaluation’. If it is a report of a missing person, it should be tagged with ‘missing person’.

This is perhaps the most time-consuming part, but it is also most required, as it opens up a lot more potential for actually managing and sharing the information.

Wrapping it all in Management Tools and Reporting
Now we can finally get down to the crux of what we’re trying to achieve – take raw unstructured information and provide it in a form that information systems can understand it, present it, and search it in far more valuable ways.

If we assume that all incoming information about building safety is tagged with ‘building evaluation’ then we can provide a web page that allows someone in the building safety evaluation team to review all the incoming reports that are relevant to them.

At this point we go the final step, as we start allowing people in these focused teams to start associating actions and history to the original record. You may have a small team with Build Evaluation reviewing incoming records for ‘building evaluation’ when they see it, because the address (and potentially lat/long and council identifiers), it should be trivial to see if other records have been entered that refer to the same building, or nearby buildings. Without adding this metadata previously, it would be a lot harder to automated some of this information management.

We can then link multiple records that refer to the same building – such as different reports over time, or a neighbouring property that may refer to the building.

The best part though, is when we start adding actions – for example, if an Urban Search and Rescue Team is tasked to a building, then that action (Sending a team to perform an intial rapid building assessment) can be associated to that building and the team, and of course the original record that reported it. This means that if someone enquires if anything is being done, we have the history of who was tasked where and when.

When the team returns, we can mark the action as completed – we have a record that it has been completed. Not only that, but any quick comments from the team could be added as a new record associated with that building. Likewise, any digital photos, or even scanned copies of the rapid building damage assessment forms could be attached.

Scanned forms are of course interesting, as you could scan them initially and add them to the system as images, but also flag those to be reviewed to create metadata so that the form data is now accessible via metadata – such as the building status as determined by the assessment Safe/Green, Restricted/Yellow or No Access/Red. Whilst Optical Character Recognition (OCR) could speed this process, after seeing the handwriting of engineers, I’d suggest that human review and triage of key information on the forms would get more usable information into the system sooner. And yes – the idea is of course a tablet application that digitises the information in the field and uses an Emergency Data eXchange Language (EDXL) extension to submit the information via EDXL-DE back to a server.

Of course, with all this structured metadata now wrapped around the original unstructured reports – this opens up so much potential for reporting and where appropriate sharing this information using standards such as the EDXL for achieving true information interoperability.

This is something that both Ushahidi and Sahana have been working since the response to the Haiti earthquake when we were trying to provide management tools in Sahana Eden to wrap around the crowdsourced information that was being collected by Ushahidi.

In this case an anonymous user was deleting data as quickly as it was entered in a shared public document. What is a more concerning risk is perhaps the subtle editing of crowdsourced information, where the edits are not obvious enough to be detected – such as the subtle and malicious modification of facts and figures.

For tech volunteers, there is a careful balance to be struck between protecting information (in this particular case its availability and integrity) and not creating significant barriers to entry.

The first obvious solution is that access on the document be restricted to authorised users. This means that only those individuals that are trusted can be expected to contribute to the collection and management of unstructured crowdsourced information.

This is less than ideal as it means that new users that volunteer immediately following an emergency haven’t developed a trust relationship with, for example, the CrisisCommons community, and are unable to immediately contribute.

I believe that with the simple use of a two-tier approach, one can easily protect the quality of the final document(s), whilst still making it easy for new volunteers to contribute.

You effectively create two types of document:

1. Public and open documents – which are open to all to edit, and are effectively a rough scratchpad for collecting unstructured information.
2. Trusted documents – which are open for only a limited pool of trusted users to edit, but draw from the content provided in the public and open documents.

The trusted editors effectively become the curators of the information, and once content has been copied and edited from the open documents, malicious anonymous users won’t be able to waste other volunteers time through deletion or editing.

There are other process benefits to this approach. For example, you may create a public document particular topics of the emergency – such as infrastructure, health/medical and background information (e.g. weather forecasts, population demographics etc) and these multiple individual documents may map to a single section within the trusted document to produce an edited and trusted version of crowdsourced information.

Still, from an operational perspective, this is a far from ideal approach, and there are certainly more robust approaches available to turn this into a process that can be used for intelligence gathering and situation reporting.