GIS/PositionFixes

GIS Devices

There are a number of different devices useful for GIS purposes: GPS receivers, DGPS receivers, and probably a lot of other stuff. If these devices are connected to a computer, the device permissions need to be properly set up, the proper kernel and userspace drivers need to be loaded, and then some user application can make use of the device.

GPS Devices

You can connect a GPS receiver to the PC using several methods: RS232(serial), USB, Bluetooth.

As an example, I will explain the current situation in Fedora 11 with a Garmin GPS60 connected via USB.

How to get position fixes from a Garmin GPS60 via USB

RS232 is easy to connect to gpsd, and most navigation apps like tangogps can connect to a gpsd daemon. However, with USB, that is different.

For getting position fixes into the system, three issues need solving:

1. find the correct device file
2. set up permissions to the device file
3. run some software reading from the device file and distributing the position fixes on the PC

How to access the USB device

With the GPS60, there are two options:

1. With kernel's garmin-gps driver emulating serial device /dev/ttyUSB$n
2. Using the USB protocol via a /dev/bus/usb/001/005 device and libusb

As serial devices are the standard in the GPS device world, using the emulated one would be nice and compatible. However, the garmin-gps kernel driver is much better at doing NULL pointer dereferences than at doing anything useful (and it appears to declared deprecated anyway).

So we are going to use the device's USB protocol via /dev/bus/usb. This can be achieved if we just add a new line to /etc/modprobe.d/blacklist.conf:

   blacklist garmin-gps

Device Permission Setup

Fedora 11 does not contain any mechanism to set up the permissions to GPS USB devices in any way.

By default, the garmin-gps kernel module (yes, the NULL-pointer-dereferencing one) is being loaded and the resulting serial /dev/ttyUSB0 device is being treated like a modem, permission-wise. Nothing at all is being done on the /dev/bus/usb/$n/$m device.

As we have already blacklisted garmin-gps above, we are now halfway set up alread.

We still need to do three things:

1. Give HAL an information/.../10-gps-devices.fdi file listing all known GPS devices
2. Give HAL a policy/.../10-gps-devices.fdi file which sets up permissions "properly"
3. Add a gps policy to HAL's device-access policy in /usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy

Everyone says HAL is being phased out and replaced by a different piece of software, but HAL is what I am running right now on F-11 and so it is what I need to change now.

TODO: Describe 3 somewhere. gps-devices git repo gps-devices RPM package?

We can now easily make backups of the waypoints routes tracks stored on the GPS with a command line such as

 $ gpsbabel -t -r -w -i garmin -f usb: -o gpx -F gps-backup-$(date -I).gpx

Which software to use for gathering position fixes

Ideas:

1. gpsd (shares position via TCP port or experimental DBUS)
2. gypsy (shares position via DBUS)
3. GPS drivers directly in application (e.g. GarminDev in QLandkarteGT)
4. gpsbabel experimental feature to output NMEA data into a named FIFO,

 which could then be read as a serial NMEA device

gpsd

gpsd can gather position fixes from many GPS devices and distributes the position fixes via a TCP port and an experimental DBUS protocol.

We could either run gpsd as an unconfined_t non-root user - which is easy when there is just one GPS connected to the system, maximum. However, we need to start it more or less manually, which sucks.

We could also run gpsd as a system service (user nobody, group gps, gpsd_t) and modify the HAL database such that new devices are added to gpsd's list of devices to be polled when they are plugged in. However, that is relatively complicated to set up SELinux wise (needs new gps_device_t for the device file, and then grant gpsd_t processes access to those device files) and (and this is the deal killer) gpsd ONLY speaks the serial protocol. This is apparently an explicit design decision to avoid depending on libusb.

However, this means we can only use gpsd with USB devices with the buggy garmin-gps kernel driver. That rules out using gpsd to connect to the GPS device.

gypsy

gypsy is being toutet as the better gpsd with its many design mistakes fixed.

Unfortunately, while I find a lot of discussion on how gypsy is supposedly better than gpsd, I cannot find any hints as to how to actually invoke gypsy, or which software can actually read its position fixes from DBUS.

Most of the navigation software (e.g. tangogps) appear to have gpsd TCP options but no DBUS things.

GarminDev in QLandkarteGT

GarminDev accesses the devices directly via the USB interface using libusb, and QLandkarteGT's GUI allows querying the GPS for position fixes directly.

Unfortunately, the only thing GarminDev is currently able to do on my system is to throw an error message about not being able to communicate with the GPS device.

Neither with F-11's ancient software versions shipped via yum, nor with the more current software versions in the F-11/ CVS branches, nor with current SVN of GarminDev and QLandkarteGT.

gpsbabel

We have seen above in the waypoint/route/track backup: Unlike all the programs built to get position fixes from the GPS, gpsbabel can at least communicate with it in some way. Unfortunately, we don't want W/R/T uploads or downloads right now. We want GPS position fixes, but gpsbabel cannot read position fixes... or can it?

Quoting http://www.gpsbabel.org/htmldoc-1.3.6/tracking.html:

   As of this writing, Garmin's PVT protocol and NMEA are supported inputs.
   KML, NMEA, and the variou XCSV formats are supported on output.

The idea coming to mind is to let gpsbabel talk to the GPS device and convert the position fixes to standard NMEA sentences, which can then be piped into gpsd and distributed further via TCP:

 $ mkfifo fake-gps
 $ gpsbabel -T -i garmin -f usb: -o nmea -F fake-gps
 $ gpsd -n fake-gps

Interestingly, this complicated setup actually works, as verified by running merkaartor.

However, this setup needs some messing with gpsd's SELinux permissions: Even if the user starting gpsd is unconfined_t, the default gpsd policy module has the actual daemon process change context. So the quick workaround is

 # semodule -r gpsd
 # fixfiles -R gpsd restore

You can revert these SELinux related changes by running

 # semodule -i /usr/share/selinux/targeted/gpsd.pp.bz2
 # fixfiles -i gpsd restore

While it is nice to see that there is a way to get GPS position fixes into the PC, this method as it stands may work but is not suitable for any official inclusion:

1. gpsd should continue to run as gpsd_t, and while we're at it, we could also lock gpsbabel into its own SELinux cage
2. This solution is unnecessarily complicated with the two processes involved.

Use the GPS position fix

TODO

Software: navit (review ticket), tangogps, gpsdrive, kismet, JOSM, QLandkarteGT, merkaartor

Purposes:

• Moving map display
• Mapping GSM/UMTS signal strength.
• Create OSM maps
• Road navigation

Conclusion

For something which should work more or less automatically, attaching a GPS device to get your position and doing a moving map display or navigation based on that position still requires an awful lot of work.