[GRASS-user] v.in-out quirks

[Shane Litherland]

hi all you GRASSers ;-)
not sure what happened when i first tried to join the mailing list a few
months ago, but i got my user/subscription sorted now :-)

I have been using GRASS for a couple years now, more consistently in the
last 12 months after a steady learning process. So hopefully as I come
across 'things' there's less likelihood it's just me being a silly
novice (less, but not a surety..)

my latest fiddling has been with import of GPS data by a few different
means, and some issues I struck.

my methods:
GPS to .gpx file using GEBABBEL (GUI for gpsbabel);
.gpx file has:
wpt (waypoints co-ords lat-long)
ele (elevation)
name (the name/number I gave each waypoint when I marked them)
cmt (supposedly a comment, it is the date/time)
desc (date/time again)
sym (name of symbol used in gps)

v.in.ogr to import gpx file to GRASS;
using Postgres as database;
specifying just one layer (e.g. waypoints);
... get an error when v.in.ogr tries to create table in postgres -
doesn't like 'desc' as a column name (one of those special db words).
...OK, so I can change the column names with cnames, but then it was
upset by 'time datetime' that corresponded to what should be 'name
varchar' in the .gpx file.
... or change 'desc' to 'description' in the .gpx file- but no, the
error still happens, seems the 'desc' cname is built into the v.in.ogr,
it's not checking any of the cnames with the input file
...but I also note in the output that the columns generated by the
v.in.ogr are way more than I have in the .gpx file, and the column
formats for the first few columns don't all match the formats for the
data they'd 'find' in the .gpx file.
... was wondering how then, I might get to the part of the v.in.ogr
module(?) that has all these columns to edit it...?? I did try in the
cnames, including 'name format' like i'd do when making a table, but
that confused the poor v.in.ogr (showed 'name format format' in the
output and didn't like making a table that way!)
... can check the box to 'not create attribute table' and import it OK
but of course, any waypoint name/info doesn't make it into GRASS /
postgres.
...OK, so v.in.ogr might not be the way to get .gpx stuff into grass
anyway, but i'm trying things out here!

my next approach-
v.in.gpsbabel;
using .gpx format;
... it runs OK, but generates a table with:
cat (added for the db)
x (lat)
y (long)
altitude (elevation)
gmt_date (blank - zero string length when table created)
gmt_time (blank - ditto)
comments (obvious)

when what was in the .gpx file was really

(cat - to be added for the db)
x
y
ele
name
cmt ('comment' actually datetime)
description (also datetime)
sym (name of symbol used in gps)

... so, whilst the v.in.gpsbabel got the waypoints in, it too 'lost' the
name of each waypoint and mucked up the date/time field/format when
populating the table.

I have not tried creating a db table directly (i.e. in postgres) and
then creating vector in GRASS and connecting them, as I figure the only
field i could safely link them on would be the datetime, because cats
generated during vector import probably wouldn't match the cats I made
manually in the table... and if the datetime was mucked up in its format
(e.g. as varchar instead) ... well, I just reckon that option could be
rather messy ;-)

Of course, I seem to have 'missed' the obvious option of directly
importing from the GPS unit to GRASS... well, I tried, but had to go and
figure out how the GPS connected to my computer (in Ubuntu 10.04, the
default connection shown in v.in.garmin of /dev/gps wasn't found)
...after getting fresh batteries for my gps, I tried connecting via:
/dev/usb
/dev/usbmon0 (thru to mon7)
/dev/ttyS0
/dev/USB0
/dev/tty0
usb:
...these 'ideas' from bits I saw in other GUI's and/or on the web, but
to no avail - the receiver did not respond on any of these ports.
I know gpsbabel (gebabbel GUI) connected to the unit with the "usb:"
setting because that's how I made my .gpx file in the first place.

I know of other 'workarounds' e.g. I have (a while ago) run the old
Mapsource in Wine, and then get the waypoints/tracks etc into a format
for GRASS, had also played with gpsman and some other bits. But I'm not
elaborating on those workarounds, at the moment it's more about sharing
my experience on how the more direct options didn't-quite-work ;-)

At the end of all that, I guess if I knew how to edit the v.in.ogr /
v.in.garmin / etc, I could tweak the bits to work..? but (I find this
bemusing still) these are .bin files, so despite them being part of an
open-source software, they are, from my perspective, still 'closed' as
far as being able to know what's going on in there ;-) and i'm not sure
i'm quite skilled enough to play too much with those binary-readers... i
could do something wrong and break things...

That's my 'quirk of the month' session done :-) I hear the sighs of
relief!

As an aside, I've been considering putting in bits for manuals/tutorials
along the way - my use of GRASS is more-or-less from an ecological and
land-management perspective and not in-depth, but OK for e.g.
entry/undergraduate level users... thoughts/contacts welcome on this one
too.

Regards,
Shane.