Archive for the ‘GPS’ Category
Next-gen iPhone unsuitable for Emergency Management?
The recent announcement of the second generation iPhone has a large number of people buzzing. The inclusion of Global Positioning System (GPS) capabilities into the phone creates a very capable mobile computing platform that has a lot of potential for emergency management.
What features make it a potentially useful tool for emergency managers?
- Large storage – 8-16GB. Plenty of room for photos, documents and other material in a slim and very portable device.
- Excellent user interface. I’ve been using an iPod Touch (iPhone less the phone) for 9 months now and have to say it is the nicest user interface I’ve used yet on a small device. I find it truly painful to use my Treo 750v mobile phone in comparison.
- Multi-method positioning. The upcoming iPhone will be able to use three different methods to locate the devices current position. First, and most accurately it will use the GPS. It will then fall back to wifi, listening for nearby wireless devices and looking these up from a georeferenced database over the Internet, If both of these fail, then the least accurate method of using the cell towers will be used.
- Multi-channel communication. The device will not only be able to connect via mobile carriers, but it the previous version it has wifi – at the minimum it could be used to connect to a local wireless LAN and access a Sahana server disconnected from the Internet.
Sure, there are some negatives too – it is a fragile device not necessarily suited to hazardous environments, and it doesn’t have replaceable batteries. Everything has limitations though and if these are recognised and accommodated, one could still achieve benefits from its usage.
Apple has also released a Software Development Kit (SDK) and infrastructure to allow software developers to write applications to run on the iPhone. This creates opportunities for development of tools that can be deployed for emergency management on an iPhone.
One example – as the iPhone has a GPS, camera, and means of connecting to the Internet (wifi or mobile) – it wouldn’t be too hard to write an application that could be made available for free download to citizen’s iPhones. Then, anytime they see say damage on the streets surrounding their home or work, they could take a photo, fill out some quick optional comments on a form, and submit the georeferenced photo and comments over the Internet to a Sahana server and instantly have the image geolocated for the emergency managers use. And, if the phone can’t make a connection due to failure or congestion, then the images are queued for delivery once communications are restored.
However, recent news of the iPhone SDK suggests that such an application would be in breach of the license agreement. I’m not a developer, but Electronista provides the following text from the license agreement, Section 3.3.7
applications may not be designed or marketed for real time route guidance; automatic or autonomous control of vehicles, aircraft, or other mechanical devices; dispatch or fleet management; or emergency or life-saving purposes.
I don’t have a problem with most of these – but the broad definition of emergency may stop deployment of emergency management applications on the iPhone. This is understandable from a liability perspective, but I hope it doesn’t stop developers creating ground-breaking emergency management applications using the potential of the iPhone.
Speaking of which, location-aware applications for the iPhone2 are already being displayed. Two very interesting ones to pop up so far are Loopt and OmniFocus. Very cool possibilites are opening up. Loopt is a location-aware social networking tool that lets you see if any of your friends are nearby so you can hook up for a meal or coffee. OmniFocus for the iPhone introduces location aware task lists. Near the office? Your office tasks pop up. Need to go to the grocery store to get item on your grocery list? It will provide directions.
It is going to be an exciting time for location-based services!
Protecting your privacy uploading tracklogs to public sites
I have become interested in the ways that you can protect potentially private or sensitive information that may be contained in tracklogs uploaded to any public site. I am primarily writing this article from an OSM perspective, but it is really valid for any site that you may upload a tracklog to.
A GPX tracklog consists of a lot of sections of code that look something this – a trackpoint.
<trkpt lat="-43.502053000" lon="172.576317000">
<ele>16.480000</ele>
<time>2008-05-06T08:37:46Z</time>
</trkpt>
A trackpoint contains two key pieces of information – the time (in UTC – the Z after the time refers to this), and the location in latitude and longitude. A whole pile of these trackpoints are then added together to produce a tracklog. This of course presents a privacy risk as anyone that has access to the tracklog might be able to assume that the person that uploaded the tracklog was at that location at the time specified. And with GPS, this can be recorded to a high level of accuracy.
So, what we need to do is look at ways to protect some of this information. I’ll write here about two techniques that I have used to protect information in tracklogs by editing them before uploading them to public websites. For most public websites, the most important information is location, and time is less important. So we need to take a two-pronged approach to tracklog privacy protection.
1. Delete track points that we might have privacy concerns with.
2. Remove timestamps that we don’t want people knowing the time we were there.
Deleting Trackpoints
1. Protecting it manually. I have been using the free GPSTrackMaker to load and edit tracklogs before uploading them to OSM. This is a manual and sometime laborious process. I use this to remove any trackpoints around the final locations of puzzles/multi-caches that I have visited, and also to remove trackpoints close to home/home/friends etc. I also use it to touch up the tracklogs such as those areas that spray trackpoints around a wide area that don’t mean anything – such as in urban canyons in Wellington. This can result in quite a ‘rich’ tracklog, especially if you delete those areas where the trackpoints are not that accurate due to GPS signal error.
2. Automating deletion of trackpoints. There are also a number of locations that one may always want to remove from a tracklog before making it publicly available. Locations such as home and work spring to mind. I was looking for a way to automate the removal of these locations using GPSBabel. Using nothing more than co-ordinates near your home and a radius, you can easily set up a filter to remove all points that fall with the circle using the following GPSBabel command. Note that the following command is needlessly complex as a little workaround is required to use the radius filter on trackpoints (you have to convert tracks to waypoints, do the radius filter on waypoints, and then convert the waypoints back to tracks – ugly but it works).
gpsbabel -t -i gpx -f in.gpx -x transform,wpt=trk -x nuketypes,tracks -x radius,distance=0.3K,lat=-43.0,lon=172.5,exclude,nosort -x transform,trk=wpt -x nuketypes,waypoints -x track,pack,split=30m,title="LOG %Y%m%d" -o gpx -F out.gpx
It is possible to build a batch file that removes multiple locations such as home, work and friends, that requires very little input. Note that this process does not destroy the original tracklog that you keep, rather it creates a new tracklog with the sensitive data removed.
Removing Timestamps
For whatever reason, it makes some sense to also remove timestamp information from tracklogs – I won’t go into the reasons here. Here is a little unix script that I use to change the timestamp information. Usually I don’t mind people knowing what day I was somewhere, but I’m not that keen on them always knowing the time. So, I will remove either minutes/seconds, or minutes/seconds/hours as have every timestamp appear as midnight.
If you want to set it so that all times are set to the start of the hour e.g. hh:00:00, use this.
#!/bin/sh
for f in *.gpx; do
sed 's/:[0-9][0-9]:[0-9][0-9]Z/:00:00Z/g' < $f > ${f%.gpx}-clean.gpx
done
If you want to set it so that all times are set to midnight e.g. 00:00:00, use this.
#!/bin/sh
for f in *.gpx; do
sed 's/T[0-9][0-9]:[0-9][0-9]:[0-9][0-9]Z/T00:00:00Z/g' < $f > ${f%.gpx}-clean.gpx
done
Naturally, this isn’t the easiest to do, but it is getting easier. It would be great if someone was able to write a tool/webpage that was able to do this sort of cleaning of tracklog data before uploading it to public websites.
National Address Register project terminated
I wanted to share some extremely disappointing news that I received today. The National Address Register project has been terminated.
This project had the intention of providing a single national authoritative dataset for roads, addresses and placename information. The potential of this project was to deliver a free dataset that all organisations and individuals in New Zealand were free to use. This would have made a fantastic resource, and had the potential to consolidate a number of mapping projects, and could have greatly simplified the work associated with project such as the NZ Open GPS Maps project, as the NAR would have provided a single national focal point for feedback and correction of road and address information.
The cynic in me says that the reason this project failed was because of the commercial interests in existing roading datasets. Currently there are multiple roading datasets from different providers, and they are making very good money from these. Some roading datasets sell for six figure sums on an annual basis. Naturally, very few organisations can afford these prices, so only large Government agencies tend to be able to purchase them. Suffice to say, these datasets are different, and there is not a single authoritative dataset amongst them.
The NAR had the potential to create a single, free and authoritative road, address and placename dataset. Tenders were invited for the project, and there was going to be only one organisation to win the tender. As a result, all but one of the current commercial providers stood to lose their revenue streams from their roading datasets. As you will see in the notification below, the tenders were too expensive. I believe that it was in all the commercial vendors interests to put in high tender prices to ensure that the NAR did not go ahead, and that they could protect their existing revenue streams rather than risk missing the tender and losing it all.
The upshot of this is that my faith in the Government to provide geospatial information to its citizens is now close to zero. If they are not capable of producing a single authoritative roading dataset (arguably one of the most important sets of spatial information as it defines most of our physical connectivity) then there is little hope of them being able to deliver any useful spatial information to citizens.
As the NZ Open GPS Maps, Zenbu and NZ Open Street Map projects have shown us, a volunteer community can develop products faster and cheaper than commercial or government organisations, and over time they will have better quality as well.
I believe the time has come for us to build more volunteer communities to provide spatial information that our Government is failing to provide to us. No longer can we wait upon them, rather we must build it ourselves. There are four key areas that we need to focus on.
1. Raw data collection – taking our GPS units out into the real world and collecting and sharing data. Collecting track logs and uploading these to the OpenStreetMap or NZ Open GPS Maps projects. Providing waypoints to OSM and Zenbu. Please – if you haven’t already, consider donating some time and information to these projects so that they have raw data to work with. This ‘field survey’ work is essential to creating our own spatial information resources. (I would particularly encourage geocachers to contribute their tracklogs if at all possible as we tend to travel a little more than others)
2. Mapping – converting the data collected in the field to information. Creating vectors for road lines, adding street name, directions, speeds. Using your local knowledge to map the community around you.
3. End products – converting the spatial information into a form suitable for others to use, for example the NZ Open GPS Maps project producing Garmin map files that can be loaded into GPS units.
4. Distribution – due to the large quantities of information involved, we may need to look at creating an ad-hoc network of individuals and websites to share the vast quantities of information about our country via torrents or similar P2P mechanism.
I believe the time has come for all those that want better access to spatial information to go out there and be a part of collecting, and building it. We can’t wait for Government to build it for us, so we will have to do it ourselves.
Let’s get started.
SUBJECT: NAR PROJECT TERMINATEDThe National Address Register (NAR) project is a cross-government initiative set up to develop infrastructure to improve the provision of address, road and place name information for government agencies, businesses and the wider community.
The project is over-seen by a Steering Committee comprised of representatives of key stakeholders from central government, local government and emergency services agencies.
An integral part of developing a business model and business case for the National Address Register (NAR) was to assess whether there was a supplier able to provide the relevant services and to identify the likely costs. An RFP process was chosen as the most effective way of identifying both of these.
Following assessment of the tender proposals, the Steering Committee has decided to terminate the project. Despite the project showing considerable potential to reduce duplication across government and reduce costs, it is too expensive to proceed with in its current form.
Further investigation into the need for, and the most cost-effective way of providing address, road and place information, will be led by the New Zealand Geospatial Office, within their mandate under the NZ Geospatial Strategy. This work will include determining the optimal role for the Crown, local government and the private sector. Brendon Whiteman, Director New Zealand Geospatial Office - brendon.whiteman@linz.govt.nz; will be happy to answer any queries that you may have in relation to these activities in the context of the overall work programme of the Geospatial Office.
It is expected that agencies will continue with existing arrangements they have for the purchase of this location data, from the commercial sector.
Nancy McBeth of the State Services Commission, is preparing a Lessons Learnt report on the NAR project. If you have some views that you would like considered in that report, please contact her at nancy.mcbeth@ssc.govt.nz by 31 May 2008.
On his return from Annual Leave next week, Laurence Millar, Chair of the NAR Steering Committee will formally write to your Chief Executive to advise of the decision.
Regards
Jill Barclay
Operational Owner NAR project
NZ Police
Received from a public email list I subscribe to.
Garmin Colorado 300 Review
Note – this is a living document and will be continually updated with more observations as I spend more time using the unit.
Introduction
For a couple of years now, I have been borrowing a friends Garmin 60csx for going geocaching with. My last GPS was a Garmin GPS Map 76S, and before that the venerable 12XL. With my use of the 60csx steadily increasing, my friend was seeing less and less of their GPS, so I finally decided after some reading to take the dive and purchase one of the new Garmin Colorado’s to become my primary GPS.
This article is my living review of the Garmin Colorado 300 that I purchased, and I’ll be continually updating the page as I find more likes and dislikes. Any additions after the first publication will have the date of addition in brackets. I’ll mark positive and negative points with the obvious +/-.
Summary
I had heard quite a few comments and discussions about the Colorado’s, and had the brief opportunity to try one out up in Hamilton recently thanks to RadioNut and ButterflyLady. I had been tossing up between trying a Colorado and getting a Nuvi for the car, but the need to stop hoggin my friends 60csx made the decision for me.
To date I haven’t regretted it. The benefits so far appear to outweigh the hassles, and I’m sure that there will be many improvements made to the software in due course. Haven’t yet cached with it, but it looks promising – although I don’t think it will replace the PDA notes functionality I use for recording multi-waypoint information and calculating final caches.
System Software History
* Initial Writing – Software Version 2.40, GPS Software Version 2.60
Casing and Connectivity
The new exterior to the unit is remarkably different. Most noticeable is the big shiny screen, the roller, and the silver finish.
+ In the hand – the unit fits in my hand much better than the 60csx and feels much more solid and durable.
+ Big screen – more real estate taken up by the screen is a good thing!
+ External antenna port – this is in a far better position than the 60csx, and is far less likely to come out during use. The problem I had with the 60csx was the rounded casing around the external antenna port caused the plug to come loose with just the slightest antenna cable movements. Initial tests in the car show this port to be far better designed.
+ Latch system – the new latch also looks a big improvement over the 60csx. Having previously attempt to carabena the 60csx to something using the metal ring on the back, I quick discovered that with a big of movement the latch would soon open the battery compartment and you’d end up with the GPS on the ground, and just the back lid still attached to you. Not good. The new latch appears to secure the back much better.
+ Mounting system – the new mounting system on the back also seems a big improvement. I haven’t got the bike mount set up yet, and the car mount hasn’t arrived, but it appears to have a very nice rile system to slide the unit snugly into mounts.
- Silver finish – sure it looks high tech and all, but I’m wondering how long it is going to remain in that pristine condition once it has been on a few geocache hunts with me.
- USB Storage mode – why oh why did Garmin decide to have the Colorado automatically switch to USB storage mode as soon as a USB cable is connected? The 60csx was fantastic in that you could power the unit in the car via USB. Now you plug it in with the same cable and the unit switches to USB storage mode. Even worse, because you can’t eject it, you have to remove the batteries to reset the unit to its ordinary operating mode. For sure, make the storage mode easy to access when connecting it to a computer, but don’t have it default to it. Perhaps pop up a brief window that gives the option of converting to USB storage mode, but if no input is given in a few seconds then the GPS should stay in the same state.
Configuration and Profiles
The Colorado can be a bit of a monster to configure at first glance. It introduces profiles for different activities that allow you to quickly change the setup of the GPS.
+ Profiles – it is great being able to customise the the GPS for different activities. The unit came with profiles for Recreational, Geocaching, Automotive, Marine and Fitness activities. Each profile allows full customisation of all settings of the unit. Even allowing different co-ordinate systems, or measurement systems to be defined.
+ XML Profiles – I haven’t had much more than a casual poke-around on the USB file system of the GPS yet, but it appears that the profiles are stored in XML. This means in theory that you may be able to create a global XML template, and then adjust them in a software editor or even a web page. This may be particularly useful for sharing profiles with mates, or for suppliers to create profiles, and then upload new profiles just by copying the XML profile files into the appropriate folder.
- No global profile – one problem with the very configurable XML Profiles is that there doesn’t appear to be a global profile. This means that if you want to change a setting in all profiles you have to either load and edit each profile individually in the GPS, or change it in each XML file. What would be really nice is being able to have a Global profile (XML, just like the rest) that defines settings, and then each profile is able to either overwrite a setting, or inherit the property from the Global profile. Likewise, if the profiles are able to inherit properties from the Global profile, then the XML profiles would be smaller and easier to edit as they would only have to record the settings that are different from the Global profile, rather than record every setting.
Interface and Input Methods
This has been perhaps the biggest learning curve yet, as the Colorado has a significantly different user interface and input methods.
Having come from the 12XL, 76S, and more recently the 60csx, I have become very accustomed to the ‘page’ style of navigation.
+ After a few days usage, the roller is very very nice for changing the map scale, and sure beats the continue – in, in, in or out, out, out on the 60′s.
- Shortcuts Menu – I’m not yet convinced this is the easiest way to navigate around the pages, and for the time being I have changed this to the more familiar ‘page’ navigation. This can be changed in System Setup Page > Shortcuts > Options > [ Use Shortcut Menu | Use Page Loops ]. This may be where profiles come in. If using a profile with only a few pages, it may be better to use Page Loops. If using a profile with a large number of pages, the Shortcut Menu is probably a far better option. At least with profiles, you’ll have the best choice.
- Navigation strangeness – When navigating to a waypoint, and using Shortcuts, the Stop Navigation function is found under the Shortcuts list. However, when using Page Loop, it is dynamically added to the top of the Other list. Strangely enough, neither of the two obvious pages that may be used for routing – Map or Active Route – provide a quick option to either Stop or Detour the current navigation. Detour doesn’t even appear in the Other list in Page Loop mode. For some reason, when you are navigation, and are set in Page Loop mode, a second Mark Waypoint is added to the Other list, so you end up with Stop Navigation, followed by two Mark Waypoints. Clearly a bug with handling these dynamic menus. As it is currently structured, the Shortcuts mode appears to be far more reliable and easier to access Stop Navigation.
- Profiles – it should be far, far easier to change profiles. Right now you have to head to either Setup or Other, select Change Profile and select the profile. Too hard for constant changing, particularly if you’re going from Automotive to Geocaching as you drive to a cache, hunt a cache, drive to the next cache etc. It should be possible to load profiles into the Shortcuts menu.
- White message pages – these have frankly become a little irritating. Having the whole screen revert to white to display an error message is annoying. Particularly when you are driving and navigating and you are not necessarily in the possible to dismiss the error. More subtle error messages should be implemented that allow you to continue to at least see the display of the GPS.
Function – Tracks
The tracklog is a mixed bag so far with the Colorado, and I haven’t yet quite got my head right around it. The setup is relatively simple and allows you to select Auto/Time/Distance as always.
One thing I loved about the 60csx – particularly for travel – was the way you could set it to record track points quite frequently, and have it save them to the card. Each day it would create a new tracklog file with the date as the filename – e.g. 20080508.gpx. This was great.
The Colorado setup is different. In particular is the way it handles Current vs Archive tracks. This of course may just be nomenclature in that the Current track is the same as the 10k active track on a 60csx, and the Archive tracks are the equivalent of those save to a card. However, instead of naming and filing the tracklog GPX files by date, the Colorado appears to be using a serial number e.g. 1.gpx, 2.gpx etc. It appears to create a new file at a certain size, rather a separate file for each day.
Function – Geocaching
The geocaching functionality on the Colorado certainly deserves a lot of discussion. Some aspects of it work very well, others leave a lot to be desired.
+ Geocaching GPX – the ability to store geocaching GPX in the unit and display cache information is quite useful. It provides nice quick access to difficulty, terrain, cache size, trackables, full description, hints and logs. This certainly brings the Colorado a long way towards true paperless geocaching.
+ Field Notes – these appear to work very well. After heading out for some geocaching where I found four, and DNF’ed another, I tested the upload of the field notes file. It worked flawlessly and provided me with an easy means of creating logs for each cache, and these were removed from the list as the caches were logged. The are loaded in the order they were logged in the field – making the logging of caches easier than ever before. I am certainly going to make good use of this function. Of course, given that field notes are nothing more than a text file, it could also be crafted on a PDA in the field and uploaded. But the Colorado certainly makes it painless.
- Geocaching GPX for multis and puzzles – the geocaching GPX is fantastic for simple geocaches such as traditionals and letterboxes. However, it does fall down when multicaches are concerned. Multis still required something to record details and solve to find the final cache. Coming from a PDA, I still found myself reaching for the PDA to complete the multi-caches today.
- Geocache waypoints – Unfortunately the geocaching functionality does not recognise multicache waypoints, or carparks and the like. Instead of finding them under the Geocache page, you have to return to the Where To? page, and go to waypoints and then try and find the waypoint. The Colorado really should be smart enough to match the 3rd-6th/7th characters of a waypoint name so that it can match it to a geocache, and then display these child waypoints under the Options menu with a nice quick Go To Child Waypoints page or similar.
- Routing – it is quite cumbersome to select road routing to drive to a cache, and then revert to geocaching mode to find the cache. All navigation in the built in geocaching mode is point-to-point. The Geocaching profile really needs an additional option when selecting Go To Location – it should ask whether you would like to route or go direct. I found it quite frustrating today to switch back and forwards between modes today so that one could route from cache to cache in the car.
- Cache identification – it would be nice on the Geocache page if the type of each geocache was identified with a little icon. It would help when deciding what cache to do next to see whether it is a traditional, multi or puzzle.
The Geocaching functionality has a lot of potential, but it is still in a relatively immature state. The capabilities are huge step up from the 60csx in terms of complexity, however the ease of use and thought about the interface doesn’t look that refined.
Function – Automotive
Wow – used the Automotive profile today and was very impressed by the map. A nice oblique view looking down from behind to show the streets ahead. Upcoming streets a nicely labelled. I’m really looking forward to getting the car mount now and using it. It looks very nice.
Function – Satellite
It is a simple page, but one I refer to quite often to check the signal. Whilst the display of information is very nice, I feel that it has a few improvements that could be made.
- Signal Strength Bars – the dark blue signal strength bars are very difficult to see against the default dark green background. Please provide a higher colour contrast setting so that you can actual see the signal strength bars at a quick glance.
- Unknown Number – there is a little number down the bottom right of the constellation map, but it is not identified. I assume it is the elevation. Please mark it as such.
Function – Map
What can I say other than the new map looks absolutely fantastic. Most of these comments are based on the NZ Open GPS Maps and the Global DEM.
+ Global Digital Elevation Model (DEM) – the inclusion of a global DEM means that even New Zealand to some degree gets the pretty shaded relief map imagery when zoomed out. Note that this is not the 3D view, and that requires additional information to be added to the maps to support that.
+ Resolution and Screen Size – the combination of increased screen size and increased resolution have created a gorgeous and practical display. Practical as you can display more detail on the map by using smaller cartography.
+ Tracklog Mapping – the mapping of tracklogs is far less intrusive than it used to be. A nice thin black line that doesn’t obscure the actual roads is a big improvement. It even allows you to see more detail in you tracklog, such as the line around roundabouts. Very nice.
+ Options – the map options are very simple and easy to use. It is simple to select maps and enable/disable them with just a few simple clicks. Likewise adding and removing data fields are quick and easy. Modifying data fields couldn’t be much easier either.
- Only Two Data Fields – with the increase in map size, it might be nice to have say four data fields on occasion, but the options didn’t appear to allow anything other than the default two.
Function – Compass
I haven’t really used the compass yet, so more comments will come.
- Easy On/Off – it seem really strange that to turn the compass on and off, you can’t do this from Compass Page > Options, rather Setup > Heading > Compass > [ Off | Auto ]. You should be able to quick toggle this from the Compass page options.
Function – Project Waypoint
This is a really bad example of user interface design. I can’t believe that to enter the bearing, you have to enter each digit of the degree. How slow, painful and indicative of someone that hasn’t really thought about the design. They should use a different graphic to indicate a compass, and have fast turns translate to +/- 10 or 15 degree increments, and have slow turns refine the bearing by individual degrees. Far quicker entry than the tortuous system they have now.
Recommended Improvements
These are listed in no particular order, and are a brief summary of what is contained in the review above. I’m sure some of these we will see in time with software upgrades – assuming that Garmin just wanted to get the Colorado’s to market, and then continue adding/refining features to an existing userbase.
* Create a global profile, and allow custom profiles to inherit or override properties from the global profile. This will make profile management quite a bit easier.
* High contrast signal strength bars on the Satellite Page.
* Identify the mystery number of the Satellite Page.
* Allow the display of more data fields on the map display e.g. default is two, allow say four, or even six.
* Provide a quick Compass Off/Auto option on the Compass Page.
* Provide a different user interface for selecting degrees on the Project Waypoint page. There is absolutely no reason to enter each digit individually for a bearing.
* It would be nice on either the Satellite or Map pages to have an option to quickly turn the Tracklog on/off.
* Make it easier to access the Stop Navigation/Detour modes when in Page Loop mode. In fact, why not just put these under the Options menu for both the Map and Active Route pages – as these are the most commonly used pages for routing.
* Profiles should be able to be added to the shortcuts menu to speed switching e.g. I’d like to be able to quickly select Automotive and Geocaching profiles with as few button presses as usual.
* Geocaches page needs to identify different cache type at a glance.
* The Geocaching function needs a much easier means of integrating routing for driving between caches, and then switching to cache hunting.
* Stop the unit switching to USB mode when a USB cable is plugged in. Why can’t it work just like the 60csx? USB should power it by default, and perhaps the USB mode could be selected from the Shortcuts instead
* Get rid of the full white page error messages.
Wellington Geospatial Mashup 2008
As part of the GOVIS Geospatial miniConference, a maps mashup is being held the day before with data sets being provided by LINZ and others. More information will be made available on the barcamp page (for more on what a barcamp is – click here).
A challenge to innovate! A challenge to find open data! Create and present your mash-up with a few data sets provided for the BarCamp! Cool Prizes! Sponsored by Statistics New Zealand, The New Zealand Geospatial Office and the Spatial Sciences Institute. Entry is open to everybody who is enthusiastic about using New Zealand’s core geospatial data in presenting current issues and analysis challenges! MashUp 2008 is an event which brings together New Zealand’s leading technical experts, as well as budding enthusiasts, in combining information sources with mapping boundaries and data in innovative ways. Rules of the competition will be downloadable here as soon as possible.
How It Works – Global Positioning System
I wrote this article for the 6 December 2007 issue of The Box, it also appeared in Stuff. I was also interviewed for a geocaching article that ran next to this GPS article, and managed a mention under Adventure Caches!
When I purchased my first Global Positioning System (GPS) receiver in 2001, it was rare to see someone else with them. These days, you can find them just about everywhere – particularly suckered to car windscreens. But how does the GPS work?
It’s quite appropriate that in-car GPS receivers are usually located close to the radio, as the GPS is similar in concept to a radio. Instead of ground-based aerials to transmit radio stations with voice and music, the GPS uses around 30 GPS satellites orbiting 20,200km above the Earth’s surface to transmit signals that GPS receivers listen to, and use these signals to calculate their position.
Each satellite accurately knows the time and its own position in space based on its orbit and onboard atomic clocks. This information is then broadcast from space for any receiver to hear. The GPS receiver uses the precise time and position information broadcast from each satellite to trilaterate and determine its location based on how far it is from known reference points – the satellites. Whereas triangulation uses angles to calculate location, trilateration uses distance. Listening to one satellite, the receiver could be located anywhere in a circle around that satellite. If the receiver knows how far it is from a second satellite, then the number of possible locations of the receiver is reduced to two. The known location of a third satellite would identify a unique location, and reduce the calculation error to an acceptable level to generate an accurate location.
A GPS receiver is capable of listening to 12-20 satellites at the same time. Generally, the more satellites the handheld can listen to at the same time, the more accurate it is at calculating your latitude, longitude and to a lesser extent altitude. The receiver needs to be listening to at least 3 satellites to calculate a location. In good conditions the location is accurate to 3-5 metres.
The default model of the Earth used for calculation is the World Geodetic System 1984 (WGS-84). This is used on all new GPS receivers. Most receivers allow alternative display systems to be selected – in New Zealand the combination of Geodetic Datum ’49 and New Zealand Map Grid should be selected when using a receiver with the current 260 series topographic maps.
GPS receivers aren’t always able to report accurate positions – this is usually due to the receiver not being able to ‘hear’ the satellite signals correctly. When the receiver has a good clear view of the sky – for example standing on top of the Port Hills – there is nothing stopping the signals reaching the receiver. Problems arise when you place the receiver under thick bush canopy or in buildings where the signals have trouble penetrating. Similar problems can be found in gullies and valleys, or urban canyons in high-rise cities. In these situations, the receiver can only produce approximate locations and often will fail to even produce a location.
Over the past 2-3 years, the processing technology within receivers has reached the point where they can produce accurate locations even in many demanding environments. With a mixture of low and high sensitivity receivers on the market, this can be an important purchasing decision if you are going to be using the receiver in challenging locations.
Change is also afoot in space, with Japan, China, India, Russia and Europe announcing new or updated navigation satellite systems. The EU’s Galileo system recently announced an agreement that will make their system compatible with the US GPS. More satellites and updated receivers will make it easier to get a signal and more accurate location!
NZ Open GPS Maps Project wins award!
I had the pleasure to see a project that I’ve watched since inception win an award on Wednesday night. The NZ Open GPS Maps Project was the winner for the Open Source Software Project.
This award recognises an outstanding project to develop open source software. The project must be either based in New Zealand or have substantial contribution from New Zealanders living here or overseas.
For those that aren’t aware, the Open GPS Maps Project started a number of years ago out of a desire to produce freely available maps for Garmin GPS receivers, and it has grown to be a fairly significant project supported by a wide community of users and ‘regional mappers’. Graeme Williams has done a fantastic job in growing and maintaining this project, and it has been very well received by members of the NZ Recreational GPS Society of which I’m the current President. Many of our members are active contributors to the project. Back in the early days of the project, I produced the original ocean to give the map a more realistic look.
Preview in OS X 10.5 to support georeferenced photos
From the 300+ features announced in OS X 10.5 (courtesy of SlashGeo), one that I really like the sound of is that Preview will now recognise and make use of georeferenced digital photos – photos that have latitude and longitude incorporated in them.
GPS Metadata Support
Get real information from your photos. If your image has embedded GPS metadata, Preview will show you exactly where that perfect photo was taken. Open the Image inspector and select GPS. Preview pinpoints the location where you took the photo on a world map. From there you can even open the GPS location in Google Maps.
Of course, not many digital cameras support GPS at this point, but there are a number of ways to add lat/long information to photos when post-processing. I recently purchased a very small GPS tracker that I can mount on my camera and it generates a tracklog that can then be matched up with the timestamp in a photo to estimate where the camera was at a given point in time. I am interested in this not only for hobby photography, but also as an application during disasters using this setup for Disaster Impact Assessment and being able to easily produced georeferenced photos of damaged infrastructure for example.
Magnificent GPS logs
Here is a cool website where you are able to sign up and upload GPS logs. It is called Magnalox – which is short for magnificent logs. It displays logs using javascript and CSS with a cursor to represent time. You can also add images, text and links to be displayed at certain points in the log. It looks quite nifty!
Space Weapons Test could impact GPS
A space weapons test by China produced a significant amount of orbital space debris that may damage satellites in orbit, including those that provide positioning information.
The Chinese test, carried out on Jan. 11, was at once complex and very simple. The missile hit the satellite with deadly precision. The missile carried no bomb because it didn’t need one. The satellite was pulverized by the impact. As of today, Kelso reports that American radar is tracking at least 525 pieces of debris from the collision — each at least the size of a baseball. There are probably hundreds, if not thousands, of smaller ones. The pieces are gradually spreading out in a ring around the Earth, creating a vast area where spacecraft face increased danger of being hit. “We’ve already seen in the range of 500 to 600 events where some piece of debris from this one event was coming within 5 kilometers of some payload,” said Kelso.