v.out.gpsbabel

[hamish]

Hi,

It would be nice to have a v.out.gpsbabel module which could export grass vector maps as, e.g., GPX waypoints, tracks, and routes.

Perhaps a good approach would be to write & submit to the gpsbabel project a new filter to handle I/O of the GRASS ASCII vector format. That would also help simplify v.in.gpsbabel, which is needed.

Are there any gpsbabel experts in our midst?

thanks, Hamish

[jachym]

IMHO, this can be done via GDAL. GDAL has support for GPX (KML maybe better) output, where gpsbabel is able to read the data and convert them to GPS formats. It is fast enough and does not requiere aditional dependance. Then v.out.gpsbabel would only be wrapper script for v.out.ogr && gpsbabel.

[neteler]

ogr2ogr with GRASS plugin seems to do something for GPX:

ogr2ogr -f "GPX" /tmp/roads.gpx /home/neteler/grassdata/latlong/PERMANENT/vector/roads/head
Warning 1: GRASS warning: GISBASE enviroment variable was not set, using:
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu
ERROR 6: Field of name 'cat' is not supported in GPX schema. Use GPX_USE_EXTENSIONS creation option to allow use of the <extensions> element.
ERROR 6: Field of name 'FNODE_' is not supported in GPX schema. Use GPX_USE_EXTENSIONS creation option to allow use of the <extensions> element.
ERROR 6: Field of name 'TNODE_' is not supported in GPX schema. Use GPX_USE_EXTENSIONS creation option to allow use of the <extensions> element.
ERROR 6: Field of name 'LPOLY_' is not supported in GPX schema. Use GPX_USE_EXTENSIONS creation option to allow use of the <extensions> element.
...

head /tmp/roads.gpx
<?xml version="1.0"?>
<gpx version="1.1" creator="GDAL 1.6.0dev" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/1" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd">
<rte>
  <rtept lat="46.496014615508486" lon="11.787510530727392">
    <ele>0.000000</ele>
  </rtept>
  <rtept lat="46.496068936543473" lon="11.788050878137794">
    <ele>0.000000</ele>
  </rtept>
  <rtept lat="46.496084453543688" lon="11.788152669713275">
...

tail /tmp/roads.gpx
</rte>
<rte>
  <rtept lat="45.836343018280424" lon="11.010669506900909">
    <ele>0.000000</ele>
  </rtept>
  <rtept lat="45.836339313174427" lon="11.010664663523668">
    <ele>0.000000</ele>
  </rtept>
</rte>
</gpx>

I didn't check what GPX_USE_EXTENSIONS does but probably a simple shell/python wrapper to ogr2ogr would do the job.

Markus

[hamish]

Replying to jachym:

IMHO, this can be done via GDAL. GDAL has support for GPX (KML maybe better) output, where gpsbabel is able to read the data and convert them to GPS formats. It is fast enough and does not requiere aditional dependance. Then v.out.gpsbabel would only be wrapper script for v.out.ogr && gpsbabel.

$ ogrinfo --formats | grep -i gpx
  -> "GPX" (read/write)

Great idea. This is pretty obviously the way to go; the (read/write) above hints that it could be a base for rewriting v.in.gpsbabel as well. Currently we parse XML ourselves in a shell script for that.

I feel the same for using GDAL tools to download WMS & tiling for r.in.wms, but there we still need to download and parse XML in python for the feature list.

v.out.gpsbabel is now in SVN, but not activated. I used v.out.ogr, not ogr2ogr.

TODO: check if we are already in ll/WGS84.  If so skip m.proj step.
TODO: multi layer will probably fail badly due to sed 's/^ 1   /'
TODO: v.out.ogr: cat ID is being reported as evelation
TODO: v.out.ogr: fix attribute <extensions>.  ogr2ogr -sql to rename columns? And generally fill in as much metadata as we can manage.

Markus:

ogr2ogr

v.out.ogr can create GPX directly, no need for ogr2ogr.

I didn't check what GPX_USE_EXTENSIONS does

it adds column attributes as <extensions> metadata fields in the GPX file. Unfortunately I can't get it to work. Perhaps column names need to be renamed to "foo_colname" etc, but then what ogr2ogr format to use to avoid the DBF 10 char problem?

Hamish

[hamish]

Perhaps a good approach would be to write & submit to the gpsbabel project a new filter to handle I/O of the GRASS ASCII vector format. That would also help simplify v.in.gpsbabel, which is needed.

I still think that needs to be done.

Hamish

[hamish]

Just to note that v.out.gps[babel] is pretty much ready to go in SVN, it just waits on bug #354 being fixed before activation. (v.out.ogr column number assumptions)

The side project of writing a GRASS vector ascii format i/o filter for gpsbabel waits on a volunteer.

Hamish

[hamish]

v.out.gpsbabel now activated in devbr6 and as v.out.gps in trunk.

Hamish