[GRASS5] v.in.ascii updates

GRASS GIS GRASS GIS developer
1

--- Hamish <hamish_nospam@yahoo.com> wrote:

Hi,

I'm looking to do some v.in.ascii updates, I thought
I'd trawl for
comments first.. most deal with format=point mode.

Fairly straight forward updates:

+ update to use G_getl2() to make MacOS9 ascii
import work.

+ add skip= option to skip any header lines when
format=point
   (e.g. column headings in cvs file)

+ add a -s flag to write those skipped header lines
to the map's
   meta-data hist file (v.info -h).

Debatable updates:

? skip any line starting with a '#' in input file.
   (could silently ignore data..??)

? skip blank lines in input file.
   (currently extra newlines at EOF break import of
points)

? strip "quotes" from both ends of varchar input.

? rename format=standard to format=grass as
format=point is default,
   so standard mode is non-standard. Confusing! I'll
fix any scripts/.

You can expect me to go ahead and do all these
things if noone objects.

Hamish

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

Also if can puts an indicative for the format to
import the values "columns='variable double f8.2' "
for when it be used with other instruction put excatly
the format that was reading; p.e. "d.vect -c file
display=attr attrcol=variable"

LCA Miguel A. Altamirano del C.
"Los Mexicanos llevamos la fiesta en la garganta"

Tel. 01(232)32 45208

La belleza de la meteorología radica en saber
pronosticarla y no simplemente en estudiarla
      (Miguel A. Altamirano 28-5-00)

_________________________________________________________
Do You Yahoo!?
Información de Estados Unidos y América Latina, en Yahoo! Noticias.
Visítanos en http://noticias.espanol.yahoo.com

2

> I'm looking to do some v.in.ascii updates, I thought
> I'd trawl for comments first.. most deal with format=point mode.

..

> Debatable updates:

..

Also if can puts an indicative for the format to
import the values "columns='variable double f8.2' "
for when it be used with other instruction put excatly
the format that was reading; p.e. "d.vect -c file
display=attr attrcol=variable"

[problem: 'd.vect display=attr attrcol=double' displays .000000 after
every number cluttering the entire screen]

Sorry, can't do that as it is an output rather than an input filter.

The computer just knows how to store text strings and numbers of the
integer and floating point variety. There is some control how the
numbers are stored (eg single/double length, signed/unsigned) but you
don't get to choose how many decimal places are stored in the data file.

You could possibly import your formatted numbers as a text string. [I
don't know if it will let you force varchar type though (in the past it
did not).] But this is wasteful.

The place to do formatting is in the output module, i.e. d.vect.
See 'd.site.labels precision=' in GRASS 5.4 for an example of this in
action.

I had a look at adding this sort of option to GRASS 6's d.vect some time
ago; I ran into trouble as d.vect just gets a text string with
db_convert_column_value_to_string(column, &valstr);

So no chance to reformat in d.vect.

You could change lib/db/dbmi_base/valuefmt.c

db_convert_value_to_string()
[...]
        case DB_C_TYPE_DOUBLE:
            sprintf (buf, "%lf",db_get_value_double(value));

"%lf" to "%g", but I worry this will break other things?
Maybe it is ok, I don't know. Radim would have to answer that.

This works for the d.vect case and the results look good!

man sprintf [%g]:

g,G
The double argument is converted in style f or e (or F or E for G
conversions). The precision specifies the number of significant digits.
If the precision is missing, 6 digits are given; if the precision is
zero, it is treated as 1. Style e is used if the exponent from its
conversion is less than -4 or greater than or equal to the precision.
Trailing zeros are removed from the fractional part of the result; a
decimal point appears only if it is followed by at least one digit.

Developers note:

db_convert_Cstring_to_value()

was missing return type. I've added type 'int', but there seem to be
many other db_() fn's missing type. Is this intended or just MIA?

Hamish

3

> Also if can puts an indicative for the format to
> import the values "columns='variable double f8.2' "
> for when it be used with other instruction put excatly
> the format that was reading; p.e. "d.vect -c file
> display=attr attrcol=variable"

[problem: 'd.vect display=attr attrcol=double' displays .000000 after
every number cluttering the entire screen]

Sorry, can't do that as it is an output rather than an input filter.

..

You could possibly import your formatted numbers as a text string. [I
don't know if it will let you force varchar type though (in the past
it did not).] But this is wasteful.

..

You could change lib/db/dbmi_base/valuefmt.c

db_convert_value_to_string()
[...]
        case DB_C_TYPE_DOUBLE:
            sprintf (buf, "%lf",db_get_value_double(value));

"%lf" to "%g", but I worry this will break other things?
Maybe it is ok, I don't know. Radim would have to answer that.

This works for the d.vect case and the results look good!

.. but when you query a point with d.what.vect, the eastings and
northings columns show up like '2.04269e+06' which is not preferred.

I guess you could make the above case statement use %lf if e+04 to e+07,
else %g for a coordinate friendly version of text formatting.

Hamish

4

Hamish wrote:

You could change lib/db/dbmi_base/valuefmt.c

db_convert_value_to_string()
[...]
        case DB_C_TYPE_DOUBLE:
            sprintf (buf, "%lf",db_get_value_double(value));

"%lf" to "%g", but I worry this will break other things?
Maybe it is ok, I don't know. Radim would have to answer that.

This works for the d.vect case and the results look good!

Yes, %g is better.

Radim