blankblank blank

Author Archive for Leszek Pawlowicz Page 6 of 79

« Previous Entries
Next Entries »

FalconView Released As Open Source

Published by
Leszek Pawlowicz
 in GIS. 3 Comments

FalconView is the Windows mapping part of the Air Force’s Portable Flight Planning Software (PFPS), under development by Georgia Tech since 1994; see this link for an interesting history of the politics of software development in the military. This mapping part, stripped of all mission planning components, has recently been OK’ed by the Air Force for release by as Open Source software. The program has an strong list of features, including:

  • Support for many raster/vector map formats
    • GeoTIFF
    • TIROS TopoBath
    • Digital Terrain Elevation Data (DTED) / LIDAR
    • Vector Product Format (VPF)
    • CADRG
    • MrSID
    • GeoPDF
    • WMS
    • ArcMap .mxd (requires that ArcGIS be installed)
    • Shapefiles
    • KML/KMZ (including network links)
  • Moving map supported if you have a connected GPS
  • Generate and overlay contour lines from elevation data
  • Skyview mode lets you fly through terrain with overlays by keyboard/joystick control

skyview

But this open source version is labeled as alpha software, and it definitely is:

  • It wouldn’t install successfully on two separate Vista systems, claiming problems with MapServer initialization; was finally able to get it installed on a Windows XP system
  • It’s a huge download (about 500 MB), partially because it also contains critical supporting applications like DotNetFX and Windows SQL Server that must be installed in order to run the program
  • Some operations can run slowly on older systems
  • Occasional crashes on my system

A bigger problem is that it’s a complicated program with lots of features and a non-intuitive interface. Documentation is currently limited to the help file, which is clearly intended for someone who’s already familiar with the program; no manuals or other documentation is currently available. I struggled for several hours trying to figure out  the simplest task possible, add a raster image to the map and view it, before finally giving up. I may not be the sharpest tool in the shed, but I’m not the dullest, either.

FalconView also installs GeoRect, a program to georectify imagery and export it in GeoTiff format. I had hopes that this could be used to convert GeoPDF files into GeoTiff format, since it does open GeoPDF files. But I was defeated on this score as well; while the help file is substantially more helpful than that for FalconView, I was unsuccessful even following their step-by-step instructions. And it appeared as though it would only convert a beta USGS quad in GeoPDF format to a GeoTiff far smaller than would be necessary for full resolution.

I welcome comments from anyone who’s used this program before, and can offer pointers, and I’ll keep an eye on it for the future. But until there’s substantially better documentation available, I’m not going to spend a lot of time struggling my way through this software.

HT to Thomas Larsen.




Garmin Maps On A Windows Mobile Pocket PC Or Smartphone

Published by
Leszek Pawlowicz
 in Garmin and GPS. Closed

In a previous post, I covered the PC version of gpsvp, a program that lets you view Garmin vector maps on your PC, and plot your live GPS position on them; it also has multiple other functions like waypoint/track management, raster maps from the Internet, and more. In addition to the PC version, there are also versions available for a number of Windows Mobile Platforms that turn them into the functional equivalent of Garmin GPS devices :

  • PocketPC 2003
  • Pocket PC 5, 6
  • Smartphone 2003
  • Smartphone 5, 6

The look and feel of the app, and most of the functionality, are virtually identical to that of the PC version:

gpsvpppc

This is the Pocket PC / Windows Mobile 5 version, with a free Garmin topographic map of Arizona loaded (available at GPS File Depot), with my current GPS position plotted as the black dot. Obviously, you’ll need either a built-in GPS receiver in your Windows Mobile device, or a Bluetooth-connected GPS receiver, to get this full functionality.

Getting the maps on your mobile device involves copying them over onto the device using the ActiveSync File Explorer. While you can put it into the device’s main RAM, you’re probably better off installing it on the device’s SD card if it has one, since it likely has more memory space available. gpsvp will automatically search the device and SD memory to find Garmin .img map files, and let you select either an individual file or a folder full of files. Don’t load too many files in, as gpsvp can choke on large numbers of files; I was able to have all the Arizona topo map files loaded up, but it took a while to load them in. As described in this post, you can use GMapTool to select the map tiles you plan to use, then copy just that limited set of files over.

There’s also a version for Java VM enabled portable devices listed as GPS4Mobile.jar in the file list; don’t have such a device, so I don’t know what it’s functionality is.




Identify Garmin Map Tiles And The Area They Cover

Published by
Leszek Pawlowicz
 in Garmin and GPS. Closed

If you load a Garmin mapset into MapSource, individual tiles are identified by a geographically-related name, and they area they cover plotted on a map. But the tile files themselves (*.img) have cryptic 8-digit filenames that don’t correlate with their name or the area they cover. But there’s a simple way to look at a file, or multiple files, and determine both their name and the geographic area they cover using the freeware utility GMapTool.  Start up the program, click on the Add Files button, and go to the directory containing the .img files, here from the Garmin Topo 2008 mapset:

selectfiles

Select one or more files, click OK, and you’ll get a listing of the filenames, their sizes, and their names in the Garmin mapset:

listing

To determine the geographic area covered by a map tile, click on the tile, then press the Details button:

details

The geographic extents of the tile in latitude and longitude are buried in the middle of this listing:

N: 48.499832, S: 48.249722, W: -121.501236, E: -121.001186

Useful if you want to create a mapset that’s a subset of a much larger mapset, and want to figure out which tiles you need.




A PC GPS Application That Lets You Use Garmin Vector Maps For Live Navigation (OSM, Google And Bing Maps, Too)

Published by
Leszek Pawlowicz
 in Garmin and GPS. 2 Comments

I’ve used Garmin’s MapSource long enough to remember when you could display a live GPS position in it on a standard Garmin vector map. A few years ago, Garmin removed GPS functionality from MapSource, and put it into a separate free application called nRoute. nRoute could display your live GPS position on a Garmin vector map, do routing, and more. But just a few months ago, Garmin pulled all links to nRoute, and now sells an application that does basically the same thing. Edit: In comments, Thomas Larsen offers this still-active Garmin download link; grab it while you can.

But if you have an NMEA-capable GPS receiver, like a Bluetooth GPS module, and a Bluetooth-enabled Windows PC, there’s a full-featured application that will let you plot your live GPS position on standard Garmin vector maps: gpsvp. Using gpsvp, you can:

  • Load Garmin .img files, and display them on your PC with your current position plotted on top:

gpsvpgarm

This is a free Garmin Arizona topo map, available at the GPS File Depot along with free maps for most of the rest of the US; a search for “Garmin maps” on this website will bring up sources for free maps for much of the rest of the world.

  • If you have an Internet connection, you can download raster map tiles for a location from Google Maps, Bing Maps, and OSM (including satellite, terrain and hybrid views):

gpsvposm

OSM Map

gpsvpgoogle

Google Map

  • Display position, GPS status, time, altitude and other data in the monitor bar at left; you can customize this to show whatever you want
  • You can also drop the map display, and only display parameters in a full screen monitor bar
  • Open, create and export waypoint and track files in GPX and PLT formats
  • The website documentation seems to suggest that you can convert your own raster imagery, or WMS imagery, into a format compatible with this program, but I’ll be danged if I can figure it out.

Documentation overall is a bit weak, so you’ll have to figure it out by experimentation; but, most of the menu items are fairly easy to understand.

Here’s a few tips:

  • To download and view raster maps, you have to turn off the Garmin maps (from the menu: Maps => Garmin Maps, and uncheck the “Show Garmin maps” item), and also set a folder to use as a cache folder for downloaded imagery (Maps => Raster maps => Set raster cache folder). Then set the Raster map type you want (Maps => Raster maps => Raster map type), and download the maps (next menu item down from the previous one). It looks as though map tiles can be cached for use offline, but I’m not sure about how that works.
  • You select the Garmin .img maps to use, either by individual .img map file (Maps => Garmin maps => Open map), or all the maps in a folder (Maps => Garmin maps => Open map folder). Be careful with the latter option if you have a large number of maps, as this can crash the program. For example, I could load the entire folder of Arizona topo maps into gpsvp at once, about 150 MB of maps; trying to load all of the US Topo 2008 Garmin maps in froze the application.

Unfortunately, all Gamin .img map files are identified by an eight-digit number that offers no real clue as to what area is covered by the map. But there is a way to find out what area is covered by a specific numbered map file, and its name as well, and I’ll cover that in a future post.

One final irony: the program only works with NMEA GPS data, and if you own a Garmin unit that doesn’t output in that format, you can’t use this program directly; you’ll need to buy a copy of GPSGate, which can convert the proprietary Garmin protocols into an NMEA-compatible data stream.

gpsvp is an open source project, with access to the source code available anonymously via svn.




Followup On Comments From GPS Accuracy Posts

Published by
Leszek Pawlowicz
 in GPS. 1 Comment

Got some good comments from several of the recent posts on GPS accuracy (one, two), comparing GPS receivers from Garmin and Holux, and thought I’d feature them here with additional comments from me.

Peter Guth (author of the freeware GIS MicroDEM) notes that measurements by his students of a NOAA tidal marker showed that its measured position was off from the specified position by a distance comparable to what I saw with the Holux GPS receiver, suggesting that perhaps the NGS benchmark position I had was off by a comparable amount. His marker has been removed during pier reconstruction and then replaced, so it wasn’t clear whether the position he had was the current position, or possibly an older one before it had been moved and replaced. My NGS benchmark showed no signs of being moved, and sits on a hill in a National Forest where it’s unlikely there was any reason to ever move it; that doesn’t mean the position I had for it wasn’t wrong.

Peter also asked about quantization of positions, i.e. what was the minimum difference in latitude or longitude for the two GPS receivers I looked at. His older Garmin units only give positions to the nearest tenth of a minute, roughly a meter or so. For both the Garmin and Holux receivers, the value was the same: 2E-06 degrees in latitude and longitude was the minimum difference, corresponding to roughly 0.2 meters N/S, 0.16 meters E/W. So the difference in measured positions is unlikely to be due to differences in positional resolution between the two units. With display set to decimal degrees, my Garmin only shows five decimal places, corresponding to an accuracy of about 2 meters or so, but downloaded data is available with more significant figures. Didn’t look at the NMEA numbers for the Garmin, but for download waypoints, accuracy is given to 8 decimal places, or 2mm accuracy; this is not a degree of precision that the Garmin, or most GPS units, can determine in real-time.

He also noted he had also seen a skewed distribution of positions in some Garmin units, similar to the diagram in this post.

PMarc suggests that I measure the benchmark position with a Differential GPS, to see whether the measured and given positions match. Don’t have access to that, but might be able to borrow a GPS unit in the future with 0.3 cm accuracy after post-processing, and I’ll update these posts if I get more data. He also asks about the stability of the benchmark, and when it was last surveyed. It’s very stable, sitting on top of a hill with a thin layer of soil on top of solid basalt and limestone. There is a fault nearby, but it hasn’t been active during recorded history, and certainly not since the benchmark was installed (1959). The last surveyed position was done in 1992 using “standard geodetic survey methods”; this is a heavily-wooded area, so establishing clear lines of sight for such a survey might have been difficult. Both receivers were pumping out raw NMEA data streams, so there was no screening of positions by either unit based on DOP.

Terry notes that in the position plots shown in the first post, the Garmin values appear to be even distributed around the center point, while the Holux points might have a directional skew. Tough to say from those posts, since the Holux points are very tightly plotted, and you’d need to expand the scale to know for sure (which VisualGPS doesn’t let you do). Follow up plots for both Garmin and Holux units using SA Watch, which Terry hadn’t seen at the time of his comment, seem to show a pretty strong NE to SW axis for Garmin points, with a less-pronounced directionality for Holux points.

Nick Hopton notes that DNRGarmin uses the Proj.4 library for re-projecting coordinates, and that might be introducing errors. Good point, and I’ll try to find a more accurate coordinate conversion program; finding a free one (or even a paid one) that doesn’t use Proj.4 isn’t easy.

Not sure what the moral of all this is; perhaps that if you’re going to use a GPS receiver to measure field positions, using tools like VisualGPS,  DNRGarmin and SA Watch to evalute its accuracy, repeatability, and variability might be a good idea.




One Final Look At GPS Positional Accuracy With SA Watch

Published by
Leszek Pawlowicz
 in GPS. 2 Comments

In previous posts (one, two), I’ve compared GPS positional accuracy for a Garmin 60Cx handheld GPS unit and a Holux M-1000 Bluetooth unit and seem to have found that:

– The Garmin’s average position seem to be better, but the distribution in measured positions is large

– The Holux’s positions have a much tighter distribution, but the average is further off from the true position than the Garmin

Just for the heck of it, I took a look at results from both receivers with one more program that’s been around a while: SA Watch (shareware, $20; 30-day demo evaluation version available). SA stands for Selective Availability, the pre-2000 government policy of degrading GPS signal accuracy to non-military GPS receivers. The idea was that you could run SA Watch for a prolonged period of time, hours if not days, and the effects of SA would get cancelled out leaving you with a reasonably accurate position. SA is now turned off, but SA can still be used to evaluate the stability of a GPS-measured position, and calculate an average. While VisualGPS gives you an arithmetic and least-squares mean, SA Watch lets you calculate a mean weighted by the Dilution Of Precision, a measure of the amount of error in the position that’s due to GPS satellite geometry.

Here’s a plot of 119 positions measured by the Holux M-1000 GPS unit; the position grouping is pretty tight:

holuxsa

And a plot of  412 positions measured over the same time period by the Garmin:

garminsa

As with previous measurements, the distribution of Garmin positions is far larger than that of the Holux. Based on all this, I’d have to say that a single position from the Holux is likely to be more accurate than a single measurement from a Garmin, even if the Garmin’s average value is better. And for my applications, that’s what really matters; you may have a different requirement. If I get the time, I may do a similar analysis in the future from a different location, and see if the results are comparable.




Determining GPS Circular Error Of Probability (CEP)

Published by
Leszek Pawlowicz
 in GPS. 6 Comments

In a previous post, I used the program VisualGPS to compare the positional accuracy of a Garmin 60Cx GPS receiver with a Holux M-1000 Bluetooth receiver, measured at a National Geodetic Survey marker of known position. The average position of the Garmin wound up being closer than that of the Holux, but the distribution of positions for the Garmin was far wider than that of the Holux. To compare the GPS receiver results another way, I measured positions from both units over the same period of time, then determined the Circular Error Or Probability (CEP) for both.

The CEP is determined by the number of points within a certain distance of a specific location as a percentage of the total number of points. So the CEP for 50% would be the distance within which half the points would lie closer to a specific location. The free program DNRGarmin can calculate the CEP from the following sets of point data:

Continue reading ‘Determining GPS Circular Error Of Probability (CEP)’




Evaluating GPS Receiver Accuracy With VisualGPS

Published by
Leszek Pawlowicz
 in Garmin and GPS. 2 Comments

The last post dealt with VisualGPS, a program that monitors NMEA GPS connections, plots measured positions as a function of time, lets you average those position measurements for improved accuracy. I took a laptop with VisualGPS and two GPS receivers out to a National Geodetic Survey benchmark with a well-defined position to see how well it works at position averaging, and to compare results from the two receivers.

Continue reading ‘Evaluating GPS Receiver Accuracy With VisualGPS’




« Previous Entries
Next Entries »