Gav's Blog

The issue of community-produced maps has reared its head on the IAEM email list today – closely linked to my post back on the 26th. The following issue was raised, and I wanted to share my reply to this.

Lack of citation was my major concern with the other available maps that have been in wide circulation. The second concern with the other maps is that they showed push-pins when they did not have or could not cite the data to support specific points.

My reply follows:

I think you’ll find that most of those maps do actually have references, in the case of the Google Maps mash-ups, they are contained in the hundreds of comments accessible from the same page as the maps. In fact, it is generally from the posting of these references in the comments, that the Google Maps get updated. What they have failed to to is to make it easier to reference the citations, by not including the reference in the popup bubble above the marker. But if you read through all the comments, you’ll likely find most of the citations there.

Another big failure is to create a timeline/history so that one can see the growth/change in numbers over time for each marker. Most of the maps are purely a snapshot of the here-and-now, and give no context via history.

The real point that emergency managers should take away from this is the following.

Agencies that ‘own’ the source information (e.g. CDC, WHO, and health agencies in every other country in this case), really should be publishing authoritative georeferenced data at the source. If agencies did this, then there would be no need for these ‘amateur’ cartographic efforts to hack together information from news, rumours and other sources. It would sure save a lot of time and effort in people trying to recreate information that already exists and either hasn’t been released, or has not been converted to a georeferenced format.

Likewise, it isn’t really the role of companies to provide this information. Once again, they are just filling a gap that we, as emergency managers, have failed to meet.

The mashup culture is a direct result of a failure by emergency managers to make information available in a form that end users clearly want it (as evidenced by the time and effort they will put into recreating the data in the form that they want to use it).

Perhaps we really should start thinking seriously about how we can produce authoritative information in formats that our communities want.

If you have a look at the example map I created in under an hour on the 26th, you’ll note that I created a little table in each popup for a marker that contained a link to the source article, and in the case of the San Diego marker, included daily figures for three days so it was possible to track the state of that marker over time.In addition, I scaled the marker images so that they were more proportional to the number of cases – a marker for each infection quickly produced an unreadable map, hence it seemed a better approach is to produce summary markers for each location, with the size of the marker indicating the numbers.

The real trick is going to be to produce a web application to track and manage this information, that can then export it in a suitable form to display the information as discussed above. This is clearly something we should look at for Sahana.

I haven’t blogged about Sahana for a long time, and I’ve got plenty to write. So much that I can’t decide where to start, so I’m going to pick a nice small piece to start with.

The Concept

Last year, I was involved in a project in New Zealand to produce an investigative report on Public Alerting Systems with the New Zealand Centre for Advanced Engineering. This report will hopefully soon go public, and I’ll provide a link when it does.

This report was looking at the different technological solutions for getting alerts out to people in as timely a manner as possible. At one point in the search for different systems, we started discussing means of injecting HTML in web pages via an ISP, so that a public alert could be sent out to anyone on the Internet. I’ll talk about this and other options later. Let me get to the point of this post.

After starting at the HTML injection idea, and progressing through a few others, I reached a kind of natural conclusion that a more suitable means of alerting users via a web browser would be a browser plugin that can subscribe to Common Alerting Protocol (CAP) feeds, and when a relevant alert comes in via CAP, this is displayed to the user in their browser using the XUL:notificationbox at the top of the webpage.

Draft Requirements

Anyway, a possible idea for a Google Summer of Code 2009 project is that of constructing a browser plugin for Firefox that implements this alerting capability, and expanding Sahana to support full publishing of CAP alerts. Here are some features it could/should support.

Firefox Plugin

• Bundle publicly available CAP feeds (ideally listed in a nice Country/State taxonomy – this will make it easy to discover and utilise existing CAP services.
• Allow users to optionally register location in some manner, so as the plugin can identify relevant alerts (by location) and give them higher status than say remote alerts. Users should be able to register multiple locations – whether it has home & work, or multiple cities. Privacy is of course king and this information must be protected.
• Provide a means of adding additional user provided CAP feeds to the plugin.
• Provide the ability to open the alert in a new tab and format in a human-readable manner, including niceties such as embedding Google Maps to show geospatial information and links back to the source website of the alert for verification.
• Implement means of verifying messages that are digital signed, and decrypting encrypted messages.

Sahana

• Implement a CAP feed in Sahana so that Sahana can act as both a producer (in terms of creating a CAP message) and a publisher (in terms of making it available via a CAP RSS/Atom feed).
• Implement a CAP proxy or similar, so that say all users of a Sahana server can obtain CAP alerts directly from the Sahana server – rather than going to an external website. This may be useful for distribution of alerts within an organisation or centre without having every client browser connecting to an external server.

What would be very nice, but may be beyond the capabilities of Sahana servers currently, is making the CAP service on a Sahana server easily discoverable on a LAN via zero-conf services such as Bonjour.

Draft Outcomes for Assessment

The outcome of such a project would be to produce a working solution whereby a Firefox Browser plugin is capable of working with public CAP alerts and that CAP within Sahana is capable of fully acting as a CAP server via RSS/Atom feeds to the CAP alerting plugin.

Compulsory

• Implement the specified requirements
• The browser plugin works as expected with publicly available CAP feeds.
• The browser plugin works as expected against the Sahana demo server. (Yes, this means that your modifications to CAP on SahanaPHP need to be implemented).

Optional

• Implement the Sahana CAP server in SahanaPY
• Provide one or more standalone CAP clients for a mobile platform e.g. Google Android, Apple iPhone/iPod Touch etc
• Write an Internet Explorer plugin with similar functionality – it is important that this functionality is also provided for IE given its widespread usage and deployment.

Whilst the plug-in can and should operate completely independently of Sahana, it should also be designed to work well with Sahana servers (e.g. SahanaPHP and SahanaPY).

Anyway, this is just an idea I wanted to float and get out in the community for discussion. I’d welcome any further comment or ideas to build upon this!

Mark has been doing some great digging on Section92. He’s just found and blogged that the Officials responsible for reviewing the Copyright Bill at the time suggested that section 92 be removed as existing arrangements already provided the tools required.

I’m still convinced that Section 92, and the ACTA negotiations, are part of a larger effort preparing the ground for a Free Trade Agreement with the United States. Copyright and Intellectual Property are one of the biggest exports from the US, and they are trying to expand controls globally to protect their interests. This however comes at the detriment of small creative folk that can’t compete with large multi-national organisations. This is clearly indicated in the structure of the complaint process within the new act that favours large organisations and makes it difficult for small copyright holders to make complaints.

These changes in legislation are non-negotiable, and likely a pre-requisite to start more formal Free Tree negotiations with the United States. This would likely explain why both major parties (Labour and National) have been for this bill all the time. They see it as a pill that has to be swallowed with the intent on snagging a United States FTA at the end of it all.

In a decision that will probably frustrate some Aucklanders, it has been announced the Whenuapai Airport will remain in the hands of the NZ Defence Force. This is probably the best outcome, as it will ensure that the field remains as an emergency alternative airstrip in case anything happens to Auckland International in Manukau. Whilst Auckland probably doesn’t need a second commercial airport, you never know when you might need an alternate airstrip during an emergency.

I tried these out in a local HiFi store and found them to be very nice headphones. The sound was quite ‘tinny’ with the noise-cancelling circuit off, but a very rich and beautiful sound with the circuit engaged.

However, I ended up having to return them. It turns out that the circuit wasn’t shielded against 2.4GHz spectrum, and in the office it suffered an incessant humm from the 2.4GHz devices. Most disappointing and I had expected more from a product designed to cancel noise in the office (I had purchased with the intent being to use them in the office, and for travel).

I would buy them again in a flash if they produced a model that was shielded from interference.

What follows is my submission to the Finance and Expenditure Select Committee on the proposed investment bill.

Members of the Finance and Expenditure Select Committee
C/- Clerk of the Committee
Select Committee Office
Parliament Buildings
Wellington

Thursday, August 3, 2006

Re: The Taxation (Annual Rates, Savings Investment, and Miscellaneous Provisions) Bill

I wish to raise my general objection to the above bill, reasons for which will be outlined in brief points to follow.

In general I believe that the proposed bill is a backwards step in terms of encouraging New Zealanders to become more capable investors. The strong focus given to fund management – at the expense of international equities is extremely ill-considered.

The key point of disagreement is that the proposed bill will not achieve the equity and balance that the promoters are suggesting – it will in fact result in the opposite, a more uneven investment environment that will seriously impact the future wealth of New Zealand.

Further points of disagreement are outlined below. These are listed in no particular order.

It will not create a neutral investment tax environment
The proposed bill will not create a neutral tax environment as is suggested. It is highly likely that investors, myself included, will look for alternative forms of investment – including residential property. Of course, residential property does not currently attract a Capital Gains Tax so it is potentially an attractive investment option relative to equities.

Tax on unrealised Capital Gains
It is extremely unfair to raise a tax on unrealised Capital Gains. Any gains shown in an investment are not concrete until the equity is sold and converted to cash. At this point in time it would be more equitable to tax Capital Gains – although this still is not a preferred option. There are many events that may cause short-term volatility in an equity that may be taxed – even though an investor does not make any real gain, these include exchange rate fluctuations.

Impact on New Zealand Dollar
This bill will have a significant impact on the strength of the New Zealand Dollar. Many investors will make the decision to repatriate their investments that are held in currencies such as the US Dollar, British Pound and Euro.

The decision to repatriate NZD will mean that New Zealand investors will hold less international currency and will reduce the income produced from other countries that increases New Zealand’s overall wealth and hence backing of the New Zealand Dollar.

Encourage inappropriate investing behaviour
The proposed bill will likely promote a change in investor behaviour to minimise the amount of Capital Gains Tax paid. This could include decisions to liquidate stocks shortly before the end of the financial year for tax reasons – as is commonplace in the US market with the stock selloffs that occur in December each year.

Increased compliance costs
This proposed bill will added additional compliance costs in terms of time and expense – and will require increased use of accounts in completing valuations and tax returns. This will reduce the overall return on investment – once again this will impact investment decisions and would likely promote the migration towards investments that are more easily understood and have reduced compliance costs.

Detrimental to New Zealand businesses
The promotion of a move away from equity investment as a result of this bill, will be detrimental for capital injection into New Zealand businesses. The reduced return, with no subsequent reduction in the associated risk will result in investors choosing lower risk and return investments. This will make it harder for New Zealand businesses to gain local capital, and they will be required to search for offshore investors – who will benefit from the returns, and potentially gain ownership control of these ventures.

Size of the Australasia equity market
The New Zealand equity market represents approximately 0.5% of the world equity markets – Australia around 2.5%. This bill will encourage gross over-investment by New Zealanders in a small (~3%) segment of the world equity market due to the lack of a Capital Gains Tax. This will increase our risks to shocks and financial crises due to the small size and value of our markets. A balanced investment portfolio requires a reasonable international distribution. Ironically, the New Zealand Superannuation Fund holds approximately 85% of its investments outside Australasia.

Promote a resurgence in property investment
If this bill is passed in its current form, it will create a bias towards further investment in property in New Zealand which may have serious negative consequences for much of the country. International returns would be repatriated and further invested in property. This increase in property investment would produce an increase in house values which would increase the level of debt that New Zealand families would be exposed to, and this would be exacerbated by the increased lending from foreign-owned banks, and the returns on debt being siphoned off to investors in other countries. For those that can’t afford to purchase property, rental rates will increase as property investors demand higher returns. This will hurt the current Governments voters the most by forcing families and first home buyers to commit to even larger loans. The cash grants offered by KiwiSaver will be inconsequential relative to the increase in property values caused by the proposed bill.

Managed Funds are not an ideal investment vehicle
Despite the promotion and marketing of managed funds, many studies have shown that a minority of funds are able to outperform passive funds tied to share-market indices. This implies that most managed funds are inefficient investments – and hence not utilised by educated investors. Additionally, managed funds often attempt to spread their risks by investing in a large number of equities – this results in not only the spreading of risk, but also suffers reduction of returns, whilst at the same time profiting the investment company.

Bringing Capital Gains Tax into the spotlight
The issue is going to raise general public’s attention towards Capital Gains Taxes. When people discover that they are paying CGT indirectly via their managed funds, and hence accepting reduced returns, they too may consider adjusting their investment portfolio in favour of those investments that don’t attract CGT – including property. This will also cause unintended growth in the property market.

Expat Kiwis will be less likely to return home
Expatriate Kiwi’s will be less inclined to return home with the investments that they may hold overseas, which may now attract considerable Capital Gains Tax on unrealised gains. The New Zealand Government has done nothing to justify taxing these yet-to-be-realised returns.

Suggestions
The proposed bill should be modified so that an unrealised Capital Gains Tax is not introduced on international investments – as it will have a significant impact on New Zealand’s approach to investment and our overall wealth. The status quo should be maintained. Other parts of the bill unrelated to this issue may be retained.

Capital Gains on managed funds should be removed to create a neutral tax environment so that international and New Zealand equities, managed funds, and property share a level playing field.

Yours sincerely,

Gavin Treadgold

This article was originally written for the July 2006 International Association of Emergency Managers Bulletin.

The rapid growth of the Internet and World Wide Web has spawned the creation of new and potentially useful software applications that may provide benefits to emergency managers. One of these applications that is currently drawing attention is the wiki.

Wiki is the Hawaiian word meaning to hurry, hasten; quick, fast, swift. Wiki software therefore refers to packages that are designed to make it quick and easy to create and modify collaborative web pages on the Internet. They have actually become more powerful and advanced than just for the creation of web content – wikis now power some very content-rich websites including the open source Wikipedia – the open encyclopaedia.

What are some of the key characteristics of a wiki?

• server-based software
• free, with few licensing restrictions
• accessible from any web browser
• can be run on a standalone laptop
• uses html links to reference other pages in the database
• designed for collaboration and sharing
• records all revisions of documents and tracks changes made by users
• immediately highlights recent page changes and by whom

What opportunities exist for wikis in the emergency management domain?

Wiki software has much potential to be used as a collaborative planning tool – whether planning occurs within or between organisations. Rather than passing a word processing document around via email to all participants in the planning process, the plan could instead be created and maintained using a wiki. A secured web site would provide an excellent home where plan developers could log in to check the latest changes and make modifications. The one key benefit over using a document-based approach is that everyone is always guaranteed to be reading and editing the latest version of the plan.

As certain milestones are reached in plan development, it is possible to lock the wiki, and create a ’snapshot’ of the current plan before continuing the review and development process. Conceptually, this model of development is quite similar to techniques used for managing the development of computer software – with developers sharing a central repository.

In addition to planning, a wiki can also be used as a knowledgebase to store information and references to other documents. For example, certain pages in a wiki could be ‘tagged’ with a pandemic tag. Then, by viewing the pandemic category, it will show all pages that are tagged with pandemic. This provides quick and easy access to relevant information.

The benefits of wikis do not end when response starts. Conceptually, wikis can be installed on laptops or PDA’s enabling responders to have an entire knowledgebase available on a PDA including all the links and available plans.

Wikis could be used on a set of wireless laptops as a tool to assist your incident management system of choice. For example, the response plan developed in the EOC could be created in a wiki, and then planning/intel, operations, logistics, finance, information could collaborate on the one document with each section being able to view the other sections.

Wikis are also starting to be used in response and recovery by those people that have access to power and communications. Probably the best recent example is the Katrina Help Info wiki that is used to consolidate response and recovery information following a disaster – in effect creating a portal for the event with links to other agencies websites. In this manner, a wiki could be used as a public information system where key infrastructure is available.

Another example is the Hurricane Katrina web page on Wikipedia which started as a collaborative effort to record open source situation information. In the case of the Flu Wiki, wikis are even being used to develop a community knowledgebase about a hazard before the event.

It is important to note at this point that public wikis with permissive access controls can have issues with the quality and authenticity of information provided. Restriction of editing rights to approved and trained personnel can ensure that quality of information contained in the wiki is not threatened.

The next likely development is going to be the consolidation of wikis and community mapping projects such as the Hurricane Information Maps that were developed following Hurricane Katrina and utilise Google Maps. The combination of information contained in a wiki linked to spatial references and presented on a map will provide a very powerful information resource for response and recovery.

I wrote this article for the July 2006 International Association of Emergency Managers Bulletin.

In February 2004, I wrote an article for the IAEM Bulletin outlining some of the benefits that open source software had the potential to provide for emergency managers. At that time, little open source software existed for emergency management, and I had just come out of a simple attempt in 2003 to create a Web-based disaster management system. That effort failed, for while there was a well-recognized need for open source disaster management software, there were no real drivers to encourage development of a solution.

2004 Tsunami Spurs Development of Sahana

The driver came with the tsunami that struck Sri Lanka on Dec. 26, 2004, which prompted the development of a free and open source solution called Sahana. Within a couple of days, the need for a system to manage vast quantities of information became obvious, along with the need to attempt to coordinate 1,300 NGOs responding to hundreds of thousands of displaced people. In the following days and weeks, a Web-based system for managing disaster information was built on-the-fly based on the most pressing needs. Accordingly, the following were the first modules developed:

• People Registry – track and match victims of a disaster.
• Organization Registry – register, connect and track NGOs involved in response.
• Camp Management System – register and track camps.
• Request/Assistance Management System – record, track and match requests and offers of assistance.

Sahana development was initially led by the Lanka Software Foundation and supported by volunteers from the Sri Lankan IT industry. As the immediate need for Sahana subsided in the months following the tsunami, more international contributors became involved in the project, myself included. These ranged from programmers wanting to help out, to those who wanted to offer assistance drawing upon their disaster experiences, including emergency managers.The positive feedback to Sahana prompted further development to add more response and recovery capabilities applicable to any disaster management situation.Longer-term, the goal is to use Sahana as a means of encouraging comprehensive emergency management in communities by supporting preparation and mitigation. This will start by providing tools to incorporate plans and reference material, such as communication directories in advance and other techniques to encourage greater interagency co-ordination before an event.

Capabilites

Sahana has been designed to operate in a diverse range of environments due to the nature of disasters. It can run on Web servers and laptops, and has even been installed on a PDA. Over time, it will support both standalone and networked modes of operation and allow communication between multiple Sahana servers, including synchronization of data.There are a number of future modules planned or under development:

• Disaster Impact Assessment.
• Alerting.
• Inventory/Supply Chain/Logistics.
• Volunteer Coordination.
• Intelligence.
• Response/Rescue Team Management.

In addition, there are a number of key technologies identified for inclusion:

• Mapping/GIS, and GPS integration – it can already use Google Maps.
• Biometrics.
• Provision of information via open standards:
  • Common Alerting Protocol (OASIS/CAP).
  • Emergency Data Exchange Protocol (OASIS/EDXL).
  • Various OpenGIS Protocols (OpenGIS Consortium).
• Support of existing paperbased forms.
• PDA forms for remote fieldwork.

Deployment

Sahana has seen official deploy ments in multiple events, including the Sri Lankan response to the tsunami in 2004, the 2005 earth quake in Pakistan and the 2006 mudslide in the Philippines. It has also recently seen unofficial deployment in support of the Yogjakartra earthquake and in preparation for an eruption of Mt. Merapi. Sri Lanka’s largest NGO is also deploying Sahana within their disaster unit.

Recent Events

In mid-May 2006, a workshop was held in New York that brought together key members of the Sahana development community and IBM. The meeting served two purposes:

1. To discuss IBM support of the project, and
2. To consider further development of modules for Sahana that could be used during response to a pandemic.

A pandemic presents an interesting opportunity for the deployment of Web-based disaster management systems, as most infrastructure should be operating normally (relative to a hurricane or earthquake).The Sahana project is interested in contributions, be they time or financial. Time contributions can be made in providing design advice based upon disaster experience, writing the code, testing Sahana or helping to write the documentation. Financial contributions will be used to target module development, such as sponsoring development of a specific module or supporting the core development team that works full time. An international community maintains Sahana, and all contributions are provided back to that community at no cost – a share-and-share-alike ethos to ensure that everyone benefits. Sahana is free to use and has no licensing costs associated with it.

Links

• Sahana Web Site
• Sahana on Wikipedia
• Dr Sanjiva Weerawarana’s Blog, a record of initial Sahana deployment (entry1, entry2)

This article was originally written for and published in the February 2004 International Association of Emergency Managers Bulletin.

What is Open Source and what are the benefits to Emergency Managers?

The spread of the Internet has given life to what some may say is a radical change in which software is developed. Traditionally, software development has been driven by commercial vendors that provide you with a software package that cannot be directly modified to suit your organisations needs. Yes, you may be able to customise it with options and configuration settings, but if it doesn’t implement a function you need, there is usually little hope of getting it implemented. This is because you do not have access to the source code – the human readable code that tells the program how to operate. Open Source Software (OSS) changes all that.

What is Open Source Software? It is software that people can freely read, copy and modify the source code. This allows people to improve software, adapt it, and fix bugs. Additionally, this can often happen at a greater speed than conventional software development. But, the essential point with OSS is that you have the source code to the software, and the freedom to modify it, and redistribute your modifications.

The Internet has brought about the spread of Open Source Software because it provides a means of linking programmers and users around the world. The individuals come together on a project-by-project basis to develop software for a specific purpose.

So how can Emergency Managers benefit from Open Source Software?

Repair and Maintenance
Have you ever found a bug in your software, but you’ve had to wait until the vendor releases the next version of the software to fix it? Well, if you are using OSS, you can fix it yourself, or pay someone to fix it for you. Additionally, your fix then is released back to the community so all benefit from fixing the bug.

Licensing and Cost
Emergency Management Agencies often are not well funded, with some having to make do with whatever hardware and software comes their way. OSS provides an extremely cost-effective means of providing functionality. For example, if you receive Windows PC’s with no office software, you could download and install OpenOffice.org – a suite of office productivity software for free, and it is also compatible with Microsoft Office files. Other day-to-day software solutions are available, including web-based groupware servers. Of course you can install the software as many times as you like – consider how expensive that would be with commercial software?

Extendibility
If you want a specific function added to your open source EM software, you can always pay a programmer to implement it for you. The real benefit of OSS comes when these additions are feed back to the community at large, so the community as a whole benefits, and spreads the cost of development. It also gives you a chance to support a programmer in you town, rather than across the country or the other side of the world!

Flexibility
Once again, with the source code in hand, you can customise the application to allow for internal consistency with jargon in your organisation. By changing the terminology used within the application, you can reduce the training requirements, and maintain consistency with other applications.

Economies of Scale
There is the potential for pooling of resources to achieve economies of scale. One EMA may not be able to afford to develop an EM application. However, by working with others and pooling resources, it would be possible to come up with enough funds to provide full time jobs for people to work on OSS – specifically an EM application (or suite of applications).

Speed
And finally, because you have the source code, you are not tied into the commercial vendors release schedule. Want that feature? Need a bug squashed? You can pay someone to do it right now.

At this stage however, there is little Open Source Software specifically designed for Emergency Management. But that is about to change. Some of the base functionality is the same across most organisations – such as a contact directory, basic message handling etc. Rather than having to build all this functionality from scratch however, we can take an existing stable OSS project (e.g. egroupware) that has some functionality required for emergency management, such as groupware which provides contact directories, calendars, user authentication etc, and then develop and integrate specific emergency management functions, such as alerts, and message handling. This translates to months not years to get a useable product into development.

Links to Popular Open Source Software and Information Sites

• Mozilla Firefox – a very popular open source web browser
• OpenOffice.org – open source office software
• Open Source Initiative
• The OpenCD – a CD containly a wide range of open source software packaged on a CD
• MediaWiki
• eGroupWare – web-based collaboration software
• Wordpress – the software that runs this website is also open source