Specify file names that cause errors without having to specify verbose output

[anbj]

I have a bunch of files that I want to plot, e.g.

for....
do
gmt info -Ib $file | gmt psxy -Ap -Wthick,blue,-
done

Some of these files have problems causing the following errors:

gmtinfo [ERROR]: Mismatch between actual (3) and expected (4) fields near line 27
gmtinfo [ERROR]: Mismatch between actual (0) and expected (3) fields near line 460524
gmtinfo [ERROR]: Mismatch between actual (0) and expected (3) fields near line 284482
gmtinfo [ERROR]: Mismatch between actual (0) and expected (3) fields near line 462867

What about including the file names in these error messages? Adding -Vd should not be necessary in these cases - of course you would want to know which files that are bad.

[anbj]

Is it also possible to say to GMT that it should just ignore malformed lines and continue with the rest of the file? A file missing say a z-value in the 3rd column will stop processing of current file and stop/move on to the next.

[anbj]

And more; gmt will only report the first record it encounters with malformed content - there might be many more.

[PaulWessel]

I have added file names in PR #697 but not ready to list every line with problems.

[anbj]

Great - works!
Still think there should be an option to ignore column mismatch (with warning of course) and listing of all lines with column mismatch.

[joa-quim]

Not sure that it applies to this case (though I suspect it does) but the GMT IO is already very complicated, checking to lots of conditions. A bad side effect of it is that it's now quite slow (relatively ofc) and there are people who complains (#587). Adding more conditions adds to this complexity and there are trade offs to be decided.

[anbj]

I see. Is this partly related to #366? I mean, if the input file always have to be in the (well known) GMT/OGR-format, one would not need as many condition tests?

[joa-quim]

Actually, the .gmt files (GMT/OGR format) plus the fact that they are an ascii only format are heavy to parse.
But we don't want to force that input file always have to be in the (well known) GMT/OGR-format. What we want, and will have, is to allow reading directly the OGR vector formats ... which you can already do (warning: proof of concept only) via the Julia wrapper. See #453

[PaulWessel]

Is it OK to close this issue now? We are not going to report every single line for the reasons discussed above, and the GDAL OGR bridge is being worked on separately.

[anbj]

Go for it.

[nschorgh]

> rm gmt.conf 
> gmt makecpt -Chaxby -T0/100/1 >! bd.cpt 
> gmt gmtinfo bd.cpt 
gmtinfo [ERROR]: Mismatch between actual (2) and expected (4) fields near line 161 in file bd.cpt
> gmt --version
6.0.0

[PaulWessel]

gmt info deals with data tables, but bd.cpt is a CPT file; it is not designed to be useful in gmt info.

[nschorgh]

Sorry - Never mind. I use GMT only once every three years, and I always completely forget how it works.