I've been thinking about how to do a real-time GRASS/GPS interface.
General idea is to have a GPS feeding NMEA statements into the laptop's
serial port, and have a program running in the background which parses
the statement, feeds it through PROJ, and appends the result into a
site_lists/gps_track file, as well as replacing the single point in a
site_lists/latest_postion sites file. Lat-Lon, Time, COG, SOG, other GPS
messages would be written to the site's comments. (or even run r.what
for that position and use that in the comment string)
then, d.redraw or d.pan should update the track whenever I update the
monitor.
I suppose you could also have a background process which runs:
g.region sites=latest_postion
d.redraw
every few minutes if you wanted. It could even do a little math so it
only redraws when latest_postion is outside WIND ...
I suppose a 5.1-style GUI could be written to control all this..
Not very clean, but I think it should work.
I've already written the NMEA parser, output to the sites format is
trivial, but I'm not sure about how to go about the serial port daemon
(although I am pretty familiar with RS232 i/o).
Anybody have thoughts or suggestions before I dive into the gpsdrive
code?
I've been thinking about how to do a real-time GRASS/GPS interface.
General idea is to have a GPS feeding NMEA statements into the laptop's
serial port, and have a program running in the background which parses
the statement, feeds it through PROJ, and appends the result into a
site_lists/gps_track file, as well as replacing the single point in a
site_lists/latest_postion sites file. Lat-Lon, Time, COG, SOG, other GPS
messages would be written to the site's comments. (or even run r.what
for that position and use that in the comment string)
then, d.redraw or d.pan should update the track whenever I update the
monitor.
I suppose you could also have a background process which runs:
g.region sites=latest_postion
d.redraw
every few minutes if you wanted. It could even do a little math so it
only redraws when latest_postion is outside WIND ...
I suppose a 5.1-style GUI could be written to control all this..
Not very clean, but I think it should work.
I've already written the NMEA parser, output to the sites format is
trivial, but I'm not sure about how to go about the serial port daemon
(although I am pretty familiar with RS232 i/o).
I have been doing some similar stuff (not directly to grass, I need some
ohter processing first), and found it convenient to make a gpsd client.
This allows the use of a remote GPS, or a local GPS, and allows you to
forget about managing the serial port, and also allows multiple programs
to access the data.
******************************************************************
Please click on http://www.cae.co.za/disclaimer.htm to read our
e-mail disclaimer or send an e-mail to info@cae.co.za for a copy.
******************************************************************
I've been thinking about how to do a real-time GRASS/GPS interface.
General idea is to have a GPS feeding NMEA statements into the laptop's
serial port, and have a program running in the background which parses
the statement, feeds it through PROJ, and appends the result into a
site_lists/gps_track file, as well as replacing the single point in a
site_lists/latest_postion sites file. Lat-Lon, Time, COG, SOG, other GPS
messages would be written to the site's comments. (or even run r.what
for that position and use that in the comment string)
then, d.redraw or d.pan should update the track whenever I update the
monitor.
I suppose you could also have a background process which runs:
g.region sites=latest_postion
d.redraw
every few minutes if you wanted. It could even do a little math so it
only redraws when latest_postion is outside WIND ...
I suppose a 5.1-style GUI could be written to control all this..
Not very clean, but I think it should work.
I've already written the NMEA parser, output to the sites format is
trivial, but I'm not sure about how to go about the serial port daemon
(although I am pretty familiar with RS232 i/o).
Anybody have thoughts or suggestions before I dive into the gpsdrive
code?
I think that what you described (write to site files + d.sites etc.)
can be easily done in few minutes but it is far from optimal solution.
I would suggest PostGIS as data store (as ready for use solution for
simultaneous read/write access) and QGIS as interface.
It would require some simple extension for vector layer in QGIS
(periodically zoom to vector). QGIS can work with both PostGIS
and GRASS data. GRASS can also access PostGIS data.
> I've been thinking about how to do a real-time GRASS/GPS interface.
>
> General idea is to have a GPS feeding NMEA statements into the
> laptop's serial port, and have a program running in the background
> which parses the statement, feeds it through PROJ, and appends the
> result into a site_lists/gps_track file, as well as replacing the
> single point in a site_lists/latest_postion sites file. Lat-Lon,
> Time, COG, SOG, other GPS messages would be written to the site's
> comments. (or even run r.what for that position and use that in the
> comment string)
> ...
> Not very clean, but I think it should work.
...
I think that what you described (write to site files + d.sites etc.)
can be easily done in few minutes but it is far from optimal solution.
It took me more than a few minutes, and yes, it is a far from optimal
solution, but hey, it works! It's just a quick proof of concept bash
script and should be rewritten in C using the GRASS projection & sites
libraries once I figure them out. Feel free to give it a try:
While it should work with any GPS or LORAN C system that can send NMEA
sentences to the serial port, I tested it out with a Garmin 48 handheld.
You'll need to modify the USER_PROJ= line at the top for your particular
dataset, and set the sample frequency as needed (currently 30 seconds).
The "current location" marker will show a time-stamp, and other text such
as underlying raster map values can be displayed as well (currently GPS
altitude).
Needs gpsd, netcat, and cs2cs. (see comments in the script)
I would suggest PostGIS as data store (as ready for use solution for
simultaneous read/write access) and QGIS as interface.
It would require some simple extension for vector layer in QGIS
(periodically zoom to vector). QGIS can work with both PostGIS
and GRASS data. GRASS can also access PostGIS data.
Two thoughts --
As the present sites format is due for retirement, PostGIS or GRASS
5.1(5.7) vector-points format is the preferable long term solution.
On the other hand, I'd think this would be quite useful tool for the
handheld-PDA GRASS people, offering a bit more power than pyGPS does
currently. Has anyone gotten PostGIS or GRASS 5.1(5.7) with its database
needs working on a handheld? Is this an issue? Does QGIS run on
handhelds yet? Does this script+QGIS offer anything over pyGPS?