[GRASS5] Re: polygon cleaning

[Hamish]

[v.clean was very slow on a huge & complicated imported shape file of areas]


On Wed, 11 Feb 2004 Radim Blazek <blazek at itc.it> wrote:
> > > Try somehow find the type of data causing the problem.
> > > Now I have just one idea, because the areas are probably isolated,
> > > it could be that exist one BIG boundary around all the map
> > > (I thing that something like that exists in ArcInfo),
> > > in that case, when this boundary is processed, it selects
> > > lines which could intersect it by bounding box, in that case ALL
> > > lines, and to check intersection of ALL segments of that BIG line
> > > with ALL segments of ALL other lines can take a very long time.
> > > Is it clear explenation?
> >
> > Yes, clear explanation, but not the case.
> 
> Why not? I think it is. Not just one BIG, but many big. The problem is,
> that areas are big, and do not share boundaries, so bounding box of
> one such big area is big and selects many other boundaries.
> 
> 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.

[haven't tried it yet]

Could this also help to speed up the "Breaking Lines" step in v.overlay?

hint for the archive:
Running v.select first (very fast) helps speed up v.overlay (very slow).


Hamish