[GRASS5] Re: [GRASSLIST:6527] Re: problem importing vector

[Hamish]

> >I'm new to GRASS (and to GIS).  I'm having trouble importing a 
> >vector file (using v.in.ogr) of the Everglades coastline in Florida, 
> >USA. The coastline is very irregular with many small islands.  My 
> >machine has been working for three days, appears to be making 
> >progress (e.g., the line number at the bottom of the output shown 
> >below keeps increasing), albeit slowly.  I estimate that it will 
> >take about a week to complete this import.  I'm using Grass 6.0 on 
> >Mac OSX and the output is displayed below.  My specific questions 
> >are:
> >
> >1.  Should I wait a week for this to complete, e.g., is it likely to 
> >successfully complete this import, or is the long time required 
> >indicative of a problem?

In my experience it does get there, but best to start it off before a
long weekend and hope it is done by the time you get back....

This is a known issue.  see this thread:
  http://grass.itc.it/pipermail/grassuser/2005-April/028518.html


> >2.  Is there a faster way of accomplishing this import?

Don't import it! Use the OGR driver (via v.external) to link into the
data without ever doing the import step; it's the cleansing for the
GRASS format which takes a long time.

Lorenzo:
> This is an old problem from grass 5.7. Grass with some shape files 
> (only some) goes to infinite loop in Mac OS X only.

I think it can be finite, just really slow. Is CPU use at 100% or 0%?
Multiple bugs here, need to figure out which one you are seeing :)

I think for the coastline case, it is just slow; depends on the data. 
Long complicated polygons take heaps of time on Linux too.


> Remember: in OS X the time to import a big shape files depends from 
> MHz but it's fast. Your problem is a bug in Grass with some shape 
> files and if you see all this time you Stop the Process of v.in.ogr 
> from Process Viewer (in Utility).

another process management hint: from a terminal window run "top", see
v.in.ogr at the top of the list, hit "r" and renice the v.in.ogr PID (on
the left) to 19. That way the rest of your system will still run at full
speed while v.in.ogr will run at minimum priority in the background and you
can at least get on with other work without it slowing you down.


Hamish


devels:
the following is about as far as I got breaking up the Vect_write_line()
step from Radim's instructions; non-functional as I only know a little of
the vector stuff and none of the OGR stuff, but maybe a wiser someone can
sort it out:


Index: vector/v.in.ogr/geom.c
===================================================================
RCS file: /home/grass/grassrepository/grass51/vector/v.in.ogr/geom.c,v
retrieving revision 1.8
diff -u -r1.8 geom.c
--- vector/v.in.ogr/geom.c      13 Jan 2005 01:48:11 -0000      1.8
+++ vector/v.in.ogr/geom.c      19 Apr 2005 05:24:19 -0000
@@ -146,9 +146,9 @@
 int
 geom(OGRGeometryH hGeom, struct Map_info *Map, int field, int cat, double min_area, int type, int mk_centr)
 {
-    int    i, j, np, nr, ret, otype;
+    int    i, j, np, nr, ret, otype, line, v;
     static int first = 1;
-    static struct line_pnts *Points;
+    static struct line_pnts *Points, *OPoints;
     struct line_pnts **IPoints;
     static struct line_cats *BCats, *Cats ;
     OGRwkbGeometryType eType;
@@ -160,6 +160,7 @@

     if ( first ) {
        Points = Vect_new_line_struct ();
+       OPoints = Vect_new_line_struct ();
        BCats = Vect_new_cats_struct ();
        Cats = Vect_new_cats_struct ();
        first = 0;
@@ -221,6 +222,20 @@
        if ( type & GV_LINE ) otype = GV_LINE; else otype = GV_BOUNDARY;
         Vect_write_line ( Map, otype, Points, BCats);

+#ifdef NOTYET
+/*     for ( line = 1; line <= Vect_get_num_lines ( In ); line++) { */
+       for ( line = 1; line <= nr; line++) {
+/*         type = Vect_read_line ( In, Points, Cats, line); */
+           v = 0;
+           while ( v < Points->n_points ) {
+               Vect_reset_line (OPoints);
+               for (j = 0; j < np && v < Points->n_points )
+                   Vect_append_point ( OPoints, Points->x[v], Points->y[v], 0);
+               Vect_write_line (Map, otype, OPoints, BCats);
+           }
+       }
+#endif
+
        /* Isles */
        IPoints = (struct line_pnts **) G_malloc ( (nr-1) * sizeof (struct line_pnts *) );
         for( i = 1; i < nr; i++ ) {
@@ -244,6 +259,18 @@
            } else {
                if ( type & GV_LINE ) otype = GV_LINE; else otype = GV_BOUNDARY;
                 Vect_write_line ( Map, otype, IPoints[i-1], BCats);
+#ifdef NOTYET
+/*     for ( line = 1; line <= Vect_get_num_lines ( In ); line++) { */
+               for ( line = 1; line <= nr; line++) {
+                   v = 0;
+                   while ( v < IPoints[i-1]->n_points ) {
+                       Vect_reset_line (OPoints);
+                       for (j = 0; j < np && v < Points->n_points )
+                           Vect_append_point ( OPoints, Points->x[v], Points->y[v], 0);
+                       Vect_write_line (Map, otype, OPoints, BCats);
+                   }
+               }
+#endif
            }
         }