Opened 10 years ago

Last modified 4 years ago

#991 reopened defect

v.out.gpsbabel export fails with layer=2

Reported by: needelsd Owned by: hamish
Priority: normal Milestone: 6.4.6
Component: Vector Version: 6.4.0 RCs
Keywords: GPS GPX export, v.out.gpsbabel, m.proj Cc: needels@…, grass-dev@…, donxfive
CPU: Unspecified Platform: MacOSX

Description

It appears that v.out.gpsbabel fails when used with the layer=2 option.

I am running William Kyngesburye's 6.4RC5-3 on Mac OS X Leopard.

[A] All exports using v.out.gpsbabel generate the following error, even when the exports seem to have worked correctly.

/Applications/GRASS-6.4.app/Contents/MacOS/scripts/m.proj: line 197: [: : integer expression expected

Spearfish example: v.out.gpsbabel -w input=bugsites type=point output=bugsites.gpx

[B] With several exports using layer=2 (including data generated from v.to.points), v.out.gpsbabel fails with the following message (this one is from a WGS84 lat/lon location).

/Applications/GRASS-6.4.app/Contents/MacOS/scripts/m.proj: line 197: [: : integer expression expected ERROR: Error reading categories: [ 2.00000000 1.00000000 0.00000000] ERROR: Error reprojecting data

Spearfish example: v.category input=bugsites output=bugsites_two option=add layer=2 v.out.gpsbabel -w input=bugsites_two type=point output=bugsites_two.gpx

/Applications/GRASS-6.4.app/Contents/MacOS/scripts/m.proj: line 197: [: : integer expression expected ERROR: Error reading categories: [ -109.48867688 0.00000902 0.00000000] ERROR: Error reprojecting data

Change History (11)

comment:1 Changed 10 years ago by martinl

Component: TranslationsVector

comment:2 Changed 10 years ago by hamish

Cc: grass-dev@… added
Keywords: v.out.gpsbabel added
Owner: changed from grass-dev@… to hamish
Status: newassigned

you are automatically cc'd if you report or comment to a ticket

comment:3 Changed 10 years ago by hamish

Keywords: m.proj added

works for me in 6.5svn on linux; I'll try later today on Mac.

I do get this warning, which should be wrong, bugsites has an attribute table.

WARNING: No attribute table found -> using only category numbers as
         attributes

Hamish

comment:4 Changed 10 years ago by hamish

I am running William Kyngesburye's 6.4RC5-3 on Mac OS X Leopard.

I guess m.proj is choking on the 'wc -l'. I'll have to check that the usage & output is the same for OSX/Dawin/BSD.

    # make sure we have at least one line of data
    if [ "`wc -l "$TMPFILE" | cut -f1 -d' '`" -eq 0 ] ; then
       g.message -e "ERROR reading data from stdin"
       exit 1
    fi

Hamish

comment:5 Changed 10 years ago by hamish

Resolution: fixed
Status: assignedclosed

I guess m.proj is choking on the 'wc -l'. I'll have to check that the usage & output is the same for OSX/Dawin/BSD.

yes, that's it.

hopefully fixed in svn with r41371. (and fixed another newly introduced bug too)

Hamish

comment:6 Changed 10 years ago by hamish

Platform: UnspecifiedMacOSX

comment:7 in reply to:  3 Changed 10 years ago by hamish

Replying to hamish:

I do get this warning, which should be wrong, bugsites has an attribute table.

WARNING: No attribute table found -> using only category numbers as
         attributes

(that comes from v.out.ogr)

Hamish

comment:8 Changed 10 years ago by donxfive

Cc: donxfive added

I still get "Error reading categories" with vectors that have layers other than 1.

I'm using GRASS version 6.4.0svn on my Ubuntu laptop (w/ GNU sed version 4.1.5), and I fixed the problem by replacing

sed -e 's/^\([PLBCFKA]\)/#\1/' -e 's/^ 1     /# 1  /'

with

sed -r -e 's/^[PLBCFKA]/#&/' -e 's/^ [1-9]+  /#&/'

on line 253 of the v.out.gpsbabel script. (The problem sed command is also used in v.out.gpsbabel for 6.5-svn, and in v.out.gps for 7.0-svn.)

I've had no problems since I did this, but I'm not sure if it would work for everyone.

comment:9 Changed 10 years ago by hamish

Milestone: 6.4.06.4.1
Resolution: fixed
Status: closedreopened

is the change to the first sed expression just a simplification, or does it contribute to the bug?

comment:10 Changed 10 years ago by donxfive

is the change to the first sed expression just a simplification, or does it contribute to the bug?

The answer is "yes and no:" when I used the plus sign in the second expression, I needed to invoke sed with the "-r" option to get it to work, and that caused sed to choke on the first expression so I changed it.

By the way, I just tried

sed  -e 's/^\([PLBCFKA]\)/#\1/' -e 's/^ [1-9]\+  /#&/'

(ie using sed without the "-r" option, and using "\+" rather than "+" in the second expression), and now the first expression works fine. I think that both the "-r" option and "\+" are specific to GNU sed, so I'm not sure about the portability of my workaround. Maybe something like this would be better:

sed  -e 's/^\([PLBCFKA]\)/#\1/' -e 's/^ [1-9][1-9]*  /#&/'

This works the same as my first workaround, but is probably more portable.

comment:11 Changed 4 years ago by neteler

Milestone: 6.4.16.4.6
Note: See TracTickets for help on using tickets.