[GRASS5] Re: [GRASSLIST:5979] speeding up v.in.ogr

Radim Blazek blazek at itc.it
Mon Mar 14 04:52:03 EST 2005


Hamish wrote:
> see:
>  http://grass.itc.it/pipermail/grassuser/2005-March/028119.html
> 
> Radim (3 Mar 2005):
> 
>>>Then the problem is that bounding box of that long boundary
>>>intersects all the islands and v.in.ogr will try to break those
>>>lines which takes long time. It was already discussed here. Try to
>>>modify v.in.ogr so that it writes long boundaries in more shorter
>>>parts.
> 
> 
> 
> Radim (11 Feb 2004):
> 
>>I have got idea. Split boundaries to smaller parts, something like
> 
>   
> for ( line = 1; line <= Vect_get_num_lines ( In ); line++) {
>     type = Vect_read_line ( In, Points, Cats, line);
>     v = 0;
>     while ( v < Points->n_points ) {
>         Vect_reset_line (OPoints);
>         for (i = 0; i < maxvertex && v < Points->n_points ) 
>               Vect_append_point ( OPoints, Points->x[v], Points->y[v], 0);
>         }
>         Vect_write_line (Out, type, Points, Cats);
>     }
> }
> 
> 
>>Could you try it? If it helps, it would be reasonable to add this
>>splitting to v.in.ogr / v.clean.
> 
> 
> I am just working through the same data with v.buffer. Again, very slow.
> 
> where should I put the above code? lib/vector/Vlib/break_lines.c ?
> or in each module, e.g. v.in.ogr? if so then at what point in the
> processing?

In break_lines.c surely not. It should go to v.in.ogr where the boundary 
(GV_BOUNDARY only) is written the first time, i.e. geom.c line 222 and 245.

Radim

> 
> 
> Hamish




More information about the grass-dev mailing list