Gav's Blog

I recently sent this email off to a number of Ministers requesting that the NZ Post Code database be opened up and made freely available. I’ll write more later about the reasons why – but the main one is that the lack of a free post code database hinders new and novel applications of the post code, such as web services.

To the Ministers of: Commerce, Land Information, Stated Owned Enterprises, Communications and Information Technology

Re: New Zealand Post Code Database

Dear Ministers,

Currently the New Zealand Post Code Database is a paid-for dataset that New Zealand Post (a New Zealand State Owned Enterprise) charges a fee for.

See: Postcode Network File

I would like the relevant Ministers to investigate the release of postcode data that was announced late last year in the UK, where they are undertaking to open up and make freely available the postcode database. This is a fundamental and key dataset for business (and indeed non-profits and other community interest groups).

I would like to refer you to this BBC article that indicates that the UK Government is going to release the postcode data for free this year, and also point out that in the US all their zip code data is made available for free.

The release of the NZ postcode dataset would certainly seem to fit well with the Geospatial Strategy , and would be a continuation of the release of digital boundaries that started a couple of years ago with Statistics New Zealand.

I thank you in advance for consideration of this matter.

Kind regards,

Gavin Treadgold
Christchurch

On the 12th I received a reply stating that Minister Joyce will respond in due course.

12 May 2010

Mr Gavin Treadgold
CHRISTCHURCH

Dear Mr Treadgold

On behalf of the Hon Maurice Williamson, Minister for Land Information, I acknowledge receipt of your correspondence of 8 May 2010 regarding the fee for accessing the New Zealand Postcode Database.

In accordance with Ministerial responsibilities Hon Joyce will be responding for Ministers and Hon Williamson will provide input as required to that response following his consideration of your correspondence.

Yours sincerely

Stephen Walsh
Private Secretary – Land Information

My friend Ajay has prompted me to create this post, and I’ll try to add to it over time as more cameras with inbuilt GPS. Why is inbuilt GPS important? Well it takes all the hassle out of geotagging photos. As you may have read in some of my previous posts, geotagged images are really useful for Emergency Management.

Whilst there are plenty of solutions available, I’m not going to provide the post-processing options here. I only want to record those that embed the co-ordinates at the time of taking the photo. No products that require post-processing are included.

Digital SLRs inbuilt GPS

• None yet, but maybe this year, there are rumours the Canon 60D may have inbuilt GPS.

Digital SLRs with Accessory

• Nikon D5000, D90, D300, D700, D3,D3X – requires  Nikon GP-1 accessory or a di-GPS
• Canon EOS 40D, EOS 50D, EOS 5D Mark II, EOS 1D Mark III, EOS 1Ds Mark III – requires Canon Wireless File Transmitter accessory (model is dependent on camera body). More info on Canon GPS, and manual page. It additionally requires a third party GPS as well that can provide position using the NMEA protocol.

Point and Shoots

• Nikon Coolpix P6000
• Ricoh 500SE
• Leica V-Lux 20 – as well as having inbuilt GPS, it also appears to have an inbuilt database of 500k points-of-interest that can be used to show nearby sightseeing opportunities (added: 2010-04-22)
• Sony DSC-HX5V Digital Camera

GPS Receivers with Camera

• Garmin Oregon 550, 550T

Mobile Phones with GPS

• Apple iPhone 3G, 3G S
• Nokia – a number of models that I’ll list in due course

Survey Quality solutions

• ikeGPS

Frankly, Nikon appear to have to produce a far smaller and lighter GPS solution for their cameras. Canon requires not only a bulky grip, but still requires a GPS to be added as well. The Nikon GP-1 or di-GPS look to be far more appropriate for field work for emergency management. Additionally, the Nikon solution can be used in conjunction with a battery grip, which allows additional batteries into camera (two, instead of the usual one). The Canon grip increases the bulk of the camera, but the camera itself cannot use a battery grip to extend the battery life in the field. Of course additional batteries can still be carried and swapped – although to replace the camera battery, the WFT must be removed. Finally, the WFT3/4 also require their own battery to operate.

As a Canon user, I am most disappointed with their solution to geotagging-at-shutter-click, and the Nikon approach appears far superier as it adds very little bulk to the camera, and doesn’t get in the way of using a battery grip to double the life of the camera without changing batteries.

This is a brief product announcement I provided to The Box, it was published on Tuesday the 2nd of June, 2009. It is archived here for my records.

Garmin announced their latest high-end hand-held outdoors GPS unit recently, and the headline feature is the inclusion of a 3.2MP camera with built in geotagging. This means that any photos taken with the unit will be instantly plot-able on maps, and will be a convenient tool for people enjoying the great outdoors and travelling. Other nice upgrades to the flagship Oregon line include support for a 3d electronic compass for accurate bearings when standing still; increased storage for waypoints, tracks, routes; capacity for a massive 5000 paperless geocaches; and fast USB 2.0 transfer when connecting to a computer at last.

Garmin Oregon 550 Product Page

This is a copy of an article I had published in The Box on Tuesday, the 26th of May 2009. This is a copy of my originally submitted text, an archive for my my records. It is a topic that has seen a bit of interest. I’ve also been interviewed on National Radio’s Panel on this topic. I will probably be writing a more detailed article about the problem in due course.

A recent report from the US Government Accountability Office has identified possible trouble ahead for the Global Positioning System (GPS). Due to governance failures of those responsible for the GPS, there is the risk that satellites may not be able to be replaced faster than the rate at which they fail over the next 10 years. Whilst replacement satellites have been ordered and developed, some technical and project management issues have delayed the launch schedule, with the next launch planned for November 2009. This doesn’t mean that the GPS will just stop working. There are currently 31 active satellites in the GPS constellation – only 24 are required for the agreed level of service. There are 13 satellites that are more than 12 years old, and are increasingly likely to fail. This happens as the solar panels age, and they produce less electricity to power the satellite. There are options for extending satellite life by turning off less critical secondary payloads that draw less power. A few satellites can fail without having a significant impact on end users. If the number of active satellites drops to 24 or below, GPS receivers will probably be less accurate as fewer satellites would be visible at any given time. Given the GPS is a strategic military asset for the US, it is highly unlikely it will be allowed to fail completely. This may drive innovation in GPS receivers to support multiple satellite navigation systems to reduce reliance on a single system.

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.

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.

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 been collecting a few links for information about how technology and GIS has been used in the Bushfies in Australia; and how it could be used in future. A few of these are listed below. I will be continually updating this as I find more links.

• Bushfires, other emergencies and recovery – how do web mapping services help the public? – a question on LinkedIn.com, note you’ll need to be a member and have access to take part in this discussion.
• Satellite imagery of Southeast Australian Fires via NASA. Whilst there, we shouldn’t forget about the Floods in Queensland either
• Computerworld summary of online response
• Red tape holds up fire alert system

– I’m particularly interested in this, as I’ve been involved in work on a report in New Zealand last year on alerting systems. I’ll write more about this later. (lost link, will replace later)

• Google Australia – Mapping the Victorian Fires.
• Fire maps using Microsoft Virtual Earth.
• The Map Room blog has more mapping linkage available here.

Since buying into the iPhone ‘cult’ back in July, I have been intrigued as to the applications that will be released for the it that have relevance to emergency managers. One I’ve just discovered (via TUAW – check out their pics of the app) is one called Hurricane. Whilst this was released last year, it has since been updated to incorporate new functionality.

The price is reasonable (USD$3.99) if you want quick access to storm information in your phone at all times. It sounds as though when there are active storms, that when opened the app will come up with a quick list of current storms to provide quick access to more information. Outside of that, it has a record of past storms, as well as quick access to satellite view.

Sure, much of this information can easily be obtained for free, but the benefits of an application such as this indicate the an application wrapper that makes it fast and transparent to get the information you’re after. The only thing that I can think of at a quick glance would be also linking to the text watches and warnings from the NOAA Storm Prediction Centre.

It is going to be exciting to see what applications are released in the coming years that provide quick access to both remote and locally stored emergency management information!

I have been involved with a couple of other people over the past few months in asking some questions, and providing feedback on, the NZ Geographic Board (NZGB) Gazetteer spreadsheets. Wendy Shaw, Secretary of the NZ Geographic Board provided some very detailed comments and feedback on this, and with her permission, I have a copy of her email here for wider sharing.

Feedback on the ‘Gazetteer’ spreadsheets recently published on the web by LINZ is gratefully received. There will be on-going corrections to get the content as correct as possible in the coming few weeks and months. LINZ is currently investigating how it might potentially convert these spreadsheets to a more user friendly and effective database platform, that enables connections and relationships, as required. Some provision would also need to be considered for capturing spatial extent. LINZ’s business analysts are currently working on this and have been provided with relevant comments, as suggested.

With the Gazetteer spreadsheets, consideration will be taken on how best to annotate changes and may introduce a unique ID for the next publication of the spreadsheets on the LINZ website www.linz.govt.nz

As to the accuracy of coordinates, they are generally the coordinate or grid reference listed in the New Zealand Gazette that made the name official. There may be a need to clarify this point for users. The accuracy could be improved, and has been generalised for 1:50,000 topo mapping. To improve the accuracy for all official names to +/-5-10m for GPS users would not be possible.

Localities and suburbs that are currently being maintained by the New Zealand Fire Service are not publicly available. The review of the New Zealand Geographic Board Act looked at locality and suburb names, and intended to devolve the naming to Territorial Authorities, leaving the Board with a concurrence role. However, this did not eventuate in the 2008 Act, because it was identified that future ‘integrated address legislation’ would cover this off and that an amendment to the Act 2008 could be made in the future. For now the Board continues to have a role in assigning, altering, approving or discontinuing locality and suburb names – see item 16.27 on page 35 of the Board’s Frameworks document at http://www.linz.govt.nz/docs/placenames/nz-geographicbd/frameworks-nzgb-200809-ver2.pdf .

To recognise the importance of locality and suburb naming and the need to engage more fully with Territorial Authorities and the community, the Board’s membership will now include a person nominated from Local Government New Zealand. Also, a number of tasks and commitments have been identified, specifically relating to locality and suburb naming:

1. Research and collation of existing recorded suburb and locality names and supporting information in electronic form from existing sources.
2. Development of Code of Practice for official naming of Suburbs and Localities.
3. Secretariat administration to confirm proposed name concurrence with Code of Practice.
4. Gazette/newspaper advertising ongoing costs after initial naming.

Locality and suburb naming will be dealt with more fully by the Board in the near future.

For any queries, please contact Wendy Shaw, Secretary of the Board – wshaw@linz.govt.nz

Regards,

Wendy