[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