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.
How to access the USB device
With the GPS60, there are two options:
- With kernel's
garmin-gps
driver emulating serial device/dev/ttyUSB$n
- 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:
- Give HAL an information/.../10-gps-devices.fdi file listing all known GPS devices
- Give HAL a policy/.../10-gps-devices.fdi file which sets up permissions "properly"
- 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:
gpsd
(shares position via TCP port or experimentalDBUS
)gypsy
(shares position viaDBUS
)- GPS drivers directly in application (e.g.
GarminDev
inQLandkarteGT
) 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 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 gpsbable
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 gpsd
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:
gpsd
should continue to run asgpsd_t
, and while we're at it, we could also lockgpsbabel
into its own SELinux cage- This solution is unnecessarily complicated with the two processes involved.
Use the GPS position fix
TODO
Software: navit, 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.