[GRASS-user] Trouble with v.in.ascii (x2) and v.out.ogr

GRASS GRASS user
1

Hi all,

I had issues while triyng to import an ASCII vector file,
that looks like this:

B 240 1
  333967.494 7610503.977
...
  326155.900 7603082.951
  326839.399 7603864.114
  326937.046 7604938.215
  327327.636 7606109.959
  327522.930 7607086.404
  327620.578 7607965.208
  327229.988 7608355.789
  324886.484 7608941.668
  323910.043 7609722.815
  324007.691 7610308.694
  327327.636 7610601.634
  330256.992 7610894.559
  331331.080 7610992.215
  332112.227 7611382.796
  332698.111 7611773.377
  334065.141 7610992.215
  334260.436 7610601.634
1 1

This should be a polygon that limits a very interesting feature.
Also, I didn't manage to, while exporting to shape, have the polygon
filled. (the GRASS polygon fills OK)

Also, I had issues while trying to import an 815k lines ASCII vector file,
that looks like this:

ORGANIZATION: Company
DIGIT DATE: 10/06/2008
DIGIT NAME: Me
MAP NAME: Isopach
MAP DATE: 2008
OTHER INFO: Geodetic Info
MAP THRESH: 100
VERTI:
P 815257 1
287750.911964 7501478.351623 -140.000000
...
353361.492455 7654299.848450 -88.000000
353461.508591 7654299.848450 -88.000000
353561.524727 7654299.848450 -84.000000
353661.540863 7654299.848450 -88.000000
353761.557000 7654299.848450 -88.000000
353861.573136 7654299.848450 -84.000000
353961.589272 7654299.848450 -88.000000
354061.605408 7654299.848450 -88.000000
354161.621544 7654299.848450 -84.000000
1 1

I tried the import with the following command:
v.in.ascii -b in=/path/to/file.ascii
out=alvo1_isocrona fs='\t' y=2 z=3 --o

and got the following:

Maximum input row length: 42
Maximum number of columns: 3
Minimum number of columns: 1
WARNING: Cannot remove directory
        '/u/user/gisdata/Location/PERMANENT/.tmp/soledade/23183.1'
ERROR: y column number > minimum last column number
      (incorrect field separator?)

This file represents a XYZ triplet for each point along a grid over
said interesting feature. Z values meaning the variable of interest =]
The grid is has 100x100m cells and GRASS region resolution is:
nsres: 99.97437069
ewres: 100.01647621

that I have defined previously with
$ g.region res=100 (also, g.region nsres=100 ewres=100 yields the same
region resolution)

When I imported (almost) the same ASCII file with r.in.xyz, somewhere
in the northern part of the raster I got a blank E-W line, that I feel
has something to do with that resolution difference (99.97 vs 100m)

So, what I tried to do was import as vector points to interpolate and
generate a nice raster.
--
Paulo Marcondes = PU1/PU2PIX
-22.915 -42.224 = GG86jc

2

Paulo Marcondes wrote:

I had issues while triyng to import an ASCII vector file,
that looks like this:

B 240 1
  333967.494 7610503.977

....

  334065.141 7610992.215
  334260.436 7610601.634
1 1

This should be a polygon that limits a very interesting
feature.

missing a centroid?

Also, I didn't manage to, while exporting to shape,
have the polygon filled. (the GRASS polygon fills OK)

see example in v.out.ogr help page for areas -> shapefile.

Also, I had issues while trying to import an 815k lines
ASCII vector file,
that looks like this:

ORGANIZATION: Company
DIGIT DATE: 10/06/2008
DIGIT NAME: Me
MAP NAME: Isopach
MAP DATE: 2008
OTHER INFO: Geodetic Info
MAP THRESH: 100
VERTI:
P 815257 1
287750.911964 7501478.351623 -140.000000
...

Not sure, do you need one coordinate per "P"?
if only points, probably better to use "v.in.ascii format=point"
and forget about all the formatting stuff, just give it a flat .csv file.

and got the following:

Maximum input row length: 42
Maximum number of columns: 3
Minimum number of columns: 1
WARNING: Cannot remove directory
       
'/u/user/gisdata/Location/PERMANENT/.tmp/soledade/23183.1'
ERROR: y column number > minimum last column number
      (incorrect field separator?)

you need to use v.in.ascii's "format=standard" if data is given in that form. "standard" format is not the default and should be renamed for GRASS 7 as the name is somewhat misleading.
Did it used to be "format=grass" ?

This file represents a XYZ triplet for each point along a
grid over said interesting feature. Z values meaning the
variable of interest =]
The grid is has 100x100m cells and GRASS region resolution
is:
nsres: 99.97437069
ewres: 100.01647621

that I have defined previously with
$ g.region res=100 (also, g.region nsres=100 ewres=100
yields the same region resolution)

When I imported (almost) the same ASCII file with r.in.xyz,
somewhere in the northern part of the raster I got a blank
E-W line, that I feel has something to do with that resolution
difference (99.97 vs 100m)

probably that is correct, caused by a partial Moiré effect.

adjust the res to be exactly 100 by expanding the bounds of the region with "g.region res=100 -a".

grass uses the grid as cell bounds, not cell centers. so west= is the coord of the left of the leftest cell, and east= is the coord of the right of the rightest cell.
ie 0,0 falls on a grid confluence, not a cell center.

So, what I tried to do was import as vector points to
interpolate and generate a nice raster.

I've had success with that method + r.in.xyz, see
  http://grass.osgeo.org/wiki/Marine_Science#Import_using_GMT
tip: use a "n" map + r.univar to check that your alignment is correct.

Hamish

3

2008/6/18 Hamish <hamish_b@yahoo.com>:

Paulo Marcondes wrote:

I had issues while triyng to import an ASCII vector file,
that looks like this:

B 240 1
  333967.494 7610503.977

....

  334065.141 7610992.215
  334260.436 7610601.634
1 1

This should be a polygon that limits a very interesting
feature.

missing a centroid?

I thought v.build would fix that for me.
So I have do add by hand? Also, where does a centroid goes, I mean,
any point inside the boundary, or some other specific place?

Also, I didn't manage to, while exporting to shape,
have the polygon filled. (the GRASS polygon fills OK)

see example in v.out.ogr help page for areas -> shapefile.

Also, I had issues while trying to import an 815k lines
ASCII vector file,

...

Not sure, do you need one coordinate per "P"?
if only points, probably better to use "v.in.ascii format=point"
and forget about all the formatting stuff, just give it a flat .csv file.

...

you need to use v.in.ascii's "format=standard" if data is given in that form. "standard" format is not the default and should be renamed for GRASS 7 as the name is somewhat misleading.
Did it used to be "format=grass" ?

Left it alone. r.in.xyz works great for my needs.
You are right with regards to the standard format, the name is a bit misleading.

When I imported (almost) the same ASCII file with r.in.xyz,
somewhere in the northern part of the raster I got a blank
E-W line, that I feel has something to do with that resolution
difference (99.97 vs 100m)

probably that is correct, caused by a partial Moiré effect.

adjust the res to be exactly 100 by expanding the bounds of the region with "g.region res=100 -a".

It works!
Raster loaded beautifully.

grass uses the grid as cell bounds, not cell centers. so west= is the coord of the left of the leftest cell, and east= is the coord of the right of the rightest cell.
ie 0,0 falls on a grid confluence, not a cell center.

Good to know. I thought otherwise.

So, what I tried to do was import as vector points to
interpolate and generate a nice raster.

I've had success with that method + r.in.xyz, see
http://grass.osgeo.org/wiki/Marine_Science#Import_using_GMT
tip: use a "n" map + r.univar to check that your alignment is correct.

Cool. Saves a lot of guessing.
--
Paulo Marcondes = PU1/PU2PIX
-22.915 -42.224 = GG86jc

4

> Paulo Marcondes wrote:
>> I had issues while triyng to import an ASCII
>> vector file,

Hamish:

> missing a centroid?

I thought v.build would fix that for me.
So I have do add by hand?

use v.centroids or v.category

Also, where does a centroid goes, I mean, any point inside
the boundary, or some other specific place?

any point inside the boundary.

> you need to use v.in.ascii's
"format=standard" if data is given in that form.

....

You are right with regards to the standard format, the name
is a bit misleading.

descriptions now updated in SVN to be more descriptive.

>> When I imported (almost) the same ASCII file with
>> r.in.xyz, somewhere in the northern part of the raster I
>> got a blank E-W line, that I feel has something to do with
>> that resolution difference (99.97 vs 100m)
>
> probably that is correct, caused by a partial Moiré
> effect.
>
> adjust the res to be exactly 100 by expanding the
> bounds of the region with "g.region res=100 -a".

It works!
Raster loaded beautifully.

cool bananas.

Hamish

5

2008/6/18 Hamish <hamish_b@yahoo.com>:

Paulo Marcondes wrote:

This should be a polygon that limits a very interesting
feature.

missing a centroid?

Also, I didn't manage to, while exporting to shape,
have the polygon filled. (the GRASS polygon fills OK)

see example in v.out.ogr help page for areas -> shapefile.

Aha,

PEBKAC. Usual.

I managed to get the shapefile the way I wanted, but exporting just
areas (in hindsight, I guess that was what you meant).
I was trying 'v.out.ogr ... type=centroid,boundary,area ...' when just
'type=area' did the trick.

Thanks.
--
Paulo Marcondes = PU1/PU2PIX
-22.915 -42.224 = GG86jc