Hamish: > > v.out.ogr can certainly _not_ export to anything that > > gpsbabel supports.
Markus M: > But see > http://gdal.org/ogr/drv_gpsbabel.html hmmm, a most interesting and welcome development. none the less, wrt v.out.gps I'd still argue for a separate, specialized, and easy to use front end (script) for interfacing with field work GPSs. I was not sure for v.in.gps if we should use the v.in.ogr GPX method directly or stay with the earlier gpsbabel grass vector ascii format (grass_write_ascii.style) definition + csv->db.in.ogr method. In the interest of strength through diversity I'm now leaning towards the gpsbabel style- file method. That makes reprojection to/from WGS84 slightly easier than fun with ogr2ogr, and I'd suspect make the operation a bit less lossy, but I suspect we'll only know the answer to the lossiness question after trying both ways. In the past the various v.in.garmin, v.in.gpsbabel, and v.in.ogr(GPX)-only methods all ended with very different levels of metadata/attribute loss, with the oldest of the 3 (v.in.garmin) giving the least loss, in situations where the gps was an old enough garmin for it to work. Hamish _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
