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 was catching up on Twitter today, and saw some references to optimising Adobe Lightroom catalogues in #Lightroom (I’ve now found the original¹ posts² and had a read of them – there is more good stuff to try out. I’ve incorporated the previews and caching as well in my cleanup today). This struck me as something I was due to do as I knew my catalogue database was well over 250MB, and when something gets that big it needs a little maintenance. This prompted me to poke around a little and have a good cleanout.

Here’s what I did – some for speed, others just freeing up space.

0. Complete a Time Machine backup first.

Naturally, I wanted to make sure a had a backup before I did anything destructive – such as deleting files – so I forced Apple’s Time Machine to complete a backup. With that out of the way, I could start tidying up. If you’re on Windows, you should do a backup first before you do anything else.

1. Check the Backups directory.

I have Lr setup to backup my catalogue weekly – this keeps a fairly good trail of backups in case something goes wrong. It hasn’t yet. However, after 2 years of Lightroom use, my directory of Lightroom catalogue backups had blown out to 13.52GB! There were a couple of things I did to trash some of the existing backups.

• I removed all Lr v1 backups. I knew the date that I upgraded (by the last modified date of my old v1 catalogue file). I deleted all the v1 backups and this freed up 8.71GB. Since the upgrade produced a new catalogue name (with a -2 appended), I was able to confirm that I was only deleting v1 backups.
• For all months bar the last one, I decided that I only really needed to keep the most recent backup in each month, rather than sometimes all 4 or 5 in a month. I deleted all but the most recent and freed up another 2.64GB of space.

This brought the Backups directly back to a rather svelte 2.42GB.

2. Optimise Catalogue

I hadn’t seen this option before today, so I thought I’d check it and see how it goes. It is accessible via Lightroom > Catalogue Settings, and is a simple ‘Relaunch and Optimise’ button. My catalogue was around 18k photos, and was 262.9MB before optimisation. My Previews file was 101.7MB. Note this figure. After expecting it to take say quarter of an hour to process, I was surprised at how little time it took.

The resulting catalogue saw ~20MB removed and the overall file size brought down to 241.5MB.

I did get a shock when I saw my Previews file though, it had blown out from a lowly 101.7MB to a massive 7.74GB! However, I think this may have been a case of the package (Previews are a package on OS X) under-reporting its true size. I don’t think the optimisation process was busy enough to create 7GB of previews in such a short time! Therefore I think the optimisation actually made the package report the correct size. So I’m not treating this as a ‘loss’ of 7GB

3. Deleting Cruft

In the same directory as my main catalogue, I noted I still had my unloved v1 catalogue, as well as a couple of ‘Temporary Folders’ Lightroom had created that contained a couple of images that I no longer needed. Since these were already backed-up, I just deleted the old catalogue and these temp directories.

4. Rendering Previews

Quite a few of my previews had already been rendered, but I decided to check my rendering settings, and force Lr to render the rest. Library > Previews > Render Standard-sized Previews. I expect I may be facing a 20GB+ Preview file by the time its finished!

5. Adobe Camera Raw cache

As per Lightroom Queen’s article, I went and configured the cache on a separate internal hard drive. I created a new directory called /Cache/Adobe Camera Raw in the root of a second ‘working’ drive and added this in the Lightroom > Preferences > File Handling dialog. I choose the new directory I had created, and upped the somewhat meagre 1GB cache to a more workable 10GB.

Summary

All up, it has been a good little cleaning effort that netted me another ~11.5GB of storage. Which I think I will probably lose to previews. Lightroom doesn’t seem noticeably faster on open, but it does seem quicker to quit. I haven’t spent any other time in it this evening yet to comment on general usage. I’ll report back once I have completed the preview rendering and had a chance to spend a little more time using the optimised Lightroom.

1. Relaunch and Optimize Your Catalog Today – Adobe Photoshop Lightroom Killer Tips [↩]
2. Hurry Up Lightroom – Lightroom Queen [↩]

Three months ago I blogged about the Conficker worm and its relevance for emergency managers. Since then, I’ve rumours that a number of health agencies were still having problems with their email systems. The reason I raise this again, is that now, with a large national response to a potential pandemic taking place, one hopes that Conficker has been well and truly removed from all Health systems (both Ministry and DHB).

If Conficker is still impacting on health agency IT systems during this period of increased activity, then honestly, heads need to roll at MOH.

Well, it has been a lot of work for the admins, the mentors, and the students, but it has paid off. The Sahana has been awarded 10 projects in the 2009 Summer of Code. We have some great projects lined up! The include:

• Person Registry for Sahana
• Warehouse Management
• Disaster Victim Identification
• J2ME clients for form data collection in the field
• Optical Character Recognition for scanning forms
• Peer to peer synchronisation of Sahana servers
• CAP Aggregation and Firefox CAP plugin
• CAP Editing and Publishing
• Mashup/Aggregation Dashboard
• Theme Manager

Having been neck deep in the process; working with others to set up our assessment process, coming up with ideas (I’m stoked to have two students working on CAP ideas that came out of my earlier suggestion), and reviewing each and every of the 45 proposals we recieved, it has been exciting to get so many projects accepted.

I think that by the end of the year, we are going to have some great new functionality available in Sahana. Even more, I hope we’ll attract more open source developers to our ever growing community!

It is interesting watching the various mashups being created by people to plot the cases of Swine flu as it appears to spread. One thing that has struck me is is the poor use of symbology to attempt to communicate the desired information.

The first Swine Flu map that appeared on Google was fairly readable, however the author had decided to use a contrary means to identify fatalities. Whilst black is commonly used during triage as a means of identifying a death, this neocartographer has decided to use a black dot in the symbol to signify that they are living and the removal of the dot to signify a fatality. Of course, when I first looked it the map my instant read was that black dots represented fatalities.

Within the last few hours, a second mapmaker has come along and tried to correct some of the errors that the first created – namely they have now adopted black to symbolise a fatality, however the new torso icon really makes it hard to get a good overview of what has happened, and all the black markers in Mexico are completely unreadable.

Perhaps the brief takeaway message from this is that some authority that is actually well versed in cartography for pandemics should have a system in place whereby they can make this information available – with well thought through, and designed cartography. There is clearly a desire for it as these mashups indicate.

Update: I thought I better have a go myself. So here is my first attempt. I took this information from the WHO Media Release. This first effort was just to get some of the case and fatality numbers out there. I decided to take an aggregated approach and use one icon per city/town. To give a slightly better representation, I had to take one of the Google Maps markers and produce scaled-down versions to represent the cities with far lower numbers of cases and fatalities. Next step later this afternoon may be to map some of the other figures – e.g. the reports in the United States from those that were infected in Mexico. I’ve also included a reference table if you click the marker, which will contain a list of figures as at various times. There is also a link to the source used for those figures. I think this approach will result in a much less cluttered map. I could look at using colour better as well. Red could be used to represent cities where there have been fatalities, and yellow where there have only been cases, but no fatalities. As reports move more towards countries and states, it will be less appropriate to maintain a city/town based approach. This then probably means that a move to polygons is required to better indicate the affected areas, as states/countries don’t lend themselves to a point-based approach.

View WHO report of Influenza-like Illness in a larger map

Finally, the Wikipedia article on the current influenza event has now received its own page.

I have just submitted the following feature request to Adobe. I think it would be fantastic to have the option to let Lightroom automatically manage all files and folders using the capture time metadata field. This approach doesn’t make sense to everyone, but for those that manage their files by date and time, I believe it makes good sense.

Update – amusingly, Adobe limit their submission form to 2000 characters, and mine was about 3600. So I split it in two!

*******Enhancement / FMR*********
Brief title for your desired feature:
Provide configuration option to allow Lightroom to automatically manage files and folders by date and time metadata.

How would you like the feature to work?
1. Lightroom Preferences. I believe there should be a preference option that allows LR to automatically manage all folders and files in a catalogue. In the preferences the user would be able to set the following policies that are applied to all images.

1a. Folder structure – determine the folder structure e.g. yyyy/yy-mm-dd/
1b. File name – determine file name e.g. yyyymmdd-hhmmss-n
1c. Manual or Automatic update – determine whether changes are made immediately when date/time metadata is adjusted (Automatic) or if a user-initiated refiling is undertaken only when the user manually starts the process (Manual). Recommended default should be Automatic (e.g. immediate) updates.
1d. Time field – probably want to default to capture time. Not sure if this approach is useful for other times.

2. When a user imports images using ‘automatic file management’ the file handling import option is greyed out, and indicates that it is being automatically managed and shows the file/folder naming structure selected in the preferences. All other relevant import options are made available.

3. When a user edits date/time information in any way, upon saving the metadata, the image filename, and if necessary the folder it is located in is adjusted to represent the new date/time metadata (Automatic). This results in immediate refiling of the photo when the date/time is adjusted. Otherwise, the image stays in the same location until such time as the user interactive tells Lightroom to refile all images based on their current capture date/time (Manual).

4. If the user opts to change the filing policy set in the preferences – Lightroom should support a complete refiling of the library. E.g. if the directory policy is changed from yyyy/yy-mm-dd/ to yyyy/mm/dd/ then Lightroom should prompt the user to restructure the whole library now under the new policy, and indicate that this may take some time depending on the size of the library

5. Provide an option to check and refile all images that are currently selected (whether in grid, or by folder). This would allow the user to force a manual refile immediately. This option should of course only be visible to users that have enabled automatic filing.

Why is this feature important to you?
I would like to avoid having to manage names and locations of files and folders. I would like to optionally configure Lightroom to fully manage the names and locations of all folders and files. As long as I can define a policy for how the folders and filenames are structured, I am not concerned about having full control over the filename and location. I would like the image metadata to determine where it is stored on the hard drive.

As Lightroom currently stands (v2.3) when the capture date/time is adjusted, the file retains the imported time (which is clearly incorrect) and possibly is stored in the wrong folder (if the time adjustment has been across midnight). This is particularly an issue with travel photos.

It would be very nice to have the option to have all this managed automatically and transparently by Lightroom. Of course this should be an opt-in process only, as it really makes sense for uses that manage their photos using date and time. Conceivably, it may be possible to have Lightroom manage files and folders using other forms of metadata automatically in future, but I believe date and time makes the most sense to start with.

Just filed this bug with Adobe. Hopefully they will fix it to provide better timezone adjust support. The current workaround is very unintuitive.

Update: Just to clarify, this is only about changing the second option (time zone adjust) in the adjust time dialog. There are a number of countries that work on 30m TZ offsets – Alaska, a number in South America, Middle East, the Pacific. There is a good table available on this page from the US Naval Observatory.

******BUG******
Concise problem statement:
Timezone adjustment does not support all timezones.

Steps to reproduce bug:
1. Attempt to adjust timezone by -7.5 hours (difference between New Zealand Daylight Time and Sri Lanka time)
2. Only 1 hour increments are available in the time zone adjust drop down combo.
3. Fail!

Results: It is not possible to adjust the timezone in half-hourly increments. After some Googling, I found a very unintuitive workaround that involves selecting the first photo, and adjusting it by the required amount. This is not intuitive enough, and as there are 30 minute timezones, I believe obvious and intuitive support for 30 minute timezones should be included.

Expected results: In addition to the hourly TZ adjustment combo box, there should be another combo to the right that allows selection of 30 minute TZ by selecting either :00 (default) or :30 that is applied in addition to the TZ hour adjustment. This would make it possible to adjust the time to 30 minute timezones (e.g. Sri Lanka and India) in an obvious and intuitive manner.

What seems like a lifetime ago, I wrote my initial thoughts on the Garmin Colorado after having owned it for a few weeks. Now I’d like to return and offer more definitive thoughts on it after nearly a year of fairly heavy use. In this time it has been with me on somewhere around 1000 cache hunts, and a few overseas trips – mostly to Australia, but also Singapore and Sri Lanka. Naturally, it has seen a fair bit of domestic usage in little ole New Zealand as well.

I’m not going to spend any time going over what the Garmin Colorado is – there are plenty of articles on the net. I want to focus on the big pro’s and con’s associated with the Colorado. (Many of these comments may or may not also apply to the Oregon, I haven’t had enough hands on time with one to see what improvements they made from the Colorado.)

Made of Win
Win 1 – Stunning Maps. The screen and map display on the Colorado is absolutely gorgeous and blows away all of the previous generations of Garmin mapping handheld GPS units. The clarity of of the mapping display and the ability to clearly represent more layers at the same time is just great. I really struggle going back to older mapping units like the 60 series with far lower resolution and clarity in the maps.

Win 2 – USB Storage Device. Whilst it doesn’t sound like much, the change in metaphor for sending/receiving information from the GPS is a huge plus. You can accomplish most things purely by mounting the GPS as a USB device, and copying/deleting files from the GPS. No longer is it necessary to have Garmin GPS drivers to be able to communicate with the GPS. This is incredibly handy for travelling. If you prepare a whole lot of geocaching GPX files before you go, you can just store them on the device, and as you move around delete the active ones you are finished with, and store the others under a filename that the GPS won’t recognise e.g. use .bak or similar. Then, just rename the file from .gpx.bak to .gpx and next time you boot up, the GPS will load the new geocaches. This works the same for maps when travelling from country to country. If you have enough storage space to store multiple countries .img files from OpenStreetMap in the main memory, then as you move from one country to another, you can just rename/delete the old file, and rename the next country you’re heading to as the current gmapsupp.img – it works very well. Compare this with the alternative of either creating a massive gmapsupp file with all the countries you are travelling to, or having to take MapSource/RoadTrip with you and reloading maps as you go.

Win 3 – Paperless Caching (PC). The basic paperless caching functionality works pretty well. Two thousand caches is a far more reasonable limit than 500/1000 waypoints. The cache specific icons are great and make it so easy to see the types of caches at a glance on the map. The field notes work really well and speed up the logging of caches no end. It is very useful having the cache descriptions and logs, and we used this feature well on the road when figuring which caches to do next on a road trip.

Win 4 – Roller. What can I say, it is absolutely brilliant for zooming in and out on the maps.

Win 5 – Mount. The new mount connecter is very solid and works well on bikes and car dash mounts.

With that said, there are some areas where the Colorado let’s you down fairly significantly.

Epic Fail
Fail 1 – Archived Tracklogs. The 60 series had a near perfect means of archiving tracklogs. You could set it up to record to the SD card, and the unit would create a file for each day. Never, ever, did the GPS unit end up writing over already recorded tracklog data. Sadly, the same cannot be said for the Colorado. The archive track capability of the Colorado will only store 20 GPX files of approximately 1MB/5k trackpoints each before it will start overwriting the archived tracklogs. As a keen OpenStreetMap track logger, and also someone that wants to keep tracklogs from travel so that one day I can geotag some of my photos, I was livid the first time that I have found the Colorado was overwriting archived tracklogs. I really liked the 60 series handling where you could leave it going, and just trust that you come back and once every couple of months copy of all the archived tracks. Not so with the Colorado and it is one of my biggest frustrations. This means that archiving tracklogs becomes a hassle and a chore. This is such a big dealbreaker to me I am now considering what my next GPS is going to be. I want to be able to travel for weeks, have everything archived AND HAVE ABSOLUTELY NOTHING DELETED WITHOUT ASKING ME FIRST. Why can’t the system save tracklogs to the external SD card just like the 60/76 series do?

Fail 2 – Paperless Caching. Whilst PC has been extremely successful for traditional caches, there are many, many failures and oversights. Consider that earthcaches don’t have their own icon, and for some reason Garmin has seen fit to default them back to Traditional caches, when at a minimum they should be Virtuals. How hard is it really for Garmin to update the software to display them with their correct icons, or at the very least as a Virtual? Why, are all the child waypoints associated with a cache loaded as actual waypoints, rather than being linked to and accessible as part of the cache? All they do is take up the waypoint allocation, and they aren’t easily accessible from a cache description. Why does the list of nearest geocaches not show the cache type icon – instead you have to click through each cache to see what type it is.

Fail 3 – Lack of user-centric design. I’m not sure how Garmin tested the Colorado, but there are some silly design decisions that make no sense at all. When changing the location of a waypoint (e.g. editing the co-ordinates to enter a waypoint for a multicache) you can only see 10 of the 20 characters at any time. This makes it very frustrating when copying co-ordinates from a cache. The only way you can see them all at once is if you save the waypoint, then find it, and view the co-ordinates on the screen before selecting ‘Go’. This is an impractical solution. This is perhaps my most frustrating experiences, but there are others, and these point to a poorly designed interface that doesn’t appear to have any real thought around the development. How hard would it have been on the lat/long entry screen to have both the latitude and longitude visible at once? There is certainly enough screen real estate to support it.

So, what does this mean?
To me, I think there is something inherently flawed in Garmin’s design process. A number of these usability errors SHOULD have been picked during testing before release. One wonders if Garmin skimped on the end-user testing and rushed the Colorado to market. The Colorado has the feel of Windows Vista about it – some really nice new features, but some absolutely fundamental design errors that are real deal-breakers.

Don’t get me wrong, I’m not about to sell the Colorado and move back to a 60 or 76 series – I just couldn’t handle looking at the maps on one of them again, or losing the paperless caching. But, more than ever, my recent experience with losing archived tracklogs on the Colorado has got me thinking about the best approach to paperless caching and decent tracklogging – what is the next step.

Perhaps it is a fundamental mistake by me, thinking that I can have a single GPS that does everything I need it to. Even now, I still need my iPhone with caching details in addition to the Colorado. Perhaps I need to use a simple tracklogging GPS unit such as the Wintec G Rays 2 for logging tracks and not rely on the Colorado for this – it after all will automatically delete the archived data (which I don’t think is mentioned in the manual, just on the unofficial Colorado wiki).

The iPhone may end up being my saviour for paperless caching. Currently, we are tied to Garmin’s model and method of paperless caching on their units – you either use their approach, or you use another piece of hardware.

I’m starting to think that perhaps I can go the other way. Perhaps I should focus on looking for paperless caching capabilities in the iPhone. After all, all we need is something like GSAK/GPXSonar for iPhone, with an inbuilt map viewer that understands Garmin img map files, and that solution would likely blow away anything that Garmin could come up with (based on my 11 months with the Colorado). Sure, you could still use a basic eTrex high-sensitivity unit with caches loaded as POI’s, and take all the intelligent processing to a device capable of acting in an intelligent manner.

Garmin has had at least 12 months to improve the capabilities of the Colorado via software updates. All these issues, and hundreds more have been identified in the Garmin Coloroado wiki. Yet few have actually been resolved.

The core problem here comes down to Garmin being a hardware vendor, and they are still locked into the thinking that once the hardware is sold, only critical bugs will be fixed, and everything else will be left to the next generation of units – so you have to purchase new hardware to get a real upgrade.

This is in almost complete contrast to the Apple iPhone. With the iPhone, the software sees regular updates, and there have been some significant updates to old hardware. For example, the 1st generation iPhone and iPod touch were able to be upgraded to the v2 OS for either free or minimal fee, but the user received significant new capabilities. Come this June or July, even the original users of these devices will be able to upgrade to v3 of the OS and reap nearly all the benefits (yes, 1st gen. iPhones don’t have A-GPS, so the users will miss out on that – one of the reasons I didn’t get an iPhone until it had GPS).

On top if this, the iPhone allows developers to create competing applications. This means if you are so inclined, you can write a caching application if you choose. Whilst only geocaching.com will be able to have the tight integration with their website, I still believe there are possibilities for developers to deliver some stunning paperless geocaching applications that will blow away any capability that a hardware vendor such as Garmin appears to be capable of developing.

The software approach means that applications are sometimes updated every couple of months for existing users, and this is an area that Garmin has perhaps had their biggest fail. Garmin has failed to improve the utility in their existing units by fixing minor issues that the community have identified, and they are not releasing software updates as frequently as they should be. Any Garmin release generally addresses only a limited number of issues, especially when compared to the large number of outstanding issues identified by the user community.

This has perhaps been my big lesson with the Garmin Colorado. Garmin don’t appear capable of maintaining and improving unit capabilities once the product has been sold – certainly not when compared to iPhone updates. If Garmin keeps up like this, they are going to be made increasingly irrelevant by programmable devices like the Apple iPhone that will deliver extremely powerful paperless caching applications in spades.

The corollary, of course, is that if Garmin want to continue to deliver more complex and software-driven units to the market, they need to be far more responsive to the issues raised by the community, and provide more significant software updates.

The summary of course is that I’ll continue to use the Colorado – it is after all a sunk cost for me, and it does do some basic things pretty well. But am I seriously going to be keeping an eye out for alternative solutions that are more responsive to user feedback. I’m hoping that by sharing my experience with the Colorado, it will get you thinking about your choices more too.

I’ve just uploaded the presentation I gave on Sahana at the Sahana 2009 Conference in Colombo, Sri Lanka on the 25th of March, 2009. I’ll put a link up to the associated paper soon as well.

Here’s another CAP idea I wanted to get out before I read a document I’ve been sent that may cover the same topic (just to make sure I don’t potentially draw on someone else’s idea). This concept came to me, again, last year whilst I was working on the CAENZ Public Alerting research report last year (I’m still waiting for this to be publicly released so I can link to it). My recent post proposing a browser plugin for CAP alerts is part of this bigger picture I am outlining today.

The background for it came from the realisation that there are a significant number of organisations in New Zealand that are responsible for the publication of alerts – whether to a secure group, or the general public. For example, there are 16 CDEMG Groups, 70 odd local authorities, GeoNet, MetService, Police and those responsible for infrastructure such as roads, and the Centre for Critical Infrastructure Protection.

Each of these agencies would need some means of hosting a CAP server, and incorporating some means of resilience into their CAP server(s). Given that there are potentially such a large number of CAP servers required, there are some aspects that could provide a strong and robust CAP network without seeing a proliferation of potentially fragile CAP servers. This is all built on the concept of a secure peer-to-peer network of CAP servers.

Federation
It should be possible to federate a group of CAP servers into a cluster. If we take a CDEM Group as an example, the group members may elect to deploy say 4 or 5 CAP servers to create a peer-to-peer network providing CAP alert hosting for the CDEM Group. Any authorised CAP message posted to one of the federated CAP servers would automatically distributed the CAP message to the other CAP servers in the federation. In this manner, the CAP message is instantly distributed and made available to other servers in the federation.

Peer-to-peer
I believe that the more robust approach to developing a CAP network is to base it upon peer-to-peer network technology, although tweaked to provide a secure means of publishing messages to the network These servers could of course be deployed any way to provide maximum resilience, and may be located close to major New Zealand Internet backbones, and quite possibly well outside of their geographic region. This has two potential benefits for resilience. Firstly, the message is available from multiple servers, so that the load (particularly for publicly accessible CAP servers) can be distributed across the multiple servers automatically. Secondly, should any particular server fail, the messages will still automatically be provided from the other CAP servers in the federation.

One example means by which this could be deployed is the following.

Provide a national CAP server network of federated CAP servers at key points – a nationally managed set of strategically located CAP servers. For example, Government internal CAP servers would be most likely located on the Government Shared Network (GSN) or whatever comes out of the recent restructure of this service. Public servers may be spread around both by geography and ISP (e.g. key ISPs may host a CAP server for their customers). In all circumstances these would fallback to other CAP servers in the federation in case of their failure.

Naturally, the open approach applied to peer-to-peer file sharing is not appropriate for a trusted network CAP service. To create a more secure network, something like a two-tier approach may be necessary.

CAP Publishing Servers
Private CAP publishing servers may be utilised to act as the publishing gateway to the public read-only peer-to-peer network provided by the CAP Read-only servers. Authentication, encryption and/or digital signing should be used as the basis to authorise the publication of a CAP message via the publishing server. The publishing server is responsible for verifying the digitally signed CAP alert, as well as the authentication details to verify the user is authorised to post the alert. Once authorised, the CAP publishing server publishes the alert to the road-only servers. This is the only channel to publishing CAP alerts to the network. Some form of CAP writing software (or service) may be useful for creating CAP messages and then publishing them to the servers. One protocol that may be useful for publishing is Atom as suggested by this IBM article.

CAP Read-only Servers
These are the user-facing servers that provide CAP messages to their end users. Only the CAP publishing servers are authorised to publish CAP messages to the peer-to-peer network for dissemination.

Naturally, this concept is part of a larger plan to build a CAP framework, and the circle would be able to be partly completed by designing web browser plugins that are capable of connecting to the peer-to-peer CAP read-only servers.

Widespread deployment of CAP browser plugins may mean that traditional servers may not be capable of supporting tens or hundreds of thousands of CAP clients regularly checking for new alerts. A peer-to-peer approach will probably provide the most scaleable and robust approach to disseminating CAP alerts via the Internet.