From Fedora Project Wiki

< GIS

m (Minor fixes)
 
(13 intermediate revisions by the same user not shown)
Line 1: Line 1:
= GIS Devices =
In order to get GPS position fixes onto the PC and use them, we need


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 device(s) attached to the PC
# kernel driver for the device
# userspace driver for the device
# service process distributing position fixes on the computer


== GPS Devices ==
This page collects the current facts and proposes a few ideas of how to make things work.


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


As an example, I will explain the current situation in Fedora 11 with a Garmin GPS60 connected via USB.
You can connect a GPS receiver to the PC using several methods: RS232(serial), USB, Bluetooth. RS232 devices will need a more or less manual setup, while the USB and Bluetooth devices can be set up automatically once the proper infrastructure bits are installed.


As an example, I will explain the current situation in Fedora 11 with a Garmin GPS60 connected via USB. I am aware that situation will change significantly with HAL being replaced for Fedora 12, but you need to start somewhere.


== How to get position fixes from a Garmin GPS60 via USB? ==
CAUTION: If there is a daemon type program continously getting position fixes from a GPS device, it might be difficult/impossible to upload/download waypoints, routes and tracks. This will need to be considered eventually.


RS232 is easy to connect to <code>gpsd</code>, and most navigation apps like <code>tangogps</code>
= How to get position fixes from a Garmin GPS60 via USB =
can connect to a <code>gpsd</code> daemon. However, with USB, that is different.


For getting position fixes into the system, three issues need solving.
RS232 is easy to connect to [[pkgdb:gpsd|gpsd]], and most navigation apps like [[pkgdb:tangogps|tangogps]] can connect to a [[pkgdb:gpsd|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 ===
# find the correct device file
# set up permissions to the device file
# 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:
With the GPS60, there are two options:
Line 36: Line 45:




=== Device Permission Setup ===
== Device Permission Setup ==


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


By default, the garmin-gps kernel module (yes, the
By default, the <code>garmin-gps</code> kernel module (yes, the
NULL-pointer-dereferencing one) is being loaded and the resulting
NULL-pointer-dereferencing one) is being loaded and the resulting
serial <code>/dev/ttyUSB0</code> device is being treated like a modem, permission-wise.
serial <code>/dev/ttyUSB0</code> device is being treated like a modem, permission-wise.
Line 54: Line 63:
# Add a <code>gps</code> policy to HAL's device-access policy in <code>/usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy</code>
# Add a <code>gps</code> policy to HAL's device-access policy in <code>/usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy</code>


Everyone says <code>HAL</code> is being phased out and replaced by a different piece
Everyone says [[pkgdb:hal|HAL]] is being phased out and replaced by a different piece
of software, but <code>HAL</code> is what I am running right now on F-11 and so it
of software, but [[pkgdb:hal|HAL]] is what I am running right now on F-11 and so it
is what I need to change now.
is what I need to change now.


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


=== Which software to use for gathering position fixes ===
== Which software to use for gathering position fixes ==


Ideas:
Ideas:


  a) <code>gpsd</code> (shares position via TCP port or experimental <code>DBUS</code>)
# [[pkgdb:gpsd|gpsd]] (shares position via TCP port or experimental <code>DBUS</code>)
  b) <code>gypsy</code> (shares position via <code>DBUS</code>)
# [[pkgdb:gypsy|gypsy]] (shares position via <code>DBUS</code>)
  c) GPS drivers directly in application (e.g. <code>GarminDev</code> in <code>QLandkarteGT</code>)
# GPS drivers directly in application (e.g. [[pkgdb:garmindev|GarminDev]] in [[pkgdb:qlandkartegt|QLandkarteGT]])
  d) <code>gpsbabel</code> experimental feature to output NMEA data into a named FIFO,
# [[pkgdb:gpsbabel|gpsbabel]] experimental feature to output NMEA data into a named FIFO, which could then be read as a serial NMEA device
    which could then be read as a serial NMEA device


==== gpsd ====
=== gpsd ===


<code>gpsd</code> can gather position fixes from many GPS devices and distributes the
[[pkgdb:gpsd|gpsd]] can gather position fixes from many GPS devices and distributes the
position fixes via a TCP port and an experimental DBUS protocol.
position fixes via a TCP port and an experimental DBUS protocol.


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


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


However, this means we can only use gpsd with USB devices with the buggy
However, this means we can only use gpsd with USB devices with the buggy
<code>garmin-gps</code> kernel driver. That rules out using <code>gpsd</code> to connect to the
<code>garmin-gps</code> kernel driver. That rules out using [[pkgdb:gpsd|gpsd]] to connect to the
GPS device.
GPS device.




==== gypsy ====
=== gypsy ===


<code>gypsy</code> is being toutet as the better <code>gpsd</code> with its many design mistakes fixed.
[[pkgdb:gypsy|gypsy]] is being toutet as the better [[pkgdb:gpsd|gpsd]] with its many design mistakes fixed.


Unfortunately, while I find a lot of discussion on how <code>gypsy</code> is supposedly
Unfortunately, while I find a lot of discussion on how [[pkgdb:gypsy|gypsy]] is supposedly
better than <code>gpsd</code>, I cannot find any hints as to how to actually invoke <code>gypsy</code>,
better than [[pkgdb:gpsd|gpsd]], I cannot find any hints as to how to actually invoke [[pkgdb:gypsy|gypsy]], or which software can actually read its position fixes from <code>DBUS</code>.
or which software can actually read its position fixes from <code>DBUS</code>.


Most of the navigation software (e.g. <code>tangogps</code>) appear to have <code>gpsd</code> TCP options
Most of the navigation software (e.g. [[pkgdb:tangogps|tangogps]]) appear to have [[pkgdb:gpsd|gpsd]] TCP options but no <code>DBUS</code> things.
but no <code>DBUS</code> things.




==== GarminDev in QLandkarteGT ====
=== GarminDev in QLandkarteGT ===


<code>GarminDev</code> accesses the devices directly via the USB interface using <code>libusb</code>,
[[pkgdb:garmindev|GarminDev]] accesses the devices directly via the USB interface using [[pkgdb:libusb|libusb]], and [[pkgdb:qlandkartegt|QLandkarteGT]]'s GUI allows querying the GPS for position fixes directly.
and <code>QLandkarteGT</code>'s GUI allows querying the GPS for position fixes directly.


Unfortunately, the only thing <code>GarminDev</code> is currently able to do on my system is to throw
Unfortunately, the only thing [[pkgdb:garmindev|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.
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
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
more current software versions in the F-11/ CVS branches, nor with current
SVN of <code>GarminDev</code> and <code>QLandkarteGT</code>.
SVN of [[pkgdb:garmindev|GarminDev]] and [[pkgdb:qlandkartegt|QLandkarteGT]].




==== gpsbabel ====
=== gpsbabel ===


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


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


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


The idea coming to mind is to let <code>gpsbable</code> talk to the GPS device and convert the position fixes to standard NMEA sentences, which can then be piped into <code>gpsd</code> and distributed further via TCP:
The idea coming to mind is to let [[pkgdb:gpsbabel|gpsbabel]] talk to the GPS device and convert the position fixes to standard NMEA sentences, which can then be piped into [[pkgdb:gpsd|gpsd]] and distributed further via TCP:


   $ mkfifo fake-gps
   $ mkfifo fake-gps
Line 141: Line 141:


Interestingly, this complicated setup actually works, as verified by running
Interestingly, this complicated setup actually works, as verified by running
<code>merkaartor</code>.
[[pkgdb:merkaartor|merkaartor]].


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


   # semodule -r gpsd
   # semodule -r gpsd
Line 155: Line 154:
   # fixfiles -i gpsd restore
   # 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:
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:


# <code>gpsd</code> should continue to run as <code>gpsd_t</code>, and while we're at it, we could also lock <code>gpsbabel</code> into its own SELinux cage
# [[pkgdb:gpsd|gpsd]] should continue to run as <code>gpsd_t</code>, and while we're at it, we could also lock [[pkgdb:gpsbabel|gpsbabel]] into its own SELinux cage
# This solution is unnecessarily complicated with the two processes involved.
# This solution is unnecessarily complicated with the two processes involved.


=== Use the GPS position fix ===
== Use the GPS position fix ==


TODO
TODO


Software: navit, tangogps, gpsdrive, kismet, josm, QLandkarteGT, merkaartor
Software: [[pkgdb:navit|navit]] ([https://bugzilla.redhat.com/show_bug.cgi?id=485652 review ticket]), [[pkgdb:tangogps|tangogps]], [[pkgdb:gpsdrive|gpsdrive]], [[pkgdb:kismet|kismet]], [[pkgdb:josm|JOSM]], [[pkgdb:qlandkartegt|QLandkarteGT]], [[pkgdb:merkaartor|merkaartor]]


Purposes:
Purposes:
Line 173: Line 172:




=== Conclusion ===
== Conclusion ==


For something which should work more or less automatically, attaching a GPS
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
device to get your position and doing a moving map display or navigation
based on that position still requires an awful lot of work.
based on that position still requires an awful lot of work.
= How programs get their position fixes =
* Unknown fields are empty
* Unsupported relations are marked ''-''
* Supported relations are marked ''✔'' (untested or not working)
* Supported relations which actually work are marked ''✔✔''
{|
! program !! [[pkgdb:garmindev|GarminDev]] !! [[pkgdb:geoclue|geoclue]] !! [[pkgdb:gpsd|gpsd]]/DBUS !! [[pkgdb:gpsd|gpsd]]/TCP !! [[pkgdb:gypsy|gypsy]]/DBUS
|-
| [[pkgdb:geoclue|geoclue]] || - || - || - || ✔ || ✔
|-
| [[pkgdb:gpsdrive|gpsdrive]] || - || - || - || ✔ || -
|-
| [[pkgdb:josm|JOSM]] || - || - || - || ✔ || -
|-
| [[pkgdb:merkaartor|merkaartor]] || - || - || - || ✔✔ || -
|-
| [[pkgdb:navit|navit]] ||  ||  ||  ||  ||
|-
| [[pkgdb:qgis|QGIS]] ||  ||  ||  ||  ||
|-
| [[pkgdb:qtgpsc|qtGPSc]] || - || - || - || ✔ || -
|-
| [[pkgdb:qlandkartegt|QLandkarteGT]] || ✔ || - || - || - || -
|-
| [[pkgdb:tangogps|tangogps]] || - || - || - || ✔ || -
|-
|}

Latest revision as of 15:30, 21 August 2009

In order to get GPS position fixes onto the PC and use them, we need

  1. GPS device(s) attached to the PC
  2. kernel driver for the device
  3. userspace driver for the device
  4. service process distributing position fixes on the computer

This page collects the current facts and proposes a few ideas of how to make things work.

GPS Devices

You can connect a GPS receiver to the PC using several methods: RS232(serial), USB, Bluetooth. RS232 devices will need a more or less manual setup, while the USB and Bluetooth devices can be set up automatically once the proper infrastructure bits are installed.

As an example, I will explain the current situation in Fedora 11 with a Garmin GPS60 connected via USB. I am aware that situation will change significantly with HAL being replaced for Fedora 12, but you need to start somewhere.

CAUTION: If there is a daemon type program continously getting position fixes from a GPS device, it might be difficult/impossible to upload/download waypoints, routes and tracks. This will need to be considered eventually.

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.


How programs get their position fixes

  • Unknown fields are empty
  • Unsupported relations are marked -
  • Supported relations are marked (untested or not working)
  • Supported relations which actually work are marked ✔✔
program GarminDev geoclue gpsd/DBUS gpsd/TCP gypsy/DBUS
geoclue - - -
gpsdrive - - - -
JOSM - - - -
merkaartor - - - ✔✔ -
navit
QGIS
qtGPSc - - - -
QLandkarteGT - - - -
tangogps - - - -